Conversation
|
@ghostwords I suspect that this is either indexedDB or web SQL. I looked into a way for clients to inspect local indexedDB data on an origin. Unfortunately the way to do this has been removed recently. I've followed up with chrome to get this restored. It seems that the only way we can get this data is to monitor indexedDB access on clients and record database names. |
cowlicks
left a comment
There was a problem hiding this comment.
I supposed we are cookie blocking solvemedia.com because api.solvemedia.com is setting cookies on it? I only saw api.solvemedia.com loaded in the linked domains.
This works because yellowlisting solvemedia.com also yellowlists api.solvemedia.com right? We should document that somewhere, but not in this PR.
|
Subdomains of yellowlisted domains should end up getting "cookieblocked". Agreed, we should add tests for the various scenarios of adding domains to the yellowlist and what effect that has on their I think we should be careful about the distinction between something being "yellowlisted" (added to our exception list of domains but not directly used by Privacy Badger's decisioning) and something being "cookieblocked" (a Privacy Badger decision state, distinct from blocked, not-yet-blocked, or non-tracking). We do have a test for when you have a blocked subdomain and a cookieblocked parent domain: privacybadger/src/tests/tests/storage.js Lines 280 to 309 in 9ebc49c |
|
@cowlicks Should we yellowlist |
|
Opened a crbug re inability to inspect IndexedDB contents in Chrome settings/dev tools: https://bugs.chromium.org/p/chromium/issues/detail?id=930773 |


Fixes #1191.