1. 31
  1. 18

    Nice job breaking it, W3C!

    My concerns/views on this are basically:

    WASM is bad for posterity, because binaries-by-default instead of source makes it easier to lose programs over time (compounding the issue with things only existing on the Cloud).

    WASM is bad for users, because it further hides what the software they’re using is doing.

    WASM is bad for developers, because it removes the utility of a mostly-lingua-franca set of skills and languages for web development and makes it harder to switch jobs.

    WASM is bad for the web, because it allows standards bodies to give up on producing useful standards in a timely fashion since “users can just build that part of the stack themselves in WASM”.

    WASM is good for advertisers, because it helps obfuscate ads and increase their performance and invasiveness.

    WASM is good for surveillance, because it helps make timing attacks more feasible.

    WASM is good for consultants, because it allows them to ship binaries and hold companies ransom years later for the source.

    That said, it’s too late to do anything about it.

    1. 24

      WASM is good for posterity because nobody but a large company can implement a compliant and performant JS runtime, while WASM is far simpler.

      WASM is good for users because it makes things possible that were impractical before.

      WASM is good for developers, because it allows people without expertise in all the weird nooks and crannies of JS to write stuff for the web in a language they find useful.

      WASM is good for the web, because it allows an opportunity to grow beyond the capabilities of JS without worrying about backwards compat, such as the work being done to expose browsers’ DOM API in WASM without the overhead of going through JS or having to conform exactly to its type system.

      I certainly agree with your other points. YMMV.

      1. 10

        WASM is good for posterity because nobody but a large company can implement a compliant and performant JS runtime, while WASM is far simpler.

        This is huge. It’s performance is also much easier to understand, which reduces the amount of cross-engine reverse engineering needed for writing performance-sensitive code.

      2. 25

        All the cons you mention are things that are already enabled by JS, and people were already doing.

        • JS minifiers, which are pervasive throughout the web, already prevent posterity and users from understanding what web software is doing.
        • Language diversity already existed on top of JS: Emscripten, Elm, CoffeeScript, ClojureScript, etc. Knowledge in JS is useless to varying degrees for developers targeting those environments.
        • People are already side-stepping inept web-standards bodies.

        WASM just makes use-cases that people were already doing more efficient. Nothing is lost.

        1. 5

          I’m going to have to strongly disagree on the language diversity front, because reasons.

          Like, there’s a future in which old legacy COBOL and Fortran programs are being compiled under WASM.

          1. 6

            If we are to throw large list around, here’s one for languages that compile to JavaScript.

              1. 1

                Like, there’s a future in which old legacy COBOL and Fortran programs are being compiled under WASM.

                Yawn, IBM did it four decades ago.

            1. 6

              Where JS is good for any of these things it is more or less accidental. If you want these properties then push for systematic change that supports them.

              Most of the issues here are that you want to consume from entities you distrust. Could either find ways to trust more or seek/build other providers.

              Trying to foster a demand for reproducible builds of open access code, combined with some infrastructure for reviewing that would be a big positive step.

              Promoting other revenue streams than surveillance and supporting companies that use those is another good one.

              1. 5

                Since you posted memes, I’ll post my own and say your comment was a whole lot of [citation needed].

                WASM is bad for the web, because it allows standards bodies to give up on producing useful standards in a timely fashion since “users can just build that part of the stack themselves in WASM”.

                This already happens with JS, are you familiar with SVG animations? Since it’s a big investment to add a WASM build to a page I don’t see this becoming an additional excuse when unnecessarily throwing JS at a problem already works great. When Canvas was being standardized, did you say “this allows standards bodies to give up on CSS because users can just put everything in their own rendering code”?

                WASM is…bad for posterity, because binaries-by-default instead of source…bad for users, because it further hides what the software they’re using is doing…good for consultants, because it allows them to ship binaries and hold companies ransom years later for the source.

                Since other users have responded to this thoroughly, I think there’s no comment needed.

                WASM is good for advertisers, because it helps obfuscate ads and increase their performance and invasiveness. WASM is good for surveillance, because it helps make timing attacks more feasible.

                I honestly just don’t see this. You’d have to make/link us a POC to show how this is true and not just FUD. The fact of the matter is that WASM is as incredibly niche as Canvas ended up being. It really only offers a meaningful difference imo where allocations and indirection that are unavoidable in JS are painful or a deal breaker for an application. In the real world, the amount of scaffolding required for a WASM application would essentially just fill up the only real bottleneck for advertisers: network I/O. Plus, and you can correct me if I’m wrong, WASM doesn’t get access to any timers that JS doesn’t; timing attacks that work in WASM would likely work just fine in JS.

                1. 2

                  Canvas hardly niche, though people often use it behind some lib like D3 or whatever.

                  WASM is also already being used in cryptominer malware on sites. The timing attacks are a pretty obvious result of shared memory and multiple threads.

                  On the SVG thing…look, with WASM it becomes possible and maybe even more performant in some cases to replace the entire rendering stack in a browser as well as possibly other things like script interpretation, network parsing, and so forth. In exchange, we get even less visibility into what our apps are doing than we have now.

                  1. 2

                    Just want to point out that it’s unlikely any user-level code on the browser will replace normal application rendering stacks, either using WASM or JS. If the UI elements on the page are opaque to the browser, then screen-readers and other accessibility features won’t function. That’s just the tip of the iceberg, you’d also have to re-implement IME for your international users.

                    1. 1

                      I dunno. WASM interfaces using webgl have already appeared. There’s a text editor written in rust, for example.

                      1. 1

                        And does that text editor provide accessibility features? Does it provide IME?

                        1. 1

                          No idea. And I can’t find the project any more, so maybe it’s been abandoned. But in principle there’s no reason it couldn’t be accessible and provide IME.

                          1. 1

                            Yeah there is, there is no way to integrate with the browser’s native accessibility features outside of using DOM. Screen readers rely on native UI widgets.

                    2. 1

                      Now the cryptominer issue is 100% one I could see, and it got me thinking about sites needing to request a capability for a “high-power” mode. However, cryptominer malware isn’t even remotely in the same domain as timing attacks; you’re still just talking anecdotes there.

                      Canvas hardly niche

                      With the exception of fingerprinting (a real ongoing API mistake, to allow inspection of rendered canvas data) what percentage of websites you view do you think utilize a canvas?

                  2. 8

                    Meta: for the five folks who have flagged this as incorrect: nothing I wrote was incorrect. I disclaimed those as my views and concerns. While you can certainly disagree with my conclusions, you can’t claim with any certainty that I am stating them falsely.

                    Please reserve that flag for inaccurate statements of fact, otherwise people will just abuse it to cudgel users they disagree with.

                    1. 1

                      because it helps make timing attacks more feasible.

                      Until you can demonstrate this, it is false.

                      1. 1

                        It is true that I believe it.

                        As recently as 2 years ago, people working on the problem seemed to to.

                        Like, regardless of what you seem to think, I’m not just pulling these concerns out of a hat.

                        Every benefit about WASM being great for high-performance stuff also kinda implies it being useful for making high-precision timers, defeating mitigations put into place elsewhere.

                        1. 2

                          It is true that I believe it.

                          That’s not how you worded it however. You would word it “I believe it might make timing more feasible” or something similar if you wanted to paint it as an opinion. The way you wrote it, I personally read it as though you were writing what you saw as fact.

                          1. 1

                            Well, hopefully you’ll read more carefully next time!

                          2. 2

                            It is true that I believe it.

                            With respect, that does not and should not cut the mustard.

                            Great rebuttal otherwise. You’re right on the money about high performance vs timers.

                            Mid-term I would hope this argument falls apart as timers become safe, but there’s definitely downsides to making web tech faster.

                            1. 1

                              Again, we have the incorrect tag for factual incorrectness. It is a fact I believe what I wrote, and it was not an accident that I put the disclaimer “hey the following are my views” instead of “the following are self-evident immutable laws of conputing”.

                              If people are punished for expressing their opinions, it doesn’t foster good-faith discussion. People flagging things incorrect because they don’t agree with them means it stops being useful to flag actual inaccurate reporting of reality.

                              My strong belief is that continued abusing of flags means nobody pays attention to them anyways, and they lose their utility completely. And then we have move closer to just being a Reddit/HN clone.

                              1. 1

                                I used the incorrect tag primarily because I personally thought you were writing something as fact which isn’t. That’s that.

                      2. 4

                        I agree with your goals, but I think that it is not important whether there is WASM or not. Even the JavaScript – however formally source code and text – can be obfuscated on the source code level, crippled by proprietary licenses on the legal level, and designed user-unfriendly (move certain parts to the server, make unnecessary calls to the server to build more vendor lock-in, implement DRM, spy users etc.).

                        It is much more about what you (as a provider of a service or software) want to do, rather than what particular technologies (WASM in this case) you will use.

                        You could also say that ELF binaries in your GNU/Linux distribution are bad and everything should be scripted, because user can read and modify scripts but not binaries. However this does not make sense. What matters is the intention – if we do free software and honestly provide services in an ethical way, we can distribute binaries, because the user can also get the source codes, study them, modify them, build his own software. And if the builds are reproducible, he can even verify that our build originated from the same source codes as he got.

                        1. 4

                          If WASM did end up posing a more substantial threat to the user than vanilla JS, I would expect browsers to implement controls like the Java applets of days gone by, at least eventually. Until then, this is still the middle ages of the web, and anything goes!

                          [Old comment edit: a more substantial comment made by @rian]

                          Isn’t this all true for Javascript minification already?

                          1. 5

                            I believe you are wrong on most counts. It will enable more security, more control and better performance across the whole computing landscape.

                            Wasm has a wonderful capabilities model built in, it actually has less ability to affect the world outside of its sandbox than JS running in the browser does.

                            1. 1

                              I agree that the loss of the lingua-franca can be viewed as a negative thing, but that already happened when we started transpiling other languages to js.

                              Most of the source found online is already hard to reverse engineer due to js minification anyway. Having to use a prettyprinter + refactoring IDE vs having to use something like IDA or Ghidra isn’t that big of a leap anyway

                            2. 9

                              Oh hey, Java Applets are back. 😏

                              1. 5

                                Just maybe not 10-15x slower and uglier than existing apps this time.

                              2. 0

                                Sad day for the internet, for reasons already mentioned.

                                1. 5

                                  Happy day for the internet, for reasons already mentioned.