Add Twitter DNT meta tag.

[cowlicks]

Twitter recently withdrew support for allowing their users to opt out of tracking with DNT. But they still quietly support this privacy policy in the case where website publisher's choose to use it when they embed Twitter content. They no longer call this privacy policy "DNT", but they have confirmed that the policy has not changed.

This PR embeds a meta tag on websites that load content from twitter. Twitter has no* way of distinguishing meta tags embedded by the website publisher, or by an extension in the user's browser. So they should continue to apply their DNT policy on visited with PB.

Twitter's documentation about this privacy policy is here: https://dev.twitter.com/web/overview/privacy#what-privacy-options-do-website-publishers-have

(*) no practical method to my knowledge

[cowlicks]

@jsha just pinging you to check if what I've said here sounds right. No need to review code.

[jsha]

Text sounds good. There are probably some tricky timing issues around whether this fires before widgets.js checks for it.

[ghost]

@jsha Maybe inject it directly into the server's response HTML?

[ghost]

https://twitter.com/personalization

This page is Twitter's replacement of their removed DNT setting. I think we can try setting the same cookies it does.

[cowlicks]

@koops76 @jsha The pull request as is does not guarantee that, but it is straight forward to do so by hooking this in to webrequests. I just wanted to put this out so I could talk about it in a blog post.

[cowlicks]

This is really an abuse of our widgets system, but I think refactoring that is better done as a separate pull request.

[ghostwords]

This is a big-time nit, buuuut, removing the space from the closing parenthesis is great, that was a typo, but creating single-space indent above isn't so great; an indentation level should be two spaces.

[ghostwords]

Adding the "twitter:dnt" meta tag to the document doesn't seem to have much to do with widget replacement. Why don't we add a new dedicated content script to be run at "document_start", "before any other DOM is constructed or any other script is run"? This should avoid any timing issues.

We shouldn't need to check if this functionality is enabled at this point, can just always run it for now.

[ghost]

@ghostwords 👍

[cowlicks]

Always injecting would make it very easy to fingerprint Privacybadger users. Sites can already do this, however with the suggested change, it would make it trivial.

Another issue is that such a content script would always be run, even if privacybadger was deactivated for the site.

I see the widget replacement system eventually becoming more a more general purpose system for running code in webpages to modify them. For example unwrapping url's could be part of it eventually.

I think this refactoring would be better suited for another pull request, when we have a better feeling for what our needs are.

[ghostwords]

Can you explain how exactly "always injecting would make it very easy to fingerprint Privacybadger users"? I don't see how adding a new content script (that does the same work as this PR's changes to socialwidgets.js do) makes Privacy Badger more identifiable.

Another issue is that such a content script would always be run, even if privacybadger was deactivated for the site.

This is an existing issue with anything race-condition sensitive. You either guarantee on-time injection, or you get conditional injection, but not both. The fix for this is tracked in https://crbug.com/478183. Injecting unconditionally seems preferable to working some of the time.