Manifest V3 now available on M88 Beta
blog.chromium.org
blog.chromium.org
The 'making extensions safer for everyone' Manifest V3 keeps the ability to spy on all traffic, but removes ability to modify headers/block requests. Killing Blocking (blocking = synchronous meaning wont complete until extension decides what to do with it) webRequest API means no more:
-intelligent/dynamic blockers
-User Agent modifications
-modifying CSP rules to disable javascript/web fonts etc
Google is removing control from users hands, from the code users want to run. This is one of the steps in a battle against general computing. https://boingboing.net/2012/01/10/lockdown.html You no longer own a computer, you own a Google Web Appliance.
It does not matter what any of you think and say to this company.
What you have to do now is organize.
The undisclosed X-Client-Data telemetry, the adblocker-busting Manifest V3 and the new APIs that are used almost exclusively for ad network fingerprinting (AudioContext and others).
Chrome is the DoubleClick browser and now that market share is so strong the facade can lift.
https://www.ghacks.net/2020/10/15/microsoft-begins-manifest-...
It's Google that are breaking the internet for people, and getting away with it because of their market share. I've not used Chrome for ages and use Edge only where things don't work (like Google Photos).
It's a catch-22. Chrome's marketshare and the power that gives Google is just further entrenching chrome's hold on the market.
The battle for privacy is lost on so many fronts; I do not believe it can be won, any longer. Even the language used by proponents for privacy shows this. What Google and others represent is not the opposite of privacy, that would be transparency. I've never heard Google's (nor Facebook's) practices designated as transparency friendly. Perhaps there is a good word for it, but as an ESL person, I've at least never heard of it.
As programmers we should know all about the benefit that proper naming provides. And things should be called by their proper name.
I am not for privacy, I have nothing to hide. Rather, I am against the exploitation of data I generate. So this comment can be taken as either a call to arms and naming the enemy, or as a statement of my ignorance of the queen's own english :p
I was mostly joking, since I can't imagine anyone buying a Google Chromebook in an attempt to avoid Google. But, for the sake of argument, I do think it's genuinely straightforward.
The internal details are slightly complicated, but from a user's perspective, all you have to do is press one button from inside settings, open a terminal, and type "sudo apt install firefox".
That's not as easy as downloading a setup.exe file, but I think it's pretty straightforward. ChromeOS will even associate URLs with Firefox, if you choose. Then, even if you open Chrome, it will redirect all links back into Firefox.
Just a small technical tangent of my own. :D
do you really think your "data" is valuable? or was this just an idea put in your head by journalists?
ponder that for a moment
provability
interoperability
reimplementability
Snippet from rules.json:
{
"id": 1,
"priority": 1,
"action": { "type": "block" },
"condition": {"urlFilter": "google.com", "resourceTypes": ["main_frame"] }
},
{
"id": 11,
"priority": 1,
"action": {
"type": "modifyHeaders",
"responseHeaders": [
{ "header": "h1", "operation": "set", "value": "v4" },
{ "header": "h2", "operation": "append", "value": "v5" },
{ "header": "h3", "operation": "append", "value": "v6" }
]
},
"condition": { "urlFilter": "headers.com/12345", "resourceTypes": ["main_frame"] }
},tldr: CSP modification was strictly forbidden. Digging in further it seems this changed somewhere in 2020 and appears to be working now https://bugs.chromium.org/p/chromium/issues/detail?id=111648...
It'd be a different discussion if this was presented as an ad revenue focused change but it's presented as if it's user focus and the community is driving the direction of how it's implemented. Clearly this is not the case, in a conveniently true way, and it'd be such a simple thing to clear up. Even if the uBlock Origin team ends up saying "hmm, we really all got together and thought about it and there was nothing else to change that couldn't impact user privacy significantly" at least it removes the divide and controversy.
Throwing references from companies with shady practices that exclude Google ads from their blocking does nothing to show a willingness to work with developers on what's best for users, in fact it makes the situation look even more shady.
I don't know if gorhill reads HN but on the off chance he does thank you for your work.
Let them all compete on performance-vs-features-vs-privacy. There's nothing about introducing a new API that requires removing an older one - this is a political change, not a technical one. It's hard to see it as anything but ad-revenue motivated.
So: mostly no, nor do I expect it to improve with manifest v3. Tracking/malicious extensions will just continue to request access to `*` and send their info via some other means, and users will continue to install them. This doesn't stop that or really change it at all.
Not saying V3 is a perfect or even good solution but just thought the option you suggested doesn't seem like it would work.
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.
[1]: https://blog.chromium.org/2019/06/web-request-and-declarativ...
That seems to me like it is more than enough opportunity for v3-based blockers to compete with v2-based blockers if they really are better for the user as Google claims. Meanwhile v2-based blockers can continue to compete based on their increased capabilities compared to v3-based blockers, and uses can decide what their own needs are.
It seems to me like Chrome is trying to limit use-cases that require full access to every single site you visit. How will Firefox solve this problem better than Chrome or Safari? It seems inevitable that the status quo for these extensions is going away.
For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it.
More manual reviewing of valuable extensions would also be a path. They don't need to allow all extensions this permissions, and there doesn't need to be a level playing field for extensions here. It's just that Google doesn't see effective ad blocking as valuable, but rather the opposite.
Safari went with an even more restrictive solution for content blockers and it seems like at least Chrome has been working with various developers to iron out the kinks with their solution before it goes live.
Make it into a special kind of "content script", that gets a blank javascript environment that does not have any of of the usual means to communicate with the outside world (no XHR, no access to any DOM, no access to any message passing, and so on).
E.g. a browser could have a special kind of "content blocker" script environment that gets fed request objects by the browser. The script can then examine all the data in the request object (the requested URL, the headers, etc) and make a decision to DENY or ALLOW and communicate this decision back to the browser in a single well-define way, and that's the only communication to the outside world it is allowed to do. No way for it to exfiltrate data. Extensions can be allowed to pass data into the environment via some form of uni-directional message passing, e.g. to update filter rules, but the content script cannot respond (and thus cannot exfiltrate data in a response).
Browsers already define different execution environments with different APIs available in them for different purposes, e.g. you have the same-origin limited environments for websites that feature Web APIs such as DOM and XHR, and those environments come in different flavors (no access to certain APIs such as the location API if you're not "secure"), Proxy-Auto-Configuration (PAC) scripts have yet another environment, extension scripts get yet another environment, extension content scripts yet another, internal browser pages such as the settings pages of browsers often get environments with access to some privileged APIs etc. To define a few more specialized environments for privacy-sensitive stuff shouldn't be too hard.
I might actually start doing this now that I considered how much access I'm giving to uBlock Origin.
That argument is always made and every single time there needs to be a reminder that:
The webRequest API -- used to observe all network requests -- will still be available, it just won't be able to be used to block or redirect network requests, but still can be used to observe all outgoing network requests and all incoming response headers.
Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering.
So essentially content blockers such as the current crop of top content blockers will still need to see all the sites visited by users in order to meet what users expect from their blocker.
> Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering.
My OP was talking about a very real problem where extensions are being sold and nefariously used to sniff credentials because they have full control over the tab execution environment. How do you propose to solve that problem while still allowing adblocking?
There are good examples out there of extensions exfiltrating browsing information and which didn't required a blocking webRequest to gather such information, and they were not content blockers.
I am not the only person having an issue with the deprecation of the blocking ability in MV3, see this EFF article:
https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...
People aren't mad that the Chromium team is trying to solve a real problem, they're mad that the Chromium team is utterly failing to solve that problem, and introducing new problems in the process.
Under Manifest V3, requests can still be monitored, they just can't be modified. So this isn't really helping with spying.
And even if the change did help with spying, adblockers help with spying. Firefox will solve this problem better than Chrome or Safari by hopefully balancing the relative privacy risks from extensions and from ads and not by making clumsy fixes that introduce additional problems.
We all recognize that extension security is an issue. The question is how to make things more secure without introducing additional privacy risks by weakening adblockers. If adblockers legitimately need full access to the page in order to work effectively, we can't just stick our fingers in our ears and pretend that they don't need that access. We can't just pretend that declarative blocking is good enough just because it would be more convenient for us if it was good enough.
I would welcome a security model that made adblockers safer without making them less effective. Does anyone have one to propose? Because I don't want a half-baked solution implemented in my browser just because "we have to do something" -- and that's what I think Manifest V3 is.
> For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it.
On the other hand, that proposal would make it at least marginally harder for malicious scripts to go undetected, and it's at least as much (if not more) of an improvement to privacy than the system Manifest V3 is going with, given that V3 doesn't prevent request monitoring, network requests from extensions, or script injection into the page. And there are probably ways to implement what you're talking about without breaking a huge number of extensions.
So I don't think that's a solution, but it's significantly better than what Manifest V3 is trying to do.
That is very, very obviously not what happened. And any attempt to spin this as "solving a real problem" ignores that Google employs tens of thousands of professionals who are trained to follow the approach above in response to solving problems. This is a business decision and the stakeholders aren't ad-blockers, they're ad networks.
This idea that we need to keep locking down markets because one day things go bad is really really not good. We should not deny ourselves software because there are bad usages of it.
These fear-inducing scenarios are all bad because they are low information marketplaces. The consumer has no idea what extensions really do, they don't see when major changes happen to the software they use, they don't see ownership changes, they don't see what data is gathered, they don't see where data goes. And yes, we can't expect consumers to watch & attend all of these things. Which is why it's important consumers be able to rely on each other, to have some way to signal danger & emergencies to one another.
Instead of trying to create a marketplace where information & understanding can flow, instead of allowing genuine competition based on markets, we continue building markets assuming every buyers is & forever will be a totally blind idiot with no help, no friends, no other voices to help them make their decisions.
I'm so fired of Fear Uncertainty and Doubt. The security apparatchik of the web today terrifies me. Deny deny deny. Close down close down close down. Severe connections, pull up the draw bridges, flood the moats, send out the alligators. I tire of these defensive wars, I tire of giving up ground, because the web has some pretense of being a perfectly secure place. I would much rather us be intertwingled, allow bold exploration of systems, mingling together, & while doing that figure out ways forward that permit some risk.
Extensions are the most vital & powerful capability on the web. They are what make it better than everything else. Keeping the user sovereign, giving them amazing mind blowingly powerful extensions, is how the web keeps from becoming just another app. Those great powers can be abused. But we need to find ways to permit these powers to exist anyways.
Perhaps installing something (A) on Monday should not give the developer/publisher the right or ability to arbitrarily exec B on your machine on Tuesday.
No-interaction updates are the problem here. They amount to a remote code exec vulnerability, exploited just as you describe.
The normalisation of silent change is one of the worst things to have happened to software in the last decade.
It seems you believe that I was indicating that the user should be presented with prompts to update, when I said no such thing.
(Disclosure: I work for Google, speaking only for myself)
The last few years they've gotten more and more strict about which permissions they hand out.
The one I need is similar to ad blocking and every time I request ANYTHING new they're very strict about explaining why I need it.
Our extension Allows you to convert pages from HTML to EPUB and for this I need the ability to fetch any arbitrary image and read the data and that's not actually possible from Javascript due to CORS.
The turnaround time for each approval is also increased and it takes about 72 hours for us to get approval for every change right now.
Our extension if you're interested:
https://chrome.google.com/webstore/detail/save-to-polar/jkfd...
However, the move to Manifest V3 also involves curtailing the power of extensions, including those that I trust as much or more than the browser itself. I want uBlock origin to be able to intercept and filter requests according to the logic that gorhill deems most sensible rather than however Chromium wants it to be done, since I trust gorhill far more than Google (and possibly slightly more than even Mozilla). I don't think that any of the tiny extensions that I've written to scratch my own itch require any of the capabilities removed in Manifest V3, but if they did, I'd also want them to keep having them.
So what happens if gorhill's account is hacked or he gets tired of working on the extension and sells it to the highest bidder? These are not theoretical problems, they've happened multiple times in the past.
I'm not saying Manifest V3 is the perfect solution but these are very real problems that cause me to not install any extensions that can access all sites.
Approximately the same as would happen if the developer of a traditional Windows* application were hacked or sold out, except less serious, since they wouldn't have access to the underlying filesystem. It's not a non-existent risk, but it is a trade-off I and many other people want to be able to make. uBlock Origin being FOSS and popular considerably mitigates the risks. (Not to mention that I trust gorhill not to sell out...)
* or Linux (except that in Linux most software is distributed via repositories, which lessens the risks, somewhat; OTOH uBlock origin is also available via the repositories, for instance on Debian[0] and Ubuntu[1]). I'm not sure about sandboxing on MacOS.
[0] https://packages.debian.org/stretch/webext-ublock-origin
[1] https://packages.ubuntu.com/search?keywords=webext-ublock-or...
Gorhill has already once given the extension away to a person who turned out to be untrustworthy! That fiasco is why we're all using uBlock Origin rather than uBlock, after all. Granted it wasn't for a financial motive, but the outcome was the same.
This says it all. Were any users actually harmed? Where's the harm to justify the destruction of blocking abilities? It's ironic to cite uBlock Origin to try to argue that uBlock Origin should not exist, which is the endgame of Manifest v3.
Any software whatsoever can change hands. Salesforce just bought Slack. Is that an argument to hobble or eliminate Slack? No. Oracle acquired Java. Facebook acquired Instagram. The list is endless, and there's nothing special about extensions here that justifies special treatment or punishment.
That said, it looks like 800k users still have the original uBlock installed. And also, uBlock Origin is blocking ublock.org on the basis of it being malware. Are you saying it's not actually a malware risk, and it's really on Origin's blocklist for some totally unrelated reason?
We don't have to speculate. The reason is right here, and it's not because of malware.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-is-comp...
If it were malware, then why would it still be in the Chrome Web Store? Google reviews every extension update, and also has the power to remove extensions from the store, regardless of Manifest v3.
It's also important to note that Manifest v3 only affects the content blocking capability of extensions. Extensions that are not content blockers still have extremely powerful capabilities that could be abused to capture user data or otherwise do harm. And those extensions can change ownership too. Manifest v3 is not even remotely close to a solution to this general problem.
To repeat: I am not talking about Manifest v3. I was commenting on how ridiculous it is to say that we trust X to not do Y, when X already did Y once before.
To be clear though, gorhill didn't "sell out". He got tired of answering support requests, so he turned the repository over to someone else. To be sure, his trust in that other person was misplaced. But in response, gorhill didn't sit idly by, he forked uBlock into uBlock Origin. All of this was done for free, with no compensation for work.
* * *
[1] https://github.com/uBlockOrigin/uAssets/commit/82067d1ef3370...
My overall point is that policing the Chrome Web Store, which is Google's responsibility, is a separate issue and not necessarily relevant to Manifest v3. If there were a malware extension in the Chrome Web Store today with 800K users, then Google ought to remove it today and doesn't need to wait for Manifest v3 for that. In fact, Google seems to indicate that v2 will continue to be supported for at least a year, so extensions using that API will continue to be in the Chrome Web Store for quite some time.
The whole issue of transfer of ownership of extensions is a red herring as far as Manifest v3 is concerned.
Indeed, which is exactly why Safari said they moved to this model years ago.
Safari gets pulled out fairly often as an example of why declarative APIs are fine for adblocking, but if you actually dig into what the adblocking ecosystem around Safari looks like, it turns out it's a pretty good example of why declarative adblocking isn't good enough. There are tons of hoops to jump through, the best adblockers on Safari are running separate desktop applications to communicate with their extension and bypass some of Apple's more arduous restrictions. Talk to the Adguard devs about whether Safari's API is sufficient on its own to make an effective adblocker.
The only reason why Apple's move got less criticism than Google's is because comparatively not many people use Safari, and most of us don't really care what the extension ecosystem looks like on Safari.
This is about Safari, which is not about preventing you from "running any code Apple didnt sell to you in the first place". It's about security/privacy.
>They are in a war against general computing
Well, general computing has many shortcomings that don't exist in computer as appliance. For some, the latter is better.
I might be misunderstanding you, but isn't this "security/privacy" argument basically "end users can't be trusted when it comes to installing extensions that respect their privacy, so let's get rid of potentially malicious extensions with arbitrary content blocking logic and enforce our single way of content blocking instead"?
Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place".
Yep. Like "speed limiters" in cars. We could also trust car drivers "when it comes to observing the speed limit", but in many cases we don't, do we? And that's a mechanical limit imposed on top of fines for speeding and so on...
"But here they only hurt themselves" is not necessarily true. If you have family private data and they're stolen because you've installed a malicious extension, doesn't it also hurt your family? If your own data are then used to phish your friends, doesn't it also hurts them?
>Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place".
Not really since:
(a) you can run many kinds of code (JS, etc) still in your web browser, can you not? Just not extensions with extra capabilities for sniffing, etc. So "only thinks Apple sold you" is not really accurate.
(b) the core reason is not profit, as the "Apple didn't sell you" part implies.
Is there not a whole chrome extension review process?
That's not a reasonable argument because it could be used to justify the removal of any and all extension APIs.
The solution to that particular problem is to prevent ownership transfer without review, not to cripple powerful addons.
What do you all plan to do?
At the moment I'm using Brave. I like that their position on Manifest v3 has been clear since day one.
Edit: I just tested it and the limit is still 30,000. Here's the error if you're curious:
[0] https://developer.chrome.com/docs/extensions/reference/decla...
[1] https://github.com/chromium/chromium/blob/987f407f2e293f9737...
Edit: I just tested it and the limit is still 30,000. Here's the error if you're curious:
the annoucement of manifest v3 moved me to firefox, glad to see I didn't waste my effort
[1] https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest...
"Rob Wu & Philipp Kewisch - The Future of Content Blockers in Firefox - Adblocker Dev Summit 2020"
What do they have to lose if they don't support M3, or support it partially?
the ad blockers slowly become more and more useless, people stop using them entirely, and google's the biggest winner
Yes it is. Effectively it takes the "machine" out of the equation entirely. DNS resolution happens between the app and the server without you have any say over it at all.
> The Chrome Web Store will start accepting Manifest V3 extensions mid-January when Chrome 88 reaches stable. While there is not an exact date for removing support for Manifest V2 extensions, developers can expect the migration period to last at least a year from when Manifest V3 lands in the stable channel.
This means that we'll have at least a year where Manifest V2 extensions will still work. Hopefully by the end of that period there will be a good selection of Manifest v3 compatible ad blockers.
User agent spoofing also sounds like the sort of thing one could use the SetRequestHeader declarative action for.
As for disabling JavaScript, yeah declarativeWebRequest appears to lack the ability to do that.
$ chromium --user-agent "..."
chrome://flags/#dns-over-https
> managing https connections
wat this mean?
https is meant to be opaque
$ dnf install python3-dnf-plugin-versionlock
$ dnf versionlock add google-chrome-beta
$ dnf versionlock add google-chrome-stable
If you think of an ad blocker like anti-virus, you're basically hobbling any ability to do heuristics, and limiting blocking to a fixed identifier. Getting around this sort of hobbled ad blocker is pretty straightforward, just lots of random domains that change.
Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.
The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.
The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome.
It seems that the publicized drawbacks have been addressed, which drawbacks remains? What could prevent uBlock Origin support?
https://bugs.chromium.org/p/chromium/issues/detail?id=896897...
It's not just about the limit.
1. Why is Stack Overflow trying to start audio? - https://news.ycombinator.com/item?id=20288768
2. Google has heavy cognitive dissonance - https://news.ycombinator.com/item?id=20289380
Then STFU and do it, it's a 30s change. If you haven't done it yet, it's just another lie.