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! <a href="https://github.com/Tampermonkey/tampermonkey/issues/1083" rel="nofollow">https://github.com/Tampermonkey/tampermonkey/issues/1083</a><p>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:<p>-intelligent/dynamic blockers<p>-User Agent modifications<p>-modifying CSP rules to disable javascript/web fonts etc<p>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. <a href="https://boingboing.net/2012/01/10/lockdown.html" rel="nofollow">https://boingboing.net/2012/01/10/lockdown.html</a> You no longer own a computer, you own a Google Web Appliance.
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.<p>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.<p>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.<p>I don't know if gorhill reads HN but on the off chance he does thank you for your work.
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.<p>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.
They did stop showing the value at [0] but if [1] is up to date it looks like the limit is still 30,000.<p>What do you all plan to do?<p>At the moment I'm using Brave. I like that their position on Manifest v3 has been clear since day one.<p>Edit: I just tested it and the limit is still 30,000. Here's the error if you're curious:<p><a href="https://imgur.com/a/EmywSUk" rel="nofollow">https://imgur.com/a/EmywSUk</a><p>[0] <a href="https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#property-MAX_NUMBER_OF_RULES" rel="nofollow">https://developer.chrome.com/docs/extensions/reference/decla...</a><p>[1] <a href="https://github.com/chromium/chromium/blob/987f407f2e293f9737f5c9c30a045308fa0590ae/extensions/common/api/declarative_net_request.idl" rel="nofollow">https://github.com/chromium/chromium/blob/987f407f2e293f9737...</a>
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)<p>the annoucement of manifest v3 moved me to firefox, glad to see I didn't waste my effort
I just wanted to call out the ending of the blog post:<p>> 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.<p>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.
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
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.<p>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'm not up to date on the topic but<p><i>Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.<p>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.<p>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.</i><p>It seems that the publicized drawbacks have been addressed, which drawbacks remains? What could prevent uBlock Origin support?