3 ms·

Cookie-based tracking, sure. But there are plenty of other avenues for fingerprinting. This[1] help doc from Adobe Analytics even makes reference to a Subscribe

by cosmie 6y ago

Cookie-based tracking, sure. But there are plenty of other avenues for fingerprinting. This[1] help doc from Adobe Analytics even makes reference to a Subscriber ID header you can get mobile carriers to give you, if you get onto the carrier's whitelist. Nothing the vendors do device/browser-side to restrict tracking will help if your mobile carrier is transparently appending an identifying header to your request after it leaves your phone. [1] https://docs.adobe.com/content/help/en/analytics/technotes/visitor-identification.html#section_60D6EAC0D16945A89DD5A7ADF3B8298D https://docs.adobe.com/content/help/en/analytics/technotes/v...

deadso 6y ago
This doesn't work for SSL enabled websites, right?
- cosmie 6y ago
  I'm really not certain, as I've never seen an implementation that involved it. There was a lot of stink about it 5 years ago[1], which called out the exact argument of it not working for HTTPS traffic. Which, is a substantially larger portion of traffic now than it was at the time. But you still see nondescript references to the capability in places like that that up-to-date Adobe Analytics doc, and the carriers aren't trying to use legal means (a la lobbying) to slow down the uptick in HTTPS traffic and preserve their revenue stream. Which leads me to presume they've developed technical solutions that are compatible with HTTPS traffic. They can't really use the spray-and-pay method[2] they were using. But all bets are off when they destination site and the carriers are coordinating with each other, as that coordination can involve technical modifications to facilitate it in addition to just the whitelisting itself. [1] https://www.ghacks.net/2015/08/31/are-mobile-carrier-injected-tracking-headers-used-to-track-you/ https://www.ghacks.net/2015/08/31/are-mobile-carrier-injecte... [2] Some carriers would inject a header into all traffic, and any interested party could slurp them up. But you'd have to pay the carrier to access any of the other information the carrier had for that particular identifier.
- toast0 6y ago
  I don't know enough about TLS < 1.3. In TLS 1.3, the whole handshake on both sides is covered by the handshake completion --- if the client handshake was modified in the middle, the client will not accept the server handshake completion. However, that doesn't stop carriers from inserting something at the start of the stream that the client doesn't see. It would need to be coordinated with the origin server, but that's already true for HTTP header insertion. Sending a pre-handshake blob to a TLS server that isn't expecting such a blob would fail hard though, rather than going on its merry way like an extra header usually would.

by cosmie 6y ago

deadso 6y ago

This doesn't work for SSL enabled websites, right?

cosmie 6y ago
I'm really not certain, as I've never seen an implementation that involved it. There was a lot of stink about it 5 years ago[1], which called out the exact argument of it not working for HTTPS traffic. Which, is a substantially larger portion of traffic now than it was at the time. But you still see nondescript references to the capability in places like that that up-to-date Adobe Analytics doc, and the carriers aren't trying to use legal means (a la lobbying) to slow down the uptick in HTTPS traffic and preserve their revenue stream. Which leads me to presume they've developed technical solutions that are compatible with HTTPS traffic. They can't really use the spray-and-pay method[2] they were using. But all bets are off when they destination site and the carriers are coordinating with each other, as that coordination can involve technical modifications to facilitate it in addition to just the whitelisting itself. [1] https://www.ghacks.net/2015/08/31/are-mobile-carrier-injected-tracking-headers-used-to-track-you/ https://www.ghacks.net/2015/08/31/are-mobile-carrier-injecte... [2] Some carriers would inject a header into all traffic, and any interested party could slurp them up. But you'd have to pay the carrier to access any of the other information the carrier had for that particular identifier.
toast0 6y ago
I don't know enough about TLS < 1.3. In TLS 1.3, the whole handshake on both sides is covered by the handshake completion --- if the client handshake was modified in the middle, the client will not accept the server handshake completion. However, that doesn't stop carriers from inserting something at the start of the stream that the client doesn't see. It would need to be coordinated with the origin server, but that's already true for HTTP header insertion. Sending a pre-handshake blob to a TLS server that isn't expecting such a blob would fail hard though, rather than going on its merry way like an extra header usually would.