Live data from Hacker News

Mozilla’s Manifest v3 FAQ

blog.mozilla.org

51–60 of 111 posts

Re: Mozilla’s Manifest v3 FAQ

#51
post #33

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

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 s…

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

A strong argument for how that change accomplishes those things, along with evidence.

Google has not been able to provide either of those things.

Re: Mozilla’s Manifest v3 FAQ

#52
post #33

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

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 s…

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

Re: Mozilla’s Manifest v3 FAQ

#53
post #33

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

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 s…

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

It's a fair question, but there are several of things that would at least help convince me.

They could demonstrate that they have tried all other solutions that would solve the security issue.

They could demonstrate that the performance benefits of the change would be bigger than the performance benefits of ad blocking.

They could implement a more performant/secure API that still allows full ad blocking.

They could build ad-blocking into chrome (doesn't seem likely to me, but it would convince me).

Re: Mozilla’s Manifest v3 FAQ

#54
post #50

Earlier quoted context omitted.

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 brea…

> Moving away from that was definitely the right approach for Mozilla Perhaps, but it also made Firefox into a browser that can no longer meet my needs.

What are your "needs"?

Perhaps it's your needs, not Firefox, that are incorrect.

Re: Mozilla’s Manifest v3 FAQ

#55
post #31
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 understand Google's motivation for nuking ad blockers, as well as their motivations for denying every which way that that is what they want to do under whatever security justifications they can bring up, even true ones. I don't see Mozilla's motivation to remove that at the moment. I mean, speaking for myself, I'd drop them both and follow a fork of the browser that lets uMatrix work, and that's not something I've…

The majority of funding Mozilla’s comes from Google, including receiving a portion of all ad revenue through google search.

A “adopt manifest v3 or we cut your funding in half” could be behind the scenes.

Re: Mozilla’s Manifest v3 FAQ

#57

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…

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

Yeah like the F-Droid [0] appstore ecosystem for Android.

[0] - https://f-droid.org/

Re: Mozilla’s Manifest v3 FAQ

#58
post #38
post #30

Earlier quoted context omitted.

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?

https://blog.mozilla.org/futurereleases/2019/06/27/reinventi... says they were planning in June to have a "feature-rich, polished" fennec release "this fall". https://github.com/mozilla-mobile/fenix/issues/879 "[Meta] Fennec -> Fenix Transition" appears to say the transition will happen in Q4 2019. The Android releases of fennec used to be updated for each Firefox release, but moved to ESR with the most recent ESR re…

GV is short for GeckoView, relevant-looking bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1468844

Apparently they are using "Raptor" for testing (https://wiki.mozilla.org/TestEngineering/Performance/Raptor) which includes a webextension, and they fix that area of the webextension API when it breaks. But in https://bugzilla.mozilla.org/show_bug.cgi?id=1562844 they mention that many components of Fennec are not implemented in GV so the corresponding API is broken.

I'm guessing the work is mostly about enabling the addons manager, so it might fit in Q4 or it might not. But it is worrisome that it isn't marked as blocking the transition.

They've already released fenix as a separate app: https://play.google.com/store/apps/details?id=org.mozilla.fe...

I would rather they call it "Firefox Lite" (in a nod to Facebook Lite etc.) and used some in-app notifications than to try to mass migrate with a version update as it seems they are plotting to do.

Re: Mozilla’s Manifest v3 FAQ

#59
post #33

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

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 s…

If the observational web request API was also deprecated, that wold be a strong indicator that Google's intentions were good.

If Gorhill (and other extension developers) endorsed the changes, that would be a strong indicator to me consider that they might be user-friendly, and that the concerns about them were overblown.

Google could also theoretically just convince me outright. They would need to convince me that extensions were currently hurting my privacy, security, and web experience more than ads. That would be very difficult, but theoretically possible. A blog post that solidly addressed critics point-by-point, rather than simply saying, "no that's wrong", would go a long way.

It's not helpful to Google now, but if the Chrome team built up a reputation for being more thoughtful, I also wouldn't be more likely to take them at their word in the future. I've written about this in the past, but Chrome has been handling developer criticism poorly for a pretty long while, and that pattern eventually reduces developer goodwill. When it comes to trust, everyone is a Bayesian.

That doesn't mean I don't try to consider their arguments, and it doesn't mean by default I assume the worst, but I'm only considering Google's arguments on their own merits. If the changes don't make sense to me, I'm not going to assume by default I should accept them anyway. They can't just say, "trust us, we've seen the numbers."

Re: Mozilla’s Manifest v3 FAQ

#60
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?

Post reply on HN