User:Eighty5cacao/misc/Privacy Badger

__NOINDEX__:This page is unmaintained. In particular, all the issues noted here predate the creation of multiDomainFirstParties.js.


 * Official EFF documentation and download page

Satisfiable by cookieblocklist (yellow)

 * All Wikimedia Foundation-related domains that serve user-visible pages: The MediaWiki software sets high-entropy cookies to track login sessions, so hotlinking of user scripts onto third-party wikis may trigger full ("red") blocking when viewed by registered Wiki[mp]edians.
 * Unified login within WMF projects: When  is manually set to green (as required to log in at all), SUL works fine for projects that use language codes as subdomains; cookies for such projects are cross-domain and are not detected by Privacy Badger's exact domain matching. However, Wikimedia Commons  and Wikispecies  still have their cookies blocked. Since there is no plan to implement a "green whitelist," this needs to be resolved by tech evangelism to make the WMF post the appropriate DNT policy on   and multilingual projects. Compare ticket #178 for the Chrome version (resolved by multiDomainFirstParties.js)
 * (used e.g. for images on CNET Download pages)
 * (KISSinsights tracking[?] script in the bucket named  triggers red because of cookies it sets?) (  contains an entry for " "; perhaps this isn't actually matching subdomains, despite the syntax borrowed from ABP?) - this may also be affecting   (https optional, no existing HTTPS-E ruleset) as mentioned at GitHub issue 461 - known issue: discussion specifically about Amazon S3 at #482; root cause described at #516
 * (TODO: describe)
 * ,  (hover over the link on https://imgur.com/gallery/5ZP7VNX/comment/248761942; very likely because of existing Google Analytics cookies set from xkcd pages; don't whitelist the 2ld xkcd.com because dynamic.xkcd.com has been used for tracking scripts on some third-party sites like the store [strictly, it would only become 3rd party after   is rewritten by HTTPS Everywhere to  ])
 * (Formerly seen on http://www.selkiecomic.com/; offending cookie is )
 * (seen on https://typekit.com/; it isn't a problem on other Adobe sites, where it is considered first party)
 * ,,  ,   (not normally a problem, but seen at http://cuteoverload.com/2014/07/15/take-us-out-to-the-ballgame-hank/ while that post was on the homepage; note that the Vine video in question is framed inside  ; there appear to be POST requests involved [according to the warning message from Firefox when Privacy Badger setting changes trigger a reload], but they don't seem essential. I couldn't find any existing cookies from vine.co stored on my system.)
 * multiple bbc.co.uk subdomains (user-visible pages are on www.bbc.com), needs diagnosis (exception: sa.bbc.co.uk and stats.bbc.co.uk are legitimately considered to be used for tracking and so should remain blocked) - known issue (#480)
 * (seen on ; probably affects other forums as well; offending cookie is probably  )
 * (only affects images?)
 * (iframe seen on ; probably a session-cookie issue) [obsolete?]
 * (e.g. hotlinked image on )
 * (see image in the entry currently on http://www.zophar.net/ that points to ; I thought there was a cookieblocklist.txt entry for *.google.com? Same bug affecting Amazon S3?)
 * (on ; not tested exactly what this affects, as the Bing search bar still shows up fine either way)
 * (seen on )
 * (seen on )
 * (Formerly seen on ) - admittedly debatable whether this is false
 * (specific subdomain seen on, but possibly affects all SourceForge subdomains)
 * (seen on ); note that   should remain blocked, so don't put the 2-level domain   on the cookieblocklist
 * (for widget frames)
 * (seen on ; no longer uses CloudFlare - needs retesting)
 * (on )
 * ,,   (seen on  ; specific post needs diagnosis)
 * (seen on ; more examples certainly exist)
 * (seen on )
 * multiple  subdomains on multiple domains (too many to list) - known issue (#484)
 * ,  (on multiple pages in , todo find other examples)
 * (seen on )
 * multiple(?)  subdomains, specifically those used for blog images (seen on  )
 * (seen somewhere in ; offending cookie probably set from some user-visible page on www.telegraph.co.uk)
 * (used for a search box on all(?) pages of ; probably due to user preference cookies?)
 * (video content on some pages of )
 * multiple  subdomains (somewhere in   - probably due to CloudFlare cookies)
 * - breaks videos on www.cbsnews.com (requires Flash)

Not satisfiable by cookieblocklist

 * - Recommended action: Tech evangelism and/or documentation; add to cookieblocklist anyway in meantime - (yellow is enough to make the  homepage display correctly, but green is needed to actually be able to log in)
 * - Recommended action: None - (script that only controls webfonts; used e.g. on all pages of ; the problem is that it returns 403 when set to yellow, probably due to referer checks. I'm okay not taking any action on this, as EFF/Tor developers tend to consider webfont issues not worth the security/privacy risks to fix, either within Privacy Badger or HTTPS Everywhere.)
 * - Recommended action: Define a syntax that allows a 2-level domain to be listed without affecting its subdomains; add to cookieblocklist anyway in meantime - ( discussion ; the same issue applies to every site that runs MediaWiki software and does not forbid hotlinking, as mentioned above for Wikipedia; barring tech evangelism to a large number of sites, it could require fundamental changes to the entropy estimator or other functionality); note that  is used on the   forum and should remain blocked

Philosophical discussion
In principle, Privacy Badger is just as vulnerable to false notices as is LibreJS. (The "notice" is EFF's proposed DNT policy. I have no further comment at present.)