Manifest v3 in Firefox: Recap and Next Steps
blog.mozilla.org
blog.mozilla.org
So will it just be impossible to have extensions like ViolentMonkey, TamperMonkey, GreaseMonkey, Stylus, etc. in Firefox as well as chrome? That wouldn't be as big of a problem if the browser had it's own way to add user scripts, but it doesn't. And making your own extension for little scripts isn't really viable either. Especially since firefox at least requires the extension to be signed to install permanently, and getting it signed is not only a pain, but may be a privacy problem if your userscript has something sensitive in it.
If you take away these extensions please at least give us a native way to add user scripts (and by all means put it behind a big scary warning that you shouldn't use untrusted scripts and you should only do it if you really know what you are doing).
Still, it is too bad that you will need all of this mess just to get the computer to work.
https://github.com/Tampermonkey/tampermonkey/issues/644#issu...
As for userscripts, those could be done in the same way, but this would reduce functionality and security.
For developers, maintaining browser extensions across browsers with different support for WebExtensionsAPI is going to become a major PITA.
Even right now one can not submit a new Chrome extension unless it is v3 so that means that extensions codebases have to be branched out for Firefox and Chrome which was not the case before.
The hardest will be on the browser side of things. Supporting both v2 and v3 sides of an already extremely complex API (which is what we plan to do) will be causing a lot of issues.
The situation is not good. The lack of standard and unity does not help the web.
The alternative is not "unity", it's Google dictating standards that only ostensibly help them and their ad business.
That is 75% of the browser market, so Google could in theory define their standards and not care about other browsers.
The Ad-friendliness of Googles implementation of Manifest V3 is a clear example of how Google uses their influence.
Somehow the standards commission should have more to say about the process and implementations, i just don't see how.
And it all started out so nice.
https://www.w3.org/community/webextensions/2021/06/04/formin...
road to hell is paved with good intentions.
- I now only have one website I need to use that only works in Chrome.
- Devs seems to start to care
- LibreWolf is starting to give Mozilla a run for its money
- I'm optimistic that we will see some break through, sooner or later, where Chrome will be punished as hard as IE was: fines, regulations and a browser choice dialog for starters (but please folks, it can happen a lot faster if it it isn't just "that one weird loon", so do contact your local authorities and do complain about how Chrome has destroyed a thriving ecosystem. And if you work in Google, do ask tough questions.)
If it wasn't for Safari, most Webdevs could update their CV as ChromeOS developer.
which is how a browser dies - when sites and apps stop checking whether they are complying with web standards using more than a single reference browser.
Hopefully, chrome becomes like the IE of old, and a new "chrome" comes along to rescue the web.
As far as I understand the move to V3 from Firefox means will be able to ship the same App for chrome and Firefox.
Firefox just supports some additional APIs which are essential for good AD blockers Google killed.
But if you don't need this additional API (or don't have the time to support them) you could just ignore them.
That is once the move to v3 fully succeeded.
> The situation is not good.
Yes the way Google turns Chrome into a de-facto standard sidestepping or force feeding normal standardization procedures is not good.
(Slightly over simplified:) Like the most common problem with running Firefox is that it's more strict with CORS related stuff, like the standard originally intended, but ups, Chrome had already implemented less strict checks and didn't want to brake any websites so that became part of the standard to (i.e. the more strict part became optional).
It was powerful & capable. But it wasnt a standard, other than that it was by far the highest potential most capable most interesting user-agency extension on the planet by a good measure.
What's so fucking twisted is that we're undergoing "standardization" in v3 at the exact same moment Google is radically rewriting & reshaping the api to be far far far less capable.
It's hard to see a single win from any of the changes. After achieving world dominating success, the very last moment before standardization these chums have repealed a huge swarth of changes, all untested & unproven. It's amateur hour, just a sas ahit show right before standardization. devlarativeNetRequesr has some ostensibly good & virtuous advatanges, but it was obviously shit & deeply insufficient in the most woefully obvious of ways. Eliminating dynamic code was tacked on as a pro-security gimmick that didnt even remotely take technical interest & possibity into concerns: oh whoops we accidentally blew up userscript extensions, sorry, but you're all safe now.
This whole thing deeply deeply walks the line between vicious & evil farce & accidnetal fuckwittery. I still tend to give these folks the benefit of a doubt, that they simply lacked vision & respect & understanding & werent actively sabotaging & neutering the web like it certainly looks like.
That all said, v3 is actually the first proposed standard, seemingly sabotaged & crippled that it may be. So when you say this, I think, no, alas, everyone is for the first time trying to join up, just, alas, it's for misbegotten quite-possibly-sabotaged greatly de-fanged trash:
> As a developer of a browser supporting WebExtensionsAPI, the move to v3 is going to add so much complexity.
While the Chrome extension API was certainly the most wide-reaching at the time, it wasn't the most capable. I used to have a Firefox extension that made Win32 API calls. Mozilla ended up deciding it wasn't sustainable, I guess?
On the other hand, Firebug could not have been created without it…
When everybody does the same thing, different ideas can't take root and express themselves, and we can't create even better ideas.
Also, other aspects (like switching from background pages to service workers) require a change in programming model (moving from simple variables to message passing/persistent storage) as your service worker can be killed off at any time.
But isn't the whole announcement about Firefox also going to support v3 (e.g. you only need to write for v3) except that it still allows some of the removed functionality _additionally_ to the v3 APIs Chrome has?
> Also, other aspects [..]
Yes, that will be a major change. But as far as I understand one you have to go through anyway if you want to support Chrome.
Right - maybe I misunderstood the previous commenter's question, but I thought they were asking if it would be possible to make a translation layer that would allow developers to seamlessly support Manifest V3 without changing their Manifest V2 code.
What you are saying is correct though - Manifest V3 code will be universally supported, with a few browsers (Firefox, and Brave I believe) also supporting some of the V2 APIs on top of that. But if you use those APIs it won't work in Chrome.
Glad to hear that uBlock Origin will live on in Firefox.
That means that very soon all Chrome (and Edge) users will no longer have uBlock Origin, and Firefox will be the only way to run it officially.
This could be a pretty decent value prop for Firefox (bigger than the random features Mozilla has been pushing recently IMO)... Although I'm sure the majority of less technical Chrome users will just switch to whatever gimped, Chrome-sanctioned declarativeNetRequest ad-blocking extensions spring up to fill the void.
This sounds like a pro in my mind. I made the switch to Firefox soon after MV3 was announced. I don't regret it. I'm hoping more people follow in my footsteps and hopefully Chromium doesn't have such a stranglehold on web standards.
I've switched back to Firefox now that I no longer work somewhere that uses Google products.
I think New Meet performs a lot better in FF now, but Old Meet (with the gray action bar) had awful performance when I used it. The performance wasn't great in Chrome either, but it wasn't show-stoppingly slow like it was in FF.
I do that on mobile, I have a heavily locked-down Fennec F-Droid for random browsing but it's awful to use Google websites from it, so I keep Bromite around only for checking my old GMail / GDrive accounts (I've moved to other providers but they're useful backups). Doesn't make much sense to bother blocking Google Analytics and friends when I'm already using a Google website.
On desktop I don't have that problem, Librewolf works fine with Google websites for me, and I have a container set up for them.
At work we're on the MS stack so instead of Chrome I keep Edge as my other browser for Azure, Office, and Teams. I have to say, the vertical tab implementation from Edge is one of the best I've seen. Vivaldi's are fancier but they're not nearly as smooth, and Firefox's Tree-Style Tabs extension can't even compare.
That will be the true test of Googles changes, if they don't come up with something else before then.
https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/
That's January 2023 for most users. You can only run v2 past January using an enterprise policy.
1: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
I always thought that would be the evolution of ads, but didn't realize it was already fairly widespread.
Maybe it's time for me to look at switching back to Firefox. I ditched them when they pushed so hard for DoH which looks a lot like ad delivery tech to me. I thought Microsoft would give users a good experience with Edge since they should be trying to gain market share, but that was totally wrong. It pushes Microsoft accounts and affiliated products super hard.
Does anyone have a recommendation for a plain, un-Googled, Chromium browser on Windows. I'd prefer something digitally signed and without extra features like Brave, etc. have.
It looks like privacy-enabling tech to me. I don't want my ISP to snoop which domains I visit or hijack DNS requests.
Just wanted to point out that different threat models and actor evaluations exist.
Learned first hand when trying to visit adguard.com with DoH enabled at a relative's. Comcast's router blocked the website by recognizing adguard's unencrypted website IP address.
DoH is not really hiding anything from ISP's.
[0]: https://www.cloudflare.com/learning/ssl/what-is-sni/
P.S. not sure why your comment got flagged. It seems perfectly reasonable to me.
But that aside, maybe Vivaldi is what you're looking for?
Agree Mozilla’s move to enable this practically by default with just a slimy quick pop up message about privacy was weak
Setting the default resolvers to cloudflare was also weak.
They even presented the problem in a misleading way. How is centralizing DNS requests to a major provider like cloudflare improving privacy. Ohh because wink wink … Mozilla said that they got privacy “guarantees”. Your local ISP will no longer snoop but instead we will just sent all requests to one of the largest resolving services in the world.
Once edge workers get cheap enough I wonder how we'll be able to stop ads at all. Everything but the bootstrap page could be randomized per user and all fronted by the same 1st-party website.
Think encrypt the real request needed into the url to the edge worker it de-crypts that payload and does the request. Everything except the content will look identical to the users computer.
It pushes Microsoft accounts
I use it on my work machine without an account, and there's no push that I could ever see. Seems about the same on that front as anything else, including Firefox. I also have a Firefox account. I do use a MS account on my personal Edge install.
and affiliated products super hard.
You would think this is a negative, but it opened my eyes and saved me a lot of money. In fact, Edge's shopping features were something I wish I had for years prior. I liked it enough that I went looking for best-in-class options, and ended up installing Honey. I now rely on both Honey and Edge's shopping features to save me money.
I would go so far as to say if I had to leave Edge and use a browser without Edge's shopping features, I'd be one of the features pulling me back to Edge.
[1] https://www.datarequests.org/blog/honey-data-collection/
Edit: When did we stop calling this stuff "spyware"? When it became widespread enough to no longer be remarkable?
I keep Tor Browser installed at all times for best-in-class privacy alongside Edge. It blows away Firefox on that front.
If I wanted to make the tradeoffs for a more privacy-oriented daily browser, I wouldn't reach for Firefox in 2022. I'd use Brave.
I can't say I fault MS on that one, but people will any way without thinking about it. They're providing a service. Teamviewer certainly requires an account.
> This is not the case with Chromium-based browsers, i.e. tracker/advertisement payloads may find their way into already opened tabs before uBO is up and ready in Chromium-based browsers, while these are properly filtered in Firefox.
Wow. I did not know this. This seems like a huge bug/problem in Chromium if you care about blocking trackers.
Hopefully, Mozilla won't be completely inept as to fail to position themselves to capture any users leaving Chrome over this.
I've seen some suggestions that the number of adblock users could be as high as 40% of all users but that's possibly an over estimation. It's also not clear how they are collecting that information.
https://www.statista.com/statistics/435252/adblock-users-wor...
No, we don't have any alternative to Chromium other than Firefox and Safari. But for the Chromium based browsers, Brave and Opera do have built-in adblocking independently of Manifest V3 [1]. Vivaldi claimed that they might maintain an alternate store [1]. So all three alternate browsers have the option to offer better level of ad-blocking to get more installs. Of course, they could also decide to monetize with an "Acceptable ads" program after they gain market shares.
[1]https://www.zdnet.com/article/opera-brave-vivaldi-to-ignore-...
Apparently that's going away entirely now and there is no good way to stream browsing history anywhere if it's not tied to a browser maker's services (even if they are selfhosted a la Firefox Sync).
You can't even read from the browsers history database because browsers for some reason lock the entire database even while running in WAL mode (my original plan was to do something similar to litestream and just attach to the places.sqlite or History files and push the url to Loki, but that just doesn't work).
There are reasonable reasons to do this, but it really seems that it's just to curb user agency with their own data and devices.
If the server doesn't supply your target domain in the CORS header, the request should fail if my understanding is correct. If it is this would allow a website like YouTube to block SponsorBlock from loading it's data. There might be ways to bypass this but for me it's just a side project, so I haven't really looked too deep into it.
The post function:
function post_to_loki () {
const data = {"streams":[
{
"stream": {
"job":"browser",
"user_agent":Navigator.userAgent,
"nodename":"desktop",
},
"values":[
[Date.now()*1000000, {"location":window.location, "referrer":document.referrer}]
]
}]};
let control = GM_xmlhttpRequest({
"url": "https://loki.example.lan/loki/api/v1/push",
"method": "POST",
"headers": {"Content-Type": "application/json"},
"data": JSON.stringify(data)
});
}
Now whatever actually triggers the POST function is up to you (I ended up using [2]).In Grafana, I have a few dashboards specific to the facets I want to see.
I have one for Dev stuff which tracks the latest 100 urls, the frequency count of websites, and a State Timeline of all the events. This filters specifically stackoverflow, MDN, any url contains "docs", github, and a few internal urls.
In an other dashboard I have a view of all the places I read online with similar panels to Dev, but with different filters.
Then I have a final dashboard which works solely on Google search queries, but instead of grabbing the search page's URL, I grab the search term from the page I actually clicked on which makes searches much more interesting.
---
[1] https://grafana.com/docs/loki/latest/api/#post-lokiapiv1push
it's all so tiresome
the long term goal for Google, Apple and Microsoft is no extensions at all. it is painfully obvious about the vision these companies have for the future of personal computing.
I know full well why does Mozilla do its competitors' bidding, but it does piss me off to no end to read their bullshit rationale for doing it. in 2032, we'll be reading about the removal of the address bar being a doubleplusgood thing. more security! less inequity!
Apple added extensions to Safari iOS last year and added WebExtensions API to Safari Mac the previous year, so that's demonstrably untrue of Apple.
[1]: https://docs.microsoft.com/en-us/microsoft-edge/extensions-c...
Firefox and Safari should be ok at least in the immediate future. I doubt Apple is going to announce next month at WWDC that v2 extensions will be dead in September 2022, even before Chrome kills them in 2023.
v3 is not even ready yet. There are still major bugs and missing features, which Mozilla's blog post alludes to. I'm postponing the migration myself as long as possible.
I expect, though, that users won't mind as much? I run very few extensions these days, due to the security risk, not wanting to vet extension authors, and not wanting to pay attention to the security implications of updates due to things like author changes.
What's really frustrating is that users don't realize how much work goes into just keeping your head above water in the Chrome Webstore. They think that they shouldn't have to pay (or pay much) for an extension because it seems so simple. But they don't understand that complying with Google's ever-shifting rules means you can't ever get that comfortable.
Possibly. Google has delayed their timetable in the past for a number of Chrome changes.
> What's really frustrating is that users don't realize how much work goes into just keeping your head above water in the Chrome Webstore.
Agreed. Also, removing Chrome Web Store payments was a huge blow to extensions.
No, that's not it. It's mainly just one API, blocking webRequest: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
That said, uBlock Origin is definitely more exhaustive since it has a lot of contributors that will write custom rules for even obscure spammy websites, so shady websites are the main reason I do reach for uBlock Origin.
Fully open source like FF, built-in adblocking that's dependent on Manifest-nothing.
What are the risks to users? How does Mozilla mitigate them?
Sure, extensions have manifests, but clearly the project is about much more. It seems like… an odd choice.
The name is very meaningful to extension developers. To others, perhaps not.
> Mozilla will maintain support for blocking WebRequest in MV3. To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest.
That means uBlock Origin will continue to work on Firefox !
This is 100% the right thing to do: let extensions use the more powerful API, while also providing the more neutered version for extensions that may not need to use the legacy version, or are designed around Chrome instead of Firefox.
There's been a fair bit of confusion regarding Mozilla and Manifest V3, but I'm glad this (somewhat) clears it up.
If Edge loses uBlock Origin, I'll definitely try alternatives first.. but I wouldn't go back to FF. I did a review of all browsers last summer and came to liking Edge the most, then Brave as my second choice. Part of my ranking methodology was how big of a vendor was supporting each browser, as I've seen some value in that now that browsers are critical. That metric really hurt Vivaldi, Opera etc. Brave only came out on top because it's the only fully open-sourced browser other than Firefox. The built-in adblocking that's not dependent on outside support may win it a lot of new users soon though, including me.
There's no such thing. There's Firefox, Chrome and Safari (and since you're using Edge, I doubt you're a macOS user). Everything else is Chrome with a different paint job. Once Google drops support for v2, everyone will. Maybe Microsoft has the engineering power to support it, but they have no reason to, and Opera might want to, but doesn't have the funding required.
Firefox is slow, but it's not that slow. <philosophical>I'll take the extra second of loading time for GMail any day over contributing to the harmful browser monoculture</philosophical>
If V3 really is Armageddon as everyone is saying, then I have my new browser lined up. It's Brave. And it already has a suitable adblocker built-in. It's the no brainer solution here.
A friend of mine is a macOS user and he loves Edge. There's a native Apple Silicon build and it works well.
Please consider switching to a non-Chromium-based browser if you want it back.
If "the web" means "There are a few standards different implementations conform to, and if I adopt those standards I'm compatible with those implementations," I don't see it dead in the adoption of MV3.
The latter I think refers to being able to execute code that is fetched at runtime? That certainly makes things a lot easier for developers, but I don't quite see what limits that imposes for users?
In terms of use cases, downloaded on the fly code is definitely one example. Userscript engines like Greasemonkey, VioletMonkey, & TamperMonkey are all alao on the chopping block, which also allow user-edited code as well as downloaded code.
There's also a huge range of uses for dynamic code in general. Data stores & engines will optimize performance by using the Function constructor[1]. Cant do that anymore: basic, sensible, multi-decade long optimizations are now off the table. Being able to use eval() to dynamically generate a complex expression- no longer allowed.
It's bitterly ironic that Apple's prohibition against interpretters (a type of dynamic code) has held their platform back from allowing interesting things to run on iOS. Chrome's real rendering & js engines are blocked there. Because Apple says it's too unsafe to trust programs to do anything not statically defined, that only code that can all be fully read & understand is ok. Now here's Google & then Mozilla, bringing the exact same prohibitions against dynamic code to the web. At it's deepest heart. It's so ugly, so hypocritical, & so menacing & massive a threat to possibility, to extensions that can grow & develop.
Long hope, but a deep one: I very much hope one day (far away) a semantic-web like world wide web might emerge, but if this sick knee-capping happens the browser will never be a viable place for user agency- which must be a dynamic & growable organic thingh never be tenable as a place where user agency can grow & flourish. Extensions are amazing, but if they're restricted to single-purpose little timmicks, unflexible static predefined capabilities, Google will have insured that the only thriving systems the world will get will be inside the data center. These restrictions mortally cripple user-agency, that which is most special & most dear about the web & what set it apart from conventional software applications.
My open github issue[2] on this.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Unfortunately I don't see that changing, especially since you can see the same dynamic in (nearly?) every other industry. The industry engages in widespread practices, sometimes legitimized by corrupt laws via regulatory capture, that harm our society and everyone is too busy trying to put food on the table to notice.
Tech has gone so radically anti personal computing, exists mostly in modern mainframes (data-centers) once again. There's so little hope for good when so much of computing is so very very far away, when technics have all so swiftly effervesced up into the cloud.
I hope it does!
[1] https://exploringjs.com/impatient-js/ch_dynamic-code-evaluat...
To repeat, since we're back here again,
> You point out only the weak, sad dynamic code & ignore the enormously speedy & optimizing dynamic code
The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/s... https://news.ycombinator.com/item?id=31432495
Everything you say is laced with doubt & scorn & skepticism. I just cant imagine living in such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. That's a shitty miserable world that looks like the hell JS plucked us out of. By being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.we crawled out of, screw systems that cant ever become more, & screw the fearmongering shit show V3 foisted upon us by removing really really important flexibilities of the language.
At the level of a browser extension (which, operating outside the per-page security sandbox, has wide latitude to observe and manipulate the user's experience and interactions with the web), the new way of thinking is that such forward-declared constraint should be the prerequisite for the security-conscious extension.
By all means, change your behavior over time... By the process of pushing new versions of the extension, which can be statically analyzed, and forward-declaring the permissions you need to accomplish your tasks. Anything else is asking the user to trust a stranger (both to not be malicious and to not be inept).
> That's a shitty miserable world that looks like the hell JS plucked us out of
JS plucked us out of one hell and put us, initially, into another where any old website could fake a query to get your bank account data or steal your password. We've been digging out of that hell ever since, and this is another step in that process.
A ridiculous proposition on the web. User agency ought be able to grow & expand the wider the set of data they encounter. To propose that each new type of data encountered requires a new version of the extension is a farce.
All for weak & vague & unspecified fears. Be afraid user! You need this restriction, anything else would be dangerous to you! It's been uncompromising stances, offering no middle ground, no opt-out, disregarding all valid cases. Fearocracy. Security concerns are ruling with fear & absolutism. With no public evidence no escape hatches no real accountability. This is degrading.
I wouldn't say "afraid," but "cautious" and "skeptical" are good attitudes to have regarding extensions with global permissions that can execute arbitrary JavaScript that originates from a source other than the signed files in the manifest directory, yes.
https://courses.csail.mit.edu/6.857/2019/project/10-Oh-Chen-...
https://www.ghacks.net/2019/07/22/how-to-search-all-chrome-e...
How can a program operate meaningfully on data that the programmer knows nothing about? I'd love for you to describe an actual example.