How a banner ad for H&R Block appeared on Apple.com without Apple’s OK

http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/

by ben336 • 13 years ago

405 169 13 years ago

degenerate• 13 years ago

Original (and better imo) article here: https://news.ycombinator.com/item?id=5486006

yk3• 13 years ago

Thinking about ad injection, it is actually quite scary what a ISP can do. Not only is it easy to display ads (or possibly even malware), but even worse my ISP is installed as a default CA by Firefox. So that they can even inject into SSL connections, with the only "warning" that the certificate was signed by the ISP...

cheald3• 13 years ago

Who is your ISP, and what CA cert do they have installed?

The thought of an ISP having CA certs that are a part of default installs is unnerving.

yk3• 13 years ago

Telekom ( actually T-Online, the German ISP branch). The certificate is identified as T-Systems (and I just found another one, Deutsche Telekom AG). Additionally looking through the certificates I found at least Swisscom who appear to have both a CA and an ISP, and AOL. But this is certainly not an exhaustive list but just the ones that caught my eye scrolling through the list of CAs.

[EDIT]And for the added 'told you so,' the German parliament uses precisely this certificate https://www.bundestag.de/

jlgreco• 13 years ago

That is why you always tell the installer that you do not have a PC or a Mac. Never let them touch your computers.

eropple2• 13 years ago

I'm not quite sure how you got the idea that he let anyone touch his computers out of his post: he said a default CA by Firefox.

There are a number of ISPs that are also CAs that are installed in many browsers by default.

cstrat• 13 years ago

I have always wondered how long it would take for this sort of behaviour to kick off.

This is to the internet what global warming is to the earth... well that might be too far, but this is high tech pollution at its worst.

8ig8• 13 years ago

zmhenkel's Reddit comments if anyone wants first person accounts:

http://www.reddit.com/user/zmhenkel

_conehead3• 13 years ago

As exciting as this is to be posted on a high-volume website, I honestly doubt CMA is going to change their practices on this issue.

If anything, the Acceptable Use Policy change on the 4th was a sign that they'd be reluctant to change their stance on this issue at all. They honestly don't care.

crgt2• 13 years ago

They might change their tune if they get a letter from a lawyer or two. Can't imagine Apple, for example, likes the idea of third-party ads overlayed on their site.

seanalltogether• 13 years ago

I could see google bringing a hammer down on them if its true that they are overwriting ad space on certain websites.

niggler• 13 years ago

Is Ars just ripping sites now? Although now changed, https://news.ycombinator.com/item?id=5505890 pointed to an Ars article from yesterday (that reached the front page) that was basically a copy-paste of an SE question

signed0• 13 years ago

Ars has been featuring Stack Exchange questions, with their permission for quite some time. I think it's some sort of partnership. http://arstechnica.com/author/stack-exchange/

eropple2• 13 years ago

It's one of the worst features that they run. I've gotten good enough at guessing which is "Ask Stack" from the headline that I don't click them anymore, though.

robert_nsu3• 13 years ago

The writer reached out over twitter. I responded with my info on the subject and another individual pointed him to Henkel's blog.

nkurz• 13 years ago

Facebook eventually addressed the issue by making the site accessible over HTTPS—though, as the authors of the 2008 paper note, HTTPS can be a "rigid and costly" solution.

This same excuse has existed for about as long as HTTPS, which dates to Netscape Navigator 1. Is it still that "rigid and costly"? Is there a technical reason that this is an unsolvable problem?

Considering the increase in computer and network speed over the last decade and a half, it seems strange that this would still be the case. Perhaps it's just that without pressure from competitors there is no pressure on the sites to solve it?

dangrossman5• 13 years ago

I have no background in crypto stuff, but the main issues seem to be (a) SSL virtually requires buying certificates so small/hobby sites won't use it, (b) it involves multiple round-trips and latency is never going to go away unless someone invents faster-than-light communication, and (c) part of what makes encryption work is that it's computationally hard on today's hardware; when it's not, we move to a different algorithm that is, so the computational cost to using encryption versus not using encryption will always be there.

kbenson3• 13 years ago

> part of what makes encryption work is that it's computationally hard on today's hardware; when it's not, we move to a different algorithm that is, so the computational cost to using encryption versus not using encryption will always be there.

It's computationally hard to crack. To be useful, it necessarily has to be easier to use than to circumvent.

jmillikin• 13 years ago

  > SSL virtually requires buying certificates so
  > small/hobby sites won't use it

startssl.com offers free SSL certificates valid in almost every browser, good for one year. I've been using them for my own site with no problems. Certificate cost is no excuse for continuing to use unsecured HTTP.

  > it involves multiple round-trips and latency is never
  > going to go away

Assuming reasonable protocol design (somewhat problematic for HTTP/1.0, better in /1.1 and SPDY), additional round trips are only a factor for the initial connection setup. Later requests can re-use the existing SSL session.

  > part of what makes encryption work is that it's
  > computationally hard on today's hardware

Encryption is based on being computationally expensive for a third party. The computational load on the communicating parties is negligible, particularly with modern CPUs. From http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht... , Google experiences CPU overheads of less than one percent:

  > On our production frontend machines, SSL/TLS accounts
  > for less than 1% of the CPU load, less than 10KB of
  > memory per connection and less than 2% of network overhead.

stephen_g4• 13 years ago

I don't know where the authors got "rigid and costly", but I think it's just BS... 2008 was a long time ago though, so maybe it was slightly more challenging then.

When Google went over to SSL for Gmail, they said "On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. " http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

That, coupled with the general availability of cheap and free CA signed certificates makes the claim pretty baseless.

nwh3• 13 years ago

Is there anybody other than StartCom offering free signed certificated?

tibbon2• 13 years ago

I've gotta say, I haven't played with HTTPS sites all that much- does it mess up caching?

jes51992• 13 years ago

an annoying thing about HTTPS is that it requires you to serve each domain name from a separate IP address, and that can be somewhat costly.

theatrus2• 13 years ago

If you ignore IE+Windows XP, you can safely use SNI.

stephen_g4• 13 years ago

This is why widespread IPv6 can't come soon enough. You can give whole subnets to each subdomain if you feel like it, without paying a cent...

SEJeff• 13 years ago

SNI has been out for a long time. Windows XP with IE < 8 doesnt support it, but at this point, Microsoft has practically abandoned it so it seems reasonable to let those users suffer and tell them to use Firefox/Chrome.

onemorepassword3• 13 years ago

No it doesn't. You can use multi-domain certificates. Works like a charm.

Also, I talked to GlobalSign recently, and they had a brand new solution that used SNI with an automatic fallback to multi-domain certificate for browsers that don't support SNI.

benjiweber2• 13 years ago

1024bit certificates are only valid until December this year. Then we have to use 2048bit, destroying the benefit we get from faster computers.

You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine. This is one of the places cost comes from.

nl• 13 years ago

You need SSL accelerators or pretty fast hardware to handle more than a few thousand SSL handshakes per second on a single machine.

That's not true - or rather it conflates two unrelated problems.

1) HTTPS/SSL (even with larger certificates) isn't computationally expensive:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.[1]

2) The HTTPS initial handshake is slow. However, this isn't because of the power of the machine, or the certificates size. It's cause by round-trip overheard (See [2]). The solution for that is to reuse HTTPS connections as much as possible (which both your server and the browser should try to do for you anyway. But doing things like using the same hostname can help)

[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

[2] http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?to...

StavrosK• 13 years ago

> destroying the benefit we get from faster computers.

That's precisely the point, though.

Retric• 13 years ago

2048bit is not all that much harder to encrypt than 1024bit you might go from 1% CPU to 2% CPU but that's about it.

onemorepassword3• 13 years ago

This thread illustrates exactly the problem with HTTPS.

The proponents of HTTPS everywhere try to sweep the significant downsides under the rug, whilst others are spreading all kinds of unfounded FUD about HTTPS.

The bottom line is that "your mileage may vary". For some applications, SSL is trivial, and there is no excuse not to do it. For other scenarios it's a nightmare with all kinds of undocumented complications.

I'm currently working on providing SSL for a SaaS service with various client domains on AWS (i.e., with a limited number of IP-addresses). Doable, but far from trivial or inexpensive.

robmcm• 13 years ago

It may not be considered costly when your advertisers pull out because their content is getting replaced via HTTP.

kevinpet• 13 years ago

HTTPS is not rigid and costly for a single connection. It's rigid and costly because it prevents simple options for caching like sharing google hosted jquery. You can still use a CDN, but then you have more complexity in managing your certificates and pay 1/3 more (Cloudfront pricing).

HTTPS is manageable where needed for security. Sleazy ISPs are making it necessary even where security is not a concern -- for example, viewing Apple's homepage.

cmelbye• 13 years ago

That's not true. Google seamlessly supports both HTTP and HTTPS, and many other sites do too through simply using // as the protocol.

iy565• 13 years ago

They are not making it necessary, only convenient. You're not harmed by seeing a few ads.

driverdan• 13 years ago

Using 3rd party CDNs, like Google Hosted Libraries, are often slower anyway.

http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...

sigzero• 13 years ago

It should be made illegal if it isn't already. Since "any site" did not consent, doesn't this injection really "change" their site?

notatoad• 13 years ago

i believe it counts as copyright infringement. if you modify content in-transit, you're creating a derivative work.

not sure if this has ever been tested legally though.

jiggy20113• 13 years ago

In such a case wouldn't any form of proxying be copyright infringement, even without modification be copyright infringement?

There are also other applications of modification of pages in transit, for example mobile connections often proxy a lower quality version of images (done transparently by the ISP) to save bandwidth. Also some proxies may block videos , ads etc which is as much modification as adding them.

jeffdavis2• 13 years ago

Maybe they should lose their "common carrier" status if they mess with the content? Then they would be responsible for whatever is said on the internet, which would probably dissuade them from doing it.

jauer2• 13 years ago

Most ISPs in the US don't operate under common carrier regulations. Even the ILECs (essentially the only common carrier data networks) sell their internet services via subsidiaries to avoid it.

deepblueocean2• 13 years ago

This is probably the best counter-argument to the best counter-argument that gets leveled at the people promoting HTTPS-everywhere. People like to say that HTTPS everywhere would break transparent cacheing by ISPs. After all, HTTP is designed to allow caching proxies to exist inline and still supports dynamic content gracefully (er, somewhat, anyway).

But in fact the same features that make transparent caching easy make this kind of shenanigans easy. There are tons of companies in this space now. Not just people like NebuAd and R66T, but lots of "subscriber messaging systems" like FrontPorch (which I've heard sells messaging data for behavioral advertising) and PerfTech (which has assured me that they do no such thing).

This should be an easy way to push back one of the last "real" arguments against using HTTPS everywhere. There's no excuse not to be running your site on HTTPS all the time - it protects you and your users from all sorts of mischief for a minimal overhead.

RossM• 13 years ago

It's getting to the stage now where I think domains should be sold with an SSL certificate as standard (minimal vetting, no warranty) - just enough to provide encryption, rather than treating it as an optional extra.

deepblueocean2• 13 years ago

One could argue that DNSSEC is a variant of this - put your SSL certificate in a TXT record in your DNSSEC-signed domain and you no longer need a certificate authority system to sign the certs. Now you can self-sign the cert and get it for free!

iy565• 13 years ago

If the best argument in favor of HTTPS everywhere is that it will prevent your ISP from showing you ads, the movement is doomed.

DanBC3• 13 years ago

The point is not to stop your ISP from showing you ads. The point is to stop your ISP from interfering with your traffic in transit.

If I ran a website with ads, and someone was stripping those ads to replace with their own ads, I'd be annoyed. I'd be amazed if that's something Google would tolerate. We've seen plenty of stories from people saying "Google closed my ad account and froze all my money!!!" so I hope they do that to this ISP and or the company serving the ads.

AJ0072• 13 years ago

The "root" of the problem -- on what marketplace are these display ads being sold?

dangrossman5• 13 years ago

Any of the hundreds of different advertising services that feed into the exchanges that are carried by the major networks. There's likely no direct connection between who sold the ad and who made the deal with this ISP to let them serve that network. H&R Block probably had no idea their ad ever appeared on Apple's site.

http://blog.inuvi.com/wp-content/uploads/2011/01/LUMA-Landsc...

AJ0072• 13 years ago

Yeah, but somewhere H&R Block purchased the inventory. You don't just generically purchase a 300x280 banner ad without regard to where or how it runs. It has to be connected with some sort of property or impression.

It could be a re marketing add, or a demographically targeted ad, but in that case the buyer still purchased it somewhere and some company or company is responsible.

kevinburke• 13 years ago

Wouldn't you know it, the CMA Communications (the ISP mentioned in the post) website is not accessible via HTTPS. "View My Bill" and similar link you off to a third party domain.

mbloom1915• 13 years ago

why wouldn't all ISPs do this for the economic incentive? Is advertising going in this direction?

crgt2• 13 years ago

If my ISP did this I would switch instantly.

Jach2• 13 years ago

And when they all do it, or no other ISP will service your area?

robert_nsu3• 13 years ago

The problem here is that in our city, we have four ISP's. My parents live in a suburb close to the edge of the city. AT&T, Comcast, and the others don't really provide any services out there.

I say "not really" because ATT provides phone service, but not DSL or U-Verse.

robert_nsu3• 13 years ago

One thing is that it can ruin the UX of the page. I was constantly hitting the overlays while using an iPad when all I really wanted to do was advance the page I was reading.

mmahemoff• 13 years ago

TLDR: ISP injected script tag ads.

I heard on the latest This Week In Security that Comcast was apparently not just injecting JS, but injecting bad JS. Meaning that closures weren't used, so name collisions could occur with the actual sites users were visiting.

For this reason, I can see HTTPS becoming standard, even for public, non-logged in users. I'm in the process of updating my site to be all-HTTPS and recently got confirmation (as much as one could ever expect) from Google there's no SEO penalty (http://goo.gl/sbtxq).

godfreykfc• 13 years ago

You're probably referring to https://news.ycombinator.com/item?id=5482178

stephen_g4• 13 years ago

If your site has a login page anywhere on your domain, I think that really every page should be served over HTTPS, and it should use HSTS to make sure the browser knows it should always be accessed that way.

Even if your login page posts to https, if there's a man in the middle somewhere between your server and user and your login page is HTTP, they can alter the login page to post somewhere else. If your login page is HTTPS, then they can change links to that page to something different.

Only with HTTPS for the entire site is it safe from those attacks. It is still vulnerable if there is a MITM the very first time the browser has ever visited the site, but it's a whole lot better than always being vulnerable!

zerr• 13 years ago

Thank you very much for TLDR. It is horrifying how many life-hours are spent for such bullshit stuffed articles...

da_n• 13 years ago

I would like to see https everywhere, but the cost of certs is still an issue.

smackfu2• 13 years ago

To be clear, Comcast wasn't injecting ads, but bandwidth overage messages. Still terrible though.

prodigal_erik• 13 years ago

Yet another reason blindly running javascript from unknown parties is a bad idea. Whitelists for progressive enhancement I want should always have been the default.

danielweber2• 13 years ago

If the ISP is injecting Javascript, they can just inject it as coming from the same domain.

I don't like "force HTTPS everywhere" but these jerks are forcing it. It sucks, but it sucks less than this.

codesuela• 13 years ago

@begurken you've been hellbanned since this post https://news.ycombinator.com/item?id=5466310, no idea why

https://en.wikipedia.org/wiki/Hellbanning

nfm• 13 years ago

I remember reading about someone with neighbours that were stealing their wifi. You can do much more interesting things with a proxy server than just inject ads: http://www.ex-parrot.com/pete/upside-down-ternet.html

IheartApplesDix• 13 years ago

It's a brave new world out there. Well, I knew this would happen eventually, and I got a lot out of the internet while it lasted. Shit, the last 15 years of my life have been grand thanks to the net, but now it's time to kiss it goodbye.

I, for one, welcome our new corporate master feudal lords.

anoncow• 13 years ago

Did he complain to the FTC?

_conehead3• 13 years ago

Holy cow. It seems this has had a direct effect: they're no longer injecting javascript into webpages. I just tried Amazon, eBay, and a few others where the script injection used to be present, and it's no longer there.

I absolutely can not understate just how happy I am about this.

ben336• 13 years ago

you mean overstate? :)

_conehead3• 13 years ago

Absolutely; thanks for the correction. It seems I was just a tad too excited to post, haha.

fauigerzigerk• 13 years ago

So an internet provider inserted ads into web pages and two bloggers blogged about it.

I hate this ultra-low signal to noise style of writing anyway, but using it for a tech piece is more than ridiculous. This isn't a 1970s western movie, nor does it appear in the NYT arts & culture section.

ck2• 13 years ago

I'm terrified to let them tamper with it but Congress really needs to make laws that regulate ISP behavior in the USA. They will never do it on their own.

The problem with such a bill is it will have a dozen riders for very horrible things.

Uchikoma2• 13 years ago

My problem with HTTPS is Google: They push it on every front, but - for various reasons - consider HTTPS and HTTP different pages, meaning you do not get link juice from any HTTP links if you're site is HTTPS only.

(1. don't listen to people telling you otherwise, it's an expensive experiment 2. redirects do not transfer all the juice, they count as links themselves, from my experience it's like not having external links to your site at all 3. If you do not depend on Google b/c you're SaaS, go for HTTPS only)

rocky1138• 13 years ago

Where are you getting the data that you don't get Google juice for HTTP-to-HTTPS links?

Uchikoma2• 13 years ago

From first hand experience. Then lately there was a discussion on /r/seo I currently can't find with a link to Matt Cutts who said redirects are handled the way links transfer juice.

[edit] People extrapolate that 301 are different because Google tells them to use 301 when moving pages.

marbletiles4• 13 years ago

HTTPS will not prevent this: the ISP can issue their own CA to their users and then decrypt/encrypt https as it passes through them. (Many corporations already do this). What will prevent this is legislation and/or competition.

It amazes me that US Internet access has very little of either. All the drawbacks of monopoly Internet, with all the drawbacks of unregulated Internet.

pellias• 13 years ago

Slight correction, ISP or Corporation can run a HTTPS proxy. In effect, your 'HTTPS' connection is to the IPS/Corporate proxy only.

peripitea• 13 years ago

I'm confused as to how what you're saying or what parent is saying would work. The trusted CAs live on your computer, and should not be susceptible to tampering by your ISP. And how can your ISP or corporate network set up an HTTPS proxy like you're suggesting without triggering a warning to the user that they are not connecting to the SSL certificate's specified domain?

Is there something about SSL/TLS that I'm fundamentally misunderstanding?

laggyluke• 13 years ago

I believe ISPs can not have a transparent HTTPS proxy without the "invalid certificate" browser warning. ISP users would have to manually trust their ISP's CA.

marbletiles4• 13 years ago

Or have it added to their chain beforehand. An ISP could trivially include this as part of their "welcome pack" installer CD or the like.

Would that silently affect people like us? No. Could they do it to all their non-technical customers? Absolutely.

olalonde• 13 years ago

This is quite common in China. Even the largest ISPs do it.

oracuk• 13 years ago

We have had a similar case publicly exposed here in the UK a little while ago with Phorm and British Telecom:

http://www.bbc.co.uk/news/technology-13015194

There is a good chance that such practices may be found to be illegal in a UK court (Regulation of Investigatory Powers Act primarily with some discussion about applying the Data Protection Act or Computer Misuse Act) but they haven't been tested yet. Both companies very quickly stepped back from the 'trial' they were conducting when it became clear there might be public support for a test case.

girlvinyl• 13 years ago

Does anyone know the CFAA implications here? My system is a "protected" system, this would clearly be unauthorized access.

kgosser• 13 years ago

Anyone else find it interesting that R66T is vaguely read as "ROOT" -- this is some kind of cruel joke, right?

rgbrgb• 13 years ago

Did anyone else have trouble hitting the back button after that article? I find that equally skeezy.

Edit: It seems they've mapped command-back-arrow to a non-default action. Not cool.

greglindahl• 13 years ago

Very interesting that r66t.com doesn't appear in the 2 most popular adblock+ block lists!

SpikeDad• 13 years ago

An interesting article but was overly verbose. Could have said the same thing in half the space.

However, a big FU to Arstechnica for prostituting the name of Apple to get more visits to the article. The headline did not need to imply that Apple.com was hacked or that Apple was somehow unaware of what's happening at their site.

It's sleazy journalism and beneath the usual ethics of Arstechnica

How a banner ad for H&R Block appeared on Apple.com without Apple’s OK

Related Stories