Live data from Hacker News

Mozilla’s Manifest v3 FAQ

blog.mozilla.org

101–110 of 111 posts

Re: Mozilla’s Manifest v3 FAQ

#101
post #15

Earlier quoted context omitted.

> Chrome has already ditched adblockers on mobile nit: chrome has never had extensions (or ad blockers) on mobile (Disclosure: I work for Google)

That's not even a nitpick. The parent got it completely wrong. If Chrome mobile never supported extensions, then it's false to claim they "ditched" them.

From the original post, it's more like a language parsing issue - Chrome was original a desktop-only application and it had extensions. When it was ported to Android, they ditched extensions, as well as jettisoning numerous other features.

Thus, not "completely wrong."

Re: Mozilla’s Manifest v3 FAQ

#103

It seems I'm in a minority here, but I was never comfortable installing any adblock extension because the existing request blocking API means that the extension would see all web traffic generated by me (including private URLs that are otherwise not known to anybody but me). 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 exte…

uBlock is open source, you can verify that the extension in your browser is the same that is published in the github repository.

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.

Re: Mozilla’s Manifest v3 FAQ

#104

The tone of this post concerns me. 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…

> What comes across is that Google is not collaborating with Mozilla over the Manifest v3 changes. 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…

Having done a fairly long stint in the telephony world, I can say that the general purpose of standards committees is to rush through a whole bunch of hacky changes on your platform and then strong arm everyone else to implement what you did -- the more work they have to do the better; the worse it fits into their original ecosystem the better. Your goal is to make your competition perpetually play catch up and to have a slightly wonkier version of your system.

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.

Re: Mozilla’s Manifest v3 FAQ

#105
perhaps a more optimistic take on "no immediate plans": there could eventually be an alternate standard for webrequest that addresses Chrome Devs' (perhaps legitimate) privacy concerns around most extensions being able to sniff, modify, and log all of your traffic on the entire web with a single, unobtrusive modal click. There is room to make the web platform more secure without stripping power from the user-agent, surely, or giving bad actors a trivial foothold. Frankly, my concerns around the webrequest API are numerous, the only reason IMO that Chrome isn't deprecating webrequest in Enterprise builds is for corporate spyware.

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

Re: Mozilla’s Manifest v3 FAQ

#106
post #60

In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. 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…

> In the absence of a true standard for browser extensions, perhaps Mozilla should consider trying to form one by leading with a strong example instead of weakly implying that they will eventually probably cave to the monopolist. 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…

Well, it's not enough to try, unfortunately. They have to persist and this talk about the importance of keeping compatibility with Chrome in the context of blocking webRequest removal is not very encouraging.

Re: Mozilla’s Manifest v3 FAQ

#107
post #30
post #27

Earlier quoted context omitted.

In that discussion (and indeed in the message you quote), the mozilla developers had every incentive to say, if it were true, « we have decided not to replace fennec with fenix on Android until fenix supports ad-blockers ». 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 e…

Thanks for this. >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?

Perhaps interesting: this post that implies that implementing full extension support might not be that much work: https://sammacbeth.eu/blog/2019/09/04/geckoview-extensions.h...

Re: Mozilla’s Manifest v3 FAQ

#108
post #22

> We have no immediate plans to remove blocking webRequest > 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.

I wouldn't want to claim that strongly that they won't remove it if I were Mozilla - for all they know, Chrome might still come up with a proper alternative that satisfies the use cases of all blocking extensions, but also performs better. Obviously Firefox would then transition as well.

Re: Mozilla’s Manifest v3 FAQ

#109
post #11

Earlier quoted context omitted.

Your choice can well be firefox and chrome as a fallback when a website doesn't work and you care enough to bother opening chrome for it. Chrome has already ditched adblockers on mobile, firefox with adblockers and reader mode is a MUCH better mobile web experience.

do you really need the fallback? i've yet to need chrome for anything, since i rarely use google products other than maps. 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.

Some sites need NoScript disabled to work. Even using the "temporarily trust everything" option doesn't work. Since it's easier to just paste the URL into chrome than disable a plug-in and remember to re-enable it later, I do that.
Post reply on HN