I keep seeing sentences like "MV3 is approaching", "when MV3 drops in x months", but the reality is that MV3 is already here and affecting extensions!<p>New extensions that use MV2 have been prevented from being added to the store since last January [1] and this has already affected some extensions which, as a result, have to be installed manually [2][3]<p>The time to switch to Firefox is right now.<p>[1] <a href="https://developer.chrome.com/docs/extensions/mv2/" rel="nofollow">https://developer.chrome.com/docs/extensions/mv2/</a><p>[2] <a href="https://github.com/libredirect/libredirect/issues/45#issuecomment-1059010144" rel="nofollow">https://github.com/libredirect/libredirect/issues/45#issueco...</a><p>[3] <a href="https://libredirect.github.io/faq.html#chrome_web_store" rel="nofollow">https://libredirect.github.io/faq.html#chrome_web_store</a>
Manifest V2 deprecation is likely going to break extensions that inject userscripts, like Tampermonkey [0] and SurfingKeys [1]. The Chrome team has been rather unhelpful. They've promised to add support for power-user tools like these in MV3:<p>dotproto from the Chrome team commented on May 27 [2]:<p>> @mon-jai, the short answer is no, I don't have any updates to share. That said, I'll reaffirm that we plan to support userscript managers in Maniest V3 before the Manifest V2 deprecation.<p>But the deprecation is approaching and the Chrome team hasn't released any more information about this AFAIK. These extensions are going to require large refactors to support MV3 and they can't meaningfully start until the Chrome team elucidates how script injection will work. With MV2 deprecation coming so soon, I worry there won't be enough time.<p>[0]: Manifest V3: examine the effects · Issue #644 · Tampermonkey/tampermonkey: <a href="https://github.com/Tampermonkey/tampermonkey/issues/644" rel="nofollow">https://github.com/Tampermonkey/tampermonkey/issues/644</a><p>[1]: Migrate to Manifest V3 · Issue #1821 · brookhong/Surfingkeys - <a href="https://github.com/brookhong/Surfingkeys/issues/1821" rel="nofollow">https://github.com/brookhong/Surfingkeys/issues/1821</a><p>[2]: <a href="https://github.com/Tampermonkey/tampermonkey/issues/644#issuecomment-1140110430" rel="nofollow">https://github.com/Tampermonkey/tampermonkey/issues/644#issu...</a>
As a proxy extension developer, this is absolutely maddening. We're forced to choose between auth-less open proxies (bad), or baking in a wacky authentication scheme through a side channel (also bad). MV3 drops in 2.5 months, and will leave tens of millions of proxy extension users unable to use products they paid money for.<p>This is all on top of the many other issues with MV3 that Google is pushing under the guise of "improving performance".
Looks like we caught someone's attention:<p>> I'm temporarily restricting comments to keep comments from turning into +1s while this is trending on Hacker News. If you have additional thoughts that you'd like to share with the Chromium team regarding this issue, please return in a few days to leave a comment (and apologies for the inconvenience).<p>> As a Chromium contributor that shares information about our progress on extensions issues, I sincerely apologize to extensions developers affected by this issue and the broader community for not sharing an update until now. I'm currently working on a "known issues" document for Manifest V3 that touches on several outstanding issues (including this one), but given the attention on this issue now, I'll quickly share our current thinking on this issue.<p>> We have always intended to provide support for this functionality in Manifest V3 (for both user-installed and force-installed extensions), and have been iterating on different possible approaches. Our tentative plan (which is not yet finalized) is that the Manifest V3 version of this capability will require extensions to request a new permission scoped to intercepting authentication requests, but will otherwise allow extensions to handle these requests in a similar manner to how they do in Manifest V2.<p>> The permission string and end user facing warning string have not been finalized yet. Also, we have not yet finalized how this new permission will interact with other permission grants, but extensions that currently have the webRequest permission and broad host permissions will likely not require an additional grant for this permission.<p>> Finally, I want to note that before we can pursue this capability, we first need to resolve issue 1024211 (now formally marked as a blocker). We are actively working on 1024211 and aim to resolve both that issue and this one before January 2023.<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1135492#c92" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=113549...</a>
Chromium team has not commented on this bug with 650+ stars (within top 10 <a href="https://bugs.chromium.org/p/chromium/issues/list?sort=-stars&colspec=ID%20Pri%20Type%20Component%20Status%20Summary%20Owner%20Target%20M%20Reporter%20Modified%20Opened%20Stars&q=&can=2" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/list?sort=-stars...</a> issues) in months
Once upon a time many years ago, Chrome was marginally better than Firefox.<p>That time has long since passed.<p>I know, I switched from Firefox to Chrome and used it for a couple of years, but Firefox got better and Chrome got worse, so I've been back on Firefox for many years again now.<p>If Chrome doesn't do what you want or what you like, use Firefox. It does everything Chrome does, and more.
I thought they were pushing it when they announced MV3, which would purposely can ad blockers. But this would finally put the nail to this coffin.<p>Now I'm even more curious to see how badly Chromium bangles this migration to V3.<p>I'm also curious as to why big internet advocacy organizations such as the EFF [0] have been quiet on this move.<p>--<p>Edit: It appears the EFF has spoken out about this a couple of times.<p>[0] <a href="https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation" rel="nofollow">https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-st...</a>
I don't know the full scope of consequences and Google's reasoning for this, but I'm going to guess it's either done under the false pretenses of improving performance, or improving security. Could there possibly be a positive outlook for improving ad revenue as well?<p>Time to settle with Firefox.
2 years without a reply, maybe it's a feature.<p>Could they be afraid of a surge in proxy Adblock extensions since they are trying to cripple the local ones?
Are proxy extensions just a hook to set the http_proxy?<p>I always have a hard time with chrome. because where firefox has a config area to set the proxy chrome wants to use an environment variable. so do these proxy extensions fill this missing config gap?
Last time I tried to use onAuthRequired in Chrome I found that it was already broken in some contexts. I think it's pretty clear that Google is on track to phase out extensions completely within the next decade.
Not trying to throw ML at the wall, but could it be used for this problem (considering all other options seem to be failing)?<p>As far as I understand, after MV3, ad blockers won't be able to use a long list of ads to remove them.<p>How about using a simple ML algorithm to detect whether the request is a genuine one or an advertisement? I am sure that getting training data wouldn't be too hard (all the ad lists that will get useless after MV3 are good data).<p>I don't make chrome extensions so I don't completely know how MV3 will cripple ad blockers.<p>Any feedback would be appreciated!
btw just like there were enterprise-hacks for Windows v7 to keep it going, manifest v2 will still work if users can be taught to turn on "managed mode" in their Chrome<p>extends v2 from January 2023 EOL until June 2023<p><pre><code> January 2023
Chrome stops running Manifest V2 extensions
Enterprise policy can let Manifest V2 extensions run on Chrome deployments within the organization.
June 2023
Manifest V2 extensions no longer function in Chrome even with the use of enterprise policy</code></pre>
The issue seems to be specifically about authentication of proxies. Something I could never find a good extension for in the past.<p>What I ended up doing and found to be better is to connect to the proxy over a wireguard IP. I can recommend this solution to individuals and people who don't need granular authentication.
So.. Chrome is too big to fork. Then why don't we make a bare-bones OSS no-DRM browser with only a subset of JS and CSS and promote at the same time an old-school webring of 'virtous' websites.<p>If it catches on (and it could since it'd be free and <i>fast</i>), maybe some big sites would evolve to advertise themselves as 'virtous'.
Finally, chromium people have spoken <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1135492#c92" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=113549...</a>
Does this mean that (non-open-proxy) VPNs will no longer be usable on a per-Chrome-profile basis? So one would need to either route all traffic through a VPN at the OS level, or none at all?
I don't want to pile on here but everyone who used Chromium while pretending they weren't supporting google's Chrome monopoly, pretending Chromium was something else, are getting the only outcome that was possible. It was entirely predictable from the start and if you play stupid games you win stupid prizes.