[HN Gopher] Mozilla solves the Manifest V3 puzzle to save ad blo...
___________________________________________________________________
Mozilla solves the Manifest V3 puzzle to save ad blockers
Author : Vinnl
Score : 142 points
Date : 2023-02-18 18:45 UTC (4 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| ravenstine wrote:
| What's even the point of disabling Manifest v2 in Firefox? Is
| there something wrong with it or _that_ significantly different
| that Firefox can 't support aspects of both v2 and v3? Having
| just made a Manifest v3 extension for Chrome, I don't really see
| how it's so wildly different that Firefox would have to do that
| much to support it. What am I missing?
|
| The world of software sure is good at "fixing" things that aren't
| broke.
|
| Also, this article doesn't seem to make it clear what Firefox is
| doing to "save" ad blockers other than continue to support
| Manifest v2. If they're making ad blocking possible with v3,
| there doesn't seem to be a lot of detail around it. Yes, I can go
| research it, but the point of articles like these should be to
| aggregate that information so people don't have to do all the
| work for themselves.
| whstl wrote:
| The problem is that Google removed a very important API that is
| crucial for ad blockers. They did that change along with the
| update to Manifest V3. Mozilla is trying to do the right thing
| by implementing Manifest V3 without the problem introduced by
| Google. It will "save" ad-blockers by _not_ removing a specific
| API that is important for them.
|
| Firefox will keep supporting both V2 and V3. They want to
| implement V3 in order to avoid forcing most developers to have
| different manifests for different browsers. This is a good
| thing in general.
|
| If you want details on what Mozilla is doing, here's a snippet
| from the linked blog post:
|
| _> While other browser vendors introduced
| declarativeNetRequest (DNR) in favor of blocking Web Request in
| MV3, Firefox MV3 continues to support blocking Web Request and
| will support a compatible version of DNR in the future. We
| believe blocking Web Request is more flexible than DNR, thus
| allowing for more creative use cases in content blockers and
| other privacy and security extensions. However, DNR also has
| important performance and compatibility characteristics we want
| to support._
|
| https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signi...
| [deleted]
| pancrufty wrote:
| Chrome has a hard wall around some features like
| chrome.scripting and promised APIs (MV3-only) but Firefox
| doesn't.
|
| It seems that Firefox is keeping around the same MV2 APIs so
| Firefox extensions will eventually be able to update the MV
| number with no effort.
| waboremo wrote:
| Your answer is hiding in your comment. You wrote a Manifest v3
| extension instead of a v2. If Firefox, an underdog, wants to
| maintain compatibility, they're going to have to adopt v3.
| However, they don't want to adopt v3 with the blocking choices
| Google has made. So they had to do this, unless they wanted
| Firefox to fade into further irrelevance through extension
| developers refusing to support it.
|
| Also, technically, Firefox is supporting both 2 and 3, their
| solution here isn't magical wizardry. It's just maintaining
| those specific features (blocking Web Requests) on top of
| adopting 3.
| denton-scratch wrote:
| > Also, this article doesn't seem to make it clear what Firefox
| is doing to "save" ad blockers other than continue to support
| Manifest v2.
|
| Yeah, that's a misleading title; the authors explain why
| extension-writers are going to switch to the "common platform",
| which will be V3, whatever Mozilla (or AdGuard) do.
|
| I was looking for an account of some cool Judo move that
| Mozilla had pulled off, to draw the teeth of V3. That's not
| what it's about.
| morelinks wrote:
| uBlock Origin Lite has been a good solution this far. It might
| not be as robust as uBlock Origin, but I fear less for the future
| that it's here.
| wkat4242 wrote:
| They did just kill bypass-paywalls-clean though. On desktop you
| can sideload it but on mobile you can't. They're not in my good
| books for a while.
|
| https://news.ycombinator.com/item?id=34774950
| [deleted]
| shadowgovt wrote:
| So what did Mozilla actually do here? The blog post never gets to
| the point.
| dang wrote:
| We've changed the URL from https://adguard.com/en/blog/firefox-
| manifestv3-chrome-adbloc... to the older blog post suggested by
| https://news.ycombinator.com/item?id=34850531 and
| https://news.ycombinator.com/item?id=34850753.
|
| Does that help?
| hoffs wrote:
| It's worse
| lapcat wrote:
| No? The submission was for a blog post from 2 days ago by
| AdGuard, and now you've made it into a blog post by Mozilla
| from last year. That's a pretty extreme change. The Mozilla
| blog post gives some background, so why not just post that
| link instead of changing the whole submission?
|
| This was a mistake, dang. Not to mention it doesn't have
| (2022). Which it didn't need, before you changed the link.
|
| The AdGuard blog post has details that the Mozilla post
| doesn't, such as a specific discussion about ad blocking, as
| well as recent developments in Chrome's deprecation timeline.
| hypothesis wrote:
| Basically they had to rewrite everything just to get the same
| functionality? What a giant waste of everyone's time... which is
| probably one of bigCo goals: keep churning, so that people with
| less bandwidth are forced to deal with churn instead of improving
| their product.
| pancrufty wrote:
| That wasn't the intention obviously. You may call it
| shortsighted, but they certainly wanted to kill the old
| platform and start fresh. Only now we know that wasn't as easy.
|
| In reality we should be thankful that it hasn't happened (yet)
| rather than bashing the choice to keep MV2 around longer. They
| could very easily pull the trigger, I don't think many will
| actually switch to Firefox just for that. Most won't even know.
|
| As a product manager, I don't know what they're waiting for
| exactly.
| [deleted]
| taeric wrote:
| I mean... Valid criticism in many ways. But also not something
| that is unique to the big companies. Or computers, for that
| matter.
|
| And there is a chance we can take learnings from the last
| attempt and improve in them.
| superkuh wrote:
| > Unfortunately, Google has made many decisions about the design
| of its new platform without taking into account the wishes and
| concerns of extension developers and, in the end, their own
| users. As a result, ad blocking extensions will lose some of
| their functionality.
|
| Basically the same thing that happened to Firefox extensions when
| they abandoned the entire old ecosystem and switched to Chrome's
| webextension. And now that they're stuck with that choice they're
| happy about mitigating even more damage to add-ons caused by it.
| This is not so much a win as a holding action after a bad choice.
| kibwen wrote:
| The idea of a well-defined extensions interface is not a bad
| idea. In fact, it's a very good idea. For as much power the
| old, everything-goes extensions model gave you, it also
| meaningfully prevented Firefox from evolving for years.
| Remember that decade where Firefox shed market share to Chrome
| for being too "slow" and "bloated"? Yeah, and it was that way
| because Mozilla couldn't change a damn thing without half of
| the entire extensions ecosystem imploding with every release.
| You need a well-defined API if you want to have any hope of
| improving the browser without breaking the whole world every
| week. Chrome had such an API, and it was popular, so Firefox
| lifted it. That's not nefarious, that's just smart. I'm happy
| that they managed to pull it off, and I'm happy that
| alternative browsers continue to exist in order to resist
| Google's death grip on the web.
| eitland wrote:
| > Remember that decade where Firefox shed market share to
| Chrome for being too "slow" and "bloated"?
|
| Except it wasn't. I used Firefox a lot on Windows and Linux
| and didn't have the slightest problems.
|
| The only reason I see why Chrome took over was a rather
| insane push, about the same level of intensity as IE6, from
| Google, using everything:
|
| - artificially reducing performance of Firefox on key Google
| properties (Google Calendar, YouTube)
|
| - bundling Chrome with Adobe
|
| - ad campaigns on the front of Google where no one else has
| been allowed to serve ads (this alone must have been worth
| billions)
|
| - lies ("switch to a better browser" they wrote even when I
| was using Firefox)
|
| Google needs to be punished - big time - for this abuse.
| dmitriid wrote:
| They keep doing it:
| https://twitter.com/dmitriid/status/1625756307297914883
| Miraste wrote:
| Firefox was slower than other browsers at the time. A lot
| slower, and buggier. There are plenty of benchmarks. I'm a
| Firefox user now, but before Quantum I didn't touch it
| because it really was terribly dated.
| adra wrote:
| If they cared and their slowdowns were simply related to
| addons, they could always sample the overhead of said addons
| and show a warning. My moderate use of addons in FF didn't
| feel too aggressive, but then again I'm not in the clique
| with dozens of open windows. There were times of
| fast/slowness in FF. It was never bad enough to chase me off
| the platform, but to say the slow ess was simply saddled on
| addons is probably disingenuous.
| Karellen wrote:
| It's not that the addons were slow. It's that the
| architecture in Firefox that was needed to support the
| addons was slow - even if there were no addons in use.
| spiffytech wrote:
| The slowness wasn't caused (just) by slow addons. As I
| remember it, Firefox was unable to move to a multi-process
| architecture as long as old extensions were supported.
| mook wrote:
| My recollection was that they had some multi-process
| things, though the problem was that they had to keep
| breaking extensions as they added more and more. I
| believe multi-process NPAPI plugins was somewhere around
| 3.6 or 4? (Of course, 4 took forever to ship too... that
| was great for extensions though, because it meant no API
| breakage during that time.)
| adjav wrote:
| It's not that the add-ons were slow, it's that the
| architecture built to support those add-ons made the
| browser as a whole inherently slow. Everything was quite
| siloed, and required a series of dynamic dispatches to
| accomplish anything. This allowed extensions to easily
| change lots of core functionality, but also meant that the
| entire Firefox codebase had become a public API, and
| practically any change made would break something.
| [deleted]
| 2h wrote:
| > The idea of a well-defined extensions interface is not a
| bad idea.
|
| when I am forced to register on addons.mozilla.org, just to
| install an extension that I wrote, yes, that is a bad idea.
|
| Give users the option to say "yes, I understand that this is
| not an 'approved' addon. install it anyway"
| modo_mario wrote:
| >Remember that decade where Firefox shed market share to
| Chrome for being too "slow" and "bloated"?
|
| The only part I remember where Firefox was notably slower was
| videos when Google led Firefox for a ring around the rosie
| when they singlehandedly decided to use a proprietary codec
| for their youtube videoplayer after first making everyone
| believe they were working on using a different one which FF
| started working on supporting. I can't count the amount of
| complaints i heard of firefox being slow there.
| lapcat wrote:
| > This is not so much a win as a holding action after a bad
| choice.
|
| That choice was made over 7 years ago. It may or may not have
| been a bad choice, but at this point Firefox is well beyond the
| "mitigation" phase of its previous add-on API migration.
|
| As an extension developer myself, I was happy that Chrome,
| Firefox, and Safari all had similar implementations with
| Manifest V2. Now it's in a very awkward phase again.
| foepys wrote:
| > Now it's in a very awkward phase again.
|
| Only because we allowed a single browser engine to become a
| quasi-monopoly _again_. Google doesn 't need to adhere to
| addon standards, Google sets them.
| phpisthebest wrote:
| you can not have both competition in the browser market, and
| every browser being the exact same all the time...
|
| I prefer less monopoly and more competition
| lapcat wrote:
| > you can not have both competition in the browser market,
| and every browser being the exact same all the time...
|
| Are you claiming that there can't be such a thing as web
| standards? HTML?
|
| Why would an extension standard be any different from an
| HTML standard?
| gorhill wrote:
| > It may or may not have been a bad choice
|
| It was a necessary choice, the previous framework for
| extensions was not multiprocess-compatible.
| whstl wrote:
| The important information referenced in the current article by
| AdGuard is in this link by Mozilla:
|
| https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signi...
|
| Posting it here since there's a lot of questions being asked here
| in HN that are answered by the post.
| dang wrote:
| Ok, we've switched to that URL from
| https://adguard.com/en/blog/firefox-manifestv3-chrome-
| adbloc.... Thanks!
|
| I guess we'll keep that article's title though (in de-baited
| form) because "Manifest v3 signing available November 21 on
| Firefox Nightly" would trigger weird responses.
| TrianguloY wrote:
| And how did Firefox solved it? I only found it mentioning that
| Firefox will continue to support V2, but that's not a solution.
| johnny22 wrote:
| they're supporting manifest v3 fully, but not removing the
| thing that breaks the better content filtering.
| dmix wrote:
| It's explained here
|
| https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
|
| And here
|
| https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...
|
| Firefox kept support for Event Pages which get direct access to
| DOM and WebAPIs in the background as well as Web Requests, both
| of which are not available via Chrome's use of service
| workers/restricted request API
|
| > "One of the most controversial changes of Chrome's MV3
| approach is the removal of blocking WebRequest, which provides
| a level of power and flexibility that is critical to enabling
| advanced privacy and content blocking features. Unfortunately,
| that power has also been used to harm users in a variety of
| ways Chrome's solution in MV3 was to define a more narrowly
| scoped API (declarativeNetRequest) as a replacement. However,
| this will limit the capabilities of certain types of privacy
| extensions without adequate replacement.
|
| > Mozilla will maintain support for blocking WebRequest in MV3.
| To maximize compatibility with other browsers, we will also
| ship support for declarativeNetRequest. We will continue to
| work with content blockers and other key consumers of this API
| to identify current and future alternatives where appropriate.
| Content blocking is one of the most important use cases for
| extensions, and we are committed to ensuring that Firefox users
| have access to the best privacy tools available."
|
| I hope FF gets service workers going soon, I haven't followed
| development closely so I'm not sure what's holding them back
| besides not wanting to replace Event Pages entirely with it
| [1]. I tried to build a (non-complicated) extension recently
| and the service worker API seemed cleaner and modern.
|
| 1 https://github.com/w3c/webextensions/issues/72
| whstl wrote:
| From the blog post linked in the article:
|
| _> While other browser vendors introduced
| declarativeNetRequest (DNR) in favor of blocking Web Request in
| MV3, Firefox MV3 continues to support blocking Web Request and
| will support a compatible version of DNR in the future. We
| believe blocking Web Request is more flexible than DNR, thus
| allowing for more creative use cases in content blockers and
| other privacy and security extensions. However, DNR also has
| important performance and compatibility characteristics we want
| to support._
|
| https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signi...
|
| So, in a nutshell, they won't deprecate an existing working
| API, like Google did. But they will _additionally_ support the
| new API.
| gpvos wrote:
| That's not in the featured article, so why isn't a more
| informative article linked instead?
| whstl wrote:
| It was a blogpost linked in the article. My wording wasn't
| correct. I edited it to clarify.
|
| As for your question, that's a legitimate request. Maybe
| dang can change the link?
| shadowgovt wrote:
| The current API is a security hole.
|
| But that's fine. "It's incumbent on end-users to know what
| they're installing" is a fine position for Mozilla to take.
| dylan604 wrote:
| I can't tell if you're being sincere or sarcastic. Allowing
| users to install whatever they want at their own risk is
| exactly what people complaining about walled gardens not
| allowing them to do. Attempting to protect people that
| don't know what they are doing from known security holes is
| what one of the things walled gardens claim as a feature.
|
| Which direction are taking it?
| Miraste wrote:
| Being forced to see and potentially click on ads is a
| security hole. I trust uBlock and gorhill more than I trust
| Google.
| dang wrote:
| We've switched the URL to that post now - more at
| https://news.ycombinator.com/item?id=34851026. Thanks!
| butz wrote:
| It would be even better if they wouldn't force unnecessary and
| unremovable "Extensions" button on toolbar.
| parhamn wrote:
| A bit off topic but, but as a person who develops an extension
| and browser, another puzzle we need to solve is how to control
| and transparently log what these extensions are doing with your
| data.
|
| Cookie, storage, exported DOM reads, fetch requests, etc should
| all be logged in clear text (maybe even pass handlers that pull
| reduced data) for the user to audit.
|
| It blows my mind what any developer can do with extension apis.
| "This site can access data on this site" warning is not enough.
| 2h wrote:
| FYI Android Firefox, since version 68, only allows installation
| of addons that are on a certain whitelist. For custom extensions,
| they require you to register on addons.mozilla.org, even if you
| just want to install an extension you wrote yourself.
___________________________________________________________________
(page generated 2023-02-18 23:00 UTC)