Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Verizon and Turn Defeat Browser Privacy Protections

eff.org

Post reply on HN
Print view View original

71–80 of 176 posts

Re: How Verizon and Turn Defeat Browser Privacy Protections

#71

Post by mahyarm »

nl wrote: post #61
FrankenPC wrote: post #59

Earlier quoted context omitted.

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.

VPN is insanely easy today How do I install a VPN on my SmartTV exactly? How do I make it actually work , even using VPN-on-a-router, given the importance CDNs have and how they use the location of your DNS resolver to attempt to give you nearest copies? How do I explain to the hypothetical 68 yo grandmother why she has to disable the VPN to use (Australian geoblocked catch-up TV Service) iView and then reenable it t…

Well since the connection is tunneled to the VPN server, the shortest hop in that topology will be the IP of the VPN server anyway for the CDN.

And you would locate the VPN server inside the same country, unless those services are blocking by ISP or similar.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#72

Post by higherpurpose »

roque wrote: post #15

My guess is that the "entrepreneurial" solution here would be a combination of: - A browser that doesn't support cookies and provides the server with a client controlled session-id (perhaps a user-id also). - Only uses SSL sessions to avoid middle-box injection of HTML headers (this still leaves the provider with the ability to inject data as IP options / TCP headers). - A micropayment solution that allows content pr…

I think Aviator doesn't support cookies, among other privacy features:

https://www.whitehatsec.com/aviator/

EFF is working on a "HTTP Nowhere" option for HTTPS Everywhere, which only allows HTTPS connections. On Firefox there already is an HTTP Nowhere addon from someone else.

But as others have said, it's probably easier to just use Tor.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#73

Post by higherpurpose »

zevyoura wrote: post #58
Cyther606 wrote: post #51

Earlier quoted context omitted.

Tor is free and much easier than a VPN. Tor Browser bundle on Win/Mac/Linux: https://www.torproject.org/download/download-easy.html.en Orweb on Android: https://play.google.com/store/apps/details?id=info.guardianp... OnionBrowser on iOS: https://itunes.apple.com/us/app/onion-browser/id519296448?mt...

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

I don't find Tor that slow. Unless you're talking watching videos or something.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#74

Post by guelo »

scintill76 wrote: post #53
evmar wrote: post #42

It's strange to read this and then simultaneously read people complaining about HTTP2 requiring SSL. It'd surely be nice if law protected us from bad actors but SSL protects from this in a way that (hopefully) can't be circumvented.

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 in /etc/hosts.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#75

Post by guelo »

noonespecial wrote: post #55
hackuser wrote: post #41

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…

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.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#76

Post by dllthomas »

x0x0 wrote: post #33
shkkmo wrote: post #27

There are two solutions I see. 1) Regulation. Maybe it'll happen, I don't have much hope of it being done intelligently. 2) Feed them garbage data. We just need a database of live UIDH numbers and a browser extension to inject a random UIDH number from that list into the header.

verizon overrides; I'm not a web engineer but (I think) ssl protects tcp headers. if so, it's probably the only technical solution is either ssl everywhere or an ssl proxy run by users

I interpreted the suggestion as for those not using Verizon to inject fake UIDH. Of course, this could be filtered by making sure the traffic is actually coming from Verizon's networks...

Re: How Verizon and Turn Defeat Browser Privacy Protections

#77

Post by ryanhuff »

nl wrote: post #40
shkkmo wrote: post #27

There are two solutions I see. 1) Regulation. Maybe it'll happen, I don't have much hope of it being done intelligently. 2) Feed them garbage data. We just need a database of live UIDH numbers and a browser extension to inject a random UIDH number from that list into the header.

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…

If you are using a VPN that proxies your request, couldn't you hide from this tracking?

Re: How Verizon and Turn Defeat Browser Privacy Protections

#78

Post by dannyobrien »

hackuser wrote: post #41

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…

Is the language on the action alert (linked in the article) any better for you?

https://act.eff.org/action/hold-verizon-accountable-for-viol...

Re: How Verizon and Turn Defeat Browser Privacy Protections

#79

Post by killface »

userbinator wrote: post #56

I feel like injecting headers is only the start of something far more pernicious; even SSL/TLS can't stop an ISP from determining and tagging where your traffic goes (and consequently, passing that information onto third parties) - all your traffic goes through equipment on their network, after all. As long as your connection to the Internet is tied to your identity in some way (and there is basically no way a non-fr…

this is what VPNs help prevent.

Re: How Verizon and Turn Defeat Browser Privacy Protections

#80

Post by mkjones »

userbinator wrote: post #56

I feel like injecting headers is only the start of something far more pernicious; even SSL/TLS can't stop an ISP from determining and tagging where your traffic goes (and consequently, passing that information onto third parties) - all your traffic goes through equipment on their network, after all. As long as your connection to the Internet is tied to your identity in some way (and there is basically no way a non-fr…

How would ISPs tag requests going over HTTPS as being from a particular subscriber?
Post reply on HN