Hacker News Reader

Comment by jniedrauer | Hacker News Reader

After playing around with immediate mode GUIs in WebAssembly, I can envision a future which renders any kind of content blocker obsolete. The internet could be turned into cable television. I don't want to sound overly pessimistic, but it seems very plausible that this is the future we will eventually end up with.

View on HN

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.

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.

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.

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

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.

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

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.

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.

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)

WASM modules can be blocked by domain just like regular ads. Just block the whole thing, problem solved.

Just like you can easily set your browser to refuse all cookies. Problem solved, now you can’t browse half the internet.

Wasm has a pretty simple execution model, wouldn’t be hard to write something that preprocesses wasm code during load, similar to what you can do with java classloaders.

Easily preventable using encrypted wasm modules.

I don't think WASM can write to its code memory to self-decrypt. At some point, the WASM has to create a DOM node containing the decrypted script, at which point you can process the code.

Now that is an idea for a prof of concept.

We can handle Wasm like Flash: declare it obsolete and then reinvent it again.

Declaring something obsolete doesn't make it so. Flash went away because of iPhone and rise of mobile app and still it took about a decade for it to be irrelevant. Without a similar tectonic shift, it would take longer.

I worry a lot about this but if this is the price of competing with the Google/Apple duopoly maybe it's worth it.

Reply on news.ycombinator.com