Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Browsers
Web Extensions
Privacy Badger Is Changing to Protect You Better
Message
<blockquote data-quote="Gangelo" data-source="post: 908276" data-attributes="member: 64716"><p>I never invested much time in this tool. In it's early days, it was a mediocre tracker blocker which broke plenty of webpages. It got a little better with later versions but once Adguard Premium was tested and purchased I never used anything else. Now that Google castrated it's only unique feature, it is practically useless.</p><p></p><p>Besides, when Manifest V3 becomes mainstream, it will be unable to block anything.</p><p></p><p>Quote</p><h3>An overview of the Manifest V3 proposal's impact upon Privacy Badger</h3><p>Privacy Badger is a browser extension that automatically learns to block invisible trackers.</p><p></p><p></p><p>The <a href="https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit" target="_blank">Manifest V3 proposal</a> 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 <a href="https://www.eff.org/dnt-policy" target="_blank">EFF's Do Not Track policy</a>.</p><p></p><p>If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with?</p><p></p><h4>Replacing persistent background pages with ServiceWorkers</h4><p>A non-persistent event-driven background page does not work well for extensions that need to keep ephemeral state.</p><p></p><ul> <li data-xf-list-type="ul">Privacy Badger maintains per-tab data that includes things like which third-party domains were detected and/or blocked on the page.</li> <li data-xf-list-type="ul">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.</li> <li data-xf-list-type="ul">As Privacy Badger requires the webRequest API (more on this below), a persistent background page is required as per <a href="https://developer.chrome.com/extensions/background_pages#persistentWarning" target="_blank">Chrome extension docs</a>:<br /> </li> </ul><p>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.</p><p></p><h4>Restricting origin access / Manifest Host Permission Specification</h4><p>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.</p><p></p><p>As <a href="https://developer.chrome.com/extensions/permissions" target="_blank">Chrome extension docs for permissions</a> state:</p><p></p><p></p><h4>Dynamic Content Scripts</h4><p>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.</p><p></p><p>It would be great to finally have dynamic, before-anything-else injection of content scripts (<a href="https://crbug.com/478183" target="_blank">478183 - chromium - An open-source project to help move the web forward. - Monorail</a>). 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.</p><p></p><h4>WebRequest</h4><p>Removing "blocking" (synchronous request/response interception) from webRequest will break core Privacy Badger functionality.</p><p></p><p>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.</p><p></p><ul> <li data-xf-list-type="ul">Privacy Badger needs to dynamically create rules.</li> <li data-xf-list-type="ul">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.</li> <li data-xf-list-type="ul">Rules need to be further qualified by things like whether the request/response domain is third-party to the top-level document.</li> <li data-xf-list-type="ul">Privacy Badger needs to report what it did (blocked, etc.) on a page.</li> <li data-xf-list-type="ul">Privacy Badger needs to be able to modify content headers (block cookies, strip referrers, perhaps modify ETag headers, ...).</li> <li data-xf-list-type="ul">Privacy Badger would benefit from being able to <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData" target="_blank">modify response bodies like WebExtensions can in Firefox</a>. The webRequest API should be gaining, not losing functionality.</li> <li data-xf-list-type="ul">Privacy Badger needs to encourage privacy-respecting ads by continuing to enforce the <a href="https://www.eff.org/dnt-policy" target="_blank">EFF Do Not Track policy</a>. This means Privacy Badger needs to continue being able to check blocked domains for declarations of DNT compliance.</li> </ul><p>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.</p><p></p><p>Unquote</p><p></p><p>Edit: Source <a href="https://github.com/EFForg/privacybadger/issues/2273" target="_blank">Will the proposed Manifest V3 changes to Chrome break Privacy Badger? · Issue #2273 · EFForg/privacybadger</a></p></blockquote><p></p>
[QUOTE="Gangelo, post: 908276, member: 64716"] I never invested much time in this tool. In it's early days, it was a mediocre tracker blocker which broke plenty of webpages. It got a little better with later versions but once Adguard Premium was tested and purchased I never used anything else. Now that Google castrated it's only unique feature, it is practically useless. Besides, when Manifest V3 becomes mainstream, it will be unable to block anything. Quote [HEADING=2]An overview of the Manifest V3 proposal's impact upon Privacy Badger[/HEADING] Privacy Badger is a browser extension that automatically learns to block invisible trackers. The [URL='https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit']Manifest V3 proposal[/URL] 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 [URL='https://www.eff.org/dnt-policy']EFF's Do Not Track policy[/URL]. If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with? [HEADING=3]Replacing persistent background pages with ServiceWorkers[/HEADING] A non-persistent event-driven background page does not work well for extensions that need to keep ephemeral state. [LIST] [*]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 [URL='https://developer.chrome.com/extensions/background_pages#persistentWarning']Chrome extension docs[/URL]: [/LIST] 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. [HEADING=3]Restricting origin access / Manifest Host Permission Specification[/HEADING] 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 [URL='https://developer.chrome.com/extensions/permissions']Chrome extension docs for permissions[/URL] state: [HEADING=3]Dynamic Content Scripts[/HEADING] 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 ([URL='https://crbug.com/478183']478183 - chromium - An open-source project to help move the web forward. - Monorail[/URL]). 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. [HEADING=3]WebRequest[/HEADING] 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. [LIST] [*]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 [URL='https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData']modify response bodies like WebExtensions can in Firefox[/URL]. The webRequest API should be gaining, not losing functionality. [*]Privacy Badger needs to encourage privacy-respecting ads by continuing to enforce the [URL='https://www.eff.org/dnt-policy']EFF Do Not Track policy[/URL]. This means Privacy Badger needs to continue being able to check blocked domains for declarations of DNT compliance. [/LIST] 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. Unquote Edit: Source [URL="https://github.com/EFForg/privacybadger/issues/2273"]Will the proposed Manifest V3 changes to Chrome break Privacy Badger? · Issue #2273 · EFForg/privacybadger[/URL] [/QUOTE]
Insert quotes…
Verification
Post reply
Top