This CL moves the base::Feature from content_features.h to
a generated feature from runtime_enabled_features.json5.
This means that the base::Feature can be default-enabled
while the web API is co...
I just don’t understand why they’re trying to solve this issue on the client side. It seems like a losing battle to me.
Instead, focus on the server side. If you want to push ads, then host on (or tunnel from) the content server. Get rid of all the <div\>s and tags and scripts and adserver links that the adblockers are using to identify ads. Just assemble the page on the host so that it looks indistinguisable from the content the user is looking for and push it out. EAT BACHELOR CHOW! NOW WITH FLAVOR! Google could even start an ad-friendly hosting service that does this - some sitebuilder tools, identify where you want Google Adsense, and host the damn thing.
Unless everybody fully customises the display and styling of the adverts for their own website, there’s going to be some sort of targetable, recognisable pattern in the way AdSense content looks. Most developers just want an easy drop-in solution.
Furthermore, Google don’t necessarily want to give you that level of control over the adverts, because that makes it easier to game the ads system with malicious, fake and misleading clicks or invisible adverts. They need their tracking tech attached to it.
So render to image? That sounds terribly inefficient. That means you’re drastically increasing the load on the server and sending way more data over the wire. And then on the client side, your page no longer changes to fit the huge variety of viewport sizes. And say goodbye to being able to copy-paste. Or any kind of user interaction. And anyone with visual disabilities can go fuck themselves, I guess.
No, they didn’t mean to render it all as an image, but that everything comes from the content server you’re getting the content you want from and thus the ads should be indistinguishable from content. I don’t understand how you could misunderstand it to such a degree as to think they meant to render it all as an image.
Because even if you host the ad content on the same server, it’s still possible to distinguish it, such as by URL or element xpath. To assemble the page to avoid this, you’d need to completely render the page.
I just don’t understand why they’re trying to solve this issue on the client side. It seems like a losing battle to me.
Instead, focus on the server side. If you want to push ads, then host on (or tunnel from) the content server. Get rid of all the <div\>s and tags and scripts and adserver links that the adblockers are using to identify ads. Just assemble the page on the host so that it looks indistinguisable from the content the user is looking for and push it out. EAT BACHELOR CHOW! NOW WITH FLAVOR! Google could even start an ad-friendly hosting service that does this - some sitebuilder tools, identify where you want Google Adsense, and host the damn thing.
Unless everybody fully customises the display and styling of the adverts for their own website, there’s going to be some sort of targetable, recognisable pattern in the way AdSense content looks. Most developers just want an easy drop-in solution.
Furthermore, Google don’t necessarily want to give you that level of control over the adverts, because that makes it easier to game the ads system with malicious, fake and misleading clicks or invisible adverts. They need their tracking tech attached to it.
So render to image? That sounds terribly inefficient. That means you’re drastically increasing the load on the server and sending way more data over the wire. And then on the client side, your page no longer changes to fit the huge variety of viewport sizes. And say goodbye to being able to copy-paste. Or any kind of user interaction. And anyone with visual disabilities can go fuck themselves, I guess.
No, they didn’t mean to render it all as an image, but that everything comes from the content server you’re getting the content you want from and thus the ads should be indistinguishable from content. I don’t understand how you could misunderstand it to such a degree as to think they meant to render it all as an image.
Because even if you host the ad content on the same server, it’s still possible to distinguish it, such as by URL or element xpath. To assemble the page to avoid this, you’d need to completely render the page.
so… PDF then?
/s
Thanks, BTW. It never occurred to me that someone could interpret my comment as “render-as-an-image”.
You explicitly state “render to image”.