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!
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]
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:
dotproto from the Chrome team commented on May 27 [2]:
> @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.
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.
We discussed Chromium's current plan to support user scripts managers in Manifest V3 during our WebExtensions Community Group (WECG) session at TPAC[1] last week. The notes for that meeting haven't been merged yet, but there's an open PR[2] and when they are they will live here[3].
In short, the current plan in Chromium is to require end users and extension authors to opt into execution of arbitrary scripts via a Chromium UI setting and new permission, respectively. During the meeting Firefox folks raised some questions/concerns about this plan and it's probably best to try to align with them on next steps if possible.
And typing this out is making me realize we don't have a great tracking issue for this in the WECG repo. Just threw together a placeholder issue[4] to track discussion in this area.
If chunks of functionality are missing from MV3 with no available alternative, if the replacement is really at such an early stage of development like this, it would be silly not to delay mandatory adoption by another year or two. (Including requiring new extensions to be MV3 - from what I'm reading here, it sounds like you're really not ready for that and should undo it.) Please don't be another https://goomics.net/50/. It's so much worse when it happens externally in an ecosystem.
I appreciate you sharing these resources. I would also like to apologize if my original comment was unfairly critical of the Chrome/Chromium Team. I understand MV2->MV3 is a complex and challenging endeavor. I just hope nobody gets left behind!
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.
This is all on top of the many other issues with MV3 that Google is pushing under the guise of "improving performance".
Oh, I don't know, maybe breaking literally all of their extension with the deprecation of XUL?
I'm a happy firefox user, and I'm pretty sure it was the right choice IMO, as firefox is certainly much more stable and fast now than it was before. But it was certainly a very, very rough process and left some very popular extensions broken without alternatives for months and even years before the necessary APIs were added to webextensions to bring them back.
"Breaking all of their extensions with the depreciation of XUL" is one interpretation, another one is that it was needed (of course it was the correct choice!) and there wasn't going to be an easier approach than just ripping the band-aid off. It needed to be done, it's done, and now instead of discussing the larger picture, we're talking about XUL depreciation from Firefox which happened in 2018. So what's your point?
Google have been doing this for 10+ years and people are only now starting to see it, it seems.
the Microsoft antitrust trial original verdict was reached in 1999 by the way (appeals kept it alive a bit longer, though, into 2001). you are probably referring to the 1990s Microsoft, I imagine.
these days many website don't work in firefox. And the worst thing is you never know it was firefox that was causing problem. Last time I tried to login verizon it didn't work. Same with many website I can't remember on top of my head.
I still can't leave firefox due to multi containers tho :(
I've found that many times when a site doesn't work in Firefox it's actually extensions causing issues rather than Firefox itself. That being said, there are still compatibility issues from time to time!
If you block third party javascript files (e.g. google analytics) other code required for the website to function correctly might fail, since it relies on that third party javascript. So uBlock doesn't block certain javascript files, and instead replaces them by its own version which contains dummy functions that avoid those errors.
Have any of the Chromium forks committed to maintain MV2 into the future? Having functioning extensions while maintaining the other features that people like from the browser could help pull some marketshare from Google Chrome. Probably just dreaming though...
Brave has committed to MV2 but they will need their own store first because the chrome web store is kicking out MV2 extensions. So far, they don’t have their own store.
> We could fork them back in at higher maintenance cost. No point in speculating — I don’t write checks of unknown amount and sign them, and Google looks likely to keep V2 support for a year (thanks be to “enterprise”).
One big thing about MV3 is that background script, persistent or not, is no more. You have a web worker that can start afresh at any point, outside your control. So variables assigned asynchronously outside your event handler (which must be registered synchronously at the top level) scope don’t work reliably.
Could you run an auth-free proxy on localhost that in turn forwards traffic to a remote proxy that does require auth? You could have your intermediate proxy expose a local interface for configuration.
We're also in the space, I don't think we're selling useless products, or falsely advertising.
Our customers use our proxy servers to test applications that use your IP address to show you localized content (IP Location, GeoIP, etc). We're in 80+ countries 250+ locations globally.
Being able to switch your location with a browser plugin makes it just a few clicks, and _much_ faster than switching VPN endpoints. You also get to proxy just your browser traffic (or even just traffic against a few specific domains) rather than all the traffic on your machine. So your Spotify/Slack/Outlook connections can all run normally, and you're only proxying the site you want to test from somewhere else.
This change is terrible for us. Especially so because users flipping around between different proxies is a major use case. A user needing to re-enter their credentials for each unique proxy server is much worse than just once.
Yes of course, but that probably represents less than 10% of the customers (I'm being extremely generous on purpose, it's probably 0.1%) of your usual NordVPN and co.
> don't do false advertising such as Windscribe
"Stop tracking and browse privately" and "block annoying advertisers from stalking you online" proves you wrong. VPNs don't stop trackers.
> don't do false advertising such as Mullvad
"Evade hackers and trackers". Sure.
> don't do false advertising such as iVPN
Hey looks good actually, they indeed don't claim to block trackers or anything else, just change your IP / geolocation.
I'm in the UK, almost all the blocked sites are unblocked just by changing DNS servers. No need to give all your data to a ~middleman~ man in the middle for that.
Authorization and access control are different problems. You can use ssh to create a auth-free SOCKS5 pipe, for example (lots of us do this every day), but that's not an "open proxy" because it's e.g. listening on ::1 or on the internal network interface, etc...
They are usually hosted by malware installed on a vulnerable system. And if they are SOCKS proxies (vs http proxies), then they can send send spam using the IP address of the infected device.
> 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).
> 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.
> 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.
> 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.
> 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.
What's really maddening is that it's the first comment from Google on that issue for over a year, despite numerous pleas of extension developers to provide guidance as the clock is ticking down.
I think this is the real story here.
Google pretends to be listening to real-world use-cases and user feedback and developing Chromium in the open, but at the end of the day, some manager has decided the millions of people using these extensions aren’t worth supporting, and that’s the end of the conversation.
opensource coming from Google, Amazon, Microsoft, OpenAI or even recent garbage coming from RedHat is just a nice facade. It's broken, it's locked to a platform, often no compiling instructions or out of date by 3 years with multiple bug reports. It's just a marketing move that came from Google early 00s' and then was widely adopted by MS: "Microsoft <3 OpenSouce - Contribute Here (for us for free, we can't be bothered to fix this TOP 10 bug or update documentation)".
It's not really any different for Firefox though is it? In fact it's not really any different for any big open source project. Someone ultimately has the power to decide what features to develop and nothing forces them to listen to their users.
Look at things like Firefox's Pocket integration, or like all of Gnome.
Chromium team replied as of 10 minutes ago to that thread (thanks to HN exposure):
"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)."
"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."
"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."
"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."
"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."
Ohh that's nice. So we're gonna get a fix last week of December, and will have to dev around a new API in a few days, test everything, and release it to millions of users hoping for the best.
So, they should also delay blocking of MV 2 if they aren't gonna give time to other developers. But nah, chromium team just wanted to block the comments so they don't get bad PR. Google is such a shame these days.
It's cases such as these invalidate the "they're not acting with malice". Thousands of google employees see this stuff, and are clearly being told they can't talk about it.
Once upon a time many years ago, Chrome was marginally better than Firefox.
That time has long since passed.
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.
If Chrome doesn't do what you want or what you like, use Firefox. It does everything Chrome does, and more.
I like Firefox and am a loyal, long term user - used it before quantum kind of loyal - but it is by far the least efficient browser on macOS with M1. In my rough personal testing Brave (based on chromium) is significantly more energy efficient, getting me up to 30% more battery time. I'm not sure why, but it's making it harder and harder to justify sticking with FF.
Not sure what you are frustrated with (can't read minds), but in my testing, the zoom setting you showed doesn't affect browser chrome, just web pages. Not sure why the rest of your chrome seems oversized, but you may be experiencing a bug. I'd report it.
I just looked at all of those images and I'm not sure what point you're making? The links you shared look about how I would expect them to look at 150% zoom.
Are you saying it has unusual default settings, and that 150% zoom is one of them? For what it's worth in my experience of installing Firefox which are probably done half dozen times in the past year or so on various devices, I haven't experienced anything like this.
I see all of those things, and none of them look unusual. Contrary to your claim, the tab part is not appear oversized but rather a normal size, contrary to your claim the icons also look a normal size, the address bar looks normal size and ublock origin looks the normal size and the settings page looks more or less normal.
It's hard to understand what you think is unusual. Everything in the browser is displayed normally. The page is different because you used a different zoom, and it zoomed the way Page is normally do.
Are you suggesting that the browser tab bar and settings pages should also grow or shrink if you zoom in or out on a particular web page inside of a tab?
I think you're not fully appreciating how unclear you're being with all of this.
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?
OK and presumably it does that by taking a request for an address A and rewriting part of it so that it actually goes to B with some additional headers to indicate how to forward it.
edit: Apparently I've hit my HN rate limit so I can't reply! Thanks Dang.
As for the proxying, obviously something has to rewrite the address that the request is going to. Depending on the type of proxy (ex: HTTP CONNECT) you may also have an x-forwarded-by header set. It sounds like Chrome never allowed you to do this manually, cool TIL.
I mean, you are just completely wrong. It does not rewrite the request. It does not change headers. There is an API that allows the extension to set a proxy server destination:
Are proxy extensions just a hook to set the http_proxy?
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?
I use a HTTP/HTTPS proxy in Chrome (and Firefox) to work remotely and access internal things from my work network. The proxy I use has very nice features to allow "auto switching", meaning based on an regex I can use the proxy or go direct. The rules are ordered any way you want them.
The proxy we all use at work is SwitchyOmega. Been using it for years and it's fantastic.
This type of decision has fully cemented that Google is an advertising company. Every decision they make is to benefit advertisers regardless of how it affects users and developers.
Maybe the entire Manifest V3 concept is "Gish Gallop" applied to software design. Create so much of a bag of questionable features that people are just trying to keep up with the nonsense, and hopefully it keeps us divided and unable to actually able to mount a solid response to their (not really buried) real goal, which is to stab at the ad-blocker industry.
It would be interesting to consider their business values on proxies too; while on the abstract level, it dilutes tracking data quality (I don't really live inside a data centre in Stockholm?!), it might improve the value of their more broadly aggregated data (we've seen this user's fingerprint elsewhere, so we can give you a more accurate location than Geo-IP lookup does)
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)?
As far as I understand, after MV3, ad blockers won't be able to use a long list of ads to remove them.
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).
I don't make chrome extensions so I don't completely know how MV3 will cripple ad blockers.
The point of the change is to go from allowing extensions unfettered access to read, rewrite and exfiltrate everything you request, to forcing them to declare upfront what they will block.
Sure, there are still going to be some work arounds that still allow extensions to read and change what a user sees, but anyone looking at this honestly can see what the intention is.
Throwing ML at this problem doesn't make sense at all as reading and then rewriting requests is exactly what Google doesn't want extensions doing anymore.
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
extends v2 from January 2023 EOL until June 2023
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
The issue seems to be specifically about authentication of proxies. Something I could never find a good extension for in the past.
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.
If it catches on (and it could since it'd be free and fast), maybe some big sites would evolve to advertise themselves as 'virtous'.
I don't get it, Firefox already exists and is a complete OSS reimplementation of everything Chrome does (and works better imo). Only thing to do is convince sites to test more on Firefox. This strategy worked last time around.
I've been using Firefox forever but the problem is - it's now too big. Because it's - like you mention - following Chrome. To stay relevant, FF implements all the bloat Chrome churns out. Even worse, it's tempted to follow Chromes' extension manifest to stay compatible.
So I meant it looks like a lost battle. And it may be better to reboot to a smaller, nifter browser that a small team/community can handle.
edit: and of course cut all ties with Google financing.
Firefox gives up 40-60% of the performance of Chrome on my platform, using common browser benchmarks. I don't see Firefox as a substitute good for Chrome. It has much worse performance, worse security, and lacks features I want. Its performance is equivalent to using Chrome on an 8-year-old CPU. The only thing it has going for it is being perceived as counter-cultural, despite the fact that it is 100% funded by Google.
Your claim is that you suffer a _40 to 60_% performance impact by using Firefox from Chrome? Would you like to try that again? I see egregious comments like this of Firefox every so often and I always have to wonder if the last time people making these remarks actually used Firefox was in the pre-Quantum era (assuming one charitable interpretation). To claim that its performance is equivalent to using Chrome on a CPU from 2013 is disingenuous at best.
Firefox is not just perceived as 'counter-cultural', its importance lies in the fact that not using Chrome and similar browsers is also a vote not to support a browser monoculture online.
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?
You can still authenticate via basic auth popup, but you can’t automate it (UX friendly). There are some workarounds mentioned in the bug comments, but they are workarounds with their own issues.
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.
To be honest, I don’t understand why people keep acting like Google has control over Chrome(ium) with some iron fist. It’s dual open license. Microsoft is contributing so many patches that they have a decent amount of sway over it already. If Google ever truly steps over the line, Microsoft will just fork it and everyone will swap their upstream to Microsoft-Chromium..
> But honestly it already happened, Firefox is already irrelevant.
> Mozilla is mis-managed organization that is funded to avoid anti-trust investigations, they dont fully push for privacy because they are afraid of google, do out of touch changes, and focus on political advocacy.
> Compare that to brave, which builds its own independent search engine, ad network, and has privacy by default in its products.
>There is no hope that Mozilla and Firefox will change the status-quo anytime soon, Firefox is losing users at crazy rate, and Mozilla is absolutely failing to do anything to change Firefox's destiny towards irrelevance.
> Brave is almost everything Mozilla should've been.
> Actually do what they sey, no hidden google analytics in their products, no unique ID for each installer downloaded, push for privacy by default and independence from big tech, not being shy from google, because they are their only income.
> I would argue, that if Mozilla wants to turn its course around with their "limited resources" it should drop gecko, and anything irrelevant to the users experience.
> Fork Chromium, the best web engine out there by a mile, and remove any anti-privacy / anticompetitive code, while still taking advantage of the huge development resources directed to chromium from many parties, and maybe Mozilla can also influence Chromium's development.
> Start pushing privacy by default, its the reason brave is gaining users at such a rapid pace, its a browser I recommend to everyone, as just by installing it they already are much more private than with chrome.
> What matters is the users experience, its why brave is growing
I'm out of the loop. I've been using FF for years without any issues across multiple OSes and devices. I plan to continue doing that. I simply don't understand the negative sentiment I see about it, it's served me very well.
Brave has publicly declared support for Manifest v2 in perpetuity, no? They even seem to be pondering how to distribute v2 extensions post-sunset in Google Chrome[0]
> Brave will support uBO and uMatrix so long as Google doesn’t remove underlying V2 code paths (which seem to be needed for Chrome for enterprise support, so should stay in the Chromium open source). Will Google Chrome Web Store really kick them out over V2? We will host if needed.
> > I’d be interested to hear a plan for Brave on what will happen if upstream removes the code paths needed for pre-v3 ad blockers.
> We could fork them back in at higher maintenance cost. No point in speculating — I don’t write checks of unknown amount and sign them, and Google looks likely to keep V2 support for a year (thanks be to “enterprise”).
Maintaining out-of-tree patches for a project as large and quickly-changing as Chromium will be a lot of work. I know someone who worked on Amazon's Silk browser team and they had an engineer (rotation) working working full-time to keep their Chromium fork up to date within Google's upstream. Brave doesn't have nearly the resources that Amazon does.
Yea you've seen it tried in projects like Waterfox and Palemoon and it eventually becomes too much to deal with. (Following the old Firefox addons system that is)
There are few projects and companies that do exactly that, including CEF open source project. Perhaps they should join forces and make a joint OpenChromium project.
> Someone warned years ago that <insert extremely specific thing>
No, the gp said:
> while pretending they weren't supporting google's Chrome monopoly
Monopoly means Google's interests will be served rather than the user's. This means taking away things that are of value to users / users losing control over features / etc. Like proxy extensions, yes.
The amount of work it would take to fork Chromium and maintain a working secure browser with MV2 hooks into the browser internals would be so large that you'd need a dedicated team whose job it is to constantly backport upstream Chromium changes and ensure they still work with the old MV2 subsystem. That would take a lot of time and money.
Well you don't need to implement every stupid thing big G thinks should be in it, just the really critical stuff. Even if you freeze all features right now you'll probably still have a better renderer than gecko for 5 years into the future.
I mean right now I bet a lot of people will simply not update to MV3 and continue using the last known MV2 build into perpetuity until certs break or something else. I sure intend to.
No, especially not if you want to watch videos, the DRM plugin is a binary blob that only Google approved browsers get to run.
Then there are all the Google services that will break in unexpected ways in your browser, sometimes just because your user agent isn't identical to Chromes if past reports from Firefox users are any indication. Basically expect to be shit on by the biggest internet giant around at ever possible corner.
The stupid prize is that by the time you decide it's time to use a different browser, Firefox and Safari have been rendered totally unusable by developers only targeting Chrome because that's all they have to do.
I use it every day as my primary browser, but there's definitely been an increase in applications that will not work except on Chrome. It's not text content that's ever the issue, it's SaaS products.
It's your anecdote vs. mine, but this is not my experience. I find that Chrome is better for Google Meet (not surprising.) Other than that FF is fine. In the last 4-5 years have become increasingly similar and easy to support as a developer.
Out of the ones that you use, maybe (I've actually never had a problem with Google Maps). There are several applications that I have to use for work that either don't work on Firefox or have limited functionality, Slack being one of them (huddles only work in Chromium or in the Electron app).
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]
The time to switch to Firefox is right now.
[1] https://developer.chrome.com/docs/extensions/mv2/
[2] https://github.com/libredirect/libredirect/issues/45#issueco...
[3] https://libredirect.github.io/faq.html#chrome_web_store