That's good to know, but the ransomware criminals probably have the skills, and they definitely have the incentive, to pwn that site.

And the ransomware that can be decrypted with this site is because of the author's incompetence. It's not hard to write secure ransomware, but they somehow failed very badly. Anyone should be able to easily protect this site.

Because ransomware criminals would probably love to take over that site and start distributing ransomware or other malware from it. And I have no way to judge how well that site's owners have protected it from that sort of attack. When I'm in doubt, I tend to err on the side of caution.

I assume most people reading the website would be those already infected.

The criminals are more likely to take over any other high traffic website and infect computers of clueless people who have never heard of ransomware.

Maybe try lynx?

Not to mention the fact that using Lynx makes you unique enough for it to be a useful tracking indicator.

Or just use VPS when surfing the web.

I used to do this on linux, as I had copies of my windows VM and I would just browse from the windows box on another screen and then work from the linux one on the main screen

Ransomware exists thanks to a fundamental mistake in the Unix (+Windows, +others) model that a process' rights to the filesystem automatically inherit from the user's rights. Imagine if all processes running under the same user shared the same address space!

There is absolutely no reason some random piece of code downloaded from the internet should have access to my home directory, let alone the rest of the filesystem, without my explicit authorization.

The future is macOS sandbox / linux cgroup by default for all processes.

The macOS solution of presenting the user a system-controlled open dialog that then grants access to the selected path outside the container is elegant and not too intrusive.

Taken a step further, it is obvious that CoW filesystems need to be standard and all activity taken by a process should be recorded in snapshots that get coalesced over time. If a rogue process does cause damage it should be possible to roll back just that process' most recent changes to the filesystem.

With dynamic prompts akin to the firewall prompts familiar from Windows/Mac.

'The program "Chrome" wants to create the file "/home/username/.config/chrome/config". Allow "Chrome" to access [just this file / the diretory ~/.config/chrome / the diretory /home/username]'

'WARNING: The program "totally_legit_for_reals" wants to overwrite the file ~/.xinitrc. This is potentially dangerous. Allow access? -> Are you sure?'

'ALERT: the unknown program "xxx" has gained superuser privileges and wants to overwrite a critical system file System32/whatever.dll. This is very dangerous....'

Then again, non techie users usually ignore all those prompts and just click accept.

Just look at the mess that is Android permissions. Almost no one actually checks them or rejects apps that ask for way too much.

I'd still really like a kernel level protection mechanism that requires granting each executable the capabilities it requests, with dynamic pin the Linux world there are SELinux, AppArmor grsecurity, which are often cumbersome to use).

I think there are a number of implementations of such things, but none mainstream enough.

Hell, I'm a technical user and after a couple of days running Comodo firewall (which does prompt in a similar way to your examples) I turned it off because I was sick of the prompts and just wanted to use my machine.

I recall that's how it worked under windows 95/98 (and the older OS).

However, everything up to, but not including, Windows 2000 (and its predecessor Windows NT) suffers from ALL local users having effectively admin rights on the machines. Not only that the OS doesn't support user permissions, also the underlying file system FAT32 does not store UID/GID or anything, except the file flags "read only"/"system"/"hidden".

Only Windows NT and above (2000, XP, Vista, 7, 8, 10) are secured in this way. Caveat: NT, 2k and XP allowed installations on FAT32, which nullified many protections.