wow, even stooping as low as to quoting eyeo (the people behind AdBlock Plus), whose business model is to extort money out of you if you don't want to be blocked (their "approved ads" list)
the annoucement of manifest v3 moved me to firefox, glad to see I didn't waste my effort
I've been having a hard time figuring out what Mozilla is really going to do with this. Best I can find [1] is "no immediate plans" to fundamentally break uBlock Origin. That phrasing makes me feel queasy.
If that happens it will be time to hard fork Firefox and abandon Mozilla. They're already teetering without a direction so I doubt they would take the risk unless their overlord presses the issue.
I know a lot of people think Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work by having full access to every tab, iframe, page, etc. What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? This has happened multiple times already with extensions in the past.
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.
> Adblockers currently only work by having full access to every tab, iframe, page, etc. What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies?
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.
Well, sure, but it seems like extensions that download remote code are being explicitly banned by Google per TFA. I can't imagine that they intend that to extend to even non-executable tabular data.
It's an unrealistic expectation that the user is going to do anything other than click "allow" the 273rd time you ask if the extension they installed 5 years ago should be allowed to update.
The only expectation that I expressed is that installing program A on Monday is not automatic consent to automatically downloading and running a different program B on Tuesday, which I think is a wholly realistic one.
It seems you believe that I was indicating that the user should be presented with prompts to update, when I said no such thing.
Precisely. Google essentially introduced this problem themselves with silent updates --- that and perhaps the rest of the software industry that wants to turn everything into a service...
The normalisation of silent change is one of the worst things to have happened to software in the last decade.
It indeed is trying to solve a real problem, but also conveniently breaks effective ad blocking. Doing that is a choice; there are other measures they could've taken to improve privacy to the same level while keeping granular blocking intact.
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.
I'm not sure how easy it would be to implement/ensure that a single function is side-effect-free in an extension given that the rest of the extension needs to be able to use the network and download filter lists.
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.
It doesn't have to be side effect free, it just has to run in an execution environment that cannot exfiltrate data.
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.
> Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work by having full access to every tab, iframe, page, etc.
Indeed, which is exactly why Safari said they moved to this model years ago.
Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place. They are in a war against general computing.
>Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place.
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.
> 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.
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".
>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"?
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.
But thats the whole point. Neither Google V3 nor Safari prevents you from sniffing users traffic and exfiltrating data, all they do is hobble ability to successfully block most ads.
And as a result, Safari has some of the worst adblocking out of any of the major browsers.
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.
AdGuard dev here. Can confirm - it’s not sufficient. But the reason it got less criticism is a little different. Content blocking in Safari was never good, and content blocking API when it just appeared was a move forward. The problem is that it’s been five years and it hasn’t got any viable improvements. Manifest V3 in its current state is already way ahead of Safari. But how good will it be 5 or 10 years from now?
Chrome extension developer here and I can absolutely confirm that this is true.
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.
Yes, I totally agree that Manifest V3 solves some real problems — in the case of many webextensions, I would welcome the ability to manually control which domains the extension can run in.
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.
> 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).
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.
> 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?
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.
> (Not to mention that I trust gorhill not to sell out...)
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.
> we're all using uBlock Origin rather than uBlock
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.
I've said nothing about manifest v3, or that uBlock Origin should not exist. The OP said that they trusted gorhill. I pointed out that gorhill already did exactly this once. It is not a hypothetical.
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?
> 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.
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.
This is what uBlock Origin tells me when I try to visit the ublock.org page: "Found in: uBlock filters – Badware risks".
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.
Well, that seems to be more the result of a personal grudge by gorhill than anything else. He didn't like that ublock.org was soliciting donations. uBlock isn't literally malware or much different from many other ad blockers out there.
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.
It's not a personal grudge, and I am not the one who added that filter in the first place[1], though I did not oppose the filter because I have come across numerous instances of people thinking that ublock.org was related to uBO[2].
Thanks for the clarification, and sorry about the misunderstanding!
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.
Just for accuracy purpose, I never transferred ownership of the extension in the Chrome and Opera stores -- I considered this would be a breach of trust. The extension in Mozilla's AMO was not handled by me at the time.
> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? This has happened multiple times already with extensions in the past.
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.
The Web started mirroring the real world when money got involved. It could have been the way you said, had it only been a place to share information, but it is now primarily a marketplace, and no govt or pvt entity has EVER not regulated or attempted to seize control over marketplaces. In fact, even the pure information sharing part is being increasingly censored under the pretext of "security" and children and so on...
> Chrome is trying to limit use-cases that require full access to every single site you visit
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.
Previously the webRequest API was the only way to do content blocking but now that there's an alternate way to do it they can block extensions still using the old way or gate it behind a special scary warning.
> 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 is no alternative way. You need to manipulate headers to modify CSP. No control over CSP means no way to block js from running altogether (Content-Security-Policy: script-src http: https:), to block web fonts (Content-Security-Policy: font-src *), to block twitch ads (overriding origin and referrer).
Where did you get the idea that "blocking webRequest API" and "extensions being sold" are part of the same problem requiring to be solved by the removal of the blocking ability of the webRequest API?
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:
If I were a product manager at Google working on solving that real problem, I'd ask, "What are the APIs and permissions an ad-blocker needs to be able to function performantly?" And that would typically then involve going to stakeholders, i.e.: people who actually write adblockers, and asking them what they need.
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.
> it seems like it's trying to solve a real problem
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 one hand, no, I don't think this would work, because part of what advanced adblockers like Ublock Origin allow is script insertion into pages and source rewrites when you request HTML pages. There's not a good, simple way I'm aware of to prevent data exfiltration in that kind of environment. Once I have the ability to change a page's source code before the browser loads it, I suspect I can kind of do anything.
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.
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?
The fact that they indicated to increase the rule limit for over a year but haven't done so yet (the beta still has a limit of 30k) doesn't seem like they really have addressed the drawbacks. I wouldn't think increasing that limit would take that much time if it's a pressing issue but maybe I'm missing something.
The limit is still 30k. As is typical with Chrome's devrel (they did the exact same thing with Web Audio multiple times) they tell the web community that they are going to fix problems, and then just don't fix anything and go ahead and ship a bad product. At best shouting about it gets a delay so you have more time to plan for the fact that they're shooting your product or service in the head.
All of the new Audio APIs are abused on a daily basis by ad networks for egregious fingerprinting. Google absolutely doesn't care because they directly profit from it.
My concern is they said that 18 months ago and the limit still appears to be 30,000. I think I'm going to check out the beta and see if that's the case.
Edit: I just tested it and the limit is still 30,000. Here's the error if you're curious:
That limit is just a red herring, they will bump it up at some point as a gesture of good will to drown out voices of valid opposition against the removal of blocking webRequest API. Its the classic Magicians look at my right hand move, while the left one is crushing little bird and pocketing its remains.
Right now (as of ~81) Chrome will load first website from previously saved session without waiting for extensions to initialize - all privacy/blocker extensions are ignored on first page load, "run_at": "document_start" is not obeyed, because loading first website 200ms faster once per daily session is more important than loading adblocker! https://github.com/Tampermonkey/tampermonkey/issues/1083
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.
You still own the computer, you just download Chrome (rather than any of the alts) and give them power.
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).
Only on HackerNews is that considered pretty straightforward. I barely understand what a container is, and I know the BIOS mbr magic number off the top of my head. We should not all have to be Andy Dufresne to escape privacyhell. A bit of a tangent coming here, if you will indulge me.
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
It's interesting to think about, that the two ways to prevent the misuse of your data would either be total privacy or total transparency.
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.
Oh, come on. Anyone who worked with FB ads system as "client" understands the power and price of the data that they collect. This is not conspiracy theory but fact. And I can't imagine the amount of data that browser owner able to collect. I'd guess that even MS knows less about me than Google despite of the fact that I use Windows.
I don't use chrome, and things like this are a big reason why. But, otoh, it is getting harder and harder not to use chrome. I'm seeing more sites that have functionality that only works in chrome. Firefox is falling behind chrome in several areas, and a lot of firefox development seems to just be mimicking chrome.
It's a catch-22. Chrome's marketshare and the power that gives Google is just further entrenching chrome's hold on the market.
We've all been watching with disbelief as Google evolved the narrative around the declarativeWebRequest API, coming up with new angles and changing the goalposts to wear people down as critics have disproved all of Google's reasons for deprecating the blocking capabilities of the webRequest API, and nothing substantial has changed.
It does not matter what any of you think and say to this company.
Google's strategy is to promise they'll look into changes when their feet are next to the fire, and then when everyone forgets they continue the despicable anti-privacy behavior.
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.
There's a good chance that none of those browsers will support the blocking webRequest API in 3 years, and that's because of Google's thumb on the scale. Quitting Chrome solves nothing.
And 1/4 (Safari) already only implements declarative request blocking, and has done that for years while being touted as the alternative for privacy conscious folks.
Last time I looked Google position was:
"Regarding which headers will be allowed, we'll look at the feedback from devs and the current metrics and decide. In general, we want to take a closer look at the security implications of header modification."
There is a clear and obvious path to implementing Manifest V3 in a way that best serves users overall and this path involves working with the uBlock Origin team/gorhill and the concerns they've brought up with the change. Until that happens I refuse to believe any train of thought that this is a user focused change and not a ad revenue focused change. To be clear that it has some benefit to users that can be pointed out does not make the change user focused in the same way putting a solar cellphone charger on a cargo ship doesn't make it environmentally friendly.
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.
There's also the option of just adding declarativeNetRequest. Then 1) uBlock Origin and others keep working un-modified, 2) they could adopt declarativeNetRequest for cases where they're able (say as a pre-filter or if you only use those rules), and 3) blockers that only use declarativeNetRequest can exist.
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.
In part that's an issue with their permission model and how they communicate it, and it's not done well now either. I'm pretty sure that people care at least a little in most cases, but the tradeoffs are far more complex than you can grasp easily so I'm not sure "privacy" is fundamentally a thing that can be provided while allowing anything except almost uselessly restricted extensions.
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.
I think that shows that "just adding declarativeNetRequest" wouldn't really accomplish much? Developers would continue using the old API and users wouldn't hold them accountable because they wouldn't know the difference or what the tradeoffs hard.
Not saying V3 is a perfect or even good solution but just thought the option you suggested doesn't seem like it would work.
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.
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?
The advantage from the users perspective is less scary permission nag screens, and if Google's word is to be believed, improved performance from manifest v3-based adblockers.
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.
Firefox has no incentive to prevent people from blocking ads, and DNS over HTTPS isn't a tool to block users from reconfiguring their own machines. All browsers let you configure your DNS settings still. The thing that DNS over HTTPS prevents is letting whoever is supplying your internet (including your ISP, whatever hotspot you're using on the go, etc) manipulate your DNS. It's not about removing control from the person who owns the machine.
> DNS over HTTPS isn't a tool to block users from reconfiguring their own machines.
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.
I guess you can run your local DNS server and point the browser to that. The local DNS server can do all the filtering you want, and forward the filtered out requests to the outside DNS server.
the doomsday scenario the top-level comment mentioned is if they disabled that option. it's possible but very unlikely because it would make that browser unusable for many corporate networks.
And the application, the browser, is configurable by the user. There's no OS standard for DoH configurability so it can't just rely on the OS for that.
then I'll use a fork that uses old DNS. maintaining a small diff that enables old DNS is easy enough that I could do it myself. much easier than trying to fork out Manifest V3.
I don't buy the safety/security line as the reason to disable the webRequest intercept capability is a bit silly. They still allow extensions to inject arbitrary javascript, which has all the same safety/security issues.
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.
I just wanted to call out the ending of the blog post:
> 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.
You cant be a good privacy/adblocker extension using V3. Want to strip umt tracking parameters from loaded URLs? cant do it under V3. Want to disable JS on a page? cant do under V3. Want to spoof your own User Agent? you know the drill.
Why can't the RedirectByRegEx declarative action be used to "strip umt tracking parameters"? That sounds very much like something you can do with that declarative action type.
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.
The fact that most users don't understand this changes and can not make and informed decision and the fact that the ones who can make a informed decision are so tiny that their voice can easily be dismissed by chromium developers is what is really concerning. I would expect that from Apple or Microsoft, but now I have to expect that from Google too
don't use chrome won't scale. Stop saying that. The only thing that could make Google change would be a YouTube 2.0 that breaks Chrome in a dally basis using dark patterns
144 comments
[ 2.4 ms ] story [ 195 ms ] threadthe 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"
https://www.youtube.com/watch?v=tpDFS-GUytg
What do they have to lose if they don't support M3, or support it partially?
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.
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.
(Disclosure: I work for Google, speaking only for myself)
It seems you believe that I was indicating that the user should be presented with prompts to update, when I said no such thing.
The normalisation of silent change is one of the worst things to have happened to software in the last decade.
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.
Indeed, which is exactly why Safari said they moved to this model years ago.
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.
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.
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...
[2] https://twitter.com/gorhill/status/1035155281729216514
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.
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.
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...
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.
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.
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.
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.
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:
https://imgur.com/a/EmywSUk
[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:
https://imgur.com/a/EmywSUk
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'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).
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
provability
interoperability
reimplementability
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
It's a catch-22. Chrome's marketshare and the power that gives Google is just further entrenching chrome's hold on the market.
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-...
Snippet from rules.json:
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.
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.
$ 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.
> 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.
chrome://flags/#dns-over-https
> managing https connections
wat this mean?
https is meant to be opaque