[HN Gopher] Manifest v3 Update
___________________________________________________________________
Manifest v3 Update
Author : TangerineDream
Score : 107 points
Date : 2021-05-27 16:47 UTC (6 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| guilhas wrote:
| Can't wait for a better Firefox fork to take its place, maybe
| bring back browser addons
|
| Improve performance, reduce bugs, stop tying to badly implement
| existing community extensions. The UI also does NOT need more
| redesign
|
| Or maybe we just need a fresh new browser
| Yaina wrote:
| Maintaining a browser requires an _enormous_ amount of people.
| Building a new one or even forking existing ones is essentially
| impossible if you don 't have huge financial means.
|
| The only other companies doing it are among the richest
| companies in the world (Google and Apple). Wishing for fewer
| bugs and better performance isn't invalid, but you have to put
| the stuff Mozilla is doing into perspective. There are only so
| many things you can do.
|
| The addons post shows a compromise in trying to the keep
| browser compatible (even if that means adopting the `chrome.*`
| namespace and implementing stuff from Googles wishlist). But it
| also shows that where it matters -- where Google wants to abuse
| their market position -- they diverge from the spec.
| Yoric wrote:
| That sounds unlikely.
| osmarks wrote:
| This is probably impossible. Web APIs are too complex now.
| Nicksil wrote:
| >Google has introduced declarativeNetRequest (DNR) to replace the
| blocking webRequest API.
|
| ...
|
| >After discussing this with several content blocking extension
| developers, we have decided to implement DNR and continue
| maintaining support for blocking webRequest.
|
| We've seen this before -- a number of times. This is what's put
| forth to avoid a cacophony and push back from developers and end-
| users alike. Both technologies will be supported for a short time
| before blocking webRequest is taken out altogether at a
| relatively short time thereafter.
|
| >We will support blocking webRequest until there's a better
| solution which covers all use cases _we consider important_ ...
| (emphasis mine)
|
| And there it is.
|
| In a short time we'll read a statement -- released on a Friday
| afternoon -- stating the EOL for blocking webRequest with little-
| to-nothing in the way of analogous behavior because it wasn't
| considered important by Mozilla (or, perhaps, the pressure from
| Google was too much).
|
| That's my cynical, entirely pessimistic outlook of it all anyway.
|
| I'd like to read Raymond Hill's thoughts on this.
| tomjen3 wrote:
| That is a very cynical view. You assume Mozilla will give up
| their one huge advantage over Chrome (ie a browser where actual
| privacy is somewhat possible), you assume they will go about it
| in a round-about way.
|
| And you assume that nobody will fork it to keep webRequest.
| This seems strange as Firefox is itself a fork of Netscape
| create because the dominant browser was horrible to use.
| yjftsjthsd-h wrote:
| > That is a very cynical view. You assume Mozilla will give
| up their one huge advantage over Chrome (ie a browser where
| actual privacy is somewhat possible), you assume they will go
| about it in a round-about way.
|
| Yes? It would be the... third or fourth, I can't remember
| anymore, mass extinction event for extensions, and be
| consistent with previous instances of sidelining
| functionality before killing it (say, tab groups, which were
| native functionality, then moved to an extension, and then
| completely killed off in one of the aforementioned extinction
| waves). Previous behavior is an _excellent_ reason to be
| cynical.
|
| > And you assume that nobody will fork it to keep webRequest.
| This seems strange as Firefox is itself a fork of Netscape
| create because the dominant browser was horrible to use.
|
| I guess someone will, but they'll always lag, and accrue
| security flaws and bugs and missing features (ex. pale moon)
| since modern web standards helpfully move too fast to keep up
| with unless you're huge and/or making only the most minor of
| changes (and even then, really; icecat failing to keep up is
| a reasonable argument that it's impractical).
| Nicksil wrote:
| >And you assume that nobody will fork it to keep webRequest.
|
| No, I'm not sure how you got that idea. There are plenty of
| instances in the past where Mozilla/Firefox has been forked.
| wnevets wrote:
| If this wasn't Mozilla I would agree with your post. However I
| believe Mozilla killing support for the webRequest API without
| a suitable replacement would be suicide with its core user
| base. I know for me the moment uBlock Origin is crippled on
| Chrome is the moment I go Firefox full time. Browsing the
| internet without it is simply a non-starter
| jackewiehose wrote:
| > If this wasn't Mozilla ...
|
| They already disabled (private) extension support on the
| Windows build (you have to upload your extension to Mozilla
| servers) and they completely disabled extension support on
| Firefox mobile (no, that small list of approved extensions
| isn't enough). I'm not sure they care much about their user
| base.
| dralley wrote:
| I guess you're a Firefox user now?
|
| https://github.com/gorhill/uBlock/wiki/uBlock-Origin-
| works-b...
| Narishma wrote:
| > I know for me the moment uBlock Origin no longer works as
| well as it does on Chrome is the moment I go Firefox full
| time.
|
| Hasn't that been the case for a while now?
| wnevets wrote:
| As far as I've noticed uBlock Origin works just as well now
| than it ever has on Chrome. I've certainly haven't noticed
| a downgrade in performance or increase in adverts.
| matheusmoreira wrote:
| _Surely_ they consider uBlock Origin important. Right?
| Nicksil wrote:
| I'm actually a _bit_ optimistic about it. I know Mozilla has
| reached-out to uBlock Origin before (I believe it had
| something to do with uBlock Origin 's UI) in what I would
| consider to be a positive light.
|
| It's also why I'm very interested in hearing what, if any,
| Raymond Hill's (author of uBlock Origin) thoughts on this
| matter.
| Qub3d wrote:
| Yes, Gorhill has published the communication between him
| and Mozilla when working on the mobile UI for firefox
| Android. It was all pretty great to see.
| OJFord wrote:
| It's on the very short list of hand-picked available-on-
| Android (iOS doesn't allow it at all) extensions, so I think
| so.
| Semaphor wrote:
| I think it was actually the first extension available in
| the new FF Android version, it's availability was the
| reason for me to switch as I need no other extension on
| mobile.
| ufmace wrote:
| Maybe, but if they were going to do that, why bother telling us
| they were going to continue supporting blocking webRequest at
| all? They'd be in perfectly good company if they maintained the
| exact same API as all the other browser vendors and deprecated
| and turned off webRequest along with them. If they did this
| because they think they maintain a genuine business advantage
| from it, why would they change their mind and throw that away
| at some later date?
| Vinnl wrote:
| If Mozilla intended to remove blocking webRequest, sure, this
| is what it'd look like.
|
| However, if Mozilla intended to keep the option of blocking
| webRequest (or whatever's necessary to keep uBlock possible),
| it would _also_ look like this. It 's not an option for Mozilla
| not to support the Chrome API, because the entire point of
| WebExtensions is the admission that Chrome is the dominant
| browser, and extension makers will only consider porting to
| Firefox if it's as little effort as possible. Hence they need
| to support the same API's.
|
| Given that uBlock Origin was the first extension they added
| support for in Firefox for Android, I'm relatively confident
| that they're intent on making sure it stays able to do its job.
| nonbirithm wrote:
| > _extension makers will only consider porting to Firefox if
| it 's as little effort as possible. Hence they need to
| support the same API's_
|
| At least the last time I developed a browser extension, this
| was not the case. I found that what was considered the
| WebExtension API was not 100% portable across browsers, and I
| had to rewrite parts of my code between Chrome and Firefox
| because Chrome had many extra APIs that Firefox lacked.
| Yoric wrote:
| If you compare with attempting to share code between XUL
| addons and Chrome extensions, you'll notice that things
| have gotten muuuuuuuuch simpler, though.
| throwaway77112 wrote:
| Also ublock origin on Firefox has significant advantages over
| that in chrome
|
| https://github.com/gorhill/uBlock/wiki/uBlock-Origin-
| works-b...
| kgwxd wrote:
| If he's not one of the several content blocking extension
| developers they talked to, I'm just going to assume this is all
| going to end up very badly.
| jcranmer wrote:
| Your quote snipping here is somewhat disingenuous: > >We will
| support blocking webRequest until there's a better solution
| which covers all use cases we consider important ... (emphasis
| mine)
|
| The sentence continues: > since DNR as currently implemented by
| Chrome does not yet meet the needs of extension developers.
|
| That's an admission that webRequest won't be removed until
| there is something better than DNR on the table.
| Nicksil wrote:
| Not at all; I cover that when emphasizing "we consider
| important" (as well as including the ellipsis to indicate the
| continuation). I did not include it as it would have been
| redundant.
| Ajedi32 wrote:
| Seems like the best solution; maintain compatiblity with Chrome
| while keeping the more powerful APIs available for those who want
| to take advantage of it.
|
| If Google screws this up, more effective ad blocking extensions
| could end up being a good, concrete way for Firefox to
| differentiate itself from other browsers.
| ocdtrekkie wrote:
| Glad to see Mozilla is holding up it's independence on this key
| issue, whereas Edge chose to implement Google's changes as-is.
| whymarrh wrote:
| There could be a simple explanation for this: Mozilla has its
| own browser stack whereas Edge is Chrome.
| butz wrote:
| If all extensions are using same standard, what about possibility
| of "universal" extensions that run on any browser without
| changes?
| Macha wrote:
| So, running from the same source code? That's already the case
| for many extensions.
|
| Running from the same artifact is a bit harder as Chrome will
| only accept extensions signed by Google from the Chrome Web
| Store. I guess Firefox could let you install them, but then it
| leaves the possibility of installing an extension that is
| actually incompatible and confusing users.
| comfyinnernet wrote:
| >DNR as currently implemented by Chrome does not yet meet the
| needs of extension developers.
|
| "Yet"?
| livre wrote:
| I find it ironic that the only API Google decided to cripple was
| the one used for adblocking when there are countless of ways to
| exfiltrate data from an extension. I share the same pessimistic
| view as Nicksil with respect to Firefox, this is the direction
| Mozilla has been going with other parts of the browser.
|
| Edit: I know Mozilla said they are waiting for a better
| alternative, but any alternative that can be proposed will end up
| being less powerful than what we currently have.
| matheusmoreira wrote:
| Google's new extension interfaces are reasonable though. They
| really are more secure. I want extensions to have as little
| access as possible.
|
| uBlock Origin just happens to be important and trusted enough
| that these limitations should not be imposed on it.
| handrous wrote:
| If they're serious about keeping uBlock Origin around, and
| aren't just stalling while intending to remove what it needs
| eventually, they should agree to the new API for extensions
| ASAP... but make uBlock Origin part of the browser, and bring
| it under their wing (to whatever extent the author's willing
| for that to happen).
|
| Now _that_ would be an interesting and pro-user move that
| sets their browser apart from others.
|
| But it might piss off Google a little _too_ much, which is
| probably why they 've not made that or a similar move long
| before now. One of FF's earliest differentiators, before it
| was even _called_ Firefox, was a form of ad-blocking, after
| all (pop-up and pop-under blocking, which at the time mostly
| meant blocking really annoying ads)
| shawnz wrote:
| I don't think this would be the best thing to do for uBO
| users. This creates the possibility that the "Firefox
| internal uBO" could diverge in functionality from the one
| maintained by gorhill and get neutered by Mozilla managers.
|
| I think it is ultimately necessary due to the incentives at
| play that the adblocking technology can be delivered by any
| third party.
| handrous wrote:
| If other major browsers are cutting off critical
| functionality for it, the concern may be moot.
|
| As long as Mozilla aren't themselves in ad
| sales/brokerage I wouldn't be worried about a browser
| shipping an ad-blocker, as far as incentives go. Google
| doing it, that'd be concerning. Mozilla? Good.
|
| [EDIT] though actually this is another case of their
| relationship with Google being kinda crippling, since
| that _does_ introduce a conflict of interest... which is
| part of why Google does it, I 'm sure.
| ufmace wrote:
| I'd rather not make any one adblock extension the single
| blessed one that's included with browsers and given
| exclusive permission to actually block ads reliably.
| Browser makers and extension authors have gone bad before
| and surely will again. We need to retain the ability for
| anyone insufficiently satisfied with ad blocking
| effectiveness to be able to fork and deploy as a new
| extension with the same access to the browser as the last
| one.
| Wowfunhappy wrote:
| > but make uBlock Origin part of the browser, and bring it
| under their wing (to whatever extent the author's willing
| for that to happen).
|
| Great, and now websites are _actively incentivized_ to not
| support Firefox, because they 'll know Firefox users
| generate zero advertising revenue by default.
| matheusmoreira wrote:
| > but make uBlock Origin part of the browser, and bring it
| under their wing
|
| I totally agree with this. At this point uBlock Origin's
| technology is so important and essential it should be a
| standard feature of every browser. I've posted this many
| times before. People usually say that uBlock Origin is
| better off independent because Mozilla is funded by Google.
| yjftsjthsd-h wrote:
| Except that the new interfaces don't stop an extension from
| recording all of your activity, they _only_ break blockers.
| jackewiehose wrote:
| > Google's new extension interfaces are reasonable though.
| They really are more secure. I want extensions to have as
| little access as possible.
|
| Maybe then just don't install the extension -> voila, zero
| access given! Of course this is a stupid advice because
| obviously you want the working extension for some reason.
| Just like others want their extension to be able to do
| whatever it needs to get its job done.
| refulgentis wrote:
| I wonder if it's because it's the one API that gets a full
| firehose log of every single ask my browser makes for data
| Nullabillity wrote:
| The asynchronous API is still around and still gives you the
| firehose. Removing the synchronous API _only_ locks out
| adblockers.
| livre wrote:
| It is possible that that's the explanation but stopping just
| one API only affects people/extensions willing to follow the
| rules (uBlock Origin for example) while the bad players will
| just change a few lines and begin using other APIs. The end
| result is people are less protected because they have
| crippled adblockers and data can still be exfiltrated, and
| worse than that, malicious ads can't be prevented from
| loading anymore.
| [deleted]
___________________________________________________________________
(page generated 2021-05-27 23:00 UTC)