Live data from Hacker News

How Verizon and Turn Defeat Browser Privacy Protections

eff.org

101–110 of 176 posts

Re: How Verizon and Turn Defeat Browser Privacy Protections

#101
post #75

Earlier quoted context omitted.

How about: Because your mobile device really belongs to the carrier and not to you, whenever you browse the web with it, they know who you are no matter what. They are now refusing to keep that information secret even if you want them to, instead selling it to advertisers without your consent (even despite your obvious non-consent). They do this by sabotaging your mobile browser so it can't really delete certain cook…

It doesn't have anything to do with who owns the device.

Sure it does. If my verizon iphone wasn't 3 months into a locked two year contract I'd just put in a different sim and forget the whole thing.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#102

Earlier quoted context omitted.

Tor is so slow as to be unusable for everyday browsing.

Tor Browser is perfectly suitable for everyday browsing. When's the last time you used it for any significant period of time? It's plenty speedy and very stable. Please, instead of bemoaning your complete lack of privacy online, do something about it for a change. Download Tor Browser right now. Tor Browser bundle on Win/Mac/Linux: https://www.torproject.org/download/download-easy.html.en Orweb on Android: https://pl…

What kind of a weasel word is "everyday" browsing?

Tor has way more latency. It's been a while since I measured bandwidth, but relatively high bandwidth transfers like videos are everyday browsing nowadays. I, for one, frequently use Youtube playlists as ad-hoc background music, for example.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#104

Couldn't you fake a false UIDH header if you don't use verizon? If yes, then people could publish their UIDH and have other people use it as well. If many do this, the unique identification aspect of UIDH is lost. Something like using a random UIDH from a list of published ones every request.

Or just get everyone to use the same UIDH, making it useless for whatever tracking purposes.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#105

Earlier quoted context omitted.

SSL can't really stop it, I think. Here's a thread where I've speculated on a way to inject metadata into SSL handshakes[0] just like they're doing with HTTP headers. If that doesn't work (I'd be interested to hear why), someone else suggested using TCP-IP source/destination metadata queried from the ISP to resolve to a customer. [0] https://news.ycombinator.com/item?id=8506492

No. An MITM starts changing the ClientHello, and the PreMasterSecret should change because it's all hashed in, and therefore Finished will fail - that's the case with the TLS 1.3 draft and I wouldn't be surprised if TLS 1.2, too, although I'll put it on my list to check. Fallbacks complicate that, but the fallback SCSV signals enough to correctly sound the alarm there too. I'm specifically on the lookout for sneaky w…

I'm sure you know a lot more than I, and you're pushing the boundaries of my limited knowledge, but I read a bit on some things you mentioned... I don't follow how the PreMasterSecret incorporates the ClientHello; PreMasterSecret seems to be just a protocol version and some random bytes. As for the Finished hash check, I didn't know about that, but can't a server complicit with the MITM (i.e., a site wanting to buy customer data from Verizon) fix up the hash by ignoring the bytes the MITM inserted? They would coordinate a scheme to reversibly inject tracking bytes, and pretend the bytes weren't there while hashing for Finished.

Since you mentioned complicit endpoints, I'm really wondering if I'm being naive here. It's certainly not as simple as injecting HTTP headers, but it looks possible if the ISP and target server collude, and the ISP makes sure to only tamper with traffic bound for servers that "know" to un-tamper it.

I could probably prove or disprove this for myself by writing a proof of concept, and maybe I will, but in case it is an issue that could be mitigated, I'd rather someone more qualified think about it sooner than I will figure it out.

Good point about "SSL", I was using the term loosely.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#106
post #99

It's a wonder to me how no Verizon competitor has jumped at the opportunity to advertise this on a large scale with a message along the lines "it's evil, we don't do that". If the users really care about this issue, that's what would happen on a functioning market anyway...

It's because the competitors do this too.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#107

Someone who understands this well needs to write a very short 'elevator' explanation for non-technical end-users that we all can copy and paste. That small act would be invaluable to spreading awareness, which is necessary for any progress. I was going to send the EFF article to some Verizon customers I know but I realized they would have no idea what it meant. I don't have time to read it thoroughly and write an acc…

When you click a button on your mobile web browser, if you're a Verizon customer, advertisers see a special tag assigned to you by Verizon. Since Verizon assigned you the tag, they can give you the same tag on every website. Advertisers have ads on many websites, so they can see the tag and match your browsing history to their logs. In effect, because of the tracking tag Verizon assigns to you, any advertisement you…

It should be made clear that it is not some pseudo anonymous "you" but it can be directly related to your phone and your contract and from that to you.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#108
post #99

It's a wonder to me how no Verizon competitor has jumped at the opportunity to advertise this on a large scale with a message along the lines "it's evil, we don't do that". If the users really care about this issue, that's what would happen on a functioning market anyway...

I doubt most people care. This isn't going to drive customers away. The only way it'll be stopped is if they're legally forced to. For example, see the history of cookies themselves and how most people never cared about them.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#109
post #40

Earlier quoted context omitted.

You can't feed them garbage. Verizon operates at the network layer - if you are on their network presumably they will copy the real value over your garbage value. If you aren't on their network then they can check IP address and ignore values not from the Verizon subnets. There are a couple of other solutions you haven't mentions: VPNs: Annoying and currently too hard for most people. Perhaps it is time for device (P…

VPN is insanely easy today. IMO Everyone should use it by default. Too bad it causes an additional load on the internet for the encrypted tunnel traffic. Another option is a blanket law about internet traffic that states no tracking can be made at all unless given express permission.

The recent European cookie law was close to that and got laughed at by tech people. Poor Europeans are constantly being asked for permission "Can we store a cookie on your computer?" whenever they visit a major website.

Also, how do you stop people tracking you by IP? Every web server's log does this by default. How do you allow sessions even? It's not easy to define tracking so it's different from essential operation.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#110
post #74

Earlier quoted context omitted.

SSL can't really stop it, I think. Here's a thread where I've speculated on a way to inject metadata into SSL handshakes[0] just like they're doing with HTTP headers. If that doesn't work (I'd be interested to hear why), someone else suggested using TCP-IP source/destination metadata queried from the ISP to resolve to a customer. [0] https://news.ycombinator.com/item?id=8506492

It's simpler then that. The advertising based site wants to show you the ad, they have no incentive to implement SSL. There's no https://espn.com , for example. Even if they did implement https it would be mixed content because the ad networks' iframes or whatever are http. The solution is things like NoScript or Adblock on Firefox (not Chrome which downloads the ad and just hides it). Or blackholing the ad networks…

>(not Chrome which downloads the ad and just hides it)

I thought this hadn't been the case for several years now? Am I wrong?

Post reply on HN