Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming

'Running Clang in the Browser Using WebAssembly' (wasmer.io) 56

Posted by EditorDavid from the what-do-you-C dept.
This week (MIT-licensed) WebAssembly runtime Wasmer announced "a major milestone in making any software run with WebAssembly."

The announcement's headline? Running Clang in the browser using WebAssembly... Thanks to the newest release of Wasmer (4.4) and the Wasmer JS SDK (0.8.0) you can now run [compiler front-end] clang anywhere Wasmer runs! This allows compiling C programs from virtually anywhere. Including Javascript and your preferred browser! (we tested Chrome, Safari and Firefox and everything is working like a charm)...

- You can compile C code to WebAssembly easily just using the Wasmer CLI: no toolchains or complex installations needed, install Wasmer and you are ready to go...!

- You can compile C projects directly from JavaScript...!

- We expect online IDEs to start adopting the SDK to allow their users compile and run C programs in the browser....

Do you want to use clang in your Javascript project? Thanks to our newly released Wasmer JS SDK you can do it easily, in both the browser and Node.js/Bun etc... Wasmer's clang can even optimize the file for you automatically using wasm-opt under the hood (Clang automatically detects if wasm-opt is used, and it will be automatically called when optimizing the file). Imagine using Emscripten without needing its toolchain installed — or even better, imagine running Emscripten in the browser.
The announcement looks to a future of compiling native Python libraries, when "any project depending on LLVM can now be easily compiled to WebAssembly..."

"This is the beginning of an awesome journey, we can't wait to see what you create next with this."
This discussion has been archived. No new comments can be posted.

'Running Clang in the Browser Using WebAssembly' More

'Running Clang in the Browser Using WebAssembly'

Comments Filter:

  • ActiveX returns (Score:5, Insightful)

    by xack ( 5304745 ) on Saturday October 12, 2024 @10:39AM (#64859221)
    In Wasm form. Can't wait until someone makes a botnet using it.

    • Re:ActiveX returns (Score:5, Insightful)

      by bussdriver ( 620565 ) on Saturday October 12, 2024 @11:02AM (#64859255)

      The tech nerds faith in solving everything with MORE tech features will eventually repeat the mistakes of history again and again... giving us more employment as we repeat the same pointless cycles.

      ActiveX, Java Applets, WASM eventually... they'll add the "missing" features like direct browser or OS access. Like how they've optimized javascript to dynamically recompile for speed opened up some vectors. Funny how size and speed go up but we will waste effort and lower security in pursuit of optimizations whose benefit is lost before implementation on new hardware... usually so advertising related software can get more bloated...

      We can't have a microkernel OS because of "speed" yet we've lost more speed with tons of less important features. I'll gladly lose some IO performance when I got such a huge boost migrating to SSD. Remember when Windows 98 transitioned to a much better NT based OS and the gamers were holding onto their unstable machines for a higher frame rate?

      • direct browser or OS access

        They already have more memory available to them than entire older machines had permanent storage space. In addition to opening arbitrary connections, running native code, directly accessing peripherals, and permanent storage of their own. At this point the browser *is* an OS. Most "developers" don't code for native, they code for the browser using native where required.

        usually so advertising related software can get more bloated

        Well of course. The industry realized a long time ago that micropayments were the only means of sustaining themselves. You can't sell a go

      • > We can't have a microkernel OS because of "speed"

        Sure you can. You can have any kind of kernel you want.

        Just write one and convince people to use it.

        • Yeah, convince tech people with a long history of refusing to support such features... best bet is some big company like MS deciding it for everybody else and forcing it.

      • Remember when Windows 98 transitioned to a much better NT based OS and the gamers were holding onto their unstable machines for a higher frame rate?

        Nope. When I made the switch from Win98 to Win2000, I was shocked at how much better gaming performance was, given that Win2000 wasn't designed for games. Never looked back to the days of Win98, not even for nostalgia.

        That being said, I understand your point, and I very much value stability over performance.

      • Remember when Windows 98 transitioned to a much better NT based OS and the gamers were holding onto their unstable machines for a higher frame rate?

        NT 4.0 put the graphics drivers in the kernel, the same as Win98. That is why so many web servers died, the OpenGL screensaver would kick on and kill all performance. Anyone who was holding out on "upgrading" wasn't doing it for framerates, even if they thought they were.

    • Re: (Score:2)

      by leptons ( 891340 )
      Everyone's commenting how the sky is falling (again) because of web browsers. Sorry but this does not make the browser any less secure. Any WASM code that runs in a web browser doesn't have access to anything it isn't supposed to. Y'all are just terrified of browsers and javascript without even really knowing why. This doesn't enable any new functionality that wasn't already possible with WASM. No, this is nothing like ActiveX. The sky is not falling.

      • Re: (Score:2)

        by Khyber ( 864651 )

        "Any WASM code that runs in a web browser doesn't have access to anything it isn't supposed to. Y'all are just terrified of browsers and javascript without even really knowing why."

        Are you that ignorant of history? Browsers are some of the LEAST secure pieces of software in existence.

        • this may be news to you

          sendmail is still the most exploited software ever

        • Using WASM doesn't meaningfully change the security posture of wen browsers one way or the other. WASM isn't like ActiveX that was basically running on the metal, or Java that ran in a horribly designed VM outside of the browser entirely. WASM still runs under the DOM and thus can't do anything that js can't.

          • Re: (Score:2)

            by DarkOx ( 621550 )

            yes but no

            We have seen in the past the browser sandbox isn't always perfect. Some of of those attacks relied on JavaScript to do things like heap sprays. Could you do them before, yes because obviously people did, is it easier to do something like that in C/Assembly code than via contortions in JS, also yes. Does that mean more people will be developing exploits for browser JS VM - because less PITA, probably.

            • We have seen in the past the browser sandbox isn't always perfect. Some of of those attacks relied on JavaScript to do things like heap sprays. Could you do them before, yes because obviously people did, is it easier to do something like that in C/Assembly code than via contortions in JS, also yes. Does that mean more people will be developing exploits for browser JS VM - because less PITA, probably.

              Do you even know how heap spray works? It's even easier to do in JS, just load a big binary blob with your staged code, repeatedly. Regardless of whether you use WASM or JS, you're still going to use code native to the host architecture/OS, which would never be done in JS anyways, unless you do something stupid like build an exploit kit in node, which means actually staging node along with it..

      • It lowers the barrier to entry for those wanting to cause harm. Previously if you wanted to compile your own customized payload you needed to either do it on the server or write a custom assembler in WASM. Now it's far easier to take existing source code and have the target's machine compile it before execution.

        How many browsers / security programs are searching for common exploits in source code form?

        Even if they are, how many are going to be successful in guarding against easily randomized variants?

        • > Previously if you wanted to compile your own customized payload you needed to either do it on the server or write a custom assembler in WASM.

          I'm sorry, that is not relevant. If you compile C code offline using Emscripten or the like, you can just put the output on a web site and any browser that visits will execute it without complaint.

          Being able to compile it within the browser doesn't add any capabilities that aren't already there.

        • Re: (Score:2)

          by leptons ( 891340 )
          There is no "lower barrier". Nobody capable of doing anything malicious with WASM has been waiting to do it until they could do it inside a web browser. You're a knee-jerking neckbeard idiot, like many other neckbeard idiots in this thread.

    • As I understand it, there are two major differences between Wasm and ActiveX.
      1. Wasm runs on any major browser. ActiveX never ran on anything but Microsoft browsers.
      2. Wasm doesn't provide the executing code with full access to the underlying machine, as ActiveX did. In other words, it doesn't suffer from the same security vulnerabilities.

      It's true that Wasm has some serious shortcomings, such as being forced to load large binary frameworks (libraries) in order to provide compatibility with traditional fram

      • Re: (Score:2)

        by ls671 ( 1122017 )

        Wasm is more like java applets than ActiveX.

        Back in 2000, we built a fat client web application which used a java applet running in the background which used javascript to display pages, cache things and do database connections etc. This saved a lot bandwidth on the restrained slow satellite link that app used. The satellite link was a phone link using conventional modems for ppp TCP-IP.

        First time it loaded it took a while to download all the applet java code but then after that it was much quicker than a r

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      In Wasm form. Can't wait until someone makes a botnet using it.

      The difference is that Wasm runs within the Javascript execution engine in the browser, so it's running with full protections.

      ActiveX was a COM DLL that ran with full OS permissions - anything any program could do, ActiveX could do. Wasm only runs with permission of the browser so you get site isolation, file isolation and other things.

      A botnet is extremely difficult because of it - you have WebSockets that allow you to create sockets, but they'

  • Then the virus can be shared in (obfuscated) source code, maybe with randomly generated variable and function names to avoid detection, and it will compile and install natively in every target platform. "It's a victory for crypto botnets everywhere", stated an unnamed Russian source.

    • How would this be so? Wasm doesn't provide higher permission levels than traditional javascript. it's not like anybody actually looks at minified javascript libraries to inspect them for viruses already.

      • Exactly. It's hard to see how this will create any security issues that WASM and JS don't already have. I mean, you can *already* compile arbitrary C code to WASM (using the Emscripten tool chain, for instance), slap it on a web site, and have it executed in any modern browser that visits the page.

    • WASM isn't native.

  • Ooh! Ooh! (Score:4, Funny)

    by dskoll ( 99328 ) on Saturday October 12, 2024 @11:23AM (#64859287) Homepage

    Neat! I plan to cross-compile Firefox into WASM so I can run the browser in the browser!

  • So, we can run a virtual machine in the browser which compiles a browser in which any code compiles to run programs like bots and adware and worms.

    Yeah, like an onion, it stinks.

  • I never understood... (Score:3)

    by MpVpRb ( 1423381 ) on Saturday October 12, 2024 @11:36AM (#64859309)

    ...the fascination with running more and more software in a browser.
    A browser is a poor OS. There are better choices.
    You can hammer in a screw with a wrench if you try hard enough, but it's better to use the proper tool for the job

    • One reason. The browser is the one "OS" that literally everyone has. If you're on Windows, Mac, iOS, Android, ChromeOS, it doesn't matter, everyone with a browser can run WebAssembly. Further, every major browser supports it. So why *wouldn't* developers be drawn to a platform that literally everyone has, instead of having to rewrite their code for each major OS?

      • Another reason: you don't have to build an installer. A third reason: getting people on the upgrade treadmill is easy.

    • The primary reason is that you don't have to fool around with distribution, installers, and similar folderol.

      You may not like it, but it's an extremely serious advantage nonetheless.

  • "Javascript" was a more or less cynical branding of an unrelated technology because "java" was still a name worth piggybacking on at the time Netscape made that call; but it's managed to evolve (more by brute force than by fitness for purpose) into something that actually has java-like properties in terms of being able to target an abstracted runtime environment for cross platform compatible programs.

    Makes one wonder how it would have gone if they'd acknowledge that that was the plan originally and follo
  • As a security developer I shudder at the thought. Darn certain that malware writers would love this.
  • Because all the web was missing was another attempt at Flash, Silverlight and applets and some such - ie. a way to execute some proprietary code a bystander won't be able to easily inspect (yes, i'm not considering obfuscation/minification a particularly problematic thing)

  • It's become a bit of a sport and hacker pastime to compile everything under the sun to WASM and launch it in the browser. The most impressive stunt in that regard IMHO being Automattic (the commercial WordPress entity) compiling the entire LAMP stack with a ready-to-run WordPress installation to WASM and providing it as an URL for anyone who want's to toy with and try out WordPress without installing anything. True thing, no joke. It's pretty crazy and the results are quite impressive [wordpress.net]. Although I did spend an afternoon pissing myself with laughter so much that eventually my belly hurt when I read the announcement.

    However, given the attention WASM and the compliation to WASM has gotten, it is no surprise that you can do this sort of thing with single programs. It's impressive that entire stacks and systems apparently can now do this too. I'm pretty sure there are entire Linux distros out there built for running on WASM. It's a neat hack and demonstrates the power of todays laptops and browsers and for sophisticated rich client webapps it's a god-send, but this is still very niche and it will likely remain that way.

  • These guys must be compensating for some inferiority complex, 'I do JS then I'm not a real developer' style.
    Nothing good could come out of this excepting some claim that "see we can serve you JS tracking code without affecting your battery" which can never the as efficient as _not_ running crappy 3rd party code in the first place

    • Javascript is a crappy language. Web GUI tools that we have today are worse than tools from 20 years ago.

  • Mainframes are back, baby! (Score:3)

    by HnT ( 306652 ) on Saturday October 12, 2024 @06:05PM (#64859883)

    So basically, mainframes are back and now it is running inside your browser! Isnt that an AMAZING idea???
    Why dont we just create a whole OS that runs inside the browser, just imagine what you could build then to run straight up!!!
    Because if there is one thing we really need, it is even more chances and technologies for websites to be bloated like crazy and run ever more binaries on your machine!

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close