61–70 of 81 posts
HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?
You shouldn't have to encrypt your data to stop your ISP from actively 1) scanning and 2) corrupting it. What is the FCC good for?
Ugh, I hate that attitude of "Macs can't get malware" that this guy exudes so smugly.
"I laughed to myself briefly, thinking: “who uses Bing?”, and then realized I was a computer science grad student who had managed to get malware on a Mac, so I wasn’t in a position to judge."
Earlier quoted context omitted.
FWIW, I haven't noticed this on any of BT, Sky or Virgin.
NXDOMAIN is hijacked on Virgin Media for sure, unless you are using some other DNS. I haven't noticed them injecting ads though.
>nslookup notarealdomainthatshouldresolve.co.uk Server: cache1.service.virginmedia.net Address: 194.168.4.100
* cache1.service.virginmedia.net can't find notarealdomainthatshouldresolve.co.uk: Non-existent domain
Earlier quoted context omitted.
You shouldn't have to encrypt your data to stop your ISP from actively 1) scanning and 2) corrupting it. What is the FCC good for?
It is not just about your ISP, it is about all the ISPs between you and the website .
1) They can't get away with it 2) That'd slow everything to a crawl, inspecting traffic is expensive at the scales most large providers operate at.
The sad thing about this is in many places (at least in the US) there are few if any alternatives. In my city, I can either get Time Warner Cable or AT&T DSL. I'm 20 miles from Verizon's office but FIOS is illegal in my city. So if the ISP starts screwing with the content then you have virtually no alternative.
I'm interested to know why FiOS is illegal in your city? I don't know of any regulation that would make it.
Earlier quoted context omitted.
https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the we…
> adds extra unneeded overhead by encrypting everything Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.
sure, the extra rtt is preferable to javascript injection, but signing the webpage is sufficient to prevent javascript injection and it wouldn't add extra rtt delay (aside from fetching a cert in the trust chain, which https can also suffer from in the exact same way).
depending on the algorithms used, on-the-fly signing of dynamic pages might be (read: almost certainly is) more painful than ssl/tls in terms of computation time, but to the user would still be quicker for most cases than the rtt delay added by ssl/tls.
Earlier quoted context omitted.
https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the we…
> Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. How would they do this without triggering certificate warnings? Or are you simply saying that everyone ignores certificate warnings?
At ShitISP we care about your cyber safety. In order to prevent viruses and other Bad Things from infecting your computer and the other computers on our network, you will be unable to do some things on the internet until you install our certificate.
Thank you for helping us keep your computer and our network safe!"
Earlier quoted context omitted.
> adds extra unneeded overhead by encrypting everything Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.
assuming you just want to browse websites and not transfer information that needs to be private, the extra rtt for establishing the ssl connection is the uneeeded overhead. for something like streaming a movie, that won't matter because the ssl connection will be long lived. for something like web browsing, where most websites require a new tcp connection for each GET, ssl is painful. sure, the extra rtt is preferabl…
This is inherently error-prone. It gives the developers a big, convenient, and reassuring assumption which the attacker is able to violate. For a complex and evolving endpoint like a web browser, I don't think you'd ever see the end of security bugs. More: https://www.ietf.org/mail-archive/web/tls/current/msg04017.h...
Furthermore, retroactive authentication still doesn't preclude the encryption: https://www.ietf.org/mail-archive/web/tls/current/msg08722.h...
I looked into switching then to another ISP, but the only one available is 1.5Mbps DSL vs their 15Mbps connection now.