Alexei

Also see #907 and #1754 for Chrome and Opera versions of the unsightly browser message shown when Privacy Badger blocks an embedded document frame.

See https://github.com/EFForg/privacybadger/pull/1766#issue-272288074 for links to collapsing approaches taken by other content blocking extensions.

Privacy Badger might be able to [leverage the list of CNAME-cloaked tracker domains published by AdGuard](https://github.com/AdguardTeam/cname-trackers/issues/4) to defeat CNAME cloaking in all browsers ([Chrome does not yet support CNAME uncloaking](https://bugs.chromium.org/p/chromium/issues/detail?id=1063095)...

Need to investigate what the status of intercepting WebSocket requests is on Firefox. Chrome should be ready, although there may (or may not, check uBlock for example) still be a...

Should also be available in Firefox as of Firefox 55: https://blog.mozilla.org/addons/2017/06/14/webextensions-firefox-55/

We may have a problem with respect to host permissions. We [declare `http://*/*` and `https://*/*`](https://github.com/EFForg/privacybadger/blob/e97b0d0dbe88ea8a08f9f4b5b06f31807bce741d/src/manifest.json#L13-L14), not ``; WebSockets require `ws://*/*` and `wss://*/*` permissions. If both switching to `` and adding...

Confirmed that switching to `` in Chrome does not produce a new permission warning: ```diff diff --git a/src/manifest.json b/src/manifest.json index 8affe96..c350525 100644 --- a/src/manifest.json +++ b/src/manifest.json @@ -9,9 +9,9 @@...

An example set of URL permission changes that did trigger a scary "access your data for all websites" warning in Firefox: https://github.com/EFForg/https-everywhere/issues/16377#issuecomment-415421819

Adding "ws/wss" permissions is still a problem in Firefox: https://github.com/ghostery/ghostery-extension/issues/253

Filed ["Adding ftp ws/wss permissions should not trigger extension permission warnings on extension upgrade"](https://bugzilla.mozilla.org/show_bug.cgi?id=1504018) in Bugzilla.