Hacker News Reader

Comment by metastart | Hacker News Reader

Google recently removed several hundred extensions which were found to contain malware. Tons of extensions have been caught saving & selling users' browsing history, notably the ironically titled popular "web of trust".

It's sadly not uncommon for malware hosts to acquire extensions and then use them to inject ads to spread their malware.

The Epic Privacy Browser presciently blocked almost all extensions citing those vulnerabilities and its desire to provide a reliably high level of privacy. It's kept its users safe while Chrome, Brave and other browsers' users were vulnerable.

View on HN

I'm continually surprised that we don't have a clear delineation between extensions that "do" something—maybe relying on well-known third-party SaaS APIs in the process—and extensions that exfiltrate your browsing data.

99% of extensions don't need to send the URL anywhere without the user clicking to activate them; nor do they need to send the whole content of the page to a server, ever.

You know how macOS now has a capability-model for apps, where it sometimes says "X wants Y, and it's been denied it; you can go into System Preferences to manually give it Y"? That tends to neatly fix the "99% of apps don't need Y" problem, by increasing the friction to getting Y to the point that users won't generally bother unless the whole point of the app is Y.

I'd love to see that implemented for browser extensions—or, in fact, for individual tuples of {extension, trigger, data, third-party origin}.

In the sane case, that'd look something like: {Instapaper, on click of the extension's button, current tab's URL, instapaper.com}

It'd be pretty clear, just from looking at one of those entries, whether it's something that contributes to the functionality of the extension or not. Extension authors would undoubtedly write "installation instructions" urging users to enable these; but if the instructions say to enable a stanza like {MalwareExt, on page load, sends everything it can, to badserver.info}... well, even the most guileless user would think twice, no?

The issue is typically that the browser itself doesn't cleanly split those roles.

Take something like Vimium - it's an extension that lets you use keyboard shortcuts to navigate webpages. You could "scope" it's interactions to adding keyboard shortcuts and modifying the page to indicate links: no external calls, etc.

But it could still add a script to the dom (and it would execute) or it could open a hidden iframe and do a bunch of wild stuff with that.

> But it could still add a script to the dom (and it would execute) or it could open a hidden iframe and do a bunch of wild stuff with that.

Maybe right now this stuff is a free-for-all, but shouldn't these scripts + iframes be executing, in some sense, under the CORS origin of the extension? (Not quite CORS in the traditional sense—you do want e.g. Greasemonkey to be able to mess with pages on all domains, even ones that don't want it to—but you could re-use the CORS origin-tracking, and just relax the rules slightly where extension:tab interactions are concerned, while still having rules.)

How would you implement navigating within the page without executing in the context of the page? For example, jump to the next form field requires finding the form fields.

By having chrome build explicit support for this kind of stuff, and creating an API around it.

It seems plausible for Google to inspect its top 500 extensions, and figure out a set of APIs that support all of those needs without giving unlimited read/write/network/execution access to the extension. Just look at how Safari created their own Adblock API thats faster/more memory efficient without giving away URLs to the part of the extension that has network access. This model should be expanded upon.

I can't tell whether you're being serious or sarcastic, but in case it's the former Google has proposed doing this (https://blog.chromium.org/search/label/manifest%20v3) and it's been very unpopular here.

(Disclosure: I work for Google, speaking only for myself)

I'm being serious. It's been a long time since I've developed a Chrome extension so I don't follow them, but it seems to be me that is a good start but there are many areas where Chrome (and other browsers) could go even more fine-grained.

I'm not sure why it's unpopular here (perhaps its implementation vs concept?), but it seems to me that with the realities of malware constantly being distributed through extensions in addition to the obvious privacy issues, that many reasonable people would wish to see this evolution.

Personally I use almost zero browser extensions because of these issues.

It's come up here several times, for example: https://news.ycombinator.com/item?id=20050173

In a nutshell, it's unpopular because it neuters adblockers, and Google doesn't have the reputation of a benevolent actor anymore.

So if that’s true, then they’re not doing as I suggested: take a fine-grained approach to the top 500 extensions (including adblocking) to make it possible to create them without having full read/write dom + networking. I believe the content blocking APIs in Safari are a great start and could be taken so much further.

This might work if Google didn't have ulterior motives here, but would still amount to neutering the browser as a general-purpose computing platform.

Not at all! Webpages can still do as they like. That’s general purpose!

We’re talking about extensions distributed on a store that often end up with malware. I’m not even necessarily advocating for them to remove the ability to anything they wish (yet)... but let the browser catch up to already do what these extensions want in a more secure way. What’s wrong with that?

> Webpages can still do as they like. That’s general purpose!

That's general-purpose for the third party. Not for the user! This is the whole thing the "war on general-purpose computing" is about - whether the software serves the user, or whether it serves its creator and third parties it trusts.

> let the browser catch up to already do what these extensions want in a more secure way. What’s wrong with that?

There's nothing wrong with that per se. I have the problem with the part involving removing user's ability to arbitrarily alter the behavior of a website.

It was unpopular because it didn't examine ad blockers and provide apis that allowed them the functionality they have in a safer way.

It instead proposed a very hobbled alternative.

Yes, when trying to write extensions I found the access requirements much to generic.

I think the back-end should also be reviewed and hosted by a trusted party.

Or make that "reviewable back-end with an option to host it with a trusted party". I also don't mind paying for a review if that improves the quality of the review (for when it is appropriate of course)

Extensions don’t need to auto-update.

Sadly they do because security holes or bugs can be found in extensions, and those can affect third-party websites. Project Zero has found many bugs of that sort and getting them patched on users' machines is very important.

If the extensions' permissions are extremely limited the risk profile becomes low, but that makes them far less useful.

Reply on news.ycombinator.com