Mozilla’s Manifest v3 FAQ(blog.mozilla.org) |
Mozilla’s Manifest v3 FAQ(blog.mozilla.org) |
What comes across is that Google is not collaborating with Mozilla over the Manifest v3 changes.
Instead of using and appreciating the engaged Firefox developer ecosystem we have PM conference rooms in Google mandating huge changes based on... well they've been shady so far about their choices on Manifest v3.
The other thing that keeps bugging me about this is -
We need a tiered App store for browsers. Part of the lockdown Google wants to do isn't wrong but its driven by having WAY too many bad actors and shoddy developers in their Chrome store.
If you have an opensource web extension, a reasonable community and with reproducible builds? You can use more powerful API versions.
If you are jrando bizplan #2000283 you get the kinda trusted tier.
Frankly if Debian had a web browser extension "store" with 20 things in it, I'd use that exclusively and turn off both the Chrome and the Firefox store 100%.
There are a handful of extensions for Firefox and Chrome in the Debian repositories: https://packages.debian.org/search?keywords=webext-&searchon...
It's actually pretty close... no Vimium but ublock origin/matrix, tree style tab, privacy badger, browserpass
<3
Here is what's in Sid -
https://packages.debian.org/search?suite=sid&searchon=names&...
We kinda have one; the tiers are "the public app store" and "your enterprise's private collection of apps, whitelisted by GSuite policy on your GSuite users."
Things are in equilibrium because no big player is complaining; and no big players are complaining because they have all their needs met by just 1. getting custom extension builds from vendors, 2. signing them with their enterprise cert, 3. pushing them to some object store, and 4. telling GSuite to allow them (https://docs.google.com/document/d/1pT0ZSbGdrbGvuCsVD2jjxrw-...).
I'd like one of the PMs at Google working on this feature to engage in actual community discussion around this issue.
Google is not a monolithic corporation. Individual people are responsible for these decisions. These people are obligated to discuss why they are making these changes, else they deserve to be called out if they refuse to do so.
Is it too much to ask for these PMs to take some personal responsibility and engage in discussion for the far-reaching changes they are forcing upon society?
Yeah like the F-Droid [0] appstore ecosystem for Android.
[0] - https://f-droid.org/
Well… duh? Google will do whatever it wants with no regards to anyone else unless they're forced to do otherwise, and "the market" will not force them to do otherwise unless their very large browser majority falls. From the moment mozilla decided (/ was forced) to adopt chrome extensions they were bound to follow google's whims.
People in large organisations take this stuff very seriously and it can be difficult for other people to concentrate on making a good spec that will work well for everybody. The idea is that the market is pretty much the same size whether you have a fantastic application or a hacked together application. What matters for the company is what percentage of the market share you have. It's worth a considerable amount of fit-for-purpose in order to lock in eternal advantage over your competition.
About as close as Mozilla can come to outright saying, "Chrome is big enough and we're small enough that what they do _is_ the standard."
Still, it's encouraging to see that they're not removing the blocking API for now. I kind of hope this does push a few adblocker extensions to abandon Chrome.
But then they'd have to give up all their Google funding. And they're way too cowardly and corporate to do that.
Seems a little over the top to me!
Also, Mozilla is very good at standing up to Google. They beat them on webasm, rust is arguably supplanting go, and most of all, it was Mozilla that effectively killed web components which were very dear to Google.
Ha. As if that will ever happen. They'll probably just pivot to something else.
The reason Chrome can try to ditch ad blockers is that they are big enough, that your only choice is Chrome or GTFO.
> immediate
We know exactly what this kind of talk means. Don't blow smoke up our ass, Mozilla, just give it to use straight: We'll have `blocking webRequest` for as long as Google allows it.
Moving away from that was definitely the right approach for Mozilla, but the timetable and effort into bringing up a non-XUL/XPCOM-based extension mechanism definitely left something to be desired.
At the time of conception, it was pretty great. However, that much customizability came at two expenses.
1) Web devs can't use XUL, because it's its own little cosmos, you as Web dev couldn't mod Firefox UI
2) The XUL was legacy software and super hard to optimize.
Mozilla's decision to remove XUL Extension support was directly a result of their decision to replace XUL in favor of HTML5 as the UI design language of choice.
https://blog.chromium.org/2019/06/web-request-and-declarativ...
Google is using a slow-frog-boil approach to re-desensitize their users to ads, and it's working. The only thing that will work here is a big splash of cold water to the face.
Maybe Chrome losing all of its ad-blockers overnight will finally start making a dent.
It's also quite disappointing how there is seemingly no one from Mozilla here, engaging with us on this topic. Instead, the only communication we get is one-sided corporate speak, with no real ability to respond.
If anyone from Mozilla is reading, who do you think will spread Firefox among non-technical users if not the type of crowd that frequents HN?
That's exactly what they've tried to do. Firefox exposes a `chrome` namespace object to extensions which is intended to be more or less API compatible with what Chrome provides and added the `browser` namespace object where improvements to the base compatibility are added (e.g. switching from callback based APIs to Promise based APIs). See the bit from the wiki below and the link to the browserext spec:
> Mozilla has worked with Microsoft and Opera to implement browser extensions so that developers can write extensions that work across multiple browsers. The preliminary specification[1] matches what Google has implemented in Chrome so that extensions will work on Chrome, Edge, Opera and Firefox.[2]
What will this mean for GM.xmlHttpRequest in userscripts? Adding content from several different sites with userscripts can be very powerful.
The change[1] only affects content scripts because they run in the same process as the website. You're still able to fetch arbitrary origins in a background page. So GM has to move the fetch to the background page, then send the content to the script via message passing.
[1] https://www.chromium.org/Home/chromium-security/extension-co... .
@-moz-document domain(example.com) {
img { opacity: 0.05 !important; }
}
Mozilla ought to be the browser for a private and usable web, but it seems they have occasional sneezes where you question what they’re doing (this, pocket in recent memory).
The future of the web where Google is in complete control is straight up nightmare fuel. Microsoft in the early 2000s never scared me as much as the future we're headed into does.
This won't be IE versus Netscape since websites are no longer served as plain old HTML. They're messy, thick, and impenetrable javascript blobs--not documents. We're not arguing about websites simply not rendering correctly in the less popular browser. This is a battle for the absolute control over information distribution.
What do we do to prevent what's happening?
Google already shot down XHTML, which was rich with semantics. That was a web written for documents and tools that could query those documents for meaning.
Whatever Google has become needs to be dismantled. The ad company can't be the browser company and phone company. It's a perverse alignment of incentives.
Well, also since Chrome if open source, cross platform, and standards compliant, and IE was none of those.
And Google (unlike Apple) allows competing browsers, based on modified Chrome code, or entirely different engines.
Soon we will have a good, cross platform Edge browser, thanks to Google, and a menu of browser options in Europe thanks to the EU. (Maybe other countries should push for the same.)
But Chrome if no IE.
And I believe that in Europe they will soon be
At the very least a new webrequest spec that is more ergonomic and more safe than the webrequest API (without neuturing adblock) could show whether the emperor has no clothes, vis a vis "Google Adtech is directly influencing Chrome and web platform development" plots
On top of that, I'm not in favor of extensions doing anything to improve security - I want that in the base browser.
I personally feel that now with manifest 3, I can actually install adblockers since the newer APIs do not share all my web traffic with the extensions.
Can somebody explain why removing blocking API was overall a bad decision by Chrome?
The webRequest API can observe the URLs you visit without needing blocking permission.
And so does the webNavigation API, the tabs API, history API, content scripts, possibly cookies API and whatever else does not come to my mind.
What's the point of an ad blocker if it doesn't block ads?
The blocking API being removed is an issue because the replacement does not cover all use cases and severely limits what ad blockers can do to intercept filtered content.
Google is obviously aiming to boil the frog slowly and make ad blockers a such terrible experience that Chrome users will not use them.
- it has a different default search engine selection that can be sold in the same way that Mozilla sells this same feature to google presently
- no ads on new tab page
- bundled with ublock origin
The goal being to increase the value of selling the search engine selection while decreasing the value of mozillas in effect siphoning off some of the value of mozillas primary revenue stream.
Such funds could be donated back to Mozilla or used to maintain a fork that doesn't ruin adblocking. Their choice.
Follow Google - and all its shady practices - and you will lose a large chunk of those users. Many of them, to use current terminology, are "key influencers": technically savvy people who advise family and friends what to do. Lose them and the outlook is, I suspect, pretty grim.
You're clever people. You'll know this. Google has a good few smart folk too (even if their motivation is questionable). It's easy to see this is difficult for you: Google is your primary funding source. Fail to comply with their wishes, and that funding might well disappear.
As has been noted in other threads, the tension between privacy principles and funding is a huge threat.
For the good of the open web, I desperately want a successful Mozilla, and a technically excellent Firefox at the forefront of a pro-privacy, anti-surveillance re-balancing of the internet.
I don't doubt the difficulty in filling a $300M funding hole. I'd gladly pay $30 per year for a pro-privacy Firefox. Another 9,999,999 is a tall order. On the other hand, you have c250M users...
Particularly on account of funding, I know I would also gladly pay $30 per year for a privacy, freedom and power use oriented Firefox instead of this new direction they keep taking it in. And so would many of my acquintances.
Perhaps there is merit to organizing a website for people to be able to pledge this.
I don't see Mozilla's motivation to remove that at the moment.
I mean, speaking for myself, I'd drop them both and follow a fork of the browser that lets uMatrix work, and that's not something I've considered very many times in the past 20 years. Control over what my browser actually connects to has become a top-3 feature concern for me. I was going to say "I suppose 'working' is technically more important to me", but then I mentally wargamed out whether I'd be willing to use a slightly nonfunctional browser to have uMatrix and noticed that I actually already put up with a slightly nonfunctional browser to use it, because uMatrix already breaks a number of sites until I do some whitelisting.
Even if there's a security impact to extensions having too much access to the web request cycle, there's a security impact to them not having enough access to the web request, too.
A “adopt manifest v3 or we cut your funding in half” could be behind the scenes.
However, how long that fork can persist, remain secure and retain feature parity is an open question. Should Mozilla cave and the community fork be unpopular, Google will definitely have a monopoly on the browser space.
I'll happily find something other than Firefox if it goes down the same route.
Given the level of cynicism directed at Google by the HN community, is it even possible for Chrome to lock down extension permissions in a way which wouldn't be seen as some sort of aggressive move against ad blocking? Keep in mind that secure, user-friendly permissions systems do have to be somewhat restrictive in order to be effective (see Android, iOS, etc), and that ad blocking extensions will necessarily be impacted as a result.
#2: In light of the backlash to the proposal they would have to actually consider not implementing the change or at least consider some alternative implementations. So far all they have done is say "we've heard your concerns, and we're just going to do it anyway". Many interesting ways have been proposed to achieve the same supposed benefits as what Google claims manifest v3 will provide. But they have not responded to any of those ideas and are blindly persisting with their proposed model with all its downsides. So why even act like this is some kind of open process which involves real developers?
#3: They would need to demonstrate that they are actually concerned about the ability of adblocker vendors to deliver good products. They could have created a transition window from the old API to the new API to see in practice how adblocker vendors choose to use it and what limitations they face. But they haven't done that, instead they announce they're killing the old API the same moment they introduce the new one. That to me demonstrates that they don't really care if it's sufficient for those vendors or not.
If Gorhill (and other extension developers) endorsed the changes, that would be a strong indicator to me consider that they might be user-friendly, and that the concerns about them were overblown.
Google could also theoretically just convince me outright. They would need to convince me that extensions were currently hurting my privacy, security, and web experience more than ads. That would be very difficult, but theoretically possible. A blog post that solidly addressed critics point-by-point, rather than simply saying, "no that's wrong", would go a long way.
It's not helpful to Google now, but if the Chrome team built up a reputation for being more thoughtful, I also wouldn't be more likely to take them at their word in the future. I've written about this in the past, but Chrome has been handling developer criticism poorly for a pretty long while, and that pattern eventually reduces developer goodwill. When it comes to trust, everyone is a Bayesian.
That doesn't mean I don't try to consider their arguments, and it doesn't mean by default I assume the worst, but I'm only considering Google's arguments on their own merits. If the changes don't make sense to me, I'm not going to assume by default I should accept them anyway. They can't just say, "trust us, we've seen the numbers."
Also lets be real there are only a handful of adblocking extensions that have most of the market share run by legit players they could trivially vet and whitelist a small number of extensions that are allowed this privilege.
It's not about security its clearly about ruining adblocking. A tiny blocklist that can only be updated with the extensions ensures that it is always trivial to work around blockers. One can simply ask which which version of the extension one has and load ads from a url/host created since.
Is there a security argument for this change? I must have overlooked it.
As for performance: users have a choice about what extensions they use. If Google sincerely believes that their proposed limited content blocking API is adequate, then they can expect that users will notice the performance advantage and move to a new ad blocker even if the old API remains present. That's the main mechanism by which uBlock Origin has largely replaced AdBlock Plus.
On the other hand, in the (fairly likely) case that we find out the new ad blocking API doesn't allow for very thorough blocking, and the ads that make it through slow things down more than our current generation of full-featured blockers, then the lower overhead of the new API really doesn't help end users in any meaningful way.
It's a fair question, but there are several of things that would at least help convince me.
They could demonstrate that they have tried all other solutions that would solve the security issue.
They could demonstrate that the performance benefits of the change would be bigger than the performance benefits of ad blocking.
They could implement a more performant/secure API that still allows full ad blocking.
They could build ad-blocking into chrome (doesn't seem likely to me, but it would convince me).
Maybe listen to the people who actually write the ad blockers.
>"I think they've been trying to give the impression that they’re working with the developer community, when in fact they’re pretty entrenched in what they want to do," says Jeremy Tillman, president of the privacy and security-focused ad blocker Ghostery."
https://www.wired.com/story/google-chrome-ad-blockers-extens...
A strong argument for how that change accomplishes those things, along with evidence.
Google has not been able to provide either of those things.
Two very different languages with very different goals. Neither want nor ever will suplant the other.
Golang is challenging Java, C#, Python, nodejs etc. It was also supposed to challenge C++ but based on how the language turned out, if that is ever true then C++ probably wasn't the right language for that project in the first place...
I thought it was generally well-accepted that developers mass-moving friends and family off of IE 11 was part of the reason why other browsers ended up beating it.
Similarly, I thought it was mostly accepted that part of the reason so much of the web was optimized for Chrome was because Chrome had genuinely better developer tools, and developers preferred to optimize first in Chrome and second in other browsers.
Maybe there's more disagreement on those points than I realized.
Even on the subject of DuckDuckGo, which is probably not going to be mass-adopted any time soon (if at all), actual usage numbers are increasing faster than any other major search provider, including Google[0]. Whether or not those numbers are coming from ordinary people or tech people, clearly somebody is being convinced to use DDG. Is it going to be a revolution? Probably not. But it's not nothing.
I really wish people would stop defining success as a monopoly. Even in the browser space, the goal isn't to make Chrome vanish. We just want Firefox to have a big enough user-base across enough markets that it can't be ignored. Even 20-30% would probably do it. Mozilla doesn't have to kill Chrome.
Similarly, if every non-tech user keeps searching on Google, and DuckDuckGo just becomes a great search engine that every programmer prefers, that's a pretty big win. I would not call that a loss.
[0]: https://duckduckgo.com/traffic (of course saturation does play a role here)
But now you're saying "mass converted the world" whereas before your goalposts were set at "friends and family."
And due to their follow google nature of monthly updates there's no stable version to fall back on.
Perhaps, but it also made Firefox into a browser that can no longer meet my needs.
Perhaps it's your needs, not Firefox, that are incorrect.
link location bar extension: this cannot be replaced with a webextension as mozilla refused to add the necessary API
websocket monitor extension: this is being built into the dev tools, after 2 years and counting
tab groups / panorama: every single extension that tries to replace this is terribly broken, because the provided extension APIs don't really support this use case or are super racey
like the link location bar extension it's impossible to write an extension to replicate the old refresh/stop/go button in the url bar. You can have 3 buttons, but that's stupid.
All that and mac (nightly & dev-edition) users only recently got back to the level of performance from pre 57 Firefox due to work described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1429522#c26 (ongoing).
And before I get crucified: there aren't any better browsers, so I'll be sticking with Firefox, but it sure isn't anywhere near as useful as it used to be.
Giving a list of my needs is pointless. Also, I never said that Firefox was incorrect. I said that it no longer meets my needs.
Mozilla has made a business decision to address a user demographic that I am not a part of. I don't have enough information to be able to say if that decision was correct or not. All it means is that I no longer use Firefox.
nit: chrome has never had extensions (or ad blockers) on mobile
(Disclosure: I work for Google)
If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.
Thus, not "completely wrong."
Oh, I fully agree. But just having a better, faster, less ad ridden browser is not enough. The sheer networking effect is propping up Chrome on Android.
I only had a few issues with some videos playing.
i've found the use of google captcha on governmental, financial, and some commercial sites frustrating though. i'll abandon a site that has google captcha if usage is anything less than critical.
There's an FF extension called Buster made someone here on HN that helps workaround Google's current generation of captchas. It doesn't work 100% of the time, but the success rate is still higher than doing it myself.
i use firefox with all kinds of privacy/blocking extensions and can access linkedin just fine (as long as first-party javascript can execute).
> We're certainly aware of how significant ad blocking extensions are. This release required a great quantity of features with only a six month timeline until now.
> We already support a very limited set of the WebExtensions API to offer features like Reader Mode. Rest assured that more features will land in the coming months.
Source: https://news.ycombinator.com/item?id=20298143
This reads like FUD to me. The dev team know how important extensions are to their users. Can you provide a source that implies Fennec will be EOL before Fenix has extension and/or ad-blocking support?
They very visibly didn't take the opportunity to do so.
From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
>From what I can make out on github, they're planning to replace fennec with fenix around the time the next ESR comes out (which I think is early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.
Would you mind linking the GitHub issues that have lead you to draw this conclusion, so I can take a look?
I still use Firefox due to the security benefits of ad blocking, but I don't find the experience particularly enjoyable (although, thinking of it, it may have either significantly improved in the past ~half a year, or I just don't notice because of a more powerful CPU in my new phone).
There are benefits to adblocking of course.
But there's no point lying.
https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019.
The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR release. I think that means that since then nobody has been keeping the Android port working as changes come in (but ESRs are supported for a year or more, so maybe I'm wrong to think that the date of the next ESR release is relevant).
https://github.com/mozilla-mobile/fenix/issues/574 is about web-extension support; the recent updates say:
« Product is looking into feasibility » « Tentatively adding needs:gv label until we know what additional GV work will be needed to support general purpose extensions. »
The issue is labelled 'Feature:FennecTransition' and 'feature request'. It isn't labelled 'should', and some other 'Feature:FennecTransition' issues are.
It isn't clear to me whether they're planning to release a new version of "Firefox" on Google Play that uses the fenix codebase, or release fenix as a separate app and declare that the fennec one is obsolete.
https://github.com/mozilla-mobile/fenix/issues/879 and https://github.com/mozilla-mobile/fenix/issues/934 have some interesting hints, but I can't tell what they've decided.
Apparently they are using "Raptor" for testing (https://wiki.mozilla.org/TestEngineering/Performance/Raptor) which includes a webextension, and they fix that area of the webextension API when it breaks. But in https://bugzilla.mozilla.org/show_bug.cgi?id=1562844 they mention that many components of Fennec are not implemented in GV so the corresponding API is broken.
I'm guessing the work is mostly about enabling the addons manager, so it might fit in Q4 or it might not. But it is worrisome that it isn't marked as blocking the transition.
They've already released fenix as a separate app: https://play.google.com/store/apps/details?id=org.mozilla.fe...
I would rather they call it "Firefox Lite" (in a nod to Facebook Lite etc.) and used some in-app notifications than to try to mass migrate with a version update as it seems they are plotting to do.