WASM with DOM support will be great. Unfortunately it will also be great for obfuscation and malware.

You can already compile malware to obfuscated asm.js. If anything, WASM blobs are easier to reverse engineer than obfuscated JS - good luck writing a ghidra plugin for JS source.

▲

throwaway12pol 5 hours ago | parent [-]

What about obfuscated WASM blobs? At least obfuscated JS is still basically source code being interpreted, with WASM we will be running proprietary obfuscated binaries in the browser.

▲

kpcyrd 39 minutes ago | parent | next [-]

Obfuscated javascript could still import a WebAssembly polyfill, if there really was any advantage in doing so: https://github.com/evanw/polywasm

Since WebAssembly instructions are much easier to reason about, you could probably auto-optimize away a lot of the obfuscation, like "this is a silly way to do X, so we can just do X directly".

▲

Retr0id 4 hours ago | parent | prev [-]

I'd rather deal with an obfuscated WASM blob than obfuscated JS.

▲

throwaway12pol 4 hours ago | parent [-]

Why is that? With obfuscated JS you can instantly create ASTs, easily patch and preview the results. We have codemodding tools for mass patching and analysis. With WASM, you can theoretically have a future anti-tamper corporation with a solution to actively obfuscate binaries and antagonize reverse engineers, like we have today with desktop binaries.

	▲	kpcyrd 35 minutes ago \| parent \| next [-]
		Many of the anti-debugging techniques for desktop binaries do not work on WebAssembly: it can't jump to an address, it can't read the instruction pointer, it can't read/access it's own machine code, ...
	▲	Retr0id 4 hours ago \| parent \| prev [-]
		ASTs are pretty useless once it's been through a control-flow flattening obfuscation pass. At the end of the day it's just one representation vs another, but there are a lot more existing tools for dealing with binary reverse engineering.