Hacker News Reader

Comment by kylec | Hacker News Reader

At this point, browsers should block all plugins not explicitly installed through the browser. I can't think of any circumstances in which I would be happy to find that some software I installed has automatically installed a browser plugin.

View on HN

Chrome, to its credit, doesn't automatically load extensions that are installed this way. (Or at least it shouldn't; I've seen enough malicious Chrome extensions in my tech support years that I suspect there's a way to bypass this prompt.) That doesn't excuse the practice though; no software update should install additional features without the user's consent, and this is a practice that seems to be all too common in the industry.

It's pretty easy to open up a webpage that says "install this extension to finish installation" or update or what have you. Simple fact is, most computer users are not very tech savvy and will trust what their computers tell them if it looks official enough - especially if it's from a major player like Adobe.

I'd presented a short talk on bypassing the prompts in both Chrome and Firefox a few years ago (2013), and it was possible by just recreating the appropriate registry entries for Windows and few changes in preferences.json.

Was slightly easier for Firefox (few entries in SQLite, iirc). However both browsers lock the data stored, so you had to force a restart as well.

How could a browser protect itself from being "infected" from the underlying OS layer? Given that the malicious installer has administrative access, it's a hole new set of challenges if they can't trust their own filesystem.

It really can't, at the end of the day, which was the major point raised during the QA. Also, you don't need Admin rights, seeing as Chrome installation works without admin rights, and all user data is maintained on a user-directory structure.

Which is why chrome is moving toward a policy of only allowing web store extensions, end of story.

It sucks, and nobody is happy with it, but at the end of the day it's the only thing that seems to be working.

I expect to see these same companies try ever more fragile and bad methods to bypass these restrictions. If chrome refuses to load extensions from disk, they'll inject themselves into the process address space somewhere, which as a bonus will likely introduce sandbox escape vulnerabilities. This is what the AV vendors are doing these days.

They already try to do that. Hell some have even gone as far as to remove chrome, and install their own "infected" chromium compiled with their extension whitelisted and updates disabled.

It's terrifying. And while you could make a case for this "not being chrome's problem", the fact is that it's really hurting their user base, so they can't not do something about it.

AIUI, many of the top crashes of Chrome are from code injected into the address space (or rewriting the binary on disk). So yeah, it is hurting their user base and as a result it is hurting them.

The problem is how do you distinguish plugins installed through the browser versus not: at the end of the day, this falls into the typical DRM problem of how do you enforce restrictions (in this case, what can install plugins).

The direction browsers are all taking is requiring them to be signed by the browser vendor, effectively making them gatekeepers (and you can't have a preference to disable it, because if you did you could just install a plugin by disabling the preference (i.e., edit the config file) and then install the plugin normally). That really sucks too, sadly.

The alternative to DRM would be OS level sandboxing of applications, and particularly their installs. There are a multitude of benefits that would come from that.

Reply on news.ycombinator.com