If a clever malicious extension can’t inject malware using non-blocking webRequest, I’ll eat my hat. For that matter, injecting malware using declarativeNetRequest doesn’t look particularly hard. I find it very hard to believe that the restriction on, specifically, blocking webRequest is genuinely motivated by security.
If Chrome really wanted a minimal change here to improve security, they might have restricted webRequest to only permit blocking the request but not modifying it.
Most of the work that the Chrome folks have been doing on web extensions recently has specifically been to make finer-grained APIs to do the sorts of things extensions do without giving them full access to edit pages etc.
For instance, see the new "Declarative Net Request" API, which allows you to specify certain transformations on requests in JSON, like blocking them if they match a regex, without knowing what the request is: https://blog.chromium.org/2019/06/web-request-and-declarativ...
In theory, this allows you to implement things like ad blockers without having high levels of access to the user's browsing behavior. In practice, it's very hard to make these APIs complete enough.
But don't they keep the original webRequest api in a way where it does not block and where an extension can observer all the traffice, do all the spying, but just cannot block requests?
I really like the point the uBlock maintainer's make:
"Extensions act on behalf of users, they add capabilities to a user agent, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."
As much as I've defended this change, I agree with you. The only justification I could see is that it might require an extra permission in an extension's manifest, but even that I'm not sure of.
If this is part of a longer-term plan to deprecate webRequest and completely remove that ability, then they should say so now.
Blocked under the supposed reason of privacy, but extensions can still see every request, and inject whatever javascript they want, exfiltrate your data, etc. Meaning the reason is pretty clearly not privacy.
It lets developers opt into a less-sensitive and higher-performance API, losing flexibility as a tradeoff. That seems like a perfectly acceptable reason for an API to exist, and a reasonable tradeoff.
Follow up with big angry warnings about extensions that use the less-safe APIs, and let users choose. As opposed to now, where all permissions are quite calmly displayed. "Half of all malicious extensions use this API, we strongly advise you to look for an alternative"[1] is very different than "x wants permission to modify requests".
The failings of the current permissions system doesn't mean users are incapable of deciding. It means the current system doesn't work for users. Either it's unsolvable for the majority (unlikely IMO), or it's not matching what users need to know to decide. I thoroughly support making better APIs (declarativeNetRequest is plenty useful, and makes decent tradeoffs), but that doesn't have to be at the cost of other things, nor is some "make everything safe" dream the only option.
Not just page content. They can read your cookies, they can see all requests (just not modify them on the fly). The extensions tracking you acting as spyware will see no change, the other kind of malicious extensions that want to modify your requests will still do so by modifying the DOM of pages for example.
So the "security" reasons google gave have long been debunked as non-sense.
The other half is the performance reasons. What's the performance burden of calling a (chain) blocking webRequest listeners? Last time I checked it was single digit milliseconds per request. So a very ad-laden worst-case website with 100 requests will spent maybe 500ms in the webRequest listeners, but will still load faster thanks to all the cruft being blocked away. So what's the win for performance exactly?
>It severely limits how many filters that can exist within the plugin
The limits are 30,000 static rules and 30,000 dynamic rules. Running tens of thousands of regexs for each request can lead to a performance impact. Allowing for even higher limits may result in people having a worse experience from the browser becoming slower. The API was designed such that these limits can be increased in the future as available computation and user needs change over time. Getting extension developers to design their extensions in a way where they have to think about not slowing down the browser too much I think is a good thing and I would not call these current limits severe.
>also prevents plugins from updating block lists themselves
declarativeNetRequest lets rules be added and removed dynamically by the extension.
>forces those updated lists to go through the plugin store
The Chrome team has said that configuration can be updated outside of a store update. What the Chrome web store does not want are extensions that download and run code. This policy does not related to mv3.
This is true. Extensions currently (manifest v2) are able to evaluate net requests dynamically, and are able to modify requests according to a dynamic ruleset that the extension can retrieve from some filter list published on the internet.
Under manifest v3, extensions are not able to dynamically inspect requests, instead, they may only apply rules to net requests. Even worse, there is a limitation of only 5000 rules per extension!! [1]
Even WORSE worse, under Chrome's manifest v3 rules, the extension cannot load any external code! Meaning that blocklists must be packaged with the extension. [2] Now, one might consider the reading of that link to no affect block lists, it's not a "library" and it's not "code" so long as it's just a list of textual rules.... however, google considers the following to be a violation: "Building an interpreter to run complex commands fetched from a remote source, even if those commands are fetched as data". [3]
Sneaky sneaky. An extension update (and hence new app store submission) is required to update filter lists.
In other words, dynamic net requests are banned, and remotely-updated blocklists are banned as well.
Funny thing is: declarative access to websites still allows for plenty of mischief if one wanted to do it. I’ve actually seen malicious extensions abuse that. Browsers might have to revisit the decision to ignore declarative access as far as the permission prompt goes.
I think browser makers don't offer this because any protection put in place would be easy to work around.
For example, even if the extension itself can't make requests, there are plenty of ways to 'trick' a webpage into making a request on your behalf when you have permissions to modify the Dom of the web page.
Yeah, the site-specific blocking seems... mostly dubious, possibly decent as a "this is a banking website - extensions are disabled by default, but you can click to enable them" thing. Right now it looks much more dubious than anything though.
But even in the very best case, it's yet another custom "premium support" feature either way, like the Public Suffix List. They should push for standards instead, these kinds of things are always leaky and sometimes dangerous.
Anyway. I just meant that extensions are not trustworthy just because they're installed. Malicious vectors exist, and protecting people from themselves / them understandably not being an up-to-date expert in all things tech by the millions-to-billions is largely a good thing.
Trying to sandbox an extension that can modify arbitrary webpages in arbitrary ways is near futile.
Just don't let them create script elements, or add any URLs that don't come from within the extension bundle itself. Browsers already have to do a ton of bookkeeping to track the origins of requests anyway. Doesn't seem hard, you just have to be thorough.
This is an oversimplification of the problem. Malicious websites run under a different security model than extensions.
Not to say I am for restricting extensions more, but just to vouch for the idea that there is, in fact, a valid and novel point to treating extensions cautiously versus other kinds of software. Even programs running locally and unsandboxed will have to work quite a bit to compromise a browser.
No, I’m saying modify the source of the extension so that the extension can only make requests to a whitelist of urls. The extension might be able to disable malicious functionality or something, but you can be certain that it’s not making malicious requests.
The reason you don't get it is that taking away the functional part of onBeforeRequest() doesn't really help with privacy. Because extensions can, for example, still inject arbitrary javascript if those permissions are in the manifest.
What it really does is ensure that adblockers can't do heuristics, and instead have to rely solely on semi-static lists of urls. That's a nice outcome if you're a company that makes most of their money from ads.
There's not really a nice way to say that aloud though, so trying to make it sound it's a way of ensuring extensions honor privacy and security sounds better.
Extension stores have a policy of only allowing the use of permissions one really needs, which they have been enforcing with automated scans and manual reviews. Why couldn't they require the use of declarativeNetRequest for extensions that only need those features?
We aren’t talking about breaking out of the sandbox here, the extension sandbox stays intact. The problem is that this sandbox has plenty of privileges. And so Chrome attempts to restrict what code runs in this sandbox.
Technically speaking, they succeed – only the extension’s own code runs inside the sandbox here. But this is a mechanism aimed at preventing security vulnerabilities, not at combating outright malicious extensions. An extension can always download some data guiding its decisions. These extensions take it to the extreme, essentially turning that data into code.
If Chrome really wanted a minimal change here to improve security, they might have restricted webRequest to only permit blocking the request but not modifying it.
reply