Hacker News new | ask | show | jobs
by saurik 774 days ago
Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things. If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.
2 comments

> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.

With software that users install, there's at least the fact that users sort of vet the software they install, and there's a somewhat restricted set of software that is running.

However, even in a fully sandboxed environments like phones we know that users don't read the dozens of permissions that apps require. They just click yes.

However, even when there are attempts at restricting software like Windows UAC and MacOS's security warnings, we know for a fact that users don't read those warning and permission dialogs.

And this is for systems with a rather small restricted set of software.

Web sites are whatever link you click in the browser. There's not even the installation step. They just run. Including any and all advertising networks (all those 11472 partners for your privacy): https://en.wikipedia.org/wiki/Malvertising

> Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things.

Yes, because those native apps have access to a much larger attack surface. (As in, they already have all the permissions they need to do major harm.) Which is why OSes have their own scare screens when installing software, and why there's been some success in educating people that installing random shit they come across on the internet is not necessarily a great idea. (Unless you're installing the 432nd dependency of your CLI npm script. Then it's fine.)

Wouldn't it be great if we had a native app where you didn't have to worry too much about what people install, but could still run arbitrary code hosted anywhere? In the limit, you could make it so a single click—on a piece of text, say—would make it do a network request to pull down the arbitrary code and execute it, with no consent required! You'd just sandbox it so that if it needed to do anything requiring extra capabilities, it'd pop up a consent box. Of course, you'd better make sure it's not popping up too many when doing normal things, because then people would just start automatically agreeing to everything that popped up. And it's not just the number, it's also whether the consent popup describes what is being requested, why, and what harm it could cause, in a way that makes sense to nontechnical users. Which means you probably don't want to use it for things where you can't explain it well enough, since then it'll boil down to "will you allow dji@@fo&suR?JGkgslf.##!14* in order to do the thing that you want to do?"

Of course you will. If it was dangerous, then it wouldn't give me the option, right?

(For the sarcasm impaired, I am describing a web browser.)

> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.

If we were talking hypothetically, I would agree. (And in fact, I do agree that we can't win. At least, not forever and not in all things.) But this isn't hypothetical! This stuff is happening, all the time. And when someone agrees to allow something that can do DMA to main memory and corrupt random bits of data, I have to debug that shit. Or more likely, someone has the great idea to dynamically load a shared library that does Super Secure Antivirus Stuff, which of course the user will agree to, and then I'll have to debug the crashes that result from the buggy thing crapping all over its nest in the browser's main process address space and hooking into things without delegating to any existing hooks. Hey, it worked fine six browser versions ago on the OS version from last year! If that sounds like an unlikely and rare case, then how unlikely is a random bit flip? Because we see ton of crashes from those every day. (Hint: if read-only memory that's supposed to contain code that lives on disk doesn't match what's on disk, then you can't really blame it on buggy code flipping a flag bit on the wrong address.)

</rant>