Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla’s Manifest v3 FAQ

blog.mozilla.org

Post reply on HN
Print view View original

41–50 of 111 posts

Re: Mozilla’s Manifest v3 FAQ

#41

Post by Allower »

zzzcpan wrote: post #4
danShumway wrote: post #2

> In the absence of a true standard for browser extensions, maintaining compatibility with Chrome is important for Firefox developers and users. 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 extensio…

I find it rather discouraging to hear they are not removing the blocking API for now . It's basically an empty statement, not reassurance. They still may or may not remove the API, they don't want to promise anything or show any commitment to users' needs and priorities.

And the alternative is an even more ridiculous claim to NEVER remove this API. Committing to your users needs and priorities is understanding that THEY MIGHT CHANGE.

Re: Mozilla’s Manifest v3 FAQ

#42

Post by jcranmer »

badsectoracula wrote: post #6
ocdtrekkie wrote: post #3

This points to the disturbing truth of how incredibly complete Google's monopoly is: Even browsers not based on Chrome are strongly pushed to implement Chrome's platform changes anyways.

Mozilla abandoning their much more powerful XUL-based extension system for Chrome's inferior WebExtensions wasn't already an indicator towards that?

It's been known since around 2010 or 2011 that the full extension system was too powerful for effective maintenance of Gecko. Going through XPCOM for everything prevents effective optimization within the codebase, and generally ensures that the APIs have to become less ergonomic compared to modern C++ (or JS, for that matter). Furthermore, multiprocess content tabs was heavily delayed because turning it on would break practically every extension (since you could no longer have synchronous access to content).

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.

Re: Mozilla’s Manifest v3 FAQ

#43

Post by WhatIsDukkha »

beacker wrote: post #37
WhatIsDukkha wrote: post #18

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…

> 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...

WOW that's awesome!

It's actually pretty close... no Vimium but ublock origin/matrix, tree style tab, privacy badger, browserpass

Here is what's in Sid -

https://packages.debian.org/search?suite=sid&searchon=names&...

Re: Mozilla’s Manifest v3 FAQ

#44

Post by cptskippy »

ohazi wrote: post #25

I hope the ad blockers completely abandon Chrome when this change gets pushed through, rather than attempting to work around it. 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.

Unfortunately the owners of the most popular adblocker have successfully created a revenue generating business out of adblocking and aren't about to abandon Chrome.

Re: Mozilla’s Manifest v3 FAQ

#45

Post by michaelmrose »

Ajedi32 wrote: post #33
purple_ducks wrote: post #20

Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!): https://blog.chromium.org/2019/06/web-request-and-declarativ...

Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking? 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 s…

It doesn't lock down the ability of extensions to inspect and spy on all your traffic just block it. This in and of itself demonstrates the purpose.

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.

Re: Mozilla’s Manifest v3 FAQ

#46

Post by idbehold »

Ajedi32 wrote: post #33
purple_ducks wrote: post #20

Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!): https://blog.chromium.org/2019/06/web-request-and-declarativ...

Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking? 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 s…

Perhaps if Google got out of the ad serving business.

Re: Mozilla’s Manifest v3 FAQ

#47

Post by diablerouge »

jerf wrote: post #31
Nicksil wrote: 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 understand Google's motivation for nuking ad blockers, as well as their motivations for denying every which way that that is what they want to do under whatever security justifications they can bring up, even true ones. 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…

I think that's an important thing to remember - we can always fork it and move on if they choose to remove the blocking webrequest API.

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.

Re: Mozilla’s Manifest v3 FAQ

#48

Post by wtallis »

Ajedi32 wrote: post #33
purple_ducks wrote: post #20

Chrome's June 2019 statement about Manifest v3 in which they tell us all how much they really care about users and this totes isn't to weaken ad blocking(which directly affects their revenue - that's just a coincidence - pinky promise!): https://blog.chromium.org/2019/06/web-request-and-declarativ...

Here's an interesting thought experiment: what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking? 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 s…

> what would it take to convince you that this change really is being made for performance and security reasons, and not to hurt ad blocking?

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.

Re: Mozilla’s Manifest v3 FAQ

#49

Post by ferzul »

clairity wrote: post #35
Iolaum wrote: 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.

linkedin doesn't work for me on firefox, so i rarely even attempt to use it. but if someone a care about wants to link to me, i have to use chromium for that.

Re: Mozilla’s Manifest v3 FAQ

#50

Post by JohnFen »

jcranmer wrote: post #42
badsectoracula wrote: post #6

Earlier quoted context omitted.

Mozilla abandoning their much more powerful XUL-based extension system for Chrome's inferior WebExtensions wasn't already an indicator towards that?

It's been known since around 2010 or 2011 that the full extension system was too powerful for effective maintenance of Gecko. Going through XPCOM for everything prevents effective optimization within the codebase, and generally ensures that the APIs have to become less ergonomic compared to modern C++ (or JS, for that matter). Furthermore, multiprocess content tabs was heavily delayed because turning it on would brea…

> Moving away from that was definitely the right approach for Mozilla

Perhaps, but it also made Firefox into a browser that can no longer meet my needs.

Post reply on HN