undefined | Better HN

0 pointsscintill7611y ago0 comments

I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, and other TLS implementations should be ignoring for compatibility. It's maybe not as easy for ad networks to consume, but where there's money to be made, there's a way.

I think this would work. Am I missing something? Has anyone checked if it's already being done?

[0] https://tools.ietf.org/html/rfc4366#section-2.1

0 comments

2 comments · 1 top-level

zrm11y ago· 1 in thread

They don't even have to inject anything, it's surprising they're doing this at all. They could just use the TCP/IP source and destination addresses and ports to identify the connection. TLS wouldn't help that. VPN would though.

scintill76OP11y ago

Maybe, but it sounds more messy. Verizon would have to maintain a semi-public (to their "other" customers, that is, advertisers etc.), low-latency queryable database of {source, destination, customerID} tuples, and ads and/or pages might not finish loading until that query returns. If the ID is more static, the trackers can cache the identity information for awhile after the first time, and Verizon probably has less work to track and resolve IDs.

j / k navigate · click thread line to collapse