Hacker News Reader

Comment by sam0x17 | Hacker News Reader

The thing with WASM though is you can always intercept it at the edges where it interacts with the DOM. The usual ad blocking tactics of either deleting particular arrangements of DOM nodes, blocking specific js/wasm payloads, and blocking specific domain names will still be unaffected. The tactics don't even need to change.

View on HN

If an entire UI (content plus ads) is drawn with wasm onto a canvas (the way Qt WebAssembly does it), it will be impossible to use CSS to hide ads, and possibly more difficult to modify the script to disable the ad-loading functions.

Doesn't sound very feasible, as this would make user experience probably much worse. No native elements, no browser integration or extensions, interaction with the page, and accessibility. They all would suffer.

If publishers valued user experience over ad income, they wouldn't show ads to begin with.

> No native elements, no browser integration or extensions, interaction with the page, and accessibility.

Sounds like the pages made in Flash (or even Java) which were somewhat common in the 90s.

> No native elements, no browser integration or extensions, interaction with the page, and accessibility. They all would suffer.

Uh, but those things are already happening right now, e.g. Flutter Web UI [1]

[1] https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-ba...

Right but my point is you can _already_ do this in javascript, but people largely don't. The playing field doesn't change with WASM. If some WASM code creates a canvas-based ad, we can use the usual tactics to block it (delete the element by ID/selector/etc or block that particular WASM payload)

Google would probably not feature you very high in search results, though, since your website has no indexable text.

Google is an advertising company. It would make sure there is a way to get your site indexed, perhaps by providing an alternate machine-readable version just to them. As a bonus, that version would not be available to potential competitors.

If this technique would become popular, Google will OCR it just like it runs JS.

This technique is essentially the same as websites made entirely in Flash back in the day. And back then, the only way to have Google index your site was to provide a separate (hidden) version that used normal, semantic HTML.

Googlebot runs a full web browser these days and executes javascript to a certain extent. WASM will have the same treatment if/when it becomes widespread if it doesn't already.

They can use it only for video players that'll autoplay for example.

If ad content is served from the same domain as normal content, and there is minimal DOM interaction, then it will be a lot harder.

The weird thing is, ads from the same domain already would be a lot harder to track. For some reason very few sites switched to this approach.

it's an ad industry thing, not a site thing. The ad industry would really have to build the solution to host on the sites, and the problem then becomes making something every site can reasonably host, and all the headaches associated with that.

And I have the suspicion that doing it wouldn't add much to the bottom line of the company who invested in it, despite how much they like to complain about ad-blockers.

That makes ad fraud detection much harder, which is something the ad industry is even less willing to accept than ad blocking.

How so?

This is what I understand the strategic intent of Google's AMP project to be.

Reply on news.ycombinator.com