WebAssembly: Finally something everyone agrees on – websites running C/C++ code Google, Microsoft, and Mozilla on Monday announced preview versions of WebAssembly, a low-level safe binary format designed to allow C/C++ code to run in web browsers. Once WebAssembly, or wasm, matures and appears in browsers, it will allow developers to create native applications, and web applications with native code …
"That said I am sure the hipster web "developers" will make enabling it near mandatory for my banking site in no time"
I should imagine that most hipter developers will have spilt their frothy frapuchinos after reading the article due to the sudden realisation that in the future they might have to learn and code in a grown up programming language. Or more likely - be out of job as functional expectations rise, to be replaced by professional coders who have a clue and don't consider amending machine generated javascript and CSS stylesheets to be programming.
Why would you need C/C++ to make a website safe?
So all the 3rd party malvertising sites can run their malware more quickly in the browser?
Yeah, progress at last. Sounds safe enough to me.
You'll have Norton running natively in the browser next. Oh well, at least that'll speed things up a bit.
I'll put it another way - laxatives for browsers. KEEP AWAY FROM THE FAN.
@PNGuin,
"Why would you need C/C++ to make a website safe?"
Wrong way round. C/C++ (or indeed anything else that can be compiled down to a WASM) can be run in the browser safely, everywhere, probably. The emphasis is on the "dangerous" language being available to a programmer but being fully constrained by the sandboxed Javascript engine that actually runs the WASM.
"So all the 3rd party malvertising sites can run their malware more quickly in the browser? Yeah, progress at last. Sounds safe enough to me."
Quicker, yes. AFAIK the safety of a WASM is vested in the safety the Javascript engine's sandbox. The C/C++ can't do anything that the sandbox won't let Javascript do. So it's neutral, security wise.
"You'll have Norton running natively in the browser next. Oh well, at least that'll speed things up a bit."
There's already been proof of concept HTML5 viruses that reside solely in the web browser. Web browsers are simply yet another execution environment, and will / are going through the same phases of bug discovery and fixes as, say, an OS. The more features that get added to that execution environment the worse it'll get. The more such features are used, the less relevant the sandboxing becomes; the sandbox merely prevents web code from interacting with the host OS in certain ways, but that's less relevant if the place malware wants to run is actually in the web browser's own execution environment itself, inside the sandbox.
There's plenty of opportunity for the web browser to use different tricks to ensure one website cannot interact with another's data (e.g. encryption of persistent data, which is in fact what they do), and this will make it considerably harder for malware to succeed. However, if it gets out of hand then there may have to be things like Norton inside browsers. Eeek! On the irony scales, that'd be a full set of tens.
Like many others posting, I'm thinking "oh no here we go again". They're talking about supporting garbage collected languages like Java, C#, god knows what else. If this isn't history repeating then I don't know what that phrase is for. If the end result is indistinguishable from a Java browser plug-in done properly (i.e. properly sandboxed), why not just do a Java browser plug-in properly and miss out the nonsense JavaScript part?
"If the end result is indistinguishable from a Java browser plug-in done properly (i.e. properly sandboxed), why not just do a Java browser plug-in properly and miss out the nonsense JavaScript part?"
That would seem to be the eventual end game, and a good thing it would be too, but the initial implementations are based on the JavaScript engine - presumably because it's got all the right hooks into the browser internals.
Why would you ever want to support a language that requires the application to perform its own memory management? I second bazza's point about having a Java plugin done properly instead. Of course, there is the small issue of Oracle's aggressive approach to the way Java is adopted and evolved...
Why would you ever want to support a language that requires the application to perform its own memory management?
What happens when there's a memory leak? Presumably, it has its own virtual address space inside the browser, which it would be trivial to maliciously consume. When the browser's memory runs out does it request more from the OS and expand to fill the system memory (and page file)?
Why would you ever want to support a language that requires the application to perform its own memory management?
Why would you ever want to support a language that has to trust that the environment within which it runs can manage its memory correctly? ... and remember that it's not just about memory.
Memory management in C++ pretty-much looks after itself if you write the C++ competently. It's not C, we have techniques like RAII that can control object lifetimes and cleanup with no additional effort from the programmer. (I'm talking about C++ specifically, here, not about what WebAssembly may or may not support.)
Java has garbage collection, yes, and that means that memory resources are just managed by the environment (except when they're not); but because of that Java lacks the basic functionality needed for object lifetime management (destructors that are guaranteed to be called in a timely fashion) so it's very bad at managing resources apart from memory. In many cases that doesn't matter (and Java can do a lot with finally blocks), but in some cases it does.
@bazza - I think you may have the wrong end of the stick as well:
@PNGuin,
"Why would you need C/C++ to make a website safe?"
Wrong way round. C/C++ (or indeed anything else that can be compiled down to a WASM) can be run in the browser safely, everywhere, probably. The emphasis is on the "dangerous" language being available to a programmer but being fully constrained by the sandboxed Javascript engine that actually runs the WASM.
Disclaimer: I've only spent 10 minutes on the webassembly website, but that seems to be good enough for ElReg comments...
Nothing to do with JavaScript. Your code compiles down to binary instructions for a stack machine. This code is then executed in what is, hopefully, a safe environment, normally in the end-user's browser, possibly by a JIT compiler, or possibly by an interpreter. Your original high-level code (C++, for example) uses standard library calls and APIs, so there's going to have to be some pretty hefty security model in the JIT compiler/whatever.
The JavaScript angle is that there's currently only one way for the browser to get the WebAssembly code from the server, and that's with a new WebAssembly object.
Speaking as someone who writes a lot of server-side C++, and a lot of client-side JavaScript, I have to say that this sounds great. JavaScript is an amorphous pile of byzantine sh**e, and this is potentially infinitely superior. Of course, the security model needs to be tighter, and this does smell of the hype originally surrounding Java and the JVM, so it could be a rocky road.
Yeah, I'd really like to learn more about why they claim it will be 'safe'. It sounds like some type of managed code that's designed for speed. Managed code is always designed for safety, but they always overlook things and it isn't safe after all.
1.13x slower compared to native doesn't leave much room for checking, so it sounds like the format is "assumed" to be safe. Which doesn't make ME feel safe.
Doesn't .NET allow you to completely block things like file IO and out-of-address memory stuff on a per-app basis, while still achieving the same speed.
If you have to provide the source - or some OBJ style compiled blob - it can be inspected pre-runtime if raw system access can only be performed via library calls, no?
No, nature never intended to run applications in something called a "browser", which was born for a very different use. It was turned into an OS wannabe by companies who tried and still tries to perform remote "processing" (also called "snooping") of user data.
I was never happy to have re-download an application almost every time I need it, use a subpar UI compared to a native one, and send my data back and forth a remote server, especially when there's really no reason to do it.
" No, nature never intended to run applications in something called a "browser", which was born for a very different use. "
I'm pretty sure nature didn't create sand just so that we could melt it down and form massive crystals that we then slice into thin sheets and bombard with focused photons in order to start firing pulses of electrons through them.
Computers are way beyond what nature intended anyway.
I remember a time when an operating system was considered to be a waste of resources. The Dreamcast was the first console with a proper OS, and even then, almost everything was coded for bare metal.
A web-browser is a type of GUI, designed initially for very specific types of data and presentation. If I'm knocking together a quick program for my own use, I'll often put up with the general crappiness of Javascript so as to take advantage of HTML forms as a quick and easy GUI.
The question is: why you still need an application called "browser" with an UI still designed to "browse" documents (i.e. the back and forward button, the bookmarks, history, etc.) to run another application?
IMHO it's time to get rid of the browser and have HTML/Javascript support built-in into the OS for such kind of applications. Type an URL or click a shortcut, and the web application opens just in its window, no "browser" app in the middle. Keep on using a "browser" to read The Register.
But believing they are "natural" application is stretching it a lot. I find an application "natural" when my interaction with it is simple, it "amalgamates" well with the OS and other applications, has an UI which is coherent with the OS and other applications, can exchange data and interoperate easily. and doesn't require constant re-learning because it changes constantly to follow the monthly fashion.
Most web application are as natural as trying to build a computer with wood only. Sure, easy to work with, but not exactly the best approach.
I prefer coding in C and providing my own safety nets which have never failed me yet. There were real (as in prison) penalties if I fragged up. I'm not so sanguine about the rest of the software writers out there. If there's a way to bend/break it for some unsavory or unintended purpose, we can be assured that we'll see it Real Soon Now.
>I prefer coding in C and providing my own safety nets which have never failed me yet
Meanwhile corporation X takes one look at your rates and then is like I can get a whole team on a certain subcontinent for that. If they are lucky by the end some of the team members might have even made it through the C for dummies in their native language.
You are seriously undervaluing (underpaying actually) the programmers of that subcontinent in that team. I'm not at all expensive since money hasn't ever been a consideration in my case. Problems are my meat and drink being a puzzle person. It's why I've been involved in testing software for decades with often the only reward keeping a license at the end of the process. Now if someone would keep me in the computer of the month club (not even expensive ones), pay my electric bill, food, and a cheap place to stay, I'm all yours.
Spending a career in the military, a couple of jobs for the Veterans Administration, and the like isn't going to get you the big bucks. Again, it's the puzzles/problems that were the reward. And the occasional pat on the head.
now I'll need a special plugin to BLOCK THAT SCHTUFF won't I?
hopefully 'NoScript' will be enough. I already disable web-java for the OBVIOUS reasons, along with the flash plugin, yotta yotta.
What the *HELL* kind of WACKY WEED are those idiots smoking in those W3C 'kumbayah' campfire (aka pass the douchie on the left hand side) sessions?
NO. we do NOT need downloadable content to INCLUDE full-blown compiled-language code. Javascript is bad enough. JAVA was bad enough, too. FLASH is even worse. Just *NO*, ok?
Q: argumentum ad hominem?
A: *yup*
Q: ranty and shouty?
A: HELLS YEAH
Q: random emphasis?
A: *YUP*, YUP, aaand *YUP*
Q: madey-uppy words?
A: douchie made this reader wtf
Q: ideological?
A: but of course
Ladies and gentleregs, it's gotta be Bombastic Bob! Mercifully as this is not a political post we have been spared such linguistical inventions as Hitlery and DemoRat -- I'm surprised we weren't treated to DoubleUseless3Semen or a similarly ridiculous epithet.
"What the *HELL* kind of WACKY WEED are those idiots smoking in those W3C 'kumbayah' campfire (aka pass the douchie on the left hand side) sessions?"
W3C have the wacky backy, meanwhile the C++ committee (going by recent iterations of the language) have long since left the campfire and disappeared off into the woods to hunt for magic mushrooms and get some feedback and ideas from the local leprechauns.
computationally complex content like streaming video, video editing, games, and virtual reality at high frame rates.
Lets just take that line right out of the PR documentation and replace it with what was meant in this case:
Digital Rights Management tools
> Can we get a system with enforced bounds checking and other safety features, please.
As any language can target WebAssembly, so yeah, why not?
Here is a discussion about Rust.
I'm a Rubyist so I'm fascinated by the idea of Ruby on Rails being able to use Ruby on the front end, intriguing. Just as Javascript migrated to the server with Node.js we now have the possibility for every other language to migrate to the client. I wonder which language will have the first decent implementation (besides Javascript). What is the provision for multiple assembled packages on a single webpage each with its own garbage collector and other runtime shenanigans?
Well, that dead language that just kept hanging around is coming back.
Only real programmers will use it, web developers who tried to be real by using javascript frameworks will once again be put in their place.
The text interface will go bye, bye. Only the supped up canvas with self-contained apps will be the future.
Yep. What goes around. Welcome back windows 3d, bye html DOS.
@Gall
Whichever ones are needed. Its called a makefile and cross-compilation.
This is how we used to do things before someone tried to make a one-size fits all platform called a browser - then tried to make it the solution to everything and spent the next decade or so making it work properly - which is why we've had Active-X, Java, Flash, SVG, Desktop views, mobile views, lousy application security (or no security), HTML5, etc.
Performance issues still remain, so they are bringing in the big guns again.
Looking at it from the other perspective. with a proper client side application, you can compile for the specifics of each platform, optimise as necessary to get best performance, utilise hardware offload, comply with local UI requirements, so it feels right for the user, etc. Its all been done before *
This is nothing new - your map app on the phone is probably a local app, as is your mail app, even your browser is local.
* We can reliably state it will all be done again when they go round the loop next time in about 20 years time.
Seems to be most of the time is wasted in frameworks and DOM thingies on most webpages, very few pages try to 'compress video on the fly' or other smoke-induced ideas they just came up with.
The cycle will be as follow:
+ Webassembly thingy is here, rejoince! Fastness the world over!
+ Wait, why have our BROWSER code in normal code, wouldn't it make more sense to have it in Webassembly so the base browser is SO simple to maintain and all the rest is webassembly?
+ Ok we've done that, now our browser is a real fat(tter) dog, WHAT CAN WE DO?!?!
+ *I know* ditch all the webassembly thing, we'll rewrite the core in plain C/C++ and life will be GOOD!
Seen that before? Remember mozilla (all *javascript* man, it's going to be sooo cool and.. and cool!11!) and then... firefox.
The main reason is to reduce the reliance on the OS.
The main cost is the reliance on "current" browsers, who may pull the rug-out at any time without warning which leads to the still-existent IE6 stuff still hanging around.
The main reason is to reduce the reliance on the OS.
The main cost is the reliance on "current" browsers, who may pull the rug-out at any time without warning which leads to the still-existent IE6 stuff still hanging around.
+1, but 'reducing reliance on the OS' includes supporting all those users on stupid OSes, dealing with moronic walled garden vendors, learning multiple development environments and languages, handling OS bugs and security flaws, rather than just browser ones, packaging and distribution, you name it.
And the commentards still turning off JavaScript in your browsers: what actually are you using the web *for*? Static webpages and videos? Really?
But the web is so much more relaxing when it's not all jittering and sliding about. It's probably fun to write that stuff but I can assure you, actually using it is no fun at all.
Web decoration is just the new DTP and we'll all be jolly glad when everyone gets over glamming it up and uses it properly.
"And the commentards still turning off JavaScript in your browsers: what actually are you using the web *for*? Static webpages and videos? Really?"
That probably tells us more about your surfing habits than you can divine about ours.
"And the commentards still turning off JavaScript in your browsers: what actually are you using the web *for*?"
I'm interested in what I'm not using it for. I'm not using it to be bombarded with pop-up advertising, pointless web designer tat such as animated hearts flying around the page, chat sessions that I don't want auto-starting without my authorisation, tracking every page that I visit via third party javascript run on my computer and all the other "you must have this" rubbish that people seem to think they need to force onto those browsing their site. If I want that stuff I'll activate it on a case by case basis. There are many sites out there that try to launch code from 20+ other sites in my browser which can slow it to a crawl. They can just go hang.
All methods of running remotely delivered code "securely", and all subject to malware attacks that break the sandbox and infect the host machine.
So , now we take an existing sandbox (JavaScript) and make it do new things it doesn't already do, running chunks of native code. Of course a whole new class of vulnerabilities will be discovered!
Even Java, with it's virtual machine - which means that the browser never runs native code, but a bytecode, is riddled with holes. In theory, every bytecode when executed can be checked. Apparently that is not enough.
Useless idiots.
Even Java, with it's virtual machine - which means that the browser never runs native code, but a bytecode, is riddled with holes. In theory, every bytecode when executed can be checked. Apparently that is not enough.
That would be enough, if it were done like that and done correctly.
It's not done like that though. The bytecodes are compiled to native code in the browser so that they will execute quickly, and any chance of policing the code as it runs goes out of the window.
As you said: Useless idiots.
I have long wished for a low-level, ubiquitous browser language that allows static types/checks (unlike Javascript) and which is not sauced in object-oriented legacies such as null-pointers everywhere, downcasts, dynamic calls, and so on. Something that is as well suited for ML or Haskell as it is for Java or C#.
There is a lot of research in typed assembly language, proof-carrying code, and so on, that allow static verification of safety properties without relying on sandboxing. Something like that would be great. I don't know enough about WebAssembly to decide if it does that, but I suspect not.
I've long held the belief that despite the fact all these web technologies have been around for a long time now, they've truly lost sight of what they're trying to achieve. I'm currently writing a web tool using Django, jQuery and javascript and I'm incredulous that these languages have to couple themselves so tightly. I'm not a Web developer by any means, and this is only the 3rd time in 30 years I've dabbled, but things have certainly not improved adequately in that time.
A complete rethink is required. We should know where all the pitfalls are and be able to come up with a set of useful, all-encompassing requirements.
We already have an increasing amount of Javascript Malware in forms like tracking software. Until now you could simply defend against it by having locally patched versions of them. Patching WebAssembly will make this a lot harder.
The reason why browser manufacturers adopt WebAssembly is probably because it makes browsers more complex, creating a higher point of entry for new competitors. It's impossible to develop a new browser (engine) with a small team. You will always need a fairly large organisation. Those organisations want to continue existing. Making the web simpler could increase competition and could kill or harm any of them. An oligopoly is a rather nice place to be in.
This is what PHP should have been.
"We need some sort of programmable way of generating web pages. I know, let's invent something that looks like C but breaks every single C programming concept."
Much better to have been able to use, eg:
<?c if (test) echo("hello"); else echo("goodbye");
c>
The reason most websites are coded in HTML/Javascript, is that they're architecture independent.
How on earth can a binary C/C++ package be portable? I've not had time to research this yet having only just heard about it here, but are these webapps built on an API provided by the browser, which provides the abstraction layer to the host OS?
Sounds like a recipie for the almost perfect malware vector to me - although such webapps will no doubt run faster, they will also be completely obscure - which can't be any good for security in the long run.
You can already compile C or C++ to for example JavaScript (yes, source code) or Flash/AVM2.
Just like you can compile it for some totally alien CPU architecture and OS and then run it in an emulator.
But yes, otherwise you are correct - both regarding how it works (restricted to APIs provided by the browser/runtime) and some of the potential problems with it.
"How on earth can a binary C/C++ package be portable?"
Look up PNaCl, C/C++ or other lang is compiled into portable bitcode which runs with or without a sandbox. Sadly Chrome and Chromium is the only browsers supporting it currently. This WebAssembly thingie seams similiar except it executes on the JS runtime instead of natively.
https://developer.chrome.com/native-client/nacl-and-pnacl
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
