Skip to content
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

Document scoping rules taking action on a domain #1515

Closed
cowlicks opened this issue Jul 18, 2017 · 9 comments
Closed

Document scoping rules taking action on a domain #1515

cowlicks opened this issue Jul 18, 2017 · 9 comments

Comments

@cowlicks
Copy link
Contributor

cowlicks commented Jul 18, 2017

When deciding what action we should take for a domain, there are many interacting things to consider.

The heuristic action of the basedomain, heuristicaction of the subdomains, is the domain on the PSL, is it a mdfp, is it on the cookieblock list, is it on the disabled sites list, is it third or first party, also user actions, etc.

The way these things interact is not well defined or documented. We need to specify how we want them to interact if we want to be able to fix them.

@cowlicks
Copy link
Contributor Author

cowlicks commented Jul 18, 2017

  1. How should setting a user action effect the sub and parent domains?

  2. If a domain receives 3 strikes for tracking, should its parent and subdomains be blocked?

  3. if a domain is added to the cookieblock list, should its parent or subdomains be cookieblocked?

  4. If a domain is removed from the cookieblock list, what should happen to its parent and sub domains?

I'm think we should answer these questions for what we'd like to see. Then adapt the code accordingly. I'll dump any answer's I have here.

@cowlicks
Copy link
Contributor Author

  1. I think user actions on domains should cascade out to sub-domains. But not up to parent domains. This includes reverting user actions.

@ghostwords
Copy link
Member

I tried to answer some of these in comments beginning from #1508 (comment).

I think the best way to "document" this sort of code interaction stuff is through unit tests. For example, getBestAction, which I think applies to some of the questions above, is "documented" in tests starting here.

@ghostwords
Copy link
Member

I'm not sure what the actionable items here are. Is it to fill in the missing unit tests?

@cowlicks
Copy link
Contributor Author

I'd like to answer these in writing to help with implementing things like #1508

@ghostwords
Copy link
Member

Here is a sample unit test to demonstrate exercising the code we are trying to understand and document: https://github.com/EFForg/privacybadger/compare/sample-blacklistOrigin-tests. Writing this test led me to think that we are discussing an impossible situation: How would a non-yellowlisted base domain get blocked when the yellowlisted subdomain got blocked because of a bad yellowlist update?

@cowlicks
Copy link
Contributor Author

Sorry, I don't think I was being very clear. The issue is about a few related things:

  1. I'd like to know how these things currently work
  2. I'd like to discuss how we think these things should work, a design discussion.
  3. With 1 we can figure out how to implement the changes we need to reach our desired design we came up with in 2.

Having 1. written out explicitly would be helpful for implementing 3.

I don't think we need to answer all of these questions, and make all of these design decisions at once. I think these will come up individually, like in #1508

If we had something explaining existing rules, and something explaining what future design we'd like to achieve, I think it would have helped guide that discussion.

@cowlicks
Copy link
Contributor Author

A new rule I learned, things in the mdfp list should always be etld+1. See cowlicks@8b2a6ac

@ghostwords
Copy link
Member

I'm going to resolve this, as I think it makes more sense to document our logic (whether through tests or actual documentation) as part of working on fixing bugs/adding features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants