3 ms·

> If it's a binary blob rendered with canvas, that won't be true anymore. The request for the ads will either happen server side or client side. If it happens

> If it's a binary blob rendered with canvas, that won't be true anymore. The request for the ads will either happen server side or client side. If it happens client side, it can be blocked at the network level by the pihole regardless of whether a blob or js script is making the request. The request happening server side is unlikely per my previous comment.

ehnto 5y ago
Your previous comment doesn't explain a reason why it would be unlikely, just that it isn't. The reason it's currently unlikely is because ad-networks need to validate their views. Because you can ad-block on HTML alone, it isn't worth it to risk webmasters falsifying serverside views in order to try and get around ad-blockers because it wouldn't work. But add the ability to get around ad-blockers entirely and it becomes worth it to solve for server-side view validation. This is the landscape as I see it: HTML, ads loaded by user network: Can be blocked at network or in HTML. Binary blob, ads loaded by user network: Can be blocked at network level Serverside ads, HTML : Can be blocked by removing the ads in the HTML, and ad-networks don't like it because their views can't be validated and they could be scammed by webmasters. Serverside ads, binary blob: Can not be blocked by network or by hiding things in the HTML, ad-networks and webmasters would want this because they can get around ad-blockers, but will need to solve view validation, the tradeoff becomes worth it.
- pdkl95 5y ago
  > The reason it's currently unlikely is because ad-networks need to validate their views. Ad-networks also want to validate views because they don't trust the hosting website. They don't need to trust the hosting website's server when they can receive a direct connection from the client. However, there is an alternative that fits "serverside ads, binary blob" scenario: the ad-network hosts the website. Obviously the website owner wouldn't want to turn over control to the ad-network, but they don't get a choice when they depend on the ad-network for revenue. Even worse: this isn't a hypothetical concern. Google already tried to implement ad-network hosted websites with "AMP".

ehnto 5y ago

Your previous comment doesn't explain a reason why it would be unlikely, just that it isn't. The reason it's currently unlikely is because ad-networks need to validate their views. Because you can ad-block on HTML alone, it isn't worth it to risk webmasters falsifying serverside views in order to try and get around ad-blockers because it wouldn't work. But add the ability to get around ad-blockers entirely and it becomes worth it to solve for server-side view validation. This is the landscape as I see it: HTML, ads loaded by user network: Can be blocked at network or in HTML. Binary blob, ads loaded by user network: Can be blocked at network level Serverside ads, HTML : Can be blocked by removing the ads in the HTML, and ad-networks don't like it because their views can't be validated and they could be scammed by webmasters. Serverside ads, binary blob: Can not be blocked by network or by hiding things in the HTML, ad-networks and webmasters would want this because they can get around ad-blockers, but will need to solve view validation, the tradeoff becomes worth it.

pdkl95 5y ago
> The reason it's currently unlikely is because ad-networks need to validate their views. Ad-networks also want to validate views because they don't trust the hosting website. They don't need to trust the hosting website's server when they can receive a direct connection from the client. However, there is an alternative that fits "serverside ads, binary blob" scenario: the ad-network hosts the website. Obviously the website owner wouldn't want to turn over control to the ad-network, but they don't get a choice when they depend on the ad-network for revenue. Even worse: this isn't a hypothetical concern. Google already tried to implement ad-network hosted websites with "AMP".