Hacker News new | ask | show | jobs
by geofft 3401 days ago
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.
2 comments
kbenson 3401 days ago
> 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...

link
random_person04 3401 days ago
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?
link
geofft 3401 days ago
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.

link