It's important not to forget about drive-by DLL injection when making the "execution is the problem" argument.
Lots of executables on Windows link to DLLs that are not protected by the "KnownDLLs" protection. This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.
I haven't read into the API yet to determine how it protects against this, but it's definitely more nuanced than the argument you're making.
Ugh, my Win32 security knowledge is non-existent, but this sounds horrible. Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed, and nothing in the system partition should be overridable like this. This sounds like a flaw in the OS design.
The real irony of the comments on HN that "it's dead on mobile because Apple won't support it", is iOS is one of the few operating systems where this kind of API is trust worth. I would not expect iOS to give Safari privileges to see any files other data files the Safari process itself created by user interaction, or something on say, a Permission-protected directory (e.g. Photos). Ditto for OSX.
If anything, the API really a selling point for OSX/iOS security architecture, in that it can be made safe.
> Seems to me that nothing marked 'from web' and non-executable should be loadable into a memory segment which can be executed,
Welcome to modern macOS and Safari. It’s a good idea, but puts up a block to third part or open source software. For now you can right-click and override (who knows for how long before Apple wants 30% of the price of all your desktop software too). I’d be more okay with the Mac version if you could add custom chains of trust.
I wouldn't be surprised if Linux had it but I haven't used desktop Linux in a long time so I don't know what to search for, but generally having browsers annotate their file streams isn't an uncommon thing to support for filesystems & browsers.
A decent number of linux filesystems do support extended attributes, which is how I assume you'd do this (actually, looking at https://en.wikipedia.org/wiki/Extended_file_attributes a lot of OSs support xattrs), but I'm not aware of any browsers using them to mark downloads.
> How would you "mark something 'from web'"? This is a file after all.
Files can have metadata, and most modern filesystems provide some kind of file attribute facility. On macOS browsers do exactly what described, setting a file attribute on downloaded files. The user will then be warned when trying to execute the file.
> This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.
Some people install browsers onto a USB drive -- or even run a browser directly from their Downloads directory. Such people are easy targets for this type of thing.
If you look at the way most scammers work, it's even simpler than that. They simply phish people by sending them a link and telling them to run it for some reason (it'll fix their computer, it's a required security update, etc) or they tell them to install something like TeamViewer so they can help them eliminate security flaws, and call center scammers then pillage their box.
I'm amazed the the number of people still forwarding chain letters to me in Facebook, so who knows how many people fall for the "pass this Javascript into your browser console" trick.
It’s funny you say this, because I did exactly this yesterday. I downloaded chromium and forgot I had not yet dragged it to my applications folder and I was running it for a few hours out of my downloads folder.
Google Chrome ships in a DMG, doesn’t it? This means that if it is running out if your downloads folder, it’s not subject to the things that would mess it up because you dragged it there.
Lots of executables on Windows link to DLLs that are not protected by the "KnownDLLs" protection. This means that if you can save a malicious DLL next to that executable you can make a perfectly legitimate executable run malicious code.
I haven't read into the API yet to determine how it protects against this, but it's definitely more nuanced than the argument you're making.