8 ms·

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what A

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

s3th 11y ago
It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
- pdkl95 11y ago
  The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
  - reissbaker 11y ago
    This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is. If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed. And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.
    - userbinator 11y ago
      Just block the network requests and you're done. Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods. That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.
      - iamsohungry 11y ago
        > Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM. It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.
    - 11y ago
- hn1234 11y ago
  Seth, the wasm "Text Format" doc at [1] says one of its purposes is "Presentation in browser development tools when source maps aren't present (which is necessarily the case with the Minimum Viable Product (MVP))" and that "Debuggers and profilers will present binary code using this textual format." However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on readability and debuggability with source maps in plain old JavaScript. Basically, it's impossible to use Chrome Devtools to see original variable names from the source file (e.g. 'jquery.js') instead of the minified file (e.g. 'jquery.min.js') mapped by the source-map file. This essentially makes source maps useless for debugging complex code and has been a known issue for almost two years. The most recent comment in that ticket notes work is blocked until a new version of the sourcemap spec is shipped, but the linked resources indicate there hasn't been any public activity on them in three weeks with the Sterland proposal [3] and three months with the Fitzgerald proposal [4]. If keeping the web open source is indeed a priority of Google and Mozilla, then why haven't more resources been allocated to develop those specifications? In brief, the lack of urgency for bugs like [2] suggests to me that Google and Mozilla don't take "The JavaScript Trip" described by Stallman [5] seriously. I fear that wasm could make it much worse. - 1. https://github.com/WebAssembly/design/blob/master/TextFormat.md#text-format https://github.com/WebAssembly/design/blob/master/TextFormat... 2. https://code.google.com/p/chromium/issues/detail?id=327092 https://code.google.com/p/chromium/issues/detail?id=327092 3. https://gist.github.com/asterland/edf028ed7947c8c258d1 https://gist.github.com/asterland/edf028ed7947c8c258d1 4. https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bindings/proposals/env.md https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bi... 5. http://www.gnu.org/philosophy/javascript-trap.en.html http://www.gnu.org/philosophy/javascript-trap.en.html
  - s3th 11y ago
    It's easy to overlook bugs in a tracker the size of Chromium's--even important ones. Thanks for raising the issue again.
eosrei 11y ago
You'll be able to reverse engineer. Interpreting JS is a massive waste of CPU/battery for the majority of users. The savings is worth a slight increase in complexity for developers.
- pdkl95 11y ago
  The solution to high CPU/battery usage is to send a static page. Invoking a new type of VM may help slightly, but it probably just moves the problem around.
  - Ace17 11y ago
    A static page ? What about games? Are you advocating to go back to Adobe Flash?
  - sp332 11y ago
    There's no reason to limit the web to static pages. How would you do this with a static page https://benedikt-bitterli.me/tantalum/tantalum.html https://benedikt-bitterli.me/tantalum/tantalum.html ? Or http://www.nytimes.com/interactive/2015/05/03/upshot/the-best-and-worst-places-to-grow-up-how-your-area-compares.html http://www.nytimes.com/interactive/2015/05/03/upshot/the-bes... Or https://play.freeciv.org/ https://play.freeciv.org/ Or anything on this page http://www.kongregate.com/ http://www.kongregate.com/ or, you know, Facebook or Twitter or Google Maps/Books/Docs/Photos...?
ossreality 11y ago
No, just like every other person who thought they were the first to notice the most obvious drawback of a binary format. Except that it's IL and that they've already planned for that. Why do people always ask these questions as if they're the first person to ever thing about them. I dunno, it just seems like once a week something WASM comes up and this same exact question gets asked
pjmlp 11y ago
For sure one will come up with nm or dumpbin for wasm, if they really want to.
alimbada 11y ago
Why does it need to be semi-readable? Why does it need to be readable at all?

s3th 11y ago

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)

pdkl95 11y ago
The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
- reissbaker 11y ago
  This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is. If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed. And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.
  - userbinator 11y ago
    Just block the network requests and you're done. Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods. That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.
    - iamsohungry 11y ago
      > Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM. It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.
  - 11y ago
hn1234 11y ago
Seth, the wasm "Text Format" doc at [1] says one of its purposes is "Presentation in browser development tools when source maps aren't present (which is necessarily the case with the Minimum Viable Product (MVP))" and that "Debuggers and profilers will present binary code using this textual format." However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on readability and debuggability with source maps in plain old JavaScript. Basically, it's impossible to use Chrome Devtools to see original variable names from the source file (e.g. 'jquery.js') instead of the minified file (e.g. 'jquery.min.js') mapped by the source-map file. This essentially makes source maps useless for debugging complex code and has been a known issue for almost two years. The most recent comment in that ticket notes work is blocked until a new version of the sourcemap spec is shipped, but the linked resources indicate there hasn't been any public activity on them in three weeks with the Sterland proposal [3] and three months with the Fitzgerald proposal [4]. If keeping the web open source is indeed a priority of Google and Mozilla, then why haven't more resources been allocated to develop those specifications? In brief, the lack of urgency for bugs like [2] suggests to me that Google and Mozilla don't take "The JavaScript Trip" described by Stallman [5] seriously. I fear that wasm could make it much worse. - 1. https://github.com/WebAssembly/design/blob/master/TextFormat.md#text-format https://github.com/WebAssembly/design/blob/master/TextFormat... 2. https://code.google.com/p/chromium/issues/detail?id=327092 https://code.google.com/p/chromium/issues/detail?id=327092 3. https://gist.github.com/asterland/edf028ed7947c8c258d1 https://gist.github.com/asterland/edf028ed7947c8c258d1 4. https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bindings/proposals/env.md https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bi... 5. http://www.gnu.org/philosophy/javascript-trap.en.html http://www.gnu.org/philosophy/javascript-trap.en.html
- s3th 11y ago
  It's easy to overlook bugs in a tracker the size of Chromium's--even important ones. Thanks for raising the issue again.

eosrei 11y ago

You'll be able to reverse engineer. Interpreting JS is a massive waste of CPU/battery for the majority of users. The savings is worth a slight increase in complexity for developers.

pdkl95 11y ago
The solution to high CPU/battery usage is to send a static page. Invoking a new type of VM may help slightly, but it probably just moves the problem around.
- Ace17 11y ago
  A static page ? What about games? Are you advocating to go back to Adobe Flash?
- sp332 11y ago
  There's no reason to limit the web to static pages. How would you do this with a static page https://benedikt-bitterli.me/tantalum/tantalum.html https://benedikt-bitterli.me/tantalum/tantalum.html ? Or http://www.nytimes.com/interactive/2015/05/03/upshot/the-best-and-worst-places-to-grow-up-how-your-area-compares.html http://www.nytimes.com/interactive/2015/05/03/upshot/the-bes... Or https://play.freeciv.org/ https://play.freeciv.org/ Or anything on this page http://www.kongregate.com/ http://www.kongregate.com/ or, you know, Facebook or Twitter or Google Maps/Books/Docs/Photos...?

ossreality 11y ago

No, just like every other person who thought they were the first to notice the most obvious drawback of a binary format. Except that it's IL and that they've already planned for that. Why do people always ask these questions as if they're the first person to ever thing about them. I dunno, it just seems like once a week something WASM comes up and this same exact question gets asked

pjmlp 11y ago

For sure one will come up with nm or dumpbin for wasm, if they really want to.

alimbada 11y ago

Why does it need to be semi-readable? Why does it need to be readable at all?