Will the proposed Manifest V3 changes to Chrome break Privacy Badger?

zikalify commented 5 years ago

https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/

ghostwords commented 5 years ago

It's not entirely clear yet, but at this point it seems that the changes proposed in the Manifest V3 document are made to support basic list-based blockers only. It's not clear how Manifest V3 would allow for more complex extensions like uBlock Origin, uMatrix, or Privacy Badger. I would like to learn more about this situation from Chromium developers.

ghostwords commented 5 years ago

Devlin writes:

Our goal is not to break extensions. We are working with extension developers to strive to keep this breakage to a minimum, while still advancing the platform to enhance security, privacy, and performance for all users. ... The most helpful feedback for us is the exact cases that this would impact, their importance, and the reasons they are impossible through either the declarative API or through other extension APIs.

ghostwords commented 5 years ago

An overview of the Manifest V3 proposal's impact upon Privacy Badger

Privacy Badger is a browser extension that automatically learns to block invisible trackers.

Instead of keeping lists of what to block, Privacy Badger learns by watching which domains appear to be tracking you as you browse the Web. Privacy Badger sends the Do Not Track signal with your browsing. If trackers ignore your wishes, your Badger will learn to block them. Privacy Badger starts blocking once it sees the same tracker on three different websites.

The Manifest V3 proposal thoroughly breaks this description. It appears that Privacy Badger will no longer be able to dynamically learn to block trackers, report what it blocked on a page, block cookies from being set or sent, strip referrer headers, nor properly support EFF's Do Not Track policy.

If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with?

Replacing persistent background pages with ServiceWorkers

A non-persistent event-driven background page does not work well for extensions that need to keep ephemeral state.

Privacy Badger maintains per-tab data that includes things like which third-party domains were detected and/or blocked on the page.
It may be possible to continuously save and restore state from storage as a workaround, but this runs counter to the stated performance goals of moving away from persistent background pages. It seems that persistent background pages are a much better fit for certain (stateful) types of extensions.
As Privacy Badger requires the webRequest API (more on this below), a persistent background page is required as per Chrome extension docs:

The webRequest API is incompatible with non-persistent background pages.

There are likely other issues (will a ServiceWorker background page support functioning in Incognito contexts, which is essential for privacy and security extensions?), but they are eclipsed by the fundamental mistake of trying to shoehorn stateful extensions into an exclusively event driven model.

Restricting origin access / Manifest Host Permission Specification

Making users confirm extension access (host_permissions) does not seem to make sense for general-purpose content blocking (adblocker/privacy/security) extensions. Outside of edge cases (for example, a Facebook.com-specific extension), content blockers need access across all URLs. Redundantly prompting users for permission to run these scripts (on top of the existing notification users see when initially installing Privacy Badger) will be unhelpful and confusing.

As Chrome extension docs for permissions state:

Use required permissions when they are needed for your extension’s basic functionality.

Dynamic Content Scripts

Many of Privacy Badger's content scripts need to run on all pages in order to do things like detect localStorage-based tracking and canvas fingerprinting, or deny JavaScript access to cookies and localStorage to "yellowlisted" third-party domains.

It would be great to finally have dynamic, before-anything-else injection of content scripts (https://crbug.com/478183). However, as per the host_permissions note above, it doesn't make sense to make users have to re-confirm this access via permission dialogs.

WebRequest

Removing "blocking" (synchronous request/response interception) from webRequest will break core Privacy Badger functionality.

The declarativeNetRequest API is an entirely inadequate replacement as it supports onBeforeRequest blocking and redirection only (not header/body inspection or modification), and seems to support (a limited number of) hardcoded rules only.

Privacy Badger needs to dynamically create rules.
Privacy Badger's rules interact with each other. A request that would be blocked may be overriden to "cookie-blocked" instead by the user, or it may be registered as a DNT-compliant domain and thus allowed.
Rules need to be further qualified by things like whether the request/response domain is third-party to the top-level document.
Privacy Badger needs to report what it did (blocked, etc.) on a page.
Privacy Badger needs to be able to modify content headers (block cookies, strip referrers, perhaps modify ETag headers, ...).
Privacy Badger would benefit from being able to modify response bodies like WebExtensions can in Firefox. The webRequest API should be gaining, not losing functionality.
Privacy Badger needs to encourage privacy-respecting ads by continuing to enforce the EFF Do Not Track policy. This means Privacy Badger needs to continue being able to check blocked domains for declarations of DNT compliance.

The above is not meant to be an exhaustive list. The point is that it is a fundamental mistake to try to shoehorn all content intercepting extensions into the limited-by-design declarative model.

Jab2870 commented 5 years ago

It looks like Google might be backtracking on this:

https://www.zdnet.com/article/google-backtracks-on-chrome-modifications-that-would-have-crippled-ad-blockers/

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/WcZ42Iqon_M

pipboy96 commented 5 years ago

Related: Eloston/ungoogled-chromium#706.

pipboy96 commented 5 years ago

⚠️ UPDATE: Blocking capabilities of webRequest are still being deprecated, see https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-495936668 (original post deleted) and commentary by @gorhill: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-496009417.

Thanks @Giltyhub for update!

pipboy96 commented 5 years ago

See the issue in HTTPS Everywhere's repository for statements recently made by browser vendors: https://github.com/EFForg/https-everywhere/issues/17268.

sillyjaybird commented 2 years ago

@ghostwords I'm finding little current info on MV3 generally and wondering if you've learned anything new about it's impact on Privacy Badger? Is any work being done to develop a POC/ MV3-compliant version of the extension?

ghostwords commented 2 years ago

You can read our latest update on the EFF blog, Google’s Manifest V3 Still Hurts Privacy, Security, and Innovation. While the post doesn't go into Privacy Badger specifically, we talk about what happened around Manifest V3 in the last two years, what's (still) wrong with it, and how it could be better.

I have been participating in the W3C WebExtensions Community Group to advocate for extension developers and to raise awareness of the many problems with Manifest V3.

Privacy Badger in Manifest V3 is blocked by at least one (long-outstanding) bug, Chromium Issue 102421: webRequest listeners not called after service worker stops.

sillyjaybird commented 2 years ago

@ghostwords I'm already familiar with the EFF post, Thanks for the specific example of an issue facing many developers.

sillyjaybird commented 2 years ago

@ghostwords Is there any development status of a MV3-compliant version of Privacy Badger other than your previous reply above?

ghostwords commented 2 years ago

Nope, https://github.com/EFForg/privacybadger/issues/2273#issuecomment-1009197551 is still the latest status.

twome commented 2 years ago

I permanently switched to Firefox when this happened (and hopefully we all realise Mozilla is subject to the same whims of private ownership & the global market as Google is).

I think this event serves as a very salient reminder that you can never truly address solve social problems with technical solutions alone. I have tremendous respect for all devs who give their time helping users sidestep or work around oppressive & exploitative technology, but we should all understand that, fundamentally, this kind of dynamic will persist forever until all users and software authors democratically share the means of making and changing software - which includes all currently private intellectual property - and that the only way to permanently achieve that is through extralegal, democratically worker-led global revolution.

sillyjaybird commented 2 years ago

Since the rollout of 2023 is fast approaching, is an MV3 compatible version of Privacy Badger in development?

ghostwords commented 2 years ago

Yes, I'm working on it. I'll post an update when we have something to share.

sillyjaybird commented 2 years ago

Thanks!

sillyjaybird commented 1 year ago

@ghostwords MV2 deprecation slated for June '24. How is MV3 development going? https://developer.chrome.com/blog/resuming-the-transition-to-mv3/

ghostwords commented 1 year ago

It's going! We've been making changes to prepare Privacy Badger for non-persistent background processes, be it an event page (Firefox) or an extension service worker (Chrome). We're now moving content filtering from webRequest to declarativeNetRequest.

sillyjaybird commented 1 year ago

@ghostwords Thanks for the update!

dotproto commented 1 year ago

@ghostwords, let me know if there's anything I can help with on the Firefox side of things.

ghostwords commented 6 months ago

Privacy Badger version 2024.5.30 is live in Chrome Web Store. You can get get this update now by visiting chrome://extensions/, enabling "Developer mode" and clicking the "Update" button.

Producing this version took months of running to stay in place. MV3-based Privacy Badger is not a "lite" version of Privacy Badger. It is functionally similar to MV2-based Privacy Badger, slightly better in some ways, and worse in other ways, some of which will get fixed over the coming months.

sillyjaybird commented 6 months ago

@ghostwords Thanks for the update.

sillyjaybird commented 6 months ago

Privacy Badger version 2024.5.30 is live in Chrome Web Store. You can get get this update now by visiting chrome://extensions/, enabling "Developer mode" and clicking the "Update" button.

Producing this version took months of running to stay in place. MV3-based Privacy Badger is not a "lite" version of Privacy Badger. It is functionally similar to MV2-based Privacy Badger, slightly better in some ways, and worse in other ways, some of which will get fixed over the coming months.

Are you able to describe the feature pros and cons of the MV3 version and which ones may get fixed over time? Or will you do this later as development progresses or is finalized, e.g. via an EFF blog post?

ghostwords commented 6 months ago

I've got to put out a few fires first. Afterwards, I'll be able to start documenting and generally sharing more. But there are few "pros". Manifest V3 is a huge mess. If Google wanted to, they could have rolled out a Manifest 2.5 with all of the pros and none of the cons, you know?

A list of outstanding issues from uBO's perspective: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-%28FAQ%29#filtering-capabilities-which-cant-be-ported-to-mv3

sillyjaybird commented 6 months ago

I've got to put out a few fires first. Afterwards, I'll be able to start documenting and generally sharing more. But there are few "pros". Manifest V3 is a huge mess. If Google wanted to, they could have rolled out a Manifest 2.5 with all of the pros and none of the cons, you know?

I don't know how many developers contirbute to the project, but will you maintain both MV2 and MV3 versions or settle on the latter when it's more polished given it's shortcomings?

ghostwords commented 6 months ago

We will maintain MV2 Privacy Badger for as long as it makes sense to do so. Right now only Chrome is on MV3.

I think the main bright side here is that we should now be much closer to having Privacy Badger for Safari on macOS.

sillyjaybird commented 6 months ago

@ghostwords ^^:)

sillyjaybird commented 1 month ago

@ghostwords Any news on developments regarding upcoming releases of Privacy Badger?

ghostwords commented 1 month ago

Not yet! You can get release notifications by "watching" releases in this repository, or you can follow @privacybadger@mastodon.social on Mastodon.

I'm closing this issue as a Manifest V3 version of Privacy Badger has been live in Chrome for a few months now.

EFForg / privacybadger