I worry it means "end of browser view source" and frankly concerned this will be (ab)used to implement DRM for information that we can easily view and copy the source now.
JavaScript minifiers are already in wide use by anyone making serious use of JS, and JavaScript obfuscators exist.
I think the cause of computing freedom is likely better served by building high-quality wasm disassemblers (radare has an open ticket, for instance) and by making sure that wasm code is so tightly sandboxed that DRM can't work, i.e., that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell. Hoping that technologies won't get developed has historically not been a productive approach for software freedom; the folks who want to take our freedom have enough resources that they'll do it whether or not there's a standards process involved.
> that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell.
Even if it isn't, it's not like the browser itself is just some binary blob these days. Taking the source for firefox or blink or webkit and compiling your own version with slight changes is not only possible, it's already done in many instances. What's Mozilla's response when you take their browser and provide a fork with the sole change being to provide more freedom and choice? Not that it even matters, as it's not like you need to get mindshare from the public for this, developers that want to see the source will actively search for and find solutions, or make their own. There are simple extensions to bypass CORS controls for most (all?) browsers. If they didn't exist, browser variants disabling those same security mechanisms would exist.
It's all opt-in gentlemen's agreement style security. Both ends have to by in for it to work, and you control your end...
Why do I get the feeling that even though it will be sandboxed, there will some sort of DRM API/standard that allows the website to play encyrpted audio/video directly through Intel's Protected Audio Video Path?
Yes, that's a very good worry - that content will be end-to-end encrypted between the provider and an approved monitor, and not even the compiled client-side code will see the cleartext content.
But if the compiled code doesn't see the cleartext content, there's no reason to obfuscate it; the provider can safely do the same thing in unobfuscated JS, by just making an XHR to retrieve the encrypted media and passing it to a <video intel-drm-crap="yes"> element.
Arguing that no such API should exist in the browser is going to be a way easier fight than arguing that no compiled code should exist in the browser. There are plenty of good use cases for compiled code, but this one API is only useful for DRM.
There are decompilers and disassemblers for pretty much every compiled language, and WebAssembly will be no different. The gains in performance, security, and flexibility for the masses greatly offsets any increased effort in the tiny percentage of people who want to view the source.
Most likely these tools will just be built-in, the same way http/2 doesn't have a text-based protocol but you don't notice anything different when using devtools to see network requests.
I'm sympathetic to that argument, but this isn't about demanding access, this is about incentives / soft encouragement.
Many websites today have readable JavaScript because that's the natural thing to do; you just send down the JavaScript source in the original form and it runs.
Many native applications today have unreadable source because that's the natural thing to do; you compile your C or C++ code, and you only need to ship the binary. Your binary even gets smaller if you remove debugging symbols.
You can do otherwise in both cases (obfuscaters in the former, provide source in the latter) but it requires an active decision to do so. Much fewer software authors make the conscious decision to leave their source code readable or unreadable based on what they want a priori. Same with server- vs. client-side development; you can easily hide all your source by keeping it server-side, but for the sake of some technical goal people will decide to move parts client-side, and decide that having it be world-readable is okay.
OP is advocating for a world where people continue to default to providing their source, not one where people are compelled to.
If you render to a canvas rather than generate plain text, then I have to use screen readers with built-in OCR to perform "copy," which is a pain. It doesn't protect you, but it makes my experience worse.
What we're learning from music and movies is that any movement to try to restrict users just leads to user flight; any movement that opens up and enables users to have a great experience with your IP, leads to user delight.
