I've seen a fair few Internet banking web sites pulling scripts from over a dozen third parties, mostly for tracking and advertising, but even for trivial things like social media. On their customer login pages. It's beyond me how they can consider this to be an acceptable risk.
But that is part of the tradeoff you make when you agree to accept money from someone to add their code to your site.
If someone offers you a hundred bucks to carry a bag onto a plane for them, you'd be right to be suspicious. Ah, but it's not just a random stranger. You were introduced to them by your buddy, the ad network. So that's okay then. Your ad provider wouldn't be dealing with anybody who was actually criminal. But what about negligent? Did they pack the bag themself? Have they let it out of their sight?
When you run ads on your site, remember which direction the money is flowing in, and remember who is the customer.
Ad networks are a trust broker. The ad provider wants to know their ad really was shown to a real person in a real web browser, who really does meet the demographic profile they are paying to target. They do not trust you, the publisher, at all. And they are paying.
You, as the publisher, are getting money from the ad network to compensate you for the inconvenience of surfacing the advertiser's content on your site. And of proving that you aren't defrauding them. To do that, you are going to give up some control.
And that includes control over whether the code you're serving is secure.
I surf with third party cookies and referers (via RefControl) disabled, and these should be the defaults
The trend for a long time was to cite using a CDN as a best practice, but no one ever calls out the downsides when making such statements. In this case, you lose control of the code and allow third-party access to your users' browsers.
If anything this is just enough facet of the weakness of the web as an app platform (Real solution: all sites serving client side libs should use package management, scripts should be digitally signed by the authors). As it stands it's far too common for people to just unzip WordPress or whatever in to their docroot, and so server-side code doesn't even get updated, let alone client-side code.
In any case, the defaults I live with cover all the other web resources too.
Not just potentially but (f)actually!
I hacked together something that implements this sort of behavior in a script loader a while ago, if you're interested: https://github.com/ryancdotorg/VerifyJS
So, though this does allow one to safely circumvent the hosting cost associated with bigger third party scripts, it means giving up some of the advantages like dynamic updates (as the hash would now be incorrect), right? This would therefore not work when ad providers want to be able to supply content they get dynamically from others right?
It seems not uncommon for ad networks to dynamically load further scripts/content, which would not fall under the hash. You can just sandbox them off in an iframe, though.
An obvious extension would be signed scripts, which would re-enable trusted updates of a script in a CDN, but there is the question of how that would be implemented.
In short; no, just a compromised dns record is not enough.
Some of them actually depend on that. We seen weird stuff show up on our sites because we made a deal with a company that sells ads for us. Suddenly we're pulling in stuff from companies we never heard of because the ad reseller made a deal with a third-party, which then again outsource part of their infrastructure to a fourth company. It's hours of detective work when you need to figure out who has misconfigured https.
> Is it violating program policy if I place ads on iframe webpages in my software?
> Yes, it does violate our policies. Firstly, you’re not allowed to place ads in a frame within another page. Exceptions to our policies are permitted only with authorization from Google for the valid use of iframes. Secondly, you’re not allowed to put ads in your software, e.g., if you control both a website with ads and an app that loads that website, we will take action against it.
Talking of which, where are the startups challenging adsense's dominance?
The fact that these ads disguise themselves as content that the site owner is recommending is particularly insidious, since it will likely encourage people to click through thinking that they can trust the content.
(You just know it's gonna happen one day under the guise of a free CDN)
increasingly hosted on the same domain
HTTP/2.0 supports _single connection multiplexing_, which means that domain sharding (splitting into different domains) is a _bad practice_.
If you're serving megabytes of JS such that that is enough to matter... no, it's still true, if that's not sustainable you've got bigger problems than a CDN is going to solve. Even on very JS-heavy sites, the amount of your bandwidth taken up by JS shouldn't be that large on a properly-configured site. (Yes, I can construct some rare exceptions... you've got a demo site for WebGL and your average viewer hits you once with no cache, grabs megabytes of JS and textures, then moves on never to return. But they are rare, even if you can construct them in your head.)
But this is the straw that's broken my camel's back and it spoils things for those of us who don't mind a few ads here and there. uBlock now installed, sod the ad networks.
(I run both)
I wonder what could be done to serve 3rd-party ads, making sure they can't hinder the experience of the users of the webpage.
Is this just laziness from those ad networks, or do we currently have the tools to counter this?