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

No recourse for domains that clean up their act #882

Open
maranomynet opened this issue Jul 19, 2016 · 4 comments
Open

No recourse for domains that clean up their act #882

maranomynet opened this issue Jul 19, 2016 · 4 comments

Comments

@maranomynet
Copy link

@maranomynet maranomynet commented Jul 19, 2016

Third-party domains that previously set cookies (even accidentally #574) and stop doing so, still remain permanently blocked for those Privacy Badger users that interacted with the domain before the cleanup.

This is overly harsh, and often even very detrimental to the user experience, as necessary resources don't load.

If PB were to delete all cookies for blocked domains, it should be fairly safe to automatically remove the block, after a while, to see if tracking happens again.

(Of course repeated blocks could gradually lengthen the block period for that domain.)

It seems that temporary blocking would make it both possible (and more desirable) for domains to clean up their act, and would provide a much less impaired user-experience for PB users.

@alexristich

This comment has been minimized.

Copy link
Collaborator

@alexristich alexristich commented Aug 10, 2016

Actually, there is one solution, and I believe the one that the EFF prefers above others: https://www.eff.org/dnt-policy. Once a domain does this, they will be unblocked:

/**
  * Loop through all known domains and recheck any that need to be rechecked for a dnt-policy file
  */
  recheckDNTPolicyForDomains: function(){
    var action_map = pb.storage.getBadgerStorageObject('action_map');
    for(var domain in action_map.getItemClones()){
      pb.checkForDNTPolicy(domain, pb.storage.getNextUpdateForDomain(domain));
    }
  },


  /**
  * Check a domain for a DNT policy and unblock it if it has one
  * @param {String} domain The domain to check
  * @param {timestamp} nextUpdate time when the DNT policy should be rechecked
  */
  checkForDNTPolicy: function(domain, nextUpdate){
    if(Date.now() < nextUpdate){ return; }
    pb.log('Checking', domain, 'for DNT policy.');
    pb.checkPrivacyBadgerPolicy(domain, function(success){
      if(success){
        pb.log('It looks like', domain, 'has adopted Do Not Track! I am going to unblock them');
        pb.storage.setupDNT(domain);
      } else {
        pb.log('It looks like', domain, 'has NOT adopted Do Not Track');
        pb.storage.revertDNT(domain);
      }
      pb.storage.touchDNTRecheckTime(domain, pb.utils.oneDayFromNow() * 7);
    });
  },

That being said, it's probably the case that most sites don't know about this. What do you think a good way of communicating this to sites that are blocked might be?

@maranomynet

This comment has been minimized.

Copy link
Author

@maranomynet maranomynet commented Aug 10, 2016

Thanks for the info.

Does PB have a FAQ? Does it link to this info? I guess that should be sufficient.

However, As I said, I still think it would be a good idea to default to auto-unblocking all domains after a while (just like cookies always expire, even the "permanent" ones) and see if they offend again.

That way you default to a somewhat forgiving stance.

There could be an exception for known nasties, or serious repeat-offenders, whose domain-block would never expire (or expire much later than normal).

@alexristich

This comment has been minimized.

Copy link
Collaborator

@alexristich alexristich commented Aug 10, 2016

PB does have an FAQ, found on the main EFF site: https://www.eff.org/privacybadger. It does include a question here about this with information about the DNT policy.

I don't know that I as a user would be comfortable with PB periodically revealing me to trackers that have been blocked to see if they are still tracking.

The proposal is interesting though; I wonder if there's a way to assess this in the background - while the tracker is still blocked - without having to reveal any identifying information from the user.

@ghostwords

This comment has been minimized.

Copy link
Member

@ghostwords ghostwords commented Jan 9, 2018

This is somewhat related to #1645.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.