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

21–30 of 111 posts

Re: Mozilla’s Manifest v3 FAQ

#21

Post by input_sh »

sorenjan wrote: post #14

> Cross-origin communication: In Manifest v3, content scripts will have the same permissions as the page they are injected in. We are planning to implement this change. What will this mean for GM.xmlHttpRequest in userscripts? Adding content from several different sites with userscripts can be very powerful.

Stylus (Stylish without the tracking) sure is a nice interface, but you don't really need an add-on for that functionality. Create "chrome/userContent.css" within your Firefox profile directory and populate it with something like:

    @-moz-document domain(example.com) {
        img { opacity: 0.05 !important; }
    }
Note that there's some about:config flag that needs to be switched since the version that got released today.

Re: Mozilla’s Manifest v3 FAQ

#22

Post by Nicksil »

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

Re: Mozilla’s Manifest v3 FAQ

#23

Post by SquareWheel »

jefftk wrote: post #15
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.

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

Re: Mozilla’s Manifest v3 FAQ

#24

Post by xg15 »

sorenjan wrote: post #14

> Cross-origin communication: In Manifest v3, content scripts will have the same permissions as the page they are injected in. We are planning to implement this change. What will this mean for GM.xmlHttpRequest in userscripts? Adding content from several different sites with userscripts can be very powerful.

Was wondering about that too - but this seems to be just a Spectre defense, not a change in what extensions can do.

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

Re: Mozilla’s Manifest v3 FAQ

#25

Post by ohazi »

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.

Re: Mozilla’s Manifest v3 FAQ

#26

Post by derefr »

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…

> a tiered App store

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

Re: Mozilla’s Manifest v3 FAQ

#27

Post by mjw1007 »

lol768 wrote: post #16
wtallis wrote: post #9

Earlier quoted context omitted.

It's basically the same as what happened two months ago with Firefox for Android being EOL'd pending a major re-write that may or may not support extensions. Mozilla is not willing to publicly commit to keeping their key features alive, and they keep hinting at the possibility that they will be leaving users behind in an attempt to be more like Chrome.

And the other point of view, directly from Mozilla: > 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/it…

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 early 2020), and there isn't currently a project in progress to add the necessary web-extension support to fenix.

Re: Mozilla’s Manifest v3 FAQ

#28

Post by derefr »

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.

Or, potentially, it's an equivocation because they want to give Google the appearance of maybe caving later (or at least the inability for Google to claim that they had the opposite appearance), while secretly hoping something changes such that they don't have to cave (and also, possibly, applying pressure below the radar to achieve that end.) Politics!

Re: Mozilla’s Manifest v3 FAQ

#29

Post by apazzolini »

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 switched from Chrome to Firefox a couple of months ago when the Chrome adblocking changes were announced.

I'll happily find something other than Firefox if it goes down the same route.

Re: Mozilla’s Manifest v3 FAQ

#30

Post by lol768 »

mjw1007 wrote: post #27
lol768 wrote: post #16

Earlier quoted context omitted.

And the other point of view, directly from Mozilla: > 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/it…

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?

Post reply on HN