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.
How Verizon and Turn Defeat Browser Privacy Protections
101–110 of 176 posts
Re: How Verizon and Turn Defeat Browser Privacy Protections
#102Earlier 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…
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
#103“How Verizon and Turn defeat browser privacy protections.”
Re: How Verizon and Turn Defeat Browser Privacy Protections
#104Couldn'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.
Re: How Verizon and Turn Defeat Browser Privacy Protections
#105Earlier 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…
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
#106It'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...
Re: How Verizon and Turn Defeat Browser Privacy Protections
#107Someone 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…
Re: How Verizon and Turn Defeat Browser Privacy Protections
#108It'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...
Re: How Verizon and Turn Defeat Browser Privacy Protections
#109Earlier 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.
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
#110Earlier 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…
I thought this hadn't been the case for several years now? Am I wrong?