
Mozilla’s Manifest v3 FAQ - Findus23
https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/
======
WhatIsDukkha
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 store for browsers. Part of the lockdown Google wants to
do isn't wrong but its driven by having WAY too many bad actors and shoddy
developers in their Chrome store.

If you have an opensource web extension, a reasonable community and with
reproducible builds? You can use more powerful API versions.

If you are jrando bizplan #2000283 you get the kinda trusted tier.

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

~~~
beacker
> 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...](https://packages.debian.org/search?keywords=webext-&searchon=names&suite=stable&section=all)

~~~
WhatIsDukkha
WOW that's awesome!

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

<3

Here is what's in Sid -

[https://packages.debian.org/search?suite=sid&searchon=names&...](https://packages.debian.org/search?suite=sid&searchon=names&keywords=webext-)

------
danShumway
> 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 extensions to abandon
Chrome.

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

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

~~~
Jonnax
A rewrite that is faster than Chrome for Android.

~~~
hajile
It may be faster than Chrome on Android, but it's certainly not faster than
Firefox on Android with adblockers. Not loading/parsing multi-megabytes of
Javascript and images is huge. Loads of ads these days incorporate entire JS
framework toolchains resulting in a binary bigger than the page they're being
injected into. Eliminating a few ads and the rest of your browser could be a
lot less efficient and still perform well. That's all before discussing how
adblockers also reduce who is tracking you everywhere.

~~~
tgsovlerkhgsel
In my experience and limited testing, even with warmed-up caches, Chrome
(without Adblocker) was faster than Firefox (with or without Adblocker),
sadly.

I still use Firefox due to the security benefits of ad blocking, but I don't
find the experience particularly enjoyable (although, thinking of it, it may
have either significantly improved in the past ~half a year, or I just don't
notice because of a more powerful CPU in my new phone).

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

~~~
spinningslate
And in case anyone from Mozilla is listening, this could well be existential
for you. Right now, your pro-privacy stance is a principal factor in users
choosing Firefox over Chrome.

Follow Google - and all its shady practices - and you will lose a large chunk
of those users. Many of them, to use current terminology, are "key
influencers": technically savvy people who advise family and friends what to
do. Lose them and the outlook is, I suspect, pretty grim.

You're clever people. You'll know this. Google has a good few smart folk too
(even if their motivation is questionable). It's easy to see this is difficult
for you: Google is your primary funding source. Fail to comply with their
wishes, and that funding might well disappear.

As has been noted in other threads, the tension between privacy principles and
funding is a huge threat.

For the good of the open web, I desperately want a successful Mozilla, and a
technically excellent Firefox at the forefront of a pro-privacy, anti-
surveillance re-balancing of the internet.

I don't doubt the difficulty in filling a $300M funding hole. I'd gladly pay
$30 per year for a pro-privacy Firefox. Another 9,999,999 is a tall order. On
the other hand, you have c250M users...

~~~
mav3rick
This tech people influencing friends and family lore has been disproven many
times. No non tech user is using duck duck go.

~~~
Nicksil
Where are you getting this information? Plenty of "tech" people influence
their friends and family with respect to what software/hardware to consider.
My entire immediate family uses DuckDuckGo as their search. All of their
(Mozilla) browsers have DDG set as the default. Not a complaint from anybody;
DDG does a damn fine job.

~~~
mav3rick
One data point doesn't change the fact that HN hasn't mass converted the world
to use DDG. They may also be telling you they use DDG while they use !g or
Google.

~~~
danShumway
But similarly, one data point that DDG hasn't overtaken Google doesn't mean
that tech people's preferences don't influence ordinary people.

I thought it was generally well-accepted that developers mass-moving friends
and family off of IE 11 was part of the reason why other browsers ended up
beating it.

Similarly, I thought it was mostly accepted that part of the reason so much of
the web was optimized for Chrome was because Chrome had genuinely better
developer tools, and developers preferred to optimize first in Chrome and
second in other browsers.

Maybe there's more disagreement on those points than I realized.

Even on the subject of DuckDuckGo, which is probably not going to be mass-
adopted any time soon (if at all), actual usage numbers are increasing faster
than any other major search provider, including Google[0]. Whether or not
those numbers are coming from ordinary people or tech people, clearly somebody
is being convinced to use DDG. Is it going to be a revolution? Probably not.
But it's not nothing.

I really wish people would stop defining success as a monopoly. Even in the
browser space, the goal isn't to make Chrome vanish. We just want Firefox to
have a big enough user-base across enough markets that it can't be ignored.
Even 20-30% would probably do it. Mozilla doesn't have to kill Chrome.

Similarly, if every non-tech user keeps searching on Google, and DuckDuckGo
just becomes a great search engine that every programmer prefers, that's a
pretty big win. I would not call that a loss.

[0]: [https://duckduckgo.com/traffic](https://duckduckgo.com/traffic) (of
course saturation does play a role here)

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

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

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

~~~
flukus
Pretty much as soon as they added multi processor support they had to start
throttling background tabs anyway, same as chrome. It's not at all clear that
going multi process was a win. And years after they change their are still a
bunch of things extensions did that don't work anymore. I was never a huge fan
of XUL or any non-native UI, but it did it's job for years and it's
replacement doesn't.

And due to their follow google nature of monthly updates there's no stable
version to fall back on.

~~~
roca
Multiprocess was and is a huge win for performance, stability and security. In
the post-Spectre world it's essential.

------
purple_ducks
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...](https://blog.chromium.org/2019/06/web-request-and-declarative-
net-request.html)

~~~
Ajedi32
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 secure, user-friendly permissions systems _do_ have to be somewhat
restrictive in order to be effective (see Android, iOS, etc), and that ad
blocking extensions will necessarily be impacted as a result.

~~~
shawnz
#1: They would have to give a rationale for the change which actually makes
sense. The privacy explanation does not make sense because the observational
capabilities of the API are explicitly not being removed. Therefore there is
no benefit to user's privacy as a result of the changes. The performance
explanation also doesn't make sense if we look at the numbers that adblocker
vendors have been publishing in response to these changes.

#2: In light of the backlash to the proposal they would have to actually
consider not implementing the change or at least consider some alternative
implementations. So far all they have done is say "we've heard your concerns,
and we're just going to do it anyway". Many interesting ways have been
proposed to achieve the same supposed benefits as what Google claims manifest
v3 will provide. But they have not responded to any of those ideas and are
blindly persisting with their proposed model with all its downsides. So why
even act like this is some kind of open process which involves real
developers?

#3: They would need to demonstrate that they are actually concerned about the
ability of adblocker vendors to deliver good products. They could have created
a transition window from the old API to the new API to see in practice how
adblocker vendors choose to use it and what limitations they face. But they
haven't done that, instead they announce they're killing the old API the same
moment they introduce the new one. That to me demonstrates that they don't
really care if it's sufficient for those vendors or not.

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

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

------
feanaro
In the absence of a true standard for browser extensions, perhaps Mozilla
should consider trying to form one by leading with a strong example instead of
weakly implying that they will eventually probably cave to the monopolist.

It's also quite disappointing how there is seemingly no one from Mozilla here,
engaging with us on this topic. Instead, the only communication we get is one-
sided corporate speak, with no real ability to respond.

If anyone from Mozilla is reading, who do you think will spread Firefox among
non-technical users if not the type of crowd that frequents HN?

~~~
chucksmash
> In the absence of a true standard for browser extensions, perhaps Mozilla
> should consider trying to form one by leading with a strong example instead
> of weakly implying that they will eventually probably cave to the
> monopolist.

That's exactly what they've tried to do. Firefox exposes a `chrome` namespace
object to extensions which is intended to be more or less API compatible with
what Chrome provides and added the `browser` namespace object where
improvements to the base compatibility are added (e.g. switching from callback
based APIs to Promise based APIs). See the bit from the wiki below and the
link to the browserext spec:

> Mozilla has worked with Microsoft and Opera to implement browser extensions
> so that developers can write extensions that work across multiple browsers.
> The preliminary specification[1] matches what Google has implemented in
> Chrome so that extensions will work on Chrome, Edge, Opera and Firefox.[2]

[1]:
[https://browserext.github.io/browserext/](https://browserext.github.io/browserext/)

[2]:
[https://wiki.mozilla.org/WebExtensions/Spec](https://wiki.mozilla.org/WebExtensions/Spec)

~~~
feanaro
Well, it's not enough to try, unfortunately. They have to persist and this
talk about the importance of keeping compatibility with Chrome in the context
of blocking webRequest removal is not very encouraging.

------
muddi900
This is disappointing. Mozilla can't seem to make up their mind if they want
to offer a different product from google or just "Chrome, but for nerds"

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

~~~
xg15
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...](https://www.chromium.org/Home/chromium-security/extension-content-
script-fetches) .

------
SirensOfTitan
Mozilla really needs to get that if they compete with Google on Google’s
terms, they’re rapidly heading toward extinction.

Mozilla ought to be the browser for a private and usable web, but it seems
they have occasional sneezes where you question what they’re doing (this,
pocket in recent memory).

~~~
echelon
I'm extremely worried that once Google disables ad blockers in Chrome,
websites will wholesale block any and all non-Chrome browsers. Be it through
user agent sniffing, feature detection, or fingerprinting, Firefox simply
won't work anymore.

The future of the web where Google is in complete control is straight up
nightmare fuel. Microsoft in the early 2000s never scared me as much as the
future we're headed into does.

This won't be IE versus Netscape since websites are no longer served as plain
old HTML. They're messy, thick, and impenetrable javascript blobs--not
documents. We're not arguing about websites simply not rendering correctly in
the less popular browser. This is a battle for the absolute control over
information distribution.

What do we do to prevent what's happening?

Google already shot down XHTML, which was rich with semantics. That was a web
written for documents and tools that could query those documents for meaning.

Whatever Google has become needs to be dismantled. The ad company can't be the
browser company and phone company. It's a perverse alignment of incentives.

~~~
tomComb
> This won't be IE versus Netscape since...

Well, also since Chrome if open source, cross platform, and standards
compliant, and IE was none of those.

And Google (unlike Apple) allows competing browsers, based on modified Chrome
code, or entirely different engines.

Soon we will have a good, cross platform Edge browser, thanks to Google, and a
menu of browser options in Europe thanks to the EU. (Maybe other countries
should push for the same.)

But Chrome if no IE.

And I believe that in Europe they will soon be

------
rrix2
perhaps a more optimistic take on "no immediate plans": there could eventually
be an alternate standard for webrequest that addresses Chrome Devs' (perhaps
legitimate) privacy concerns around most extensions being able to sniff,
modify, and log all of your traffic on the entire web with a single,
unobtrusive modal click. There is room to make the web platform more secure
without stripping power from the user-agent, surely, or giving bad actors a
trivial foothold. Frankly, my concerns around the webrequest API are numerous,
the only reason IMO that Chrome isn't deprecating webrequest in Enterprise
builds is for corporate spyware.

At the very least a new webrequest spec that is more ergonomic and more safe
than the webrequest API (without neuturing adblock) could show whether the
emperor has no clothes, vis a vis "Google Adtech is directly influencing
Chrome and web platform development" plots

------
kup0
"no _immediate_ plans to remove blocking webRequest" ... yikes

------
levani
Really interesting what the new Edge is going to do in this regard...

------
phkahler
I dont like the idea of extensions being able to inject data in either
direction.

On top of that, I'm not in favor of extensions doing anything to improve
security - I want that in the base browser.

------
eh78ssxv2f
It seems I'm in a minority here, but I was never comfortable installing any
adblock extension because the existing request blocking API means that the
extension would see all web traffic generated by me (including private URLs
that are otherwise not known to anybody but me).

I personally feel that now with manifest 3, I can actually install adblockers
since the newer APIs do not share all my web traffic with the extensions.

Can somebody explain why removing blocking API was overall a bad decision by
Chrome?

~~~
gorhill
> the newer APIs do not share all my web traffic with the extensions

The webRequest API can observe the URLs you visit without needing blocking
permission.

And so does the webNavigation API, the tabs API, history API, content scripts,
possibly cookies API and whatever else does not come to my mind.

~~~
SquareWheel
Shouldn't those be visible in the permissions prompt, prior to installing the
extension?

------
michaelmrose
A humble proposal: A build of firefox that initially differs from Mozillas in
that

\- it has a different default search engine selection that can be sold in the
same way that Mozilla sells this same feature to google presently

\- no ads on new tab page

\- bundled with ublock origin

The goal being to increase the value of selling the search engine selection
while decreasing the value of mozillas in effect siphoning off some of the
value of mozillas primary revenue stream.

Such funds could be donated back to Mozilla or used to maintain a fork that
doesn't ruin adblocking. Their choice.

