Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If ad blocking really became a significant problem, the next big change I suspect is server-side ad network integration for ad serving.

Architecturally, it is definitely possible to interleave ads from an ad network into your server's http3 response stream by doing server-side ad network integration. Only the measurement needs to be client-side and directly integrated with ad network, if at all. The same underlying mechanism used for content security policy can be used for ensuring integrity of ad content even when not served directly by the ad network. So, any domain/url/path/extension/dom-id etc based ad blocking mechanism isn't going to work.

Very likely this will result in superior technical performance (latency and measurement), and superior ad performance (due to richer backend data integration and better ad selection). It is just a matter of time.



Quite possibly. Google and the other major players are reluctant to do that because it's much, much harder to do a server side integration solution without compromising user privacy by handing the third party owning that server a lot of intimate knowledge about the ads being served to a customer. Under the current system, your privacy is protected because the only place that integrates your browsing habits and the ads you're seeing is actually your browser.

I'm sure that such intimate server side integration will eventually result in legislative pushback for privacy protection, and the measure-countermeasure game will continue.


Sorry, I do not believe this.

I do believe that Google doesn't want ads served through the site that's actually being visited, because it reduces Google's visibility into what's going on, which affects both Google's semi-legitimate interests, like being able to detect click fraud, and Google's total control over information that might be used for targeting.

I also believe that many of the sites don't want that, especially the smaller ones. It'd be more complicated for them to set up, and would mean they needed more bandwidth.

I do NOT believe that Google actually cares enough about user's privacy per se to do much about it. If that were the case, Google itself wouldn't collect about 95 percent of what it actually does collect.

User privacy sounds good as an excuse, though.


> Google and the other major players are reluctant to do that because it's much, much harder to do a server side integration solution without compromising user privacy by handing the third party owning that server a lot of intimate knowledge about the ads being served to a customer.

They might be able to address this by flipping things around. Instead of the ad service providing ads to the content provider for the content provider to them embed in the content and server, have the content provider provide content to the ad service which then puts in the ads and serves the content.

Let's say content provider foo.com wants ads from Google. One way this could be done is for foo.com to organize their site so that any pages they want ads on come from content.foo.com. They would set content.foo.com to point to a server run by Google. That server would provide a way for foo.com to put their content there, with some mechanism for Google to do the ad integration and then serve the pages.


In the current status quo, there is a data détente that keeps either solution from happening: advertisers don't want to give third-party websites intimate knowledge of ads vended because they don't want to compromise user privacy (or more cynically: they don't want to give third-party sites so much info about what ads are run to what users that those sites cut out the middle-man and just broker adds to run for users directly). But third-party sites don't want to give intimate details of users of their site to ad companies for symmetrical reasons (Google has dipped its toe into social media before).

If the industry moves to a place where only server-injected ads are profitable, something will surely give here. The end result will be more large conglomerates knowing more about us than ever before, unfortunately.


> If ad blocking really became a significant problem, the next big change I suspect is server-side ad network integration for ad serving.

I'm surprised that's not already the case. Well, not that surprised, it's a business where at least one of sides is scum and server-side makes it a hell lot easier to cheat


The problem with server side ad insertion as you call it is the lack of accountability.

It gives way too much power to the publisher: they want the ad money and therefore have all the incentives to commit fraud.

At the moment, having the ad distributed by a third party and a ton of other third party JS in the browser allow all parties involved to cross check each other.

The bot problem would be way worse with server side.


We've been really lucky so far that most marketing departments don't seem to interact with the core codebase when it comes to injecting ads, they just get a Tag Manager and can inject as many ads as they like.



Yes, platforms like cloudflare worker can be used to inject personalized ads into html before it served to visitors. It's likely to be much cheaper than forgoing cache and process ads on your web server for every visitor.


I can see that happening and that could be a good way to remove all that JS nightmare and provide better visibility on perf impact, eventually improving overall user-experience.

In the meantime, someone will build adblocker undoing what has been done server-side. And if this is hard to detect, that will be based on training/model. Data integration will be subject to GDPR.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: