The question is, who is sending binary WASM blobs? That ad data needs to come from an ad server, and if network requests to the ad servers are blocked, the ads will not load.
It might, but it doesn't have to be served from a different website. YouTube content is indistinguishable from ads since Google serves them both from the same domain. pi-hole does not work with YouTube ads, and it hasn't for years.
Needing to reverse engineer and recompile the YouTube app is the only way to block YouTube ads with the mobile client. It's the same situation with everything being a JavaScript canvas with custom rendering. The bar for preventing ad-infested content from being shown becomes much higher than simply removing an HTML element when everything is byte-compiled.
I feel like this is not talked about enough, because the implications are heartbreaking. This will be the end game for web ads: WASM + single canvas for ads and content + companies with the infrastructure to host ads on the same domain as the content. There will be no longer be a single content blocker that will be automatically compatible with a large ratio of web content if such a combination of tech becomes widely adopted. YouTube Vanced is essentially one of those specialized content blockers, where YouTube is a service lucrative enough to wall off with its own specialized ads implementation.
As mentioned earlier in this thread, I would guess that the only reason the ad agencies haven't won out and pushed WASM/canvas rendering everywhere is because of the necessity of screen readers.
I see, that is a valid point. I suppose Google could provide dynamically including ad content into the WASM blob before serving it out to the browser, but I would agree if you said this is pure speculation.
Yeah, and it's possible today to route that data through a first-party server and randomize the file paths too. So I would say it's plausible, but moving to canvas doesn't automatically make that part worse.
