WebAssembly: Key to a high-performance web, or ideal for malware? Reg speaks to co-designer Andreas Rossberg WebAssembly will not magically speed up your web application and may be as significant running in environments other than web browsers as it is within them, a co-designer of the language told The Register. WebAssembly (Wasm) was formally approved as a W3C recommendation in December 2019. The technology is a low-level …
Since the world finally buried Flash and it's weekly parade of vulnerabilities in an unmarked grave, I suspect team wASm will have an awfully hard time convincing the populous to adopt another, "hey let's download and execute arbitrary code off the interwebs so it can encrypt all my files till I send my year's pay in bitcoins to some complete bastard".
The "populos" have already accepted Wasm, since it is included as standard in the major browsers. So, no I don't think it will take much convincing. Another thing is that Wasm is extremely simple and designed for sandboxing from the start, so it can not encrypt your files. It can be used to mine bitcoin, as all that requires is some CPU time and the ability to send short messages to a web server somewhere. But it does not have access to your own bitcoins.
Wasm has a complete formal specification, which means that undefined or implementation-specific behaviour (which is often used as an attack vector) is avoided. I trust Wasm much more than Javascript, which is only somewhat safe because browsers have become good at detecting bad behaviour in Javascript.
"Wasm has a complete formal specification, which means that undefined or implementation-specific behaviour (which is often used as an attack vector) is avoided."
So, if I want to exploit it, I have to adhere to the spec...? Stop, take a breathe, and think about that for a second.
"designed for sandboxing from the star"
Both java and flash are sandboxed and look how well that turned out.
"Wasm has a complete formal specification, which means that undefined or implementation-specific behaviour is avoided."
Big deal and no it does not. A formal proof proves the DESIGN of the language , not the numerous different implementations which could have more holes than a swiss cheese at a mouse turophiles convention.
"Wasm has a complete formal specification..."
What about a complete formal verification, to be sure it cannot possibly escape its sandbox (recall Java had a sandbox, too...yet coders kept finding ways to escape it)?
There is also concern about the necessary evil of external interfaces; otherwise, what use is it? The moment you have one (which you need if you want to access external files, graphical interfaces, etc.), it part and parcel becomes a potential exploit.
I am looking for the option in firefox to just DISABLE it. A less-than-quick search online shows "javascript.options.wasm" in about:config might do it... but of course, IT IS NOT IN THE NORMAL PREFERENCE OPTIONS.
(the article has done nothing to convince me I should actually ALLOW it)
instead the web servers do their own processing and stop pushing for yet more user exposure.
Site owners seem to be increasingly angry with their users, almost as though they feel they are being ripped off in some way, this is very redolent of the movie and music industry believing that they have some right to profit at any cost and without the users being able to judge the quality of the content before hand. This trend towards yet more exposure of their users so they can make a profit off their back by selling it to whomever is just another symptom of the sickness that the internet.
If your content is really worth something then go the subscriber model and see if others agree, don't rape your audience for whatever you can steal or you will find yet more legislation coming you way to limit your bad behaviour
And there's the slippery slope.
I'm afraid "things like Java's JNI (Java Native Interface) or .NET's Platform Invoke" aren't inherently dangerous - they can only invoke whatever "native" code their runtime environment makes available to them, stuff that a potential sandbox would allow to exist in their address space. In other words, stuff imported from your host environment. Any security problems they have are problems that apply equally to Wasm as soon as it has access to anything outside its own environment.
It's always the same claim: our idea is safer because we have a better sandbox and a limited attack surface. I'm afraid this sandbox will prove as vulnerable as everyone else's and over time there will be pressure to import so much stuff "from your host environment" that the distinction between browser code and local application code will be hard to perceive.
It really doesn't matter that there is a "machine-verified proof of its safety" - the machine verification goes right up to the point at which you "import stuff from your host environment" and then ceases to have any validity. Code running in an isolated machine is by definition safe, but punch a hole in the isolation and all bets are off.
I can see why Google might be interested in "multimedia editing, simulation, compilers and debuggers, encryption, and games" running in the browser. I'm not: they're precisely the things that should either be done as local applications or on remote servers with clear boundaries of authentication and control. I'm not entirely sure, in any case, how you'd manage multimedia editing or games if Wasm only has access to the browser display by means of JavaScript updating the DOM: there'd have to be a lot of "import stuff from your host evnironment" to get that to work at an acceptable rate.
Browsers are for presentation not for computing. Admittedly their document-centric presentation model is inadequate for our current model of remote interaction and they have insufficient hooks to provide secure identification and to allow the secure remote storage of personal data based on local credentials. However, as long as browsers stick to presentation, there's some hope of keeping them reasonably secure. A browser capable of running a "virtual operating system" is a nightmare - that's the problem with JavaScript already, please don't make it worse.
remember ActiveX? "Oh the control has been marked 'safe' so THAT means it is OK!"
What about downloadable windows font files? Not web fonts, WINDOWS fonts [which are actually DLLs]
The tech itself is not dangerous. No, no no. It's what people CAN DO with it. It's almost like why the local 7/24 convenience store doesn't sell dynamite...
Not sure what you mean, but it appears to be neither, as it is being presented as unique. How about a contraction of abbreviations using possessiveness, does that not require an apostrophe (') with names in either case? i.e. W'asm and not Wasm? Or Jesus' and Jesus's but not Jesuss.
I guess in English you can make a name capitalized, sound and spelled as anything you want, so I'll spell it as... _TRENdy_NeW_thiNg_to_DaTA_minE_yOuR_ShIT_FaSTeR_ ... because in the end, it will have no greater usage than that.
if you say it like a word (like laser), that's an acronym. If you speak it letter by letter (like RSVP), that's an initialism.
Wasm isn't even a contraction (I'll leave it to the reader to identify both of the contractions in this sentence). Wasm is an elision (like gonna), of which contractions are but one subset.
There are plenty of grammarians and linguists who would consider both "gonna" and "Wasm" contractions. There's no generally-agreed definition of contraction in English, either in general use or as a term of art, which would exclude either of those words.
If you want a more-specific description of what sort of elision "Wasm" represents, it could be considered a portmanteau, since it's an elided noun phrase used to describe a (notionally) new concept.
I think the point was that the distinction between acronym and initialism originated in the US. Or perhaps it's more complicated than that: my Chambers defines 'initialism' as being either 'an abbreviation in which each letter is pronounced separately', or 'an acronym', with the second being marked as 'US'. So perhaps in American English (or some variants of it) an initialism is a word made out of the initial letters of other words, however it is pronounced, while in UK English (or some variants ...) there are are two distinct notions.
I'd call both 'acronyms' and I'm a British English (home counties but spent a long time in Scotland) speaker, so I don't have the distinction but have folded both concepts onto the other word than American English speakers have, if the dictionary is right. But I might be wrong even by the standard of the dialect I speak.
Anyway, this term is not either an acronym or an initialism as others have said.
(It's also a fucking stupid idea.)
Architecturally WebAssembly is a code-verification sandbox with a controlled API to a runtime: if it works well in a browser, it’ll be an ideal platform for microservices where a different runtime is provided. The challenge on the server-side will be providing a distributed identity-verification runtime to avoid spoofing
In one respect WebAssembly is just the latest incarnation of platform-independent environments that started with UCSD p-system followed by OSF ANDF, JVM, CLR and PNaCL, but standardized and matched with a large browser providing a runtime environment.
Change the runtime to stripped-down Fuchsia like OS with little more than network stack + Kerberos and you have an ideal environment for micro-services
Except those never worked as well as it sounded like they would. Many programs written in something that was supposed to be platform-independent but originally written for and on a specific platform ended up running correctly only on that original platform. Take, for example, a program I ended up reimplementing. The original was written in Java. Nice, clean, write once run anywhere Java, without calling anything OS-specific. So it should work great, right?
Well, it was designed for Windows, and it needed to identify and write to external media (or simulated external media). And since it was checking the volumes by enumerating drive letters, it couldn't find them on anything using a unix-style volume mount system. It would run properly until it wanted to read or write to one, then keel over. There was a similar bug that happened when you tried to run the tool on Windows 10, which was a bit more complex and had to do with the way the OS's SSL/TLS implementation worked. Once again, the program failed badly.
In both cases, the version of the JVM running it was the same. While it didn't call OS-specific APIs, it was written in a way that called universal APIs with platform-specific parameters. It was clear that the original devs hadn't planned for anyone to run it on something other than Windows. It's unlikely that Wasm will go that way, but as there were platform-specific parameters that could cause that Java program to crash, there will likely be platform-specific bugs or ambiguities that allow a Wasm program extra functionality or alter its state. The majority of those will cause an annoying glitch seen only by the user. The minority will be developed into methods of accessing the users' systems to their detriment.
"leave the real interactivity for other protocols."
So either a server side round trip for every update (or websockets), or remove it from the browser?
Sorting a table requiring a full page refresh? Nah.
Partial refresh? That would be called AJAX, and one of the things you want to remove. Also unecessary for sorting a table.
"So either a server side round trip for every update (or websockets), or remove it from the browser?"
If you need that much updating, maybe you should be using a different protocol like VNC. And if the server side complains, tell them it's going to be The Cost of Doing Business going forward if they don't want lawyers knocking because shoddy design results in customers getting pwned.
Right... Because giving randomers a vnc session for interactively SORTING A TABLE makes sense? (Sarcasm).
That's before we start talking about the server side horse power required to have a vnc session to something like YouTube.
And when your server can only handle several(?) orders of magnitude fewer users? For the sake of moving the attack surface from the browser to the vnc client?
You talk about a cost/condition of doing business. Client bandwidth is cheap. Server bandwidth is expensive. If you want to make your business less competitive, go right ahead.
That's *before* we get to the whole "we're not on the web, you need a special program" hurdle.
Why can't YouTube just do what Real Player did and make a client app? They do that already for Android and iOS, so there's no excuses. Not to mention it pins the responsibility and liability right where it belongs: with the provider.
The Web is not meant to be a multimedia protocol. It got shoehoened, and that's part of the problem.
Why can't YouTube just do what Real Player did and make a client app?
Nobody wants a client app.
What people want is for the browser to have the ability to play a video built in. YouTube (or whoever) just provide the stream of data and let the browser display the video in a standard way, using standard facilities.
That way the service provider (YouTube or whoever) don't have to do any coding, and the user doesn't have to worry about how their (now non-existent) code is run, or whether it's safe to let it run. No need for any dodgy JavaScript or Wasm stuff.
YouTube might complain that this would rob them of control over the way their video stream was used, or of the ability to monetize their provision of that stream by adding advertising or collecting data about the user ... but that's not the user's problem.
Nobody wants a client app.
Everybody wants a client app. They just want it to be automagically downloaded on the fly when they look at the web page, and to run within this big app-container thing that they already have called a web browser.
(Note, I'm not disagreeing with you really: I'm just niggling over the definition of 'app'.)
What next, a custom application to display still images?
RealPlayer was utter **** and I'm very, very glad it's dead. In many ways it was worse than Flash.
I cannot afford to install random crap to watch a video or play a daft game on the Internet. If I have to, I'll just leave. No website is worth installing random executable code - if you think that's more secure then get the hell off this website.
I want a standard saying how a video will be displayed and how it will be encoded and streamed. Then someone I trust can provide a decoder and display system. We could could call it a "burning minidog", a "shiny thing", or a "play where everyone is singing all the time"
"I cannot afford to install random crap to watch a video or play a daft game on the Internet. If I have to, I'll just leave."
Then why are you still here? Installing games is still very much a thing. Watching a video? I'd prefer to download it to local storage and play it on MPC-BE, TYVM. Oh, and a separate program for images? For me, that's called IrfanView.
"No website is worth installing random executable code"
And YouTube's website content is any different? That's precisely why we're in the mess we're in. People blindly trust web "apps" and in turn get pwned. For everyone else's sake, it would be preferable for apps or anything of the executable sort be left to the control of the operating system. OS's are designed to run programs, not web browsers.
"I want a standard saying how a video will be displayed and how it will be encoded and streamed."
I want a standard that demands that anything that large can be downloaded to local storage to play. If you insist on streaming, I insist on finding another way (I keep an external video capture device) or finding another provider. I know firsthand how ephemeral the Web can be.
Since we seem to be looking at two different worlds here, we'll just have to agree to disagree. I prefer to keep things in local context. You prefer things to stay online.
"make a client app"
Things like ionic and atom exist because in the real world, the opposite is happening.
To the point where the fragmentation is happening as to *which* web platform you should target.
Add to that the unecessary permissions the client apps "require", and the world of randomly downloaded virus ridden MSIs adding to that junk pile when the web is fine... is a hard sell.
That's *before* we get to the whole "we're not on the web, you need a special program" hurdle.
That ship has already sailed, look how many popular sites want you to install their app, and notice that some of them are breaking their sites to make simple things difficult because they really REALLY want you to install the app.
And on desktop, absolutely everyone I know just says "**** that, get lost". Someone else will provide something similar that doesn't.
On iOS and Android, there's a sandbox system already. It needs improvement, but it is already there.
Apple also actively reject "apps" that are simply a website wrapper.
Admittedly, an expanded version of HTML could implement some of the more common functionality without requiring JS to do it for you. For example, for table sorting, imagine if you could write this and the browser would handle it: (I'm trying to do this so the comment HTML checker will leave it alone. Note to self: the system will not auto-expand < and > into angle brackets. Apologies if it doesn't work)
<table>
<tr><th sortable>Name</th>th sortable>Value</th></tr>
That could be customized in various ways, and you'd no longer need to download a sorting function over and over. HTML5 already has a "sorted" property which allows specifying some details about sorting, but it is limited where this wouldn't be. Of course, you'd have many small details to handle, such as sorting on rows instead of columns, but it could be quite nice.
I don't think people would mind if a web processing engine only did things to and with the page it came with. It's when it starts collecting data and sending it somewhere else that we get annoyed or worried. As specified, Wasm is restricted enough that it only does processing. Which we all know is not ever the way it'll be used.
Now that's close to what I'm envisioning for an HTML6. Fuctionality can be incorporated but with the understanding it will have limited scope (to the content currently loaded). The ability to show, hide, or move things in local context I can accept. It's just when you start considering outside contexts that you get in trouble. Indeed, one requirement I would like to make is strict hierarchy: content must be at the same or a sub level, never anything above or outside it.
Spawns of Satan? I think they're just the opposite. Sure, downloading them can be a pain, but something like that probably only needs to be downloaded once in a long while. Just SAVE that copy and use it locally for a while.
Otherwise, just keep separate pages in the SAME directory and link back and forth between them so you only update pages as needed. Hell, even eBay had to use something like this before websites got more interactive.
"content must be at the same or a sub level, never anything above or outside it."
Bare in mind that this was how things used to be. What has happened is that the advertisers have effectively *become* the top level because websites like to get paid.
I don't think that's a good thing, but whining about a lack of a walled garden whilst presumably still wanting content for free is not realistic. Patreon exists for a reason.
Javascript is in a local context. Adding more scriptable power to HTML is just moving the scripting to the same thing and breaks the primary model of the browser whcih actually works quite well.
The separation of framework & content, styling and display and scripting. That separation is a good thing, you don'y need to revert back to a monolithic giant of HTML.
Also when things are server side you can enable better security, you can implement server side processing based on client side requests. For example you don't want local processing to download a massive picture to then scale it down (as per the 'olden days'.). It is far better for the server to dynamically scale it and send down the correct format to the client to digest. Similar to how you wouldn't want the server to download 10,000 lines of data to be locally filtered when you can do it on the server and download the required information.
I wonder if that's really true. The majority of sites need to run code for one of three reasons:
1. To manipulate the content already on the page. This includes input verification, changing whether a section is hidden or not, moving content around for better presentation, and the like. I at least am completely fine with that running.
2. To pull content from a remote source to keep it updated without needing a refresh. I'll admit we use and like this, and we might need a solution to that. We have some capabilities outside of JS to do this already, which might need some improvement.
3. To pull data from the user's system, send it to a remote server, and pull new data back. This is often done for advertising, and it also is the source of innumerable security vulnerabilities. However, as already pointed out above, a site can still perform advertising by sending the ads when the page is initially loaded. While there are possible legitimate uses for that, I cannot think of many pages that are doing so.
If we limited JS to only be capable of the first two purposes, I don't think many sites would look any different. Of course it's simply a dream that has no chance of happening, but I think it would work if you managed to get it started.
So, it's only just got out of the starting gate, and immediately by far the biggest use is parasitic misuse of other people's machines. This tells me all I need to know about it, apart from "how do I disable this from ever running on my machine?". The last thing we need is for it to become mandatory on most websites in order for them to even function, because the web developers haven't thought through the downsides of the new shiny, yet again. At the start it'll be the cryptominers, scammers and malware bastards that make the most use of it, closely followed by the ad slingers and anisocial networks abusing it to invisibly grab all they can about us. Javascript's bad enough but at least you can see the source code if you want to. Who on earth is going to bother to decompile and inspect web assembly code if it proliferates?
From the printing press onwards, pretty much the first things that any new communications technology has been used for have been porn and fraud. Good luck finding a reasonably priced scribe for all your clerical needs.
OTOH, since I browse most of the web with NoScript active, I am probably closer to your basic stance on this than this reply might suggest. :)
I will not allow WASM stuff to run, for the same reason that I don't allow JS to run. It exposes my machine too much, sandbox or not.
I'm particularly uninterested in standalone WASM applications. I've yet to see a web-based application that is actually good when compared to native apps, so I'll stick with the native apps.
If the native app is just a different front end for the web back end (CRUD), why have the app at all?
I don't have social media apps on my phone, I just use the websites. Facebook et al only get to see what the browser sees. Yes, that might be too much sometimes, but it's a damn sight less than what the app sees. How many permissions does it actually need?
Errr, no thinks. Why allow all the permissions, power and risk to a native app when you can run it via the web.
It's like the old days when ecommerce or a product catalogue required an application download to view it. There is no way I would download a facebook app, but I feel forced to visit facebook on the web every now and then due to a very limited purpose. Why do you think facebook are so keen to get you to download an app (even going as far as refusing to show you messages on a mobile unless you do). As you know from facebook, the only reason they want you to do that is because there's something in it for them With everything facebook, what's in it for them is more data from more sensitive areas of you device that they can't get via the web.
Nothing to stop malware like bitcoin miners from running in JS even today. They could even use asm.js to optimize their performance and obfuscation to hide their purpose. If you're worried about such things, the best defence is not to visit sites that are likely to host them, or mitigate the threat by turning off 3rd party JS or using a proxy like Opera Mini.
WebAssembly runs with the same privilege model as JS so it doesn't really have the potential on paper to be any more of a threat that JS. But it is less mature than JS so there might be implementation bugs yet. Mitigate the threat in the same way as you would for JS.
"Like I said, do we REALLY need this?"
Yes. Not because it is any good but because it is cheap and powerful and the vast majority simply don't care.
Want an example? Look what happened to TalkTalk and they still have NEW subscribers.
A few geeky types saying "hell no" won't change anything any more than those of us using NoScript (etc).
I honestly don't even know what to make of your "reliable" argument. That same reductive argument could be applied to anything new. Oh who needs electric bulbs when we have gas lamps! Who needs gas lamps when we have candles! etc.
But please cite what you think this other, "more reliable" way is. There have been three main ways that C++ software has been able to run in a browser in the past.
1. Via a plugin. This was dropped a long time ago because the bindings were horrible, installing them was horrible and vulnerabilities were per-plugin and often necessitated frequent updates outside the browser's own.
2. Via Empscripten. This produce Javascript which essentially emulated a processor and address space. It was pretty cool idea but painfully slow and ad hoc. e.g. if I compiled a C++ program it was dumped out as a big JS that had to be parsed before anything would run and occupy a large footprint in memory even as it did. It also runs very slowly because it emulates the C runtime. Even asm.js (a simplified subset of JS that browsers could potentially optimize codepaths for) didn't improve performance as much as desired.
3. NaCl / PNaCl. These were a Google proprietary precursor to WebAssembly. It was a good concept that was proven in Chrome/ChromeOS but being a proprietary meant it was never a good fit for the web.
A side note to all this, is that JS wastes a lot of power. That might no mean much in isolation but it should when we're talking about mobile devices or sites which are accessed millions of times a day.
WebAssembly will have issues to iron out along the way. Nobody is denying it. But there is a clear and obvious need for it as anyone who has struggled with JS performance or maintaining logic either side of the client/server divide could tell you. It's not going away. If you feel worried about it, disable it for the time being or use a browser that does.
You forget method #4: run it on the server and just send an interface to the client. Remember all the way back to Telnet and its modern counterpart Secure Shell? That was pretty much the only way it could work then. Why not go back to what worked? VNC is out there now, is well-specced and well-tested. Not to mention it helps keep proprietary code where it should be: server's eyes only.
"Oh who needs electric bulbs when we have gas lamps! Who needs gas lamps when we have candles! etc."
Who needs gas-guzzling, lung-choking automobiles when we have our own two feet? Who needs privacy-trampling Facebook when we used to do nigh-everything face to face? Sometimes, newer isn't always better.
PS. I DO avoid scripting whenever possible. Trouble is, more and more sites are breaking without it, and as I've mentioned before, some (like government websites) have no substitutes and no assurances they won't get hacked into drive-by sites in future.
This post has been deleted by its author
... that the only things which will benefit from the performance boost are the ads. I can turn JavaScript on and off right now and barely detect the difference in the function of many web pages. What really takes a hit is the advertisements popping up in front of the content I was trying to see.
Let's say ads did get a performance boost and that you're not running an ad blocker. So now your phone also gets a performance boost. Multiply by however many hundreds of millions of phones are showing ads at any given time.
But it wouldn't just be for ads of course. Any website, or web application which has complex or computationally expensive JS could benefit from the switch. WebAssembly is even supported by NodeJS so there is the opportunity to speed up server side too.
WASM is basically JavaScript (same APIs), but much faster on account of running in a fast VM. That means one would use WASM for stuff one would use JS for, and then some.
Yet the real question is, why even need JS, or WASM for that matter? If one needs a more dynamic website, use CSS scripting (yes, that's a thing), which is far safer than JavaScript.Only thing that's relevant for websites that CSS cannot do (yet) are asynchronous HTTP requests (AJAX).
Basically, I'm in favor of blocking WASM just as hard as JS, enabling it only on a case-by-case basis when there's no other choice.
"when there's no other choice."
There's the rub. There's *always* another choice. Even if that choice is not to use the site.
Given that the vast majority don't mess with the defaults, and even those techies that enable selectively would still cave and enable the bare minimum for the site to work (gawker). Those kanuts trying to hold back the tide are outliers within a group of outliers.
The rest of the world will move on without you. Which you may or may not be happy with.
"The rest of the world will move on without you..."
As a parent would say, "If everyone jumped naked off a tall cliff onto jagged rocks, would you?"
I guess what the comedian said was true; you can't fix stupid. The concern right now is stupid taking the rest of us with them.
to ditch all Javascript and Webassembly and instead provide a socket-based way for the server to controll the DOM tree. Essentially you would get a "smart terminal" which handles everything that needs to be handled in real-time, while the logic runs on your server. You'd even save lots of processing time on the server as you don't need to string together a bunch of requests into a session.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
