Study Confirms ISPs Meddle With Web Traffic

Last July, a research team from the University of Washington released an online tool to analyze whether web pages were being altered during the transit from web server to user. On Wednesday, the team released a paper at the Usenix conference analyzing the data collected from the tool. The found, unsurprisingly, that ISPs were indeed injecting ads into web pages viewed by a small number of users. The paper is available at the Usenix site. From PCWorld: "To get their data, the team wrote software that would test whether or not someone visiting a test page on the University of Washington's Web site was viewing HTML that had been altered in transit. In 16 instances ads were injected into the Web page by the visitor's Internet Service provider. The service providers named by the researchers are generally small ISPs such as RedMoon, Mesa Networks and MetroFi, but the paper also named one of the largest ISPs in the U.S., XO Communications, as an ad injector."

Comments

common carrier?

[wannasleep]

I am wondering whether altering web pages by inserting ads changes the ISP status of common carrier (http://en.wikipedia.org/wiki/Common_carrier) thereby exposing it to liability for crimes and/or infringement perpetrated by its customers. Any takers?

Re:common carrier?

[pegdhcp]

While IANAL, I used to manage our relations with Telecommunications Authority of Turkey, whose regulations are closely similar to other ITU member organizations. Here we are required to protect customer privacy during their telecommunication activities and only share pertaining data with legal authorities. Similarly we are required to modify some web content (in fact, we are poisoning DNS data) only under legal orders. However it is not clear if the traffic from public web sites are private traffic, while messing with a banking site's traffic and/or a transactional traffic carrying credit card info will certainly put you behind the bars.

Thank goodness

[Dunbal]

Someone actually had the balls to NAME these ISPs, instead of referring to generic "providers". Of course it sucks to be you if you live in an area where they have exclusive coverage - but it's good to know who thinks they have the right to tamper with packets going between you and the destination of your choice.

Signed pages (pity it won't work) and SSL

[Craig Ringer]

Because of this issue and some related problems I've often wondered about extensions to HTTP to support cryptographically signed pages.

HTTPS is great, but involves a significant CPU cost per page and isn't friendly to web caches.

Signed pages, if static, could be signed once and stored. They'd also be cacheable with all the normal rules.

The main issue is key management. How do you get the signing key? Well, I'm pretty sure the HTTPS certificate key could be used to sign a page, though there might be risks to the integrity of the key. A better way would be to use a single HTTPS request to grab a signing key from the remote site.

Signatures could be just another HTTP header, so browsers without support would never even notice. An alternative would be a HTML comment after the close body tag. The HTTP header, though, would work for related resources like images as well, and for that reason would probably be much better.

Unfortunately, it's all useless because an ISP could trivially strip signatures from HTTP headers or pages if they wanted to mess with the page.

If this sort of thing keeps on happening sites will just have to start offering HTTPS for all communication. The dodgy ISPs will have lower cache hit rates and higher demand for external bandwidth, but they will have done it to themselves.

If only browsers would FINALLY include support for HTTP+TLS and for TLS upgrades, encryption could even be done transparently to the user.

Cant see the story...

[Kenja]

All I see is "Local ISPs cure cancer. All hail SBC!"

USA ISPs are NOT common carriers!

[The tECHIDNA]

When will this zombie...er, urban legend die (at least in the US?)

Cable Internet Service Not Common Carrier ... and that was a ruling by the US Supreme Court.
Corollary:
FCC Reclassifies DSL, Drops Common Carrier Rules ... so DSLs don't escape either.

I'm not rooting for this, but we need to try harder for an actual solution rather than seek the unicorn of a "solution" that didn't/no longer exists.

Toolkit for detecting changes to your own page

[csreis]

If you're interested in knowing if your own page is being modified in flight, we (the authors of the study) have an open source toolkit for adding a "web tripwire" to your page. It's just a piece of JavaScript code that does an integrity check within the user's browser, and it can report any in-flight changes back to your server.

The toolkit requires you to run CGI scripts on your server to collect results, but we also have a web tripwire service that is easier to use (available on the same page above). Just add one line of JavaScript to your page, and our server will handle the integrity check and collect the results. We can then provide you with reports of the changes, much like Google Analytics.

We hope that by spreading web tripwires to other pages, we can at least deter ISPs from making further changes to web pages in-flight.

Call it "Tampering"

[theonetruekeebler]

We need to stop referring to these shenanigans with neutral or pragmatic names. We call these actions "modification" or "altering" or "injection" and it riles us, but you can bet your bottom dollar that the ISPs and Comcasts of the world are sitting around coming up with terms like "shaping" and "adapting" and "presentation opportunity."

Names are powerful.

If an ISP modifies a web page, they are tampering. Putting their own ads there is impersonation

If an ISP puts your IP at the top of a RST they generated, they are packet forging.

If an ISP examines the data portion of a packet they are reading your content.

If they change the header (other than decrementing TTL or doing NAT) they are packet tampering.

And if they say it's to enhance user experience they are lying