>My guess is to prevent ad-fraud by website owners. It's a lot harder to detect fraudulent clicks/impressions if all data are routed through website.

Isn't the solution to that problem a flat rate fee (similar to how advertisements on tv, newspapers and magazines work)?

Instead of a pay-per-click it could be a simple $X dollars and your ad will be visible for Y days/weeks.

I don't see how that would work. If my site gets zero traffic, would I still get paid a flat rate to 'serve' ads? Pay per impression/click works to pay proportionally to individual site traffic and the extent of a campaign.

The current solution is effectively a flat rate as far as an ad campaign is concerned: impressions/$

People would either (a) pay to place ads on sites they knew had a decent amount of traffic just from reputation, or (b) would hire ad-buying companies which made it their business to know what different sites' ad space is worth.

Needless to say, this could be inconvenient for the adwords-make-me-five-bucks-a-month scale sites. It'd work out OK for the New York Times-es of the world though.

What would happen if browsers simply didn't allow cross domain referencing? Would the web break (and would it be worse than NoScript)?

I've thought about this before, since NoScript is too disruptive for me. One issue is that it's common for scripts to served from assets.whateverwebsite.com. I also thought of allowing anything from the same second-level domain (so anything on .whateverwebsite.com), but that would allow anything on .co.uk. ¯\_(ツ)_/¯ in Chrome I trust, for now.

Sounds like a job for the public suffix list.

Ooh, cool, hadn't heard of that before! TIL.

But even with the added complexity of regularly pulling in the public suffix list, the problems keep going: e.g., facebook.com's scripts are all served from static.xx.fbcdn.net.