ISPs Inserting Ads Into Your Pages

TheWoozle writes "Some ISPs are resorting to a new tactic to increase revenue: inserting advertisements into web pages requested by their end users. They use a transparent web proxy (such as this one) to insert javascript and/or HTML with the ads into pages returned to users. Neither the content providers nor the end-users have been notified that this is taking place, and I'm sure that they weren't asked for permission either."

Comments

I've known about this for a while...

[Saint Aardvark]

When I worked at the helpdesk of a small ISP, we were approached by this company to see if we were interested in letting them test their ad-inserting proxy server on our customers. I protested that it was scummy and might lead to legal trouble (I was guessing) over changing pages in-flight, but my bosses didn't listen. That was back in 2002 or 2003, and I left shortly after to take another job. No idea what's going on there now.

I'm moving to a new ISP since my current one has started blocking port 25 in and out. I run my own mail server, so I appreciate that Uniserve's TOS explicitly allow servers (clause #19). However, they also explicitly say that they insert ads:

65. UNISERVE shall have the right, without notice, to insert advertising data into the Internet browser used by a UNSERVE customer, and transferred to a UNISERVE customer over UNISERVE's network, so long as this does not involve UNISERVE establishing the identity of the customer to whom such data is sent.

Needless to say I'm not happy about that, but in Vancouver my choices are limited: Telus (who'll censor web pages if they belong to a union striking against them), Shaw, or a handful of small ADSL ISPs that all seem to be much the same. Uniserve seems the best of a bad bunch.

Re:I've known about this for a while...

[KiahZero]

U.S. Copyright law is about a utilitarian bargain between content creators and content consumers - in exchange for creating the content, the creators are given a limited monopoly on certain actions. Moral rights don't really have a foundation in American law.

Links to Belkins suckiness (Re:Belkin sucks! )

[Werrismys]

Belkin hardware sucks: http://www.google.fi/search?hl=fi&q=belkin+router+ adware

Yes I know their hardware sucks for other reasons also.

Opt Out Link

[cybermage]

The company that runs the box the ISP installed provides an opt-out option. Go to this page and click opt-out.

I think their behavior with this product is reprehensible. Pass the link on to anyone you know who is affected and encourage them to call their ISP and complain every day until it's removed. If all their call center does is get complaints, they'll reconsider whether it's making them any money.

Re:ISP comparisons need to note this

[Anon E. Muss]

Hit them where it hurts: right where people are deciding which ISP to go with.

That only works if there is actual competition. In most large cities, customers have only two choices. They can go with cable modem service from Some Big Cable Company or DSL service from Some Big Telecom Company. Both usually suck. People living in smaller communities often have no choice at all.

Re:Suprise!

[spottedkangaroo]

The ISP even having this information in their logs starts a huge slippery slope.

Clearly you're not familiar with CALEA. They not only log your traffic, they store all the packets so the courts can request them later.

Re:What about code validation?

[Ant P.]

I found something funny with using XHTML 1.1. Certain free hosting sites are totally oblivious to its existence, so if you rename all your pages to *.xhtml their injected ads magically disappear.

Re:How to take advantage of this

[Nimey]

How about people like me who have the Adblock extension?

Of course, I also have Noscript, so I'd not even register in your scheme.

Use a proxy...

[skeftomai]

Why not just run your internet through your own proxy and remove the ads? Sure, it may be a bit slower, but surely it could be done with something like Privoxy on top of Squid.

Re:What about code validation?

[Bogtha]

When I checked it there was script just after the html element but before the head.

The problem was not the placement of the <script> element. While the <head> element is mandatory in HTML 4.01, its opening and closing tags are optional. All you had to do was delete your opening <head> tag. Everything after the opening <html> tag but before your closing </head> tag would be assumed to be in the <head> element.

The real problem was that they didn't specify the mandatory type attribute for the <script> element, which results in an invalid document, and that they used the deprecated language attribute, which cannot appear in a valid Strict document.

Re:Suprise!

[tylernt]

If all you want is a pipe, I suspect that your last refuge will be setting up up a tunnel to a datacenter. Assuming hosting and colocation companies don't start this crap too, you can SSH into your shared server or colo host and your traffic will originate from there, effectively making your hosting provider your new ISP.

Additional cost, additional latency... but at least you'll have a real internet connection again.

Re:Suprise!

[Tim C]

Like creating a derivative work? This is taking someone else's work in transit from server to client, inserting other content into it, then sending this modified version on to the client instead.

This isn't like creating a derivative work, it is creating a derivative work. They're even profiting from it, as they're selling the ad space thus created.

Bluecoat does it for businesses that was to block

[mailman-zero]

Here is an explaination of how Bluecoat allows businesses to create a deliberate man in the middle so it can block content on SSL encrypted sites. It's a frightening Internet we do business in.

http://directorblue.blogspot.com/2006/07/think-you r-ssl-traffic-is-secure-if.html

From the site:

If you use SSL at work in ways designed to elude acceptable-use filters (e.g., WebSense) or to secure applications like telephony and file-sharing, you may want to re-think that proposition.

A series of products, among them Blue Coat's SSL Proxy, provide SSL-cracking capabilities to organizations interested in shutting down SSL violations of policy.

In effect, Blue Coat's SSL Proxy breaks any SSL traffic its been configured to intercept.

When a connection request is made by the browser, it passes through the Blue Coat proxy on its way to the real SSL server. The response from the destination SSL server includes a certificate. This certificate is designed to (a) irrefutably identify the server; and (b) secure the communications between client and server. To do so, the cert wraps the server's public-key, which is tied to the domain name (or, less likely, IP address) of the server.

The real server's cert, though, is intercepted by the proxy on its way back to the browser.

Before the proxy passes the certificate through, it unwraps the public key and then re-wraps it in an "emulated certificate" (I'll go ahead and call it a spoofed cert, which I think is more accurate). This spoofed cert is then returned to the client browser. The client thinks everything is on the up-and-up and -- after it verifies the spoofed cert -- it establishes the encrypted tunnel.

The tunnel, though, is now terminated at the proxy server. The proxy itself has established a second tunnel to the real destination SSL server.

The proxy can now inspect the cleartext traffic, block the traffic, or pass it on to other devices for their use (more about this later), and otherwise fiddle with it prior to sending it down the second encrypted tunnel to the real SSL server.