I don't think Privacy Badger considers tracking via TLS token ids.

[eshellman]

With the implementation of TLS Token Binding in Chrome and in Google services, Privacy Badger should consider "channel ids" to be the equivalent of non-expiring ID cookies. See https://tools.ietf.org/html/draft-ietf-tokbind-https-07#page-17 Advertising companies already have started to use this to replace conventional tracking cookies. OS X Chrome saves the token ids in an SQLite file at "~/Library/Application Support/Google/Chrome/Default/Origin Bound Certs"

[eshellman]

https://go-to-hellman.blogspot.com/2017/01/googles-crypto-cookies-are-tracking.html

[cooperq]

Indeed it is not, though I'm not sure that there is a way for us to track this in the chrome API. It is probably worth filing a bug in chrome and firefox to fix this so that we can detect and block this sort of tracking.

[eshellman]

you should be able to partly address this by cookie blocking the top domains that shouldn't be tracking at all - gstatic.com, googleapis.com, etc.

I've not gotten anything back on my chrome bug report (focused on channel ID UI); I don't know enough about the API to file a bug on that aspect.

[cowlicks]

@eshellman do you have a link to your chrome bug report?

[eshellman]

I reported it to Google fonts as a security issue and got a case number [9-3181000015161] but no link. I reported it to Chromium as a privacy issue but received no response at all.

[cooperq]

Since google uses this anti-feature I doubt we will get them to do anything about it.

…

On 01/25/2017 06:41 PM, eshellman wrote: I reported it to Google fonts as a security issue and got a case number [9-3181000015161] but no link. I reported it to Chromium as a privacy issue but received no response at all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD91XeqVlvaHpTcoIXqJsCCRAjRvPy-ks5rWAfZgaJpZM4LjNKx>.

[eshellman]

If Privacy Badger can address the issue, it would be appropriate for EFF to make some noise about it for the corresponding release.

[cooperq]

Agreed

[cowlicks]

I poked the chromium devs, and got a response. I'm still decoding what it actually means.

https://bugs.chromium.org/p/chromium/issues/detail?id=467312#c23

[dhowe]

any update on this?

[cooperq]

not from my end.

[cowlicks]

Disclaimer: this is all new to me, so I'm probably getting something wrong.

I think there are a few things being confused here, so I'll try to straighten them out: token binding, channel id, token ids, origin bound certificates. A quick explanation of these:

• origin bound certificates - an abandoned proposal for stronger client authentication.
• token id - I think this is a understandable conflation of "token binding" and "channel id". It is in the title of this issue, but I don't think it is actually a "thing".
• channel id - This unfortunately seems to actually be TWO things with the same name. Channel ID was at first another proposal for strongly authenticating clients at the TLS level. This seems to be abandoned now (link). The other use of "channel id" is that chrome labels origins in chrome://settings/cookie with "ChannelID" but they are using token binding (not ChannelID). I'd like someone to double check this, but I think it is correct.
• Token Binding - this is what we care about. And I'll explain my understanding of it, and what we can do about it below.

Token Binding is yet another proposal to more strongly authenticate clients. The basic idea is that you generate a new key pair for every origin. You send the public key to the origin. And the server associates the identification token (like a cookie) it issues to you with you public key. You receive this token. And every time you send this token back to the server you include proof that you posses your private key.

So! What is our concern here? Previously with Channel ID the authentication was happening at the TLS layer, where applications had no access. But now with token binding, the information exchanged at the TLS layer is just parameter negotiation. And it is my understanding that this is not de-anonymizing (info here). Your public key - which is the identifiable information - is sent at the application layer. So Privacy Badger should be able to intercept through the current webrequest api!

So our plan should be to identify the http headers (Sec-Token-Binding) that public keys are exchanged with. Then figure out our policy for intercepting this stuff.

@cooperq @dhowe @eshellman

[eshellman]

This aligns with my understanding.

[ghostwords]

Also see Token Binding in the Google Chrome Privacy Whitepaper doc.

[wiredrunner]

Token binding is being removed from Chromium.

https://bugs.chromium.org/p/chromium/issues/detail?id=875046

https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/AjFQjBmaEQE

[ghostwords]

See also:

• Token Binding - Chrome Platform Status
• Intent to Remove: Token Binding

Apparently it's also been implemented in Edge.

[wiredrunner]

Token binding is no longer being supported in Chrome yet 'Channel ID's' are still being loaded on to Chrome.

I'd settle for something that just removed them after they were loaded. They can be removed manually by the user by going into cookies and searching for them but no chrome extension does that as part of a process.