Slashdot Mirror


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."

3 of 131 comments (clear)

  1. common carrier? by wannasleep · · Score: 5, Interesting

    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?

  2. Thank goodness by Dunbal · · Score: 5, Interesting

    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.

    --
    Seven puppies were harmed during the making of this post.
  3. Signed pages (pity it won't work) and SSL by Craig+Ringer · · Score: 5, Interesting

    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.