Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security The Internet Technology

Half of the Websites Using WebAssembly Use it for Malicious Purposes (zdnet.com) 109

Around half of the websites that use WebAssembly, a new web technology, use it for malicious purposes, according to academic research published last year. From a report: WebAssembly is a low-level bytecode language that was created after a joint collaboration between all major browser vendors. It introduces a new binary file format for transmitting code from a web server to a browser. Once it reaches the browser, WebAssembly code (Wasm) executes with near-native speed, similar to compiled C, C++, or Rust code. WebAssembly was created for both speed and performance. Due to its binary machine-friendly format, Wasm code is smaller than its equivalent JavaScript form, but also many times faster when executing. This has made WebAssembly the next incarnation of Adobe Flash, allowing websites to run complex CPU-intensive code without freezing a browser, a task for which JavaScript was never designed or optimized for.
This discussion has been archived. No new comments can be posted.

Half of the Websites Using WebAssembly Use it for Malicious Purposes

Comments Filter:
  • by samwichse ( 1056268 ) on Wednesday January 08, 2020 @09:57AM (#59598964)

    I am very surprised.

    No one could have predicted this.

    Oh no.

    • JavaScript, it is slow, and having the source always available makes it too easy to hack and tweak.
      Web Assembly, it is too fast, and difficult to manage malicious code, as we are running off of a binary blob.

      So what will need to be done, is boggy software like Anti-Virus to be able to detect malware patterns and alert us of the problems, so we get to the point where WebAssembably will slow it down just as poorly as Javascript.

      • by ceoyoyo ( 59147 ) on Wednesday January 08, 2020 @10:34AM (#59599128)

        I've got another suggestion. We should have some kind of document viewer for random content on the Internet. Those documents could be written in some kind of markup language and be primarily static, with *very* restricted dynamic capabilities.

        For actual programs that do sophisticated processing, you would have to download code from a trusted source and explicitly run it.

        ** Note: this post contains sarcasm.

        • How 1990's of you.

          Like it or not. HTML has moved from a document format, to the Interface Application Layer of an applications.

          Because of this migration the standard form request, and HTML push based apps quickly have gotten to cumbersome to handle, as well put undo burden on the servers pushing thousands of requests. Client Side processing (while granted some sites go too far) takes the burden off the Server which is doing a lot of work all the time. To the Client (where if I expect if you check your PC,

          • To the point where Windows 98 had integrated the web browser into the OS, and using IE for basic stuff like file browsing. Also unlike other methods at the Time, such as Terminal Emulation and XServers. Everyone had a decent Web Browser which did the job. And made deployment of software easier.

            It was very handy to bundle IE with Windows 98. Then I could download Netscape Navigator directly instead of having to find the CD.

          • by ceoyoyo ( 59147 )

            Damn man, I even put in the sarcasm footnote.

            So seriously, yeah, of course everyone has decided the web is this awesome way of getting software to users. We've trained them to load and execute that code with impunity. Meanwhile, the capability of browser-hosted code has expanded. Google wants to give it access to the host filesystem now. I'm sure that will work out fine.

            Google's desktop strategy is clearly to expand the capabilities of the browser until browser-based code can do anything. I think it's quit

          • How 1990's of you.

            Like it or not. HTML has moved from a document format, to the Interface Application Layer of an applications.
            And in parallel with this migration, the internet has become a hotbed of malware which has been enabled by this change in the web methodology. You're taking remote code and running it on your local computer without adequate safeguards. There are many things which *could* be purely an HTML styel view of a remote page but for which the devs have added bells and whistles to jazz it up, and opened the door to malware as a side effect. Is WebAssembly more of the same, something to make devs happen but which also props open the door for bad actors?

          • Ah yes, 1990. When the web had to be efficient because the bandwidth was actually limited, when we got static ads that were easy to get rid of and when webpages were actually created by people who wanted to deliver information rather than harvest eyeballs.

            Can we get that back?

        • I've got another suggestion. We should have some kind of document viewer for random content on the Internet. Those documents could be written in some kind of markup language and be primarily static, with *very* restricted dynamic capabilities.

          For actual programs that do sophisticated processing, you would have to download code from a trusted source and explicitly run it.

          ** Note: this post contains sarcasm.

          ** Note: I noticed the sour chasm.

        • by Tom ( 822 )

          Two flaws in your thinking:

          a) users want dynamic capabilities. Like it or not, you can't change a billion people.

          b) where, exactly, from a security perspective, is the difference between downloading code as a binary file and executing it natively and downloading code as a binary blob and running it in the browser?

          • by ceoyoyo ( 59147 )

            Sigh. Sarcasm.

            But since you want to take it seriously, here you go: the difference is that users are trained to download web pages, and run the code on them, without thinking. They're trained *not* to do that with native programs. Sure, some do anyway, but it's a minority. IT departments are the same way: they're very eager to lock down systems so you need them to install anything, but very few use a web whitelist.

            The only thing that's protecting those users (and IT departments) is the browser's sandbox.

            • Now any web page can download and run code from anywhere it wants to and send data wherever it wants to.
              Nope it can't.
              The original web page has to white list every other site it allows to interact with.

              • by ceoyoyo ( 59147 )

                "Now any web page can download and run code from anywhere it wants to and send data wherever it wants to."

                Um. Read more carefully?

                "any web page" = "the original web page"

                "it wants to" = pages it "allows" or "whitelists".

                • Yes, but your post implied: you download java script from A and it can wildly access the world wide web, which it can't (or should not be able to do).

                  • In the beginning, JavaScript was slow, because it had no static typing. Really clever compiler tricks made it fairly fast, but still not as fast as C++.

                    But then came TypeScript etc. as it dawned on the JavaScript community that no static typing was a bad idea for code maintenance.

                    But, golly gosh, once we have static typing (plus a few other thing) it is possible to compile JavaScript down to binary, just like Java has been for years (or Lisp for years before that). This is not there yet, but will be.

                    So t

                    • by Tom ( 822 )

                      So then the ONLY benefit of WASM will be obsfucation.

                      The primary benefit of WASM is that you can write your app in a programming language that's not utter garbage.

            • by Tom ( 822 )

              They're trained *not* to do that with native programs.

              They are?

              37 years of malware prove you wrong.

              Sure, some do anyway, but it's a minority.

              We actually have "Ransomware as a Service" providers. Your minority is large enough to support an entire industry.

              The only thing that's protecting those users (and IT departments) is the browser's sandbox. It is *very* different than running a native app.

              Yes, because native apps generally don't even run in a sandbox.

              And the powers that be have been constantly eroding the security of that sandbox

              I do agree with that. It's ridiculous what some random JS can do. But you know - at least there are some restrictions. Not so for native apps. At least until we get an iOS like permission model for the desktop. But yes, they've driilled to many holes into the box that it's more like a fenc

              • by ceoyoyo ( 59147 )

                Yes. Users are trained not to run random programs. Some do. Imagine what would happen if people regarded running native programs the same way they do loading websites.

                My point is that web apps are sandboxed, but as they get more sophisticated there is continual pressure to poke holes in the wall, and the wall *is* eroding. Yet we've retained the early web paradigm that it's pretty safe to load any web page and let it execute whatever code it wants. That becomes less true with every Google innovation.

                Origi

                • by Tom ( 822 )

                  Imagine what would happen if people regarded running native programs the same way they do loading websites.

                  A lot of them do, that's a big part of the problem.

                  The web has evolved over the last thirty years in the direction of native apps, getting more and more dangerous.

                  That is true. It was never really safe, though. There were attacks on browsers long before the browsers allowed native code execution.

                  So now we've got two sources of "apps" and zero sources of safe static hypertext.

                  I see what you mean. You want a "reader" for the Internet, instead of an application platform. I do agree with that. Browsers do need a "safe mode" where code can manipulate the website it displays and can't touch anything outside that.

          • where, exactly, from a security perspective, is the difference between downloading code as a binary file and executing it natively and downloading code as a binary blob and running it in the browser?

            A native application distributed as source code under a free software license at least offers the opportunity for a user to inspect and patch the source code between downloading and installing it.

            • by Tom ( 822 )

              least offers the opportunity for a user to inspect and patch the source code between downloading and installing it.

              Theoretically.

              In reality, the number of people who actually do that is not much different from the number of people who could just as well inspect and patch a binary. Really. Most developers don't inspect the 300 libraries they're embedding thanks to their auto-dependency-resolving build environment, nor are they actually sure which version of what library they're using thanks to continuous integration. Most of them couldn't list all the libraries that are in their binary without asking their toolchain.

          • a) They do? Can we get a survey on whether people enjoy autoplaying videos and pages that need half an hour to load just because the menu wants to do somersaults before actually giving the user the content?

            b) From a security perspective, the difference is having the user deliberately execute something that he deliberately downloaded from a source that he can actually verify for security purposes vs. something being downloaded from some webpage without the user's consent and executing it, with all that stand

            • by Tom ( 822 )

              a) They do?

              Yes, they do. Your auto-playing videos is a strawman. But users want a webmail that's not too different from a nativ app, they want Google Maps and drag-and-drop dashboards on their corporate web-apps.

              the user deliberately execute something that he deliberately downloaded from a source that he can actually verify for security purposes

              dreamland.

              99.9% of users have never, ever, verified any source of any software.

              I do agree that auto-play functionality should be restricted or require user permission. But we both know that 90% of users will click on "stealyourcreditcard.evil wants to run software that reads all your personal data. Do you agre

              • Yes, they do. Your auto-playing videos is a strawman. But users want a webmail that's not too different from a nativ app, they want Google Maps and drag-and-drop dashboards on their corporate web-apps.

                And it's too much work to offer a downloadable browser plugin that does this? Or something else where the user actually gets a say in whether he wants some code to run on his machine?

                dreamland.

                99.9% of users have never, ever, verified any source of any software.

                I do agree that auto-play functionality should be restricted or require user permission. But we both know that 90% of users will click on "stealyourcreditcard.evil wants to run software that reads all your personal data. Do you agree?" without even reading any of that.

                Your dreams are my reality, because I do. And anyone who wants to, could. Right now, we aren't even able to. All I can do right now is to disable WebAssembly altogether and navigate around webpages that use it. The very least I'd expect is some sort of question whether I want a certain page to run arbitrary code on my machine,

                • by Tom ( 822 )

                  And it's too much work to offer a downloadable browser plugin that does this?

                  Apparently it is. Have you looked at the Internet sometime in the last five years? You can't fight a billion people and their desire that the shit should simply work.

                  All I can do right now is to disable WebAssembly altogether and navigate around webpages that use it.

                  I did that back in the days when Javascript was optional and mainly used for scrolling status bar advertisement.

                  The very least I'd expect is some sort of question whether I want a certain page to run arbitrary code on my machine, so I can say no in 99% of the cases.

                  I'm sure someone will write a plugin that does that for you. But you don't matter. It's more important to think about making the vast majority of users more safe, and for them your solutions don't work.

        • For actual programs that do sophisticated processing, you would have to download code from a trusted source and explicitly run it.

          Who decides what is "a trusted source"?

          And with what operating system's API would this "code from a trusted source" interact? If, for example, you can build and run a nontrivial app that uses the Cocoa API under an operating system other than macOS or iOS, I'd be interested to see how you did it.

          • by ceoyoyo ( 59147 )

            Who decides what is "a trusted source"?

            Well, I think the obvious authority would be the people who made the device, or operating system. For example, you could have a large multinational corporation that made smartphones and also ran an "app store" where third party developers could submit their "apps" for review and distribution. The multinational could take a 30% cut or something for the service.

            And with what operating system's API would this "code from a trusted source" interact?

            Why, the OS running on th

            • by tepples ( 727027 )

              And with what operating system's API would this "code from a trusted source" interact?

              Why, the OS running on the device of course.

              Different devices run different operating systems. What can the operator of an Internet service do to predict in advance with which operating system its prospective users will attempt to access the service first?

      • How about having a dedicated computer in your vidio card that only runs this stuff, with no ability to modify anything else, no permanent storage, and each time you open a browser window you get a new clean copy. A hardware firewall in your computer just for browser stuff.
      • Most browsers compile JavaScript to machine code ... the C8 VM claims to be as fast as C.

        WebAssembly is supposed to run in a VM.

        If either the JavaScript VM or the WebAssembly VM allows malicious access to the system: then the VM is buggy. It has nothing to do with WebAssembly or JavaScript per se.

    • by fermion ( 181285 )
      Reminds me of the downfall of Flash. It was useful, there were a few use cases which really benefited from it, but overall it was used to promote evil, like ads for Google.
    • The description of WebAssembly in the summary sounds oh so similar to Java (not Javascript). Ie, a byte code system designed for portability across different systems, often in web pages. Java was intended to be very secure, since it's in a sandbox and the language takes care of common security pitfalls, but it ended up not being secure in many ways. Will WebAssembly fall into the same trap, will it learn from the past or is it just another in a long stream where people reinvent the wheel without knowing

      • by tlhIngan ( 30335 )

        The description of WebAssembly in the summary sounds oh so similar to Java (not Javascript). Ie, a byte code system designed for portability across different systems, often in web pages. Java was intended to be very secure, since it's in a sandbox and the language takes care of common security pitfalls, but it ended up not being secure in many ways. Will WebAssembly fall into the same trap, will it learn from the past or is it just another in a long stream where people reinvent the wheel without knowing tha

        • The big difference between asm.js and webassembly is: that asm.js is still JavaScript text while WebAssmely is a bytecode/binary format.
          ActiveX had no execution environment, it was simply a fancy *.dll loaded into Internet Exploder.

      • Java [a bytecode platform purchased by Oracle] ended up not being secure in many ways. Will WebAssembly fall into the same trap

        I doubt it. Unlike the Java platform, WebAssembly has more than one independent implementation with more than trivial usage share. Namely, both Chromium and Firefox implement it. This was far less practical with Java because Oracle asserted copyright against those who would distribute a work-in-progress independent implementation to the public.

  • If it's still this way in a year or two, web browsers or OS-level security software will start throwing up warnings and start blocking it soon thereafter.

    If WASM code can't be easily screened at the client for "badness" then I predict it will follow Flash into the security-hazard graveyard.

    • by thsths ( 31372 )

      The whole idea of WASM is that it can be easily sandboxed. "badness" is subjective, and I think that is always going to be hard to measure.

      I think the main result is that there are currently few legitimate applications for WASM. But that does mean it is useless? I know two or three sites that use it, and that I would miss.

      But click to enable sounds like a good idea, especially if it is draining your CPU resources.

      • If the code does not produce meaningful output, it is useless.

        If the code produces meaningful output, it must have a way to transport data out of the sandbox environment. If it can transport out data, the code can have harmful effects on the data outside of the sandbox.

        If the code produces meaningful output, but it is not all tranported out of the sandbox, the sandbox ceases to be a sandbox and becomes the execution environment and the code can have harmful effects on the valuable data inside of the sandbox

        • by Ryzilynt ( 3492885 ) on Wednesday January 08, 2020 @11:35AM (#59599364)

          If the code does not produce meaningful output, it is useless.

          If the code produces meaningful output, it must have a way to transport data out of the sandbox environment. If it can transport out data, the code can have harmful effects on the data outside of the sandbox.

          If the code produces meaningful output, but it is not all tranported out of the sandbox, the sandbox ceases to be a sandbox and becomes the execution environment and the code can have harmful effects on the valuable data inside of the sandbox. If the data inside the sandbox was not valuable, the code would be useless again.

          So I can clearly not choose the wine in front of you.

          • by Tom ( 822 )

            If the code produces meaningful output, it must have a way to transport data out of the sandbox environment.

            Not really. The output could interface with the user, but not with the rest of the machine. You would retain the sandbox, while having it useful. If data needs to be exported, it could be an explicit export step the way "do you want to save this file?" is now - and the output channel would be under the control of the sandbox, not the code.

        • Every webasm snipped is in its own sandbox. Why you think the sandbox can not access the HTML DOM and hence present data, is beyond me.

      • If it's easy to use for evil then it's not fit for purpose. This stuff needs to be safe by design.
        • by hoggoth ( 414195 )

          There is a security bit in every packet that your browser can check to see if it is being used "for evil". It will be relatively easy to secure WebAssembly, at least compared to Flash and other things that came before it. https://www.ietf.org/rfc/rfc35... [ietf.org]

    • by Dunbal ( 464142 ) *
      How many decades did it take before people got fed up with Flash?
  • Shocked! (Score:5, Insightful)

    by DarkOx ( 621550 ) on Wednesday January 08, 2020 @09:58AM (#59598978) Journal

    Really a system where by users download largely opaque blobs of code from more or less authenticated sources and automatically execute it gets abused?

    This was entirely predictable and expected by everyone who has been watching longer than one technology cycle. The sandbox is a better this time, but given so much has moved into that same sandbox the risk is still significant.

    We really need to just learn a simple lesson - Running thirdparty code without user intervention is bad. Its bad when its plain old js, its bad when its auto play on a optical disk, its bad when its active-x. How bad varies but the out come is always at least as many negative side effects as gains.

    • by ceoyoyo ( 59147 )

      This whole thing is a bit silly. WebAssembly, despite the name, is essentially JavaScript bytecode. Any security issues with WebAssembly are equally shared by JS. The only difference is that JS is *theoretically* source code, except for the minimizers and obfuscators everyone uses.

      • No. It's not. In fact, it's more like a classic CPU emulator. Good to compile code that calculate things (like mining cryptomoney, that its normally the bad usage), but without any direct peripheral or real access to the hardware or OS.
        Just a gateway to the JavaScript layer, so in fact, the only way to interact with the "outside world" (besides burn CPU cycles) is through Javascript.

        I guess that the best way to avoid bad use is limiting CPU usage. Efficient is always better, but not necessary it shouldn't

        • Re:Shocked! (Score:4, Insightful)

          by ceoyoyo ( 59147 ) on Wednesday January 08, 2020 @11:41AM (#59599388)

          You are perhaps unfamiliar with the correct use of "essentially." It doesn't mean "exactly the same as". It refers to the important qualities. WebAssembly is assembled to a byte code for a virtual machine. You can do all sorts of weird things with JavaScript, but compiling it to intermediate byte code, or compiling it directly to machine code for the target machine are both done.

          For the purposes of this discussion, they are essentially the same. You can't magically do anything with WebAssembly you can't do with JavaScript (rather the opposite, as you yourself pointed out). Chrome, for example, uses V8 to run both.

    • by Tom ( 822 )

      Running thirdparty code without user intervention is bad.

      No, it's not.

      It is bad when it is allowed to do things outside a well-defined scope.

      For example, I use webasm to compute and display a probability distribution curve on a statistics-heavy dashboard. Doing that in the browser allows real-time updates for the user. Doing it in JS would slow the browser to a crawl, doing it in webasm you barely notice it.

      The problems only begin when you execute code that can do whatever. That's a difficult line to draw, but there are a few very clear and obvious indicators tha

  • "a task for which JavaScript was never designed or optimized for"

    It certainly was not designed for it originally, but it's amazing how fast JavaScript got when enough effort was thrown at optimizing the runtimes. How much of a speedup could we anticipate from something like WebAssembly? (Also, how is this not essentially client-side Java?)

  • by JoeyRox ( 2711699 ) on Wednesday January 08, 2020 @10:03AM (#59599012)
    Most sites today are ad-invested, link farm cesspools containing only enough useful data to fool Google's indexer.
  • by famebait ( 450028 ) on Wednesday January 08, 2020 @10:08AM (#59599042)

    How in the world do they square such diametrically opposed goals?

    • by OzPeter ( 195038 )

      How in the world do they square such diametrically opposed goals?

      Take a Hamster Wheel as an analogy. It doesn't matter how fast the hamster runs around the wheel, the hamster doesn't go anywhere. So you could say that the hamster has high speed but low performance.

      But then replace the hamster wheel with a series of tubes*, and now the hamster can go places - so that's high speed and high performance!

      ---

      *This works on multiple levels - with physical and metaphorical

      • While us 3d thinkers have unlimited hamster mobility [wikipedia.org].

        You can find out more in my 6 hour Ted Talk series. The Blu Rays are only $39.95.
        • by OzPeter ( 195038 )

          While us 3d thinkers have unlimited hamster mobility [wikipedia.org].

          You can find out more in my 6 hour Ted Talk series. The Blu Rays are only $39.95.

          I disagree. You seem to think that tubes are not 3D in nature. What you are actually highlighting is constrained vs unconstrained 3D path planning. The tubes are capable of any 3D path as long as that path is pre-planned. A ball does not require pre-planning of the path. However a simple ball fails in at least one area compared to a tube - going up stairs.

          I look forward to your modified TED talk where you charge an extra $39.95 in order to profit from the realization of your arrogance.

        • by Dunbal ( 464142 ) *
          They are limited to a 2D plane.
          • That's not true at all, to verify this, just place a hamster occupied hamster ball at the top of a skyscraper.
            • by Dunbal ( 464142 ) *
              Then will certainly be limited to a 2D plane after a short while, changing hamster height into hamster area.
    • I don't know about wasm, but in the bedroom it can be hard to perform if you're too speedy.

  • was reported a couple of month ago already , ...
  • by davidwr ( 791652 ) on Wednesday January 08, 2020 @10:20AM (#59599074) Homepage Journal

    Study Estimates 50% of WebAssembly Sites Are Using It For Malicious Purposes, Nov 02, '19 [slashdot.org]

    This time I blame ZDNet.

    There is one significant update: The academic conference paper is no longer at https://www.tu-braunschweig.de... [tu-braunschweig.de] although that link's archives in archive.org do work.

    It has been moved to https://www.sec.cs.tu-bs.de/pu... [tu-bs.de] as listed in the current ZDNet article. It is also in archive.org.

    For people looking at this years from now, the reference is

    Musch, Marius et al, New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild DOI: 10.1007/978-3-030-22038-9_2 [researchgate.net], June 2019

    It was published as a chapter in
    Perdisci, Roberto et al, ed., Detection of Intrusions and Malware, and Vulnerability Assessment: 16th International Conference, DIMVA 2019, Gothenburg, Sweden, June 19-20, 2019, Proceedings.

  • by DrXym ( 126579 ) on Wednesday January 08, 2020 @10:42AM (#59599158)
    Web Assembly is as exactly as malicious as Javascript on the same website. It runs with the same privilege and it is capable of the same things. The only difference is WASM is slightly faster (since it is precompiled and closer to machine instructions), and slightly harder to disassemble. That's it.

    If people find themselves victim of malicious content, then maybe they shouldn't be visiting the websites that was hosting it. Chances are they've always been victim of malicious content on those sites and just didn't know it.

  • I wish browser makers wouldn't make some stupid item (pop-ups, autoplay vids, autoplay audio, blink tags), then gasp in awe as websites abuse the living shit out of it. We don't need stuff like WebAssembly. All that does it cause the browser to balloon with RAM, and allows low level coin mining to be done in the background, as well as trying to find any CPU or hypervisor level exploits to break out of the browser and pwn the machine.

    Even something as "safe" as Javascript has been quite an infection vector

  • Disable WebAssembly (Score:5, Informative)

    by xluap ( 652530 ) on Wednesday January 08, 2020 @11:08AM (#59599240)

    In firefox, it is possible to disable webassembly.

    In about:config, set javascript.options.wasm to false.

    • by tokul ( 682258 )

      Or just continue browsing same way as before with noscript turned on. If you are paranoid about wasm, you should be paranoid about other JS code too.

  • Their headline says nearly half the sites. Then in the article they write this:

    However, while the vast majority of samples were used for legitimate purposes, two categories of Wasm code stood out as inherently malicious.

    So which is it -- half the WA sites are malware or the vast majority are legit?

    • Probably bad writing. "Journalism" ain't what it used to be. I haven't had a chance to read the cited paper yet but my guess is that the truth is most CATEGORIES of WASM are fine and there are two that are almost always malicious. But the number of examples that fall into those two categories is somewhere around 50% of all studied.

    • They found 150 different code samples, on 932 different websites.

      For instance, there are 2 different ways to check whether a browser supports wasm-. But those two fragments were found on 244 different websites.

      There are 48 code samples designed to mine currency. Those used by 913 different websites.

      There are 10 code samples designed to obfuscate potentially malicious javascript. Those are are used by 4 websites.

      The majority of code samples were not malicious. The majority of websites that used wasm, however

  • WebAssembly may just go the way of Java applets and Flash.

  • Time to install Norton Antivirus 2020 for your Web Browser

  • I prefer not to run malicious code, but when I do, I would like it to consume as little memory and CPU cycles as possible.

    I'm only half joking here. Do not falsely assume that malicious code didn't exist before WebAssembly. This just means those same sites that were sending malicious code via JavaScript are now doing it more efficiently. Any new technology will be first used for crime, then porn, then video games, then something actually useful. We are now at the first rung of the ladder!

  • I said when WASM became the new hotness it would eventually be used for just as malicious behavior as NPAPI plugins were and everyone laughed at me and I told everyone to get off my lawn Ha Ha Ha. If you want the beneficial functionality you are going to have to let the browser do things that can potentially damage the system as well. Sandboxes are a good tool but they aren't a silver bullet against malicious intent. Only due-diligence can defend against that and most people check their brains at the door w
    • And it was on the plugin itself to sandbox code. This caused no end of problem. WebAssembly was built from the ground up to be sandboxed so it shouldn't be nearly as bad; if there are problem it will actually be possible to patch them out as opposed to having to give up and create a new API (like PPAPI).
  • Hopefully client-side Blazor (basically .NET in WebAssembly) will take off and we'll see more legitimate usage. There really is a lot of potential in WebAssembly.
  • Is WebAssembly really that much different from Java applets, which ended up not being a great success? Applets had their issues, but the fundamental idea really sounded like it was on the right track, and I haven't (so far) found any essential difference compared to WebAssembly.

    • by tepples ( 727027 )

      Two words you will find in Java but not WebAssembly are "Copyright Oracle". This is enough for many.

  • It's obvious that webassembly has failed, with it's high uptake for use with malicious practises.
    I propose to develop a new web runtime, it will be fast and save... this time, really.

Single tasking: Just Say No.

Working...