Just when you thought that web browsers were becoming boring, Mozilla announced that Firefox 52 now supports WebAssembly, which brings greatly enhanced speeds to web apps. Learn more about how this expands the capabilities of the web for everyone.
From where I sit, this development is a big boost to Linux. Sitting beside me at my public library job is a former Windows Vista laptop that is blazing fast with Linux installed. And Firefox 52 — it just made this laptop even faster. Somebody could conceivably be using this laptop for another eight years. Born again. Halleluyah!
For the past 10 years, Phil has been working at a public library in the Washington D.C.-area, helping youth and adults use the 28 public Linux stations the library offers seven days a week. He also writes for MAKE magazine, Opensource.com and TechSoup Libraries. Suggest videos by contacting Phil on Twitter or at pshapiro@his.com.
Let’s all run opaque binaries downloaded from the web!
It’s as safe as javascript!….oh wait.
@ Mike
Apparently, all the web-assembly does is isolated math operations, currently integer and (I think) basic floating point (386 FP-unit style), with media/vector ops (like SSE and friends) set for later introduction — there’s (very deliberately) no system access or basically anything else functions exposed; for that you (still) use javascript.
The idea is to provide webassembly for near-native speed math operations, without unduly increasing the security exposure. All interfacing with the system and IO is done using existing javascript and etc functionality, with webassembly exposed for use with the math-heavy parts in web-based games, media codecs, etc.
At a higher level, it’s another step toward replacing flash, including where it was used for games and media codec support, with HTML4/5+ technology, with webassembly being used for the math-heavy stuff.
(This is based on the arstechnica report and discussion. I’m not a (web or otherwise) dev and am simply relaying what was said by apparent devs there, in reply to the exact same security skepticism was expressed. Seems reasonable, but my take is still a cautiously optimistic time will tell.)
One Firefox 52 on Linux problem I did /not/ see covered in the announcement/release-notes or in any of the press I’ve seen so far, is that at least for the Mozilla-shipped binary, alsa support has now been disabled — you must have pulse-audio support in ordered to get audio.
Of course most of the mainline binary distros install pulse-audio by default these days, but it’s optional on some of the more technical-user aimed distros such as Arch and Gentoo (which I run here), and apparently as well on at least some of the audio-workstation focused distros where the latency of pulse tends to be unwanted and the lower-latency jack audio is preferred.
There’s already quite some hubbub around this decision and the problems it’s bringing to those where pulse-audio is an unwanted “solution” to a problem they don’t have… or at least didn’t until firefox created it.
For now, the build-time options to enable alsa and disable pulse-audio support remain and are reported to still work, but the alsa support code is now officially unmaintained and will likely be removed at some point. However, building firefox is a big enough job even normally from-source distros such as gentoo ship firefox-bin packages with the official upstream-built binary. Additionally, on gentoo at least, the build-from-sources package tends to lag upstream release, sometimes significantly, as the gentoo package maintainers figure out how to deal with the latest wrenches to self-building that upstream has (perhaps inadvertently as it’s simply not their focus) slipped in since the previous release. For anyone with any sort of security focus, due to the fact that the vulns fixed in the upgrade are open season as soon as the release reveals and announces them, that’s worrying enough that they might choose to run the upstream binary anyway — that’s the reason I decided I had to get off the gentoo firefox package here.
The easiest workaround I’ve found, mentioned in one of the multiple firefox bug filings on the problem, is to install apulse (there’s a gentoo ebuild for it but as of last night they didn’t have the latest upstream release, with some firefox-specific fixes, I googled it and grabbed a -9999-live-git ebuild from someone’s public overlay), which provides pulse-audio functionality for alsa. The documentation mentions two options for library install location, in the normal library path if you don’t have pulse-audio installed there and don’t want to have to fiddle with things, as apps such as firefox pick it up automatically then, or in its own path (gentoo uses the $libdir/apulse subdir), so it won’t interfere with the main pulse-audio libs if they are installed, but then you have to run firefox (and any other apps you want to use apulse) via the apulse wrapper script, which tells the binary it wraps where to find the apulse fake pulse-audio libs.
Since I had pulled the live-git ebuild to my own overlay anyway, I modified it to use the main $libdir (/usr/lib64 on amd64) instead of $libdir/apulse, so now I don’t have to worry about using the apulse wrapper script.
And firefox audio, and thus youtube, etc, work again! =:^)
@Duncan
Webassembly is sandboxed, but that deosn’t mean flaws can’t be exploited. Even the security section of the webassembly site lists some possible attacks. Even without webassembly specific attacks we’ll get more closed source code running in our browsers, executed by an ALREADY insecure javascript. *sigh*
I’ve known about the upcoming dropping of alsa support for some time and it has bothered me because I DO NOT and NEVER WILL run PulseAudio. Thanks for pointing out apulse. I wasn’t aware of it. I will definietly check it out when the time comes.