WebAssembly gets nod from W3C and, most likely, an embrace from cryptojackers online The World Wide Web Consortium (W3C) on Thursday published three WebAssembly specifications as W3C Recommendations, officially endorsing a technology touted for the past few years as a way to accelerate web code, to open the web to more programming languages, and to make code created for the web more portable and safe. “The …
It's too dangerous to allow random websites to execute code on my machine as it is, which is why I don't allow most sites to execute any client-side scripting. It's nice that WebAssembly uses a sandbox, but that doesn't really reduce the risk enough for me to be comfortable with it.
So, no WebAssembly for me.
It's cute you think you will have a choice long term ...
I fear that you've nailed it. I think that Web Assembly -- which looks to be a **REALLY** BAD IDEA will likely turn out to be the final nail in the Internet's coffin. The inscription on the gravestone should read "The Internet 1991-2021. So much promise. Sadly unfulfilled"
>The worst that could happen is that the bulk of the web will be unacceptable for my use, but honestly, that's already true.
Which is fine until government or your company decides it will make something that is mandatory for you only available through the web running WebAssembly (again long term). Web is quickly becoming a necessary utility like power in modern life. Hopefully it will be like Javascript and NoScript is now but direction Chrome (and perhaps eventually Firefox) is headed who knows. Death by a 1000 cuts.
"Which is fine until government or your company decides it will make something that is mandatory for you only available through the web running WebAssembly (again long term)."
So far, it doesn't look like that day is on the horizon. No company I interact with requires the use of their website (they all provide other means of interacting with them, even if it's a phone call or a visit to an office), and I don't see any sign that will change. Same with government agencies.
However, should that day actually come within my lifetime, I can always use the computers at the local library.
No worse than anything else.
It's basically the same as the Javascript (ECMAScript) permissions - given that WebAssembly has its roots in the "virtual machine" made in Javascript.
Seriously, the problem is not what technology you choose, but how stupid your browser manufacturer's are.
P.S. You've had a webassembly-enabled browser for several years now, I guarantee it.
Go play with Emscripten, which has been compiling to Webassembly for a long time already. It's basically bound by the browser DOM security model. If that was broke, it really doesn't matter *what* language you've been using.
But you'll notice that you can't access local files, you have to run code from remote websites (so you can't just be pointed at something compromised on a local network machine), that permissions to audio, video capture and everything else are: the same damn permissions you've got available to every website and are denying/allowing already. It doesn't allow arbitrary file, memory or resource access. Hell, you have to jump through hoops just to preload files from a website and access them in a virtualised storage in order to do anything on them, and the performance hit is enormous because of the way it's done (but still more than viable for 99% of things you want to do in a browser because, hey, it's a browser).
The only interesting thing is WebSockets, but that's no different to the myriad of websites that talk back in the same way over HTTPS already.
Honestly, if your browser is dumb, it doesn't matter what language it's dumb in.
WebAssembly is just Javascript-compressed. That's it. If there's a vulnerability in it, you had that vulnerability for the last 10 years in your browser already.
But with Javascript, it's a pain in the arse to write a full 3D FPS (or, say, something like Sketchup for the Web). In WebAssembly, it's just another target for a compiler.
And, no, if you compile a memory-unsafe language (say, C99) to WebAssembly, all that happens is that your code falls over inside the WebAssembly virtual machine. Arbitrary memory pointer access is actually faked by allocation of a giant array, for instance. There are some things you just can't do because the browser DOM and the inherent absence of a capability in WebAssembly stops you.
Focus on the problem (browsers which don't implement proper security for their page interpretation) not the brand name on the language that exposes that (e.g. Javascript, WebAssembly). And, no, it's not even close to Java. Java plugins in browsers worked by Java having arbitrary access to the machine and then imposing its own (broken) security model. That's why Java plugins are basically dead now.
"Java plugins in browsers worked by Java having arbitrary access to the machine and then imposing its own (broken) security model. That's why Java plugins are basically dead now."
That's part of it, yeah [probably the biggest part]. However, what makes you think WebAssembly is NOT heading down the EXACT SAME PATH? I suggest that it _IS_.
"Unsafe at any speed" - kinda fits this, too.
Do you REALLY want automatically downloaded PROGRAMS being run by TRACKERS and ADVERTISERS (and scammers) running on YOUR computer? Just like the way I block scripting with NoScript, this 'WebAssembly' crap needs the SAME kind of treatment. Ideally, it can have a finer level of control applied to it, such as blocking 3rd party scripts, block 3rd party WebAssembly, or ALL WebAssembly for that matter...
There also needs to be finer control of permissions when you do want such a program to run.
So if I give an application access to a local file, then it can only access that local file. If I give it permission to a directory, then it can only access that directory. And under no circumstances should it have access to any system files or directories.
"It's basically the same as the Javascript (ECMAScript) permissions - given that WebAssembly has its roots in the "virtual machine" made in Javascript."
Yes, and I already don't allow almost any Javascript to execute in my browser.
"Seriously, the problem is not what technology you choose, but how stupid your browser manufacturer's are."
No, the problem is that websites cannot be trusted to execute code on my machine.
"You've had a webassembly-enabled browser for several years now, I guarantee it."
My browser allows me to disable it, which I do.
"Focus on the problem (browsers which don't implement proper security for their page interpretation) not the brand name on the language that exposes that (e.g. Javascript, WebAssembly)."
My problem is not improper implementations by browsers -- that's something that can be addressed. My problem is that even if the browser's security is 100% bulletproof, client-side scripting is still for more powerful and capable than I'm comfortable allowing web developers to use on my machines.
hopefully NoScript shuts that *#!+ off, too.
from the article: "wasm modules operate in a sandbox that isolates them from the host runtime"
I've heard this rumor about JavaScript, too. And yet, HOW MANY TIMES has it BEEN ABUSED to SPY on us, STEAL CPU CYCLES for crypto-mining, and so on???
FACT: This is 3rd parties RUNNING CODE on YOUR COMPUTING DEVICE, quite possibly inviting RANDOM 4TH PARTIES [advertisers] TO DO THE SAME.
Yeah "no security risk" doing THAT, right?
My hacker-mind ALREADY envisions the potential abuse of THAT kind of "open-ness" on the CLIENT. And it's as bad as the first MS-DOS viruses and MAC viruses that prompted an ENTIRE INDUSTRY of anti-virus tools.
NO THANKS opening my LINUX or FreeBSD box up to the SAME KINDS OF CRAP that Windows users have to protect themselves from...
WebAssembly: *FAIL* (might as well use embedded Java objects, and WHY was that dumped again?)
So, just how many folks would prefer digging through a mini-fied 1MB JavaScript source file relative to the organised & annotated disassembled source code of a WASM binary?
Because having done JavaScript development for a living for a few years (it was a job...) I am not sure what this touted 'readability of JavaScript' is meant to be. After all JS source has been merged into a single file and minified to 'compress' it, it was sufficiently unreadable that even us JS devs would just try to replicate any issues on integration instead of trying to do any debugging on production.
Indeed, A few months ago I took a shot at reverse engineering 700k of "compressed" Javascript to see if there was any chance of detecting when it was finished doing its work.
My take. Reverse engineering of JS can be done. But not by me.
I threw the whole thing out and replaced it with a hundred or so lines of Python that did the same job (faster) using standard tools like curl and image magick.
I haven't looked at this, but I expect there are tools to un-minify JavaScript. Just breaking the statements into separate lines and pretty-printing should go a long way. After that some facility to support replacing obfuscated identifiers with more meaningful ones (like good disassemblers allow doing to replace generated labels with readable ones), and the result should be easy to read.
There are tools to do it dynamically in firefox. So you can publish minified js in production and also a map file that allows firefox debugger to unminify it so you can step trough the code as if it had been delivered before minification. Map files are generated by the same tool that minifies. I dont think you can reverse them if they are not published
I believe the map file solves a bit different problem: They don't unminify but allow deciphering errors and debugging in terms of the original source files and locations, instead of everything happening on line 1 of file bundle.js. But you cannot see the (hopefully) nicely laid out and commented original code, unless you have the original source files available.
Yeah, it's new generations growing up and re-inventing the wheel because they weren't around for the previous debacle. .... John Brown (no body)
How about ... it's new generations growing up and re-purposing the wheel because they weren't around for the previous debacle, John Brown (no body).
That would suggest they be able to access and exercise Alternative Remote Command with Virtual Control Leverage.
Have you any idea what that is worth in/to any market?
* The Grand Irony and Almighty Opportunity for Pedestrian Status Quo Sources and Forces is that Any Failing to Engage and Enjoy and Employ New Generational Programming, and there ADA is a sterling star language for AI on Missions, Automatically Instantly Deny Themselves Privileged Access to New Fonts of IMPerfect Source Drivering Assets.
:-) The spooky thing is ... Nowadays, machines such as produce and display the likes of the above, and they surely be the bringers and breakers of all news presently, are advising humanity what next to expect ...... rather than the reverse ....... and that is Real Freaky Stuff In Deed, Indeed . :-)
And if you worry for your sanity, ....... well, give it a try or a bye for now, and see how you progress on the path chosen. And don't worry about missing such chances, for they'll all be available again tomorrow although then is one simply trailing in support some way behind the bigger pictures being created further up ahead in the Fields Following New Generational Programs.
Is that latter condition/situation akin to Serfdom?
"... That would suggest they be able to access and exercise Alternative Remote Command with Virtual Control Leverage.."
You're totally creating a grandeur behind WASM that isn't there (at least we hope!!). WASM has its place, but it's just a slower version of Java. We are in a age of market code, not functional code. Just get your "code" out there, become a paper millionaire and watch someone with much less wealth take a huge hit to their retirement plan.
I'd go on, but I have to go and re-re-re-re-re-invent an IRC client to sell to a SaS support team.... long days on StackOverflow ahead as my CTRL, C and V keys are about shot.
You're totally creating a grandeur behind WASM that isn't there (at least we hope!!). ..... overunder
Oh? One shouldn't be so sure, overunder, whenever so much is always so unsure and able to be designedly and decidedly so totally disruptive and/or creative.
I'd go on, but I have to go and re-re-re-re-re-invent an IRC client to sell to a SAS Support Team deeply embedded in an AWEsome Program.
You are aware of such shenanigans, overunder? El Reg must have highlighted them at some time, surely?
"new generations growing up and re-inventing the wheel because they weren't around for the previous debacle."
Or, in the case of the invasive/pervasive 2D FLATTY McFLATFACE FLATSO FLUGLY interface "design", re-inventing the wheel "for the lulz" "because they CAN" (and TOTALLY b0rking it, out of arrogance NOT going back to what was OBVIOUSLY BETTER BEFORE) and THEN cramming it into EVERYONE ELSE's body orifice and calling it "modern".
Because, after all, it's "their turn now". and everyone over the age of 'whatever' is OLD and STICK IN THE MUD and WRONG and WON'T LEARN and and and... [you get the idea]
yeah having all competing choices (effectively) taken away is the MOST irritating part. Expect WebAssembly to do THAT, too.
Yeah, it's new generations growing up and re-inventing the wheel because they weren't around for the previous debacle.
Not to play devil's advocate, but the wheel has actually been re-invented many times, this is why they aren't still made of slices of a tree trunk. Not everything that is re-invented is done by ignorant Young Turks ignoring history, sometimes they learn from the problems and issues with previous solutions to develop better solutions.
Java on a modern CPU is technically faster than the original computers, but I don't think there are many people who consider "faster" to be synonymous with "java".
amazingly Java still manages to be #1 or a very close #2 on the TIOBE index. But it _does_ run cross-platform. And on Android. But of course what Android apparently does is re-compile it into something native, rather than relying on running Java's pseudo-code. And, THAT causes significant startup delays every time something "upgrades". I HATE that. (let me start my slab up really quick so I can test this... OH @#$% the @#$% @#$% just @#$% had to UPDATE, and now I have to wait for @#$% @#$%^ @#$% to finish before it'll finish starting up, @#$%!!!)
i can't imagine what would happen if you get a WebAssembly "thing" somewhere down the line, where it's forcibly 'optimized' (read: re-compiled for up to a minute or two) while your browser and/or the content on the page has to WAIT FOR IT because, "updates". Yeah, does not happen FOR NOW, because it runs that code with a virtualizer. but that's not FAST ENOUGH, and you know, it COULD become NATIVE CODE, and next step in the "evolution" puts us into the situation I JUST described, and and and (you get the idea). And we ALL know who devs LOVE to SHOVE THEIR UPGRADES into our body orficies, because ALWAYS BETTER even with FEATURE CREEP!
I’d say that JavaScript is rubbish and slow.
A few JS entities -- Open Street Map, text editors used for comments on some web sites -- seem pretty decent. Others -- Amazon, anything from Google -- are utterly atrocious -- slow, buggy, -- a user experience reminiscent of running Windows 1.0 from floppies. I admit to being mildly curious about why. Not curious enough to start tearing code apart.
But I submit that there is a possibility that Javascript per se might not be as bad as it seems
"Based on experience of using web apps, I’d say that JavaScript is rubbish and slow."
Javascript can be very fast or very slow. The transition between the two can seem inconsequential at the source level and can vary between engine. And that's before you get to the giant anchor that is the DOM and devs who insist they're going to do it their way because they don't care about speed, and then pile on React, Jquery and yet gods knows what else, only to code using a functional paradigm. (I don't have a problem with functional programming - but javascript ain't optimised for it.)
Back in the day you could find C++ apps that ran like overweight dachshunds and apps that ran like greyhounds. The dachshund-guys guys can write code that's even slower using javascript. But I used to be able to get core maths heavy stuff to run within a factor of 2 of native code. It doesn't seem to have got any slower - although increasing mobile phone screen sizes have put the old code under more strain.
Java ran with full permissions to the user, and then had it's own "security" (in your Control Panel modules, etc. no less).
WebAssembly is Javascript-compressed. It can't do anything that Javascript couldn't already do. And it runs inside the browser DOM, which literally doesn't have certain capabilities (if it did, Javascript would have had them too).
Please Mozilla, make this an opt-in feature per site. Last time I wanted to try a Java applet on an ancient site I had to fire up IE because Java is apparently so bad that Firefox absolutely refused to run it. What makes them think web assembly will be any safer? Remember how secure Java was touted as being in the beginning, but the applet vulnerabilities just kept rolling in until it was worse than Flash.
WASM is very like Java in many respects, but has a significant difference. That difference is very likely why it has taken it as long as it has to gain any kind of traction. The difference is that Java defined a fairly standard sort of standard library, with access to essentially all of the host operating system's resources. Java web applets nominally had a restricted set of APIs available, but they aren't all that restricted, and the big problem is that the libraries are huge, and implemented on top of (not-memory-safe) C and C++ code that turned out to be full of bugs that could be exploited. WASM has no standard libraries, and no object model. Indeed, it has no inherent access to _any_ APIs at all. It's just a blob of code that has access to a pre-allocated chunk of memory. All it can do is run its program when asked by the JavaScript attached to its host web page, which will have to extract the result from a chunk of raw shared memory set up for that purpose beforehand. So the only system access that WASM code has is through the host JavaScript.
At first, host JavaScript just did the specific things that WASM wanted, and it was fairly gnarly. Now though, various groups have gone to the bother of writing fairly sophisticated libraries of interface routines, function-calling mechanisms with argument marshalling and so on, so that fairly normal sorts of developments can in fact be done. But the restrictions are still those of the browser JavaScript, which although not unblemished is not bad at security. Essentially, the sandboxing is significantly stronger this time around.
If WASM is succesful, its interface will inevitably be extended to allow it to do more useful things. And then it is just a matter of time before Java-like security problems start appearing.
Newsflash from 2030: Google has finally banned WASM from Chrome due to security concerns, after having had it opt-in (with scary warnings) for a year. Mozilla is expected to follow suit.
My browser is locked down as much as possible and run in sandbox locked down as much as possible - I still will not run scripts or binary blobs. If a site breaks, I go somewhere else. Usually, I do not give a flying f*** what the standards say. If it looks like shite and smells like shite... Want Another Shite Meal?
"If a site breaks, I go somewhere else."
If the site that breaks is something with no alternative like a government website, meaning the only somewhere else you can go is away and not get anything like benefits and so on?
"Want Another Shite Meal?"
If there's nothing else, what's it gonna be? Shite or starve?
Wanna bet? Many places are now without brick & mortar presence in a lot of things...including banks and government services. Worse, the closest one's still open are too far away, have wonky hours, and because of them usually have overnight campers in an age where missing a day means losing your job (your replacement's already here).
"If the site that breaks is something with no alternative like a government website, meaning the only somewhere else you can go is away and not get anything like benefits and so on?"
In my area, there is literally no website that is actually indispensable. Any government agency that is entirely web-oriented still lets you go the their office to conduct your business, even if in the end it's still using the website.
I literally cannot think of a single essential thing that I'd have to do without if I could not use the web at all, and I see no reason to believe that will change in my lifetime.
So we're told again and again that plugins, like Flash, are evil security threats that must be banned and will be blocked entirely after 2020 to save us all from their malicious intents... Only for them to be replaced by basically the same thing (but no doubt implemented in half a dozen ever so slightly different ways by each of the major browser makers, like HTML5, to ensure you need to implement the usual array of workarounds and polyfills)
I can see how the *implementation* of web assembly could be made secure, since implementing a bytecode interpreter is much easier than a JavaScript one. But that won't stop people deliberately writing malicious code to run on it. So I hope I can disable it by default, and whitelist for those hopefully few sites where I have to use it (government sites, perhaps banking ones).
Implementing pretty good security wouldn't be all that hard. Just don't provide any Web Assembly access to the hardware or to the OS. However, the first version of Chrome that bypasses THAT will probably appear within 72 hours. Firefox will take a bit longer. Maybe a week.
Or the memory...
Oops. Can't run unless it's in the memory. Now it can start using those electrical DRAM tricks and so on...
Frankly, even burying your computer in a bunker isn't safe anymore (can't they get them to do funky stuff using Ground-Penetrating Radar now?).
When is someone going to realise that a necessary, but not sufficient, condition for preventing malware is "all code must be human-readable, not obfuscated?"
Beside which, if you think you need to prevent me from scrutinising your code, as far as I am concerned that makes it malware. At least it gives me no reason to trust you.
When is someone going to realise that a necessary, but not sufficient, condition for preventing malware is "all code must be human-readable, not obfuscated?" ..... JulieM
I would certainly disagree, JulieM, for surely such is perfectly adequate and a remarkably simple requirement to perform. Isn't that what Total Transparency is All About and Offers.
No hiding place for malware without all code being human-readable is the base cost price for guaranteed protection against prevention and humans nowadays.
I think what's missing from this thread is the distinction between code running on your private machine and code on the internet which someone wants to run on other people's machines.
I don't care if the former kind is impenetrable but the later kind should, ideally be clear and legible. The caveat is that I do have some sympathy for those who want to minify JavaScript to lower their visitors' bandwidth usage.
"I think what's missing from this thread is the distinction between code running on your private machine and code on the internet which someone wants to run on other people's machines."
Exactly that. If it's delivered via public space, it's kind of anything goes but should remain clear, at least in the functional parts where worries like security and privacy could arise. But otherwise, whatever.
As far a minified _JAVASCRIPT_ code, wellllll... you'd think. After spending a lot of time in Javascript, there's so many dependencies in "frameworks" it's a bloat festival. I feel now if you ever need to worry about minifying code, you've either A. Done way too much with one file. B. Added in so much shit you don't understand that you haven't minified your script, but mystfied it.
The caveat is that I do have some sympathy for those who want to minify JavaScript to lower their visitors' bandwidth usage.
If the app is so large that downloading it each time a user accesses the 'website' (I put website in quotes, because it seems like you aren't accessing a websiite, but a mechanism for downloading code to one's computer) uses significant bandwidth, many it should be made into this thing called a client application, that can be downloaded once and re-used many times?
Are you willing to submit YOUR code to the same scrutiny, even if it means losing trade secrets or even possibly breaking confidentiality laws?
If you have code that contains trade secrets or personal information you'd be a fool to run it on someone else's PC. That kind of thing should be kept on the server and not run in the browser.
Things like WASM might obfuscate it, but while that makes it hard to read it doesn't make it unreadable.
The user has a right to want to be able to inspect code that a site wants to run on the user's own machine, and if the user is not able to do that then the user might reasonably wish to eschew the site.
"Things like WASM might obfuscate it, but while that makes it hard to read it doesn't make it unreadable."
I don't know dude. I tried WASM a bit as I come from a C background and found while it does obfuscate, it doesn't really hide anything. It kind of just templates everything, but the instructions are clear to follow. If by hard you mean time consuming, probably, but surely not difficult.I admit i did have a nudge to write something to make it all readable again, but due to the small size and lack of interest/purpose, I didn't.
I think the size of the WASM delivered should be talked about more, because if these become huge, they just might wind up choking out the browser. This happens even with plain JS of course, but creating a little photo editor in it started to seriously starve everything else as everything else still had to sit around and wait (can't really stack crop commands with sharpening commands... just doesn't work out).
For sure! I am no anonymous coward.
I write beautiful code I would not be ashamed to show to anybody. Some of it is in JavaScript, and it will never, ever be mutilated by minification. Appreciate my indentation! Understand my comments! Anybody could have done it, but nobody could have done quite as beautiful a job as I did.
Now press your face against my code, inhale deeply and try not to faint.
This post has been deleted by its author
"all code must be human-readable, not obfuscated?"
But must the code _always_ be transported in such a condition?
I have relatively often taken a piece of 3rd party .net assembly, churned it through .NET Reflector and looked at the disassembled code. One memorable moment was fixing one of xceed software's bugs and then not receive any rebate on the upgrade they shipped containing that fix. (if memory serves, it was a thousand dollar upgrade)
To some degree I agree that the source should be readily available. However, to shun compiled code completely, strikes me as a tad extreme.
The web browser is becoming the new operating system: Intended to abstract the differences between different computers and "real" operating systems.
Which in turn run on hypervisors - which are mini operating systems.
And let's not get started on IBM's Ultravisor - a hypervisor for hypervisors.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
