WebAssembly doesn't grant any extra permissions into the inside of the browser sandbox. Audio and canvas HTML elements already exist and don't have any innate connection to WebAssembly. (If you ignore performance, WebAssembly could be entirely polyfilled into old browsers that didn't support it through a Javascript interpreter.)

Yep, people seem to have a hard time understanding that WebAssembly doesn't add any new functionality, it just makes what JS can already do more performant (for cases that benefit from it). WebAssembly by itself is actually running inside a more restrictive sandbox even.

It's not about permissions. It's about decoding video using WebAssembly and rendering it on canvas. Browser can't prevent it. Now I'm not sure that it wasn't possible before WebAssembly... Decoding some tiny video should not be that resource-intensive. Also you could just utilize GIF.

It is about permissions. You can autoplay video just fine with HTML5. But you can't do it with sound. And how would your WebAssembly decoded video play sound? Right, using the exact same HTML5 media elements. WebAssembly doesn't allow you to somehow do different things in the page. It only allows some computations but to actually have any output it has to resort to the same APIs that your normal JS uses.

If you can autoplay html video without sound right now, then you're right, I thought that autoplay was forbidden for all videos.

That's what I told Firefox, but for some reason video autoplays just fine all the time so...

Same, is there a fix for this?

Firefox media developer here.

It's a bit hard to understand what the problem is, sorry.

You can block video and sound auto-play altogether, or just audio, or none, in `about:preferences#privacy`, and choose or check exceptions you've granted, but if I read the grand-parent comment correctly, an appropriate setting has already been put in place.

Additionally, if the website really wants to play audio against a visitor's will, it can try to hijack clicks and touch events. There are some plans to tighten this, the spec was designed to allow implementing various policies. It should also be possible to write a content blocker for this as a Web Extension (maybe it already exists).

Does this happen on all websites? On some websites, that you could possibly share with us, so we can have a look and understand what's up ?

Can anybody that is not satisfied about this open a ticket at https://mzl.la/363s8KN, and put in `:padenot` in the box `Request information from` (log in with github or a bugzilla account) with some info about the websites ? An alternative would be to send me an email, username at mozilla.com.

Thank you, I have only noticed this occurring after clicking a different video first. It is probably due click highjacking or the like.

Thanks, I'll keep this in mind and report when I get it next time.

So far uBlock Origin seems to be pretty good at keeping the most annoying videos at bay, but sometimes they do slip through.

I also noticed it today on a website that video was autoplaying and was shocked by it as Firefox has stopped that for some time.

I'll note where it happens again.

I don't suppose you dismissed one of those "totally GDPR compliant" cookie bars right before that, did you? (You may have to think very hard; it's basically muscle memory for us these days...)

I've seen this trick in the wild. "No autoplay" means "no autoplay without some user interaction first". And clicking one of those "I accept" buttons is indistinguishable from clicking on any other random element to make it play a video. So they just made the "I accept" button play the video as well as dismiss whatever thing was probably covering up the website.

Some people are terrible.

You know what that could have been it, that would be one of those tricks.

Thanks for the tip.

This already happened. It's why the Chromium team doesn't allow blocking video completely because they saw the advertisers just working around the issue by making custom players. Those players were bloated and heavy so by blocking video for the user they didn't actually help block video and they made the problem worse.

So yes, with or without wasm, people will roll their own ways of trying to get your attention.

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.

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 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.

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.

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.

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.

It’s long been possible to decode H.264 using JavaScript (which obviously uses way more power than the native decoder). This is why browsers only restrict audio playback rather than actually autoplaying video.

Playing audio from WASM means going through WebAudio, there is no magic direct connection between WASM and the system's audio device.