Hacker News Reader

It is almost a 'stopping problem'. You can send any data by sending GET with data encoded in url path, without any query string. How is any sandbox supposed to detect if you are sending data or really just getting information (like updating adblock list).

The url path shouldn't change on each call, so ask the user to whitelist each request the first time that they are made. Subsequent GET requests to the same endpoint and same params can go through without a prompt.

It's very possible to solve this but not without completely overhauling WebExtensions. It's a relatively bad, old API that has multiple security problems paired with a distribution platform (the Chrome Web Store) that is severely neglected and also poorly designed for dealing with security threats. Fixing this would basically break every existing extension, and Firefox is living proof that doing this (for basically any benefit) is very expensive.

Unfortunately since the Firefox team gave up and just adopted WebExtensions wholesale and Edge is dead, the only vendor that's likely to do anything about this is Apple, which means you only get to benefit from a better extension security model on OS X (and maybe iOS, one day).

The idea you describe of tagging data from sensitive sources and limiting its flow is something that's been done in production software here and there, but never to the extent necessary here. It's commonly used to mitigate SQL injection attacks [https://en.wikipedia.org/wiki/Taint_checking]. Part of the problem is that the real issue here is not whether the data is privileged, the issue is whether the use of the data is permitted. If I install the 'Google Translate' extension it wants access to all my tabs, which is technically correct - if I ask it to translate some text in a gmail tab, it's going to need to access that gmail tab. But that doesn't mean I also want it to harvest all my emails and POST them to a server somewhere. You can say "well, disable POST requests", but how are the translation API calls going to hit the remote server?

Naturally gtranslate isn't going to exfiltrate my emails, but if the translation extension was maintained by a smaller vendor, some state-level actor could buy them overnight no problem.

> Potentially dumb question here, but would it be generally possible to create a permissions system for browser extensions that can distinguish between an extension that is actually sending information based on sensitive sources like page content and browser history and an extension that only sends harmless stuff over the network like e.g. asking for updated ad block lists?

An invasive but effective strategy would be Javascript string/object tagging, where objects and strings derived from identifying API accesses are marked as dirty, and attempting to serialise these into requests or URLs triggers a permissions check. This would also give the option of replacing numbers and strings with junk data if the permission is denied, which seems pretty attractive.

Given the massive scope of a change like this, I don't expect it to happen, but it's nice to think of a world where any website or extension that attempts to exfiltrate data will be noticed by default.

> asking for updated ad block lists

You could only allow GET requests and require the user to whitelist this the first time the extension does it.

Subsequent calls to the same blocklist would go through without a user prompt, but if it suddenly started trying to send your email address or some other param, it would stand out.

A trivial way way to get around that:

Make calls to two seemingly benign requests early on. Now you can send whatever data you want to without triggering another prompt by successively requesting the first resource to indicate a '0' and the second resource to indicate a '1'.

I don’t see why it wouldn’t be possible to make a more granular extension permission system that also has stricter sandboxing. Safari is already going in that direction. The new extension system is more restricted, although I don’t know if there is any granularity to it.

So WebExtensions support this, even dynamic permissions (like on Android). But I've found I've had to push developers to use it because it makes their life a bit harder and it's already a side-project.

The UX for the dynamic permissions and fine-grained permissions is, to be generous, not good. I never saw any expressed desire or commitment from the Chrome team to improve on this which is likely why so many extensions still just request blanket access instead.

Firefox already tells you what things an extension can do /what kind of permissions it has, when you are about to install one. You cannot install one and later turn off those permissions though.

Would this fit what you describe?

The Chrome extension install flow is like this too. The problems are many but a few, briefly, are:

* "What the extension can do" is very poorly specified, using language that casual computer users won't understand

* The granularity of permissions is poor so in some cases one operation requires a seemingly unrelated permission. (Android historically has had this problem too)

* While Google have recently made some steps towards improving this specific issue, per-website permissions are something that WebExtensions barely handle. You can technically put a specific list of domain names in your permissions list, but if a site changes domains or adds a new subdomain your extension won't work until you push an update that requests the new permission... and that update will disable the extension for everyone on the planet until they dig around in the UI to find the permission request warning. The last time I checked Google's new solution for this was to allow the end user to narrow the 'access everything' permission to specific websites, which is... something, I guess.

How would the browser detect an extension that gets access to information that should not get out, then mixes it into a unrecognisable (by the automatic analysis) wad of data that is sent to some server, and actually is decodable by some third party? This is bad. This is what Chrome apparently does with X-Client-Data. For reason that I would relate to Godel's theorem I think detection cannot be done automatically.

Therefore, any access to private information makes any extension tainted somehow.

What about an extension that does not explicitly ask for information? In this post-Meltdown world, private information can be inferred by any program running for a sufficient amount of time. So, any program or extension could be considered tainted.

Also, even a "neutral" feature, for example implementing a faster alternative to HTTP, could exfiltrate data in non-obvious ways, if only via playing with timing.

TL;DR open-source only, code reviewed software is the only hope in sight , but it is currently weak enough to allow channels mentioned in these threads.