[HN Gopher] Manifest v3 in Firefox: Recap and Next Steps
___________________________________________________________________
Manifest v3 in Firefox: Recap and Next Steps
Author : TangerineDream
Score : 86 points
Date : 2022-05-18 17:17 UTC (5 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| rektide wrote:
| Murdering userscript extensions & dynamic code is such a sad
| thing to declare a win. There's so much FUD being used to scare
| the web into accepting so many sad new limits. I detest this
| technical fearocracy.
| Vinnl wrote:
| What do you mean when referring to userscript extensions and
| dynamic code?
|
| The latter I think refers to being able to execute code that is
| fetched at runtime? That certainly makes things a lot easier
| for developers, but I don't quite see what limits that imposes
| for users?
| rektide wrote:
| There's a range of different ways to author & uses for
| dynamic code.
|
| In terms of use cases, downloaded on the fly code is
| definitely one example. Userscript engines like Greasemonkey,
| VioletMonkey, & TamperMonkey are all alao on the chopping
| block, which also allow user-edited code as well as
| downloaded code.
|
| There's also a huge range of uses for dynamic code in
| general. Data stores & engines will optimize performance by
| using the Function constructor[1]. Cant do that anymore:
| basic, sensible, multi-decade long optimizations are now off
| the table. Being able to use eval() to dynamically generate a
| complex expression- no longer allowed.
|
| It's bitterly ironic that Apple's prohibition against
| interpretters (a type of dynamic code) has held their
| platform back from allowing interesting things to run on iOS.
| Chrome's real rendering & js engines are blocked there.
| Because Apple says it's too unsafe to trust programs to do
| anything not statically defined, that only code that can all
| be fully read & understand is ok. Now here's Google & then
| Mozilla, bringing the exact same prohibitions against dynamic
| code to the web. At it's deepest heart. It's so ugly, so
| hypocritical, & so menacing & massive a threat to
| possibility, to extensions that can grow & develop.
|
| Long hope, but a deep one: I very much hope one day (far
| away) a semantic-web like world wide web might emerge, but if
| this sick knee-capping happens the browser will never be a
| viable place for user agency- which must be a dynamic &
| growable organic thingh never be tenable as a place where
| user agency can grow & flourish. Extensions are amazing, but
| if they're restricted to single-purpose little timmicks,
| unflexible static predefined capabilities, Google will have
| insured that the only thriving systems the world will get
| will be inside the data center. These restrictions mortally
| cripple user-agency, that which is most special & most dear
| about the web & what set it apart from conventional software
| applications.
|
| My open github issue[2] on this.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [2] https://github.com/w3c/webextensions/issues/139
| user3939382 wrote:
| The basic problem is that the average non-technical user
| lacks the knowledge that these policies exist, much less
| their deleterious effects. This is the problem with some of
| the valid points RMS has been raising for decades. Look at
| dragnet surveillance- ask the average person who Snowden
| is.
|
| Unfortunately I don't see that changing, especially since
| you can see the same dynamic in (nearly?) every other
| industry. The industry engages in widespread practices,
| sometimes legitimized by corrupt laws via regulatory
| capture, that harm our society and everyone is too busy
| trying to put food on the table to notice.
| shadowgovt wrote:
| Honestly, Mozilla's approach here is sound: they create a
| potential competitive edge by _not_ removing the existing APIs,
| betting that the good outweighs the harm.
|
| I hope it does!
| rektide wrote:
| No, Mozilla is imposing the same brand new restriction
| against dynamic code (eval, Function[1]) as Google & has no
| affordances to allow this sometimes performance-critical &
| creatively necessary set of capabilities. Extensions can no
| longer grow & evolve, turning back multiple deacdes of
| possibility.
|
| [1] https://exploringjs.com/impatient-js/ch_dynamic-code-
| evaluat...
| SemanticStrengh wrote:
| fearocracy is a nice term
| [deleted]
| freediver wrote:
| As a developer of a browser supporting WebExtensionsAPI, the move
| to v3 is going to add so much complexity.
|
| For developers, maintaining browser extensions across browsers
| with different support for WebExtensionsAPI is going to become a
| major PITA.
|
| Even right now one can not submit a new Chrome extension unless
| it is v3 so that means that extensions codebases have to be
| branched out for Firefox and Chrome which was not the case
| before.
|
| The hardest will be on the browser side of things. Supporting
| both v2 and v3 sides of an already extremely complex API (which
| is what we plan to do) will be causing a lot of issues.
|
| The situation is not good. The lack of standard and unity does
| not help the web.
| dathinab wrote:
| > extension unless it is v3
|
| As far as I understand the move to V3 from Firefox means will
| be able to ship the same App for chrome and Firefox.
|
| Firefox just supports some additional APIs which are essential
| for good AD blockers Google killed.
|
| But if you don't need this additional API (or don't have the
| time to support them) you could just ignore them.
|
| That is once the move to v3 fully succeeded.
|
| > The situation is not good.
|
| Yes the way Google turns Chrome into a de-facto standard
| sidestepping or force feeding normal standardization procedures
| is not good.
|
| (Slightly over simplified:) Like the most common problem with
| running Firefox is that it's more strict with CORS related
| stuff, like the standard originally intended, but ups, Chrome
| had already implemented less strict checks and didn't want to
| brake any websites so that became part of the standard to (i.e.
| the more strict part became optional).
| mhitza wrote:
| Unfamiliar with WebExtensions API, but is there no polyfill
| type tool for the v2/v3 API, which can be specified at "build"
| time?
| daveidol wrote:
| No, for certain changes in Manifest V3 there is no way to
| polyfill the V2 API because the functionality is essentially
| removed/impossible to do now.
|
| Also, other aspects (like switching from background pages to
| service workers) require a change in programming model
| (moving from simple variables to message passing/persistent
| storage) as your service worker can be killed off at any
| time.
| dathinab wrote:
| > No, for certain changes in Manifest V3 there is no way to
| polyfill the V2 API because the functionality is
| essentially removed/impossible to do now.
|
| But isn't the whole announcement about Firefox also going
| to support v3 (e.g. you only need to write for v3) except
| that it still allows some of the removed functionality
| _additionally_ to the v3 APIs Chrome has?
|
| > Also, other aspects [..]
|
| Yes, that will be a major change. But as far as I
| understand one you have to go through anyway if you want to
| support Chrome.
| bayindirh wrote:
| Good things in browser space came out of sparks created by
| opposing forces' clashes.
|
| When everybody does the same thing, different ideas can't take
| root and express themselves, and we can't create even better
| ideas.
| prox wrote:
| The existence of a monopoly does not help the web.
| falafelite wrote:
| I'm in the same boat and feel the same. It's just not a great
| state of things for extension development, and yeah the
| separate Firefox and Chrome code in my codebase truly irks me.
| worble wrote:
| The fact that Firefox is standing up to Google and their
| crippling of WebRequest is a good thing, for users at least.
|
| The alternative is not "unity", it's Google dictating standards
| that only ostensibly help them and their ad business.
| Confiks wrote:
| It would aid communication if Mozilla would denote the maintained
| support for blocking `WebRequest` in the version number.
| Unfortunately `manifest_version` is a number, not a string, but I
| guess naming it 4 would clarify things plenty by annoying the
| standards process _just_ enough.
| wolpoli wrote:
| > Mozilla will maintain support for blocking WebRequest in MV3.
|
| Glad to hear that uBlock Origin will live on in Firefox.
| foepys wrote:
| I have a slight hope that gorhill will just remove the Chrome
| extension which might get users back to Firefox. It's next to
| useless with Manifest v3 and has been quite constricted for a
| while now when being used in Chrome [1].
|
| 1: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-
| works-b...
| donmcronald wrote:
| > Ability to uncloak 3rd-party servers disguised as 1st-party
| through the use of CNAME record.
|
| I always thought that would be the evolution of ads, but
| didn't realize it was already fairly widespread.
|
| Maybe it's time for me to look at switching back to Firefox.
| I ditched them when they pushed so hard for DoH which looks a
| lot like ad delivery tech to me. I thought Microsoft would
| give users a good experience with Edge since they should be
| trying to gain market share, but that was totally wrong. It
| pushes Microsoft accounts and affiliated products _super
| hard_.
|
| Does anyone have a recommendation for a plain, un-Googled,
| Chromium browser on Windows. I'd prefer something digitally
| signed and without extra features like Brave, etc. have.
| brobinson wrote:
| The only pushback I saw on DoH was from network admins who
| want DoT so they can MITM/block it easily. Firefox lets you
| set the DoH endpoint anyways so you can run your own
| resolver (dnscrypt-proxy or whatever).
| Gare wrote:
| > I ditched them when they pushed so hard for DoH which
| looks a lot like ad delivery tech to me.
|
| It looks like privacy-enabling tech to me. I don't want my
| ISP to snoop which domains I visit or hijack DNS requests.
| krono wrote:
| The untouchable foreign databroker that is Google
| concerns me to a far greater degree than my heavily
| regulated and monitored ISP whose HQ is only a 30m bike-
| ride away here in the Netherlands.
| sp332 wrote:
| Firefox doesn't have Google on their preinstalled DoH
| provider list. You can go out of your way to configure
| it.
| BuckRogers wrote:
| Just one man's opinion here but on these-
|
| _It pushes Microsoft accounts_
|
| I use it on my work machine without an account, and there's
| no push that I could ever see. Seems about the same on that
| front as anything else, including Firefox. I also have a
| Firefox account. I do use a MS account on my personal Edge
| install.
|
| _and affiliated products super hard._
|
| You would think this is a negative, but it opened my eyes
| and saved me a lot of money. In fact, Edge's shopping
| features were something I wish I had for years prior. I
| liked it enough that I went looking for best-in-class
| options, and ended up installing Honey. I now rely on both
| Honey and Edge's shopping features to save me money.
|
| I would go so far as to say if I had to leave Edge and use
| a browser without Edge's shopping features, I'd be one of
| the features pulling me back to Edge.
| e2le wrote:
| uBlock Origin and other content blocker extensions have 10+
| Million users each on Chrome, it'll be interesting to see
| what happens when they eventually to cease to function (June
| 2023). How will users react?
|
| Hopefully, Mozilla won't be completely inept as to fail to
| position themselves to capture any users leaving Chrome over
| this.
| daveidol wrote:
| Yeah, didn't gorhill already say that uBlock Origin will never
| be ported to Manifest v3 due to how much he'd have to cripple
| it?
|
| That means that very soon all Chrome (and Edge) users will no
| longer have uBlock Origin, and Firefox will be the only way to
| run it officially.
|
| This could be a pretty decent value prop for Firefox (bigger
| than the random features Mozilla has been pushing recently
| IMO)... Although I'm sure the majority of less technical Chrome
| users will just switch to whatever gimped, Chrome-sanctioned
| declarativeNetRequest ad-blocking extensions spring up to fill
| the void.
| SemanticStrengh wrote:
| > didn't gorhill already say that uBlock Origin will never be
| ported to Manifest v3 due to how much he'd have to cripple
| it? I don't think that is up to date
| pictur wrote:
| why are these manifest files a complete mess? I really don't
| understand how they manage to complicate something so simple
| freediver wrote:
| Different tech companies, that are also major browser
| manufacturers, have a radically different vision of what the
| web should be and how it should be consumed.
| djbusby wrote:
| Maybe it's not actually simple?
| guelo wrote:
| Here they defend the decision to adopt WebExtensions even though
| they're now reduced to chasing Chrome's whims. But maybe all the
| disruption and pain can be justified because there has been a
| flood of cross-platform plugins that were previously unavailable
| in Firefox. I don't have any data but my sense is that there are
| a lot fewer extensions than their used to be. There is definitely
| less plugin innovation happening since, as with most Google APIs,
| it is less powerful, less transparent, more locked down. There is
| also the question of differentiation, what is Firefox's value if
| it is but another Chrome clone?
| sp332 wrote:
| It's a superset of Chrome's functionality. E.g.
| https://github.com/w3c/webextensions/issues/134. The Web
| Extension API in Firefox is generally a lot bigger than
| Chrome's, so there's plenty of differentiation and I wouldn't
| call it a clone.
| nbp wrote:
| "[...] by virtue of the combined share of Chromium-based
| browsers, will be a de facto standard for browser [...]" -- i.e.
| The web is dead.
|
| Please consider switching to a non-Chromium-based browser if you
| want it back.
| shadowgovt wrote:
| If "the web" in this case means "several incompatible standards
| I have to adopt to work on all likely users' browsers," I won't
| miss _that_ web.
|
| If "the web" means "There are a few standards different
| implementations conform to, and if I adopt those standards I'm
| compatible with those implementations," I don't see it dead in
| the adoption of MV3.
| zamadatix wrote:
| It's not really about whether it's Chromium based or not it's
| about what the fork does once it's disabled in Chromium.
| [deleted]
| wolpoli wrote:
| Microsoft Edge will stop running Manifest v2 on January 2023 [1],
| or 6 months from now.
|
| [1]: https://docs.microsoft.com/en-us/microsoft-
| edge/extensions-c...
| anaisbetts wrote:
| This is the day I move off of Microsoft Edge, uBlock Origin is
| a Required Extension imho
| lapcat wrote:
| As an extension developer, I see a catastrophe coming for
| extensions in Chromium browsers. I don't think users are going
| to be prepared for the slaughter. You're going to lose a ton of
| extensions, and many others will be hobbled by manifest v3.
|
| Firefox and Safari should be ok at least in the immediate
| future. I doubt Apple is going to announce next month at WWDC
| that v2 extensions will be dead in September 2022, even before
| Chrome kills them in 2023.
|
| v3 is not even _ready_ yet. There are still major bugs and
| missing features, which Mozilla 's blog post alludes to. I'm
| postponing the migration myself as long as possible.
| wildrhythms wrote:
| What's the uBlock Origin equivalent for Safari? Every time I
| think about switching to 'the better browser on my Mac' I
| find there is no such replacement.
| fiddlerwoaroof wrote:
| I find 1Blocker is sufficient, even if it's not as flexible
| as ublock origin. I like that Safari's content blockers are
| designed to make it easier to trust them (e.g. you don't
| have to trust that they don't send your browsing history to
| a server, because they cannot make network requests)
| lapcat wrote:
| There's no equivalent for Safari. There are a number of
| Safari content blockers, but the API is strictly limited.
| It's somewhat similar to declarativeNetRequest in Chrome
| manifest v3.
| WalterGR wrote:
| Can anyone explain the "Manifest" in the name "Manifest v3"?
|
| Sure, extensions have manifests, but clearly the project is about
| much more. It seems like... an odd choice.
| anaisbetts wrote:
| In this case, you can think of it as the API surface exposed to
| Chrome/FF extensions, or akin to the iOS version/Android API
| Level - it fundamentally affects what an extension can Do
| lapcat wrote:
| The manifest.json file of an extension has a key
| "manifest_version" which for many years had the value of 2. You
| set the value of "manifest_version" to 3 to signify to the
| browser that your extension adopts the new API.
|
| The name is very meaningful to extension developers. To others,
| perhaps not.
| WalterGR wrote:
| Sure. It's just odd synecdoche.
___________________________________________________________________
(page generated 2022-05-18 23:00 UTC)