-
-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add migration to fix yellowlisted yet blocked domains #1508
Conversation
To add to #1474 (comment), yellowlist domain removal logic marked subdomains ( This PR should fix the affected subdomains by looking for blocked, yellowlisted domains and then fixing their status to one of "cookieblock", "allow" or "", depending on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I was concerned about performance, but I tested it out and it seemed fine.
I restarted the failing travis job. I'll merge if it passes. |
Note that this is still not a perfect reversal of the incident:
|
Looking through error reports, it looks like we do have some substring-blocked domains, for example, |
I expanded the scope of the migration to try to undo everything we might have blocked by mistake when we blanked out people's yellowlists. The updated migration goes through every blocked domain and checks if the domain ( If we have three or more entries in If there are bugs in this logic, I expect they would be in the direction of unblocking too much, which should be OK since Badger will relearn to block as necessary. |
The updated migration checks every blocked domain to see if it ends with any yellowlisted domains. This mirrors current yellowlist domain removal logic, which checks if any known domains end with the removed-from-yellowlist domain.
a3e00c1
to
37abdf8
Compare
Question: What is the policy for subdomains of domains on the CBL? What is the policy of parent domains on the CBL? What is the policy when a domain on the CBL is also in the PSL? I think the answer to this should be documented somewhere. Reviewing now. |
When we block a domain (the correct way, via blacklistOrigin) now, we "cookieblock" the domain (instead of blocking) when the domain, or any of its subdomains down to the base domain are on the yellowlist. We also "cookieblock" those subdomains. When we add a domain to the yellowlist and its base domain is already blocked or cookieblocked, we cookieblock that domain right away. So, subdomains of yellowlisted domains should end up getting "cookieblocked". |
The PSL is used when we get the base domain. The base domain of |
However, |
Some bits use the PSL, some do not; the various bookkeeping structures can drift apart; importing data loses |
Just recheck all blocked domains, don't even look at the yellowlist.
I think there is a problem. If we have a site on the cookieblock list like If Is this correct? If so which way should it be? |
|
Wouldn't |
@ghostwords yeah you are correct. It seems like there would still be an issue, should it be cookieblocked or noaction/allow? |
As I wrote above, previously non-tracking, yellowlist-associated domains are now yellowlisted for affected Badgers. I think this is OK, something that we can deal with later, if it actually becomes an issue. |
@ghostwords with the current PR as-is, we don't know if the domain would be set to noaction/allow or cookieblock. It depends on the order that these get run in. |
Both are acceptable, although have you verified this actually happens? See my comments above please. |
I realize that both are better than incorrectly blocked. However I'd like it to be at least deterministic. Can we just decide on one to be correct and go with that? I'm working on verifying this issue. |
@ghostwords do you still plan on adding tests? |
I did, here: #1515 (comment) |
Fixes #1466, fixes #1469, fixes #1494, fixes #1495.
Follows up on #1482.