Slashdot Mirror
Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard (tomshardware.com)
An anonymous reader quotes Tom's Hardware
Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly... Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly. WebAssembly can give web apps near-native performance, offers support for more CPU features, and is simpler to implement in browsers and use by developers.
None of this matters a bit to desktop users.
WebAssembly is a byte code for a virtual machine. It's not native.
PNaCl is a byte code for a virtual machine, with an interfaces based on an earlier native virtual container (NaCl).
these are secure if virtualization is complete. but all known implementations are still susceptible to row hammer as it's too difficult a problem to solve for VM implementers.
“Common sense is not so common.” — Voltaire
WebAssembly: Mozilla Won (Not a put-down to the excellent Chrome developers, but acknowledging the massive and important contribution Mozilla made here.)
fuck Mozilla and Google for obfuscating the web, why the fuck would you want to run assembly in the web browser ? unreadable shite that malware will exploit instantly, performance is just a bullshit excuse, obfuscation and a new era of exploits, we just got rid of binary bullshit ala Flash et al, now you want to replace that with another binary format ? fuck off
It's time to go back to Web 1.0, back when web sites could be used on Megabytes of RAM and just 56K modems. Modern sites have become so morbidly obese with HTML5 and autoplaying media that even my computer with 16 Gigabytes of RAM slow down. This Web assembly will be used to create even more bloated web sites with adblock defeating adverts and tracking. Firefox has jumped the shark too, with Version 57 being the death of "classic" Firefox.
I'm looking forward to the next hit browser that won't support javascript for just any ol' page and when it does, it uses an interpreter engine for increased security. It may require a new standard which means the W3C may have to fall (since they are backed by people pushing increasingly intrusive tech).
Anons need not reply. Questions end with a question mark.
We should be going the opposite direction and eliminating JavaScript altogether.
Though I agree with you and others that JavaScript has been abused, I disagree that the web ought to throw the proverbial baby out with the bathwater. In some cases, JavaScript dramatically improves the user experience in web applications. It makes others possible in the first place.
Say you want to let a user fill out a web form, but you don't want the poor experience associated with having to fill out the entire form and then perform a form submission and full page reload to catch the most common entry errors. The common way to improve the user's experience is by sending a short script that prevalidates the entries before the server validates them authoritatively, letting the user fix things before they're submitted.
Say you want to offer a chat service, where users send short strings of up to 100 characters or so to a channel and other users in the same channel receive them. You might consider putting up an IRC server, but your prospective users lack privileges to permanently install an IRC client on the devices that they use. You might try to do this as a web application without JavaScript, but you'll have to rely on users remembering to repeatedly click a "Check for New Messages" button to reload the iframe containing recent messages sent to a channel, which is a poor experience for users. In this case, the least bad option is a web application with a script that waits for new messages to arrive through a WebSocket and appends them to the list of recent messages.
Say you want to develop a real-time video game and allow members of the public to play it, but Valve, Apple, and the major console makers have turned your game down for one reason or another. So instead, you decide to offer the video game as a web application. The only interactivity possible without script is a form submission followed by a full reload of a page or iframe, but that's not possible for a real-time game. Thus script is again least bad.
If you're not convinced, I have more examples.
and run it? What an amazingly original idea! What could possibly go wrong? /sarcasam /ref java applet
I have always been so surprised how Java never really took off like it should have. It's main flaw to me was binding the language to the virtual machine. The language is terrible. And before everyone jumps to Java's defense... ask yourself, If Java was so great, why would we have needed Javascript? Python? Flash? Java done properly would have removed the need for any of these languages... at least as separate entities unto themselves.
WebAssembly is a byte code for a virtual machine. It's not native.
Eh... Oberon slim binaries format is a byte code for a virtual machine. But the code does run as native, because slim binaries are just a platform-independent and compact Oberon program representation. I presume WebAssembly does exactly the same thing.
Ezekiel 23:20
It's time to go back to BBS, back when a BBS could be used on kilobytes of RAM and just 300bps modems. Web sites have become so morbidly obese with HTML and images that even my computer with 4 MB of RAM slows down. This Web 1.0 will be used to create even more bloated web sites with ads. Netscape has jumped the shark too, with version 3 being the death of "classic" Mosaic.
#DeleteFacebook
Virtualization vendors can't manage to keep people from finding new escape vulnerabilities. All major VMs including java and .NET have long histories of escape vulns. OS level jails such as android platform have met similar fates.
What makes web assembly different? Why won't there be a steady drip of escapes? FFS there are tech demos of web assembly running unreal engine controlling GPUs. How is any of this even remotely secure?
Have a feeling first thing we'll see is people implementing custom malware browsers in web assembly that look like the real thing in a bid to own users even more than they are already owned today.
The advantage of WebAssembly over Java is that the former isn't owned by One Rich American Called Larry Ellison.
If there's more than one implementation of a particular platform released as free software, these implementations can compete on security. Chromium is free software, supports JavaScript, and will support WebAssembly. Likewise with Firefox.
But we didn't get that opportunity with Java or Flash. Last I checked, the license of the Java Language Specification prohibited publishing an incomplete implementation. This requirement to keep works-in-progress confidential within an organization in turn had the effect of keeping independent free implementations of Java from existing legally, ultimately leading to Oracle v. Google. Likewise, Adobe's SWF spec was intended for developers of tools that output SWF, and its license specifically banned using the spec to make a third-party SWF player until February 2009.
Virtualization vendors can't manage to keep people from finding new escape vulnerabilities.
Nor can CPU vendors. Despite the engineers' best efforts, some CPUs ship with defects that allow userspace software to lock the physical CPU. Some examples:
F00F bug Some Intel Pentium processors misinterpret the LOCK CMPXCHG8B EAX instruction. Cyrix coma bug Some Cyrix processors misinterpret the XCHGL instruction in a tight loop, blocking interrupts.PNaCl and NaCl are *not* virtual machines!
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
I talk about it in another post.
Which means that a defect in the verifier that enforces "constraining the assembly language generated" in NaCl or "the final LLVM stage backend" of PNaCl would lead to a sandbox escape.
When I saw the title I first thought that the article was about PhosphorusSodiumChlorate.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
how many times do we have to see 'native' browser tech nerfed then depreciated because "it isn't safe", only to have the next round of ideas fall a few years later for the self-same reason? The truth is that today browsers are vastly worse at running PC-like code (like hi-performance 3D) than they were 10 years ago, yet they are not one lick more secure as is (giving us yet another reason to run as many ad-block systems as possible).
iD had their multi-player Quake game running on the browser a few years back, then had to cancel it when Google, Mozilla etc killed such functionality.
for sure, non-'native' pure browser tech renders pages better than ever- but then the browser runs on resources vastly more powerful than a few years ago- so that's no achievement for the browser coders. But games, emulators, 3D etc on a browser are now a bad joke whereas a little time back all worked really quite well.
The PC platform won out because it was a 'can do' situation. but the walled-off garden approach of everything else in computing shows an 'alternate' history of lousy performance and artificial restrictions for no gain whatsoever. The 'best' browser apps run literally thousands of times slower than what the native hardware is capable of.
The demise of PNaCl is really unfortunate.
"WebAssembly" is a virtual machine; it might as well be named "JVM".
PNaCl pushed down partially compiled code so that a compiler backend could localize it to Native code on the local machine. It used LLVM IMF (effectively) to implement ANDF -- Architecture Neutral Distribution Format, which was a promise Apple was never able to achieve -- which is why Apple has "Fat Binaries": single binaries with multiple images.
NaCl, by contrast, targeted a specific binary instruction set in the target, and people would use different wrappers for the actual code itself, via JavaScript, to select the architecture (ARM, x86, etc.) of the actual binaries being downloaded in NaCl form.
The question is whether you do the finalization work on the sender, or the receiver. Both systems, however, had as their primary intent the ability to extend JaveScript with native code plugins.
In the absolute limit, you'd write all your code in native code, and then ship it down with a small JavaScript shim, in order to call into that code's "main" with a thread context, and set it running as native code.
There are a number of Games which did this, and there's a (moderately common) use of NaCl to push down x86 games running in a PC emulator as a packaged lump in NaCl.
PNaCl -- which was platform independent -- and NaCl, which I would say has arguably failed as well -- failed because it was massively difficult to develop applications in it.
This is predominantly because there is insufficient glue code and no IDL in order to define JavaScript interfaces which also described C/C++ code containers for the compilers used to generate the native code on the front end.
This made it impractical to have what is -- in essence -- a browser-level jandboxed "JNI" equivalent for JavaScript.
So people simply didn't use it.
In other words, it was not a complete product, and like Mozilla in the early days, it was nearly impossible to build anything useful out of it that actually did anything that had any impact on anything.
NaCl -- apparently not (yet) deprecated -- still has this problem.
Think of it as having DCE or Sun RPC available as an interface between JavaScript and native code, and having no "rpcgen" and no "xdr" library available to use.
This is pretty typical of some Google products: they go 80% of the way there, and then, because they are organizationally not motivated to do things which are difficult -- because you can pretty much walk to any other job inside Google, should your manager ask you to do something you considered "unfun" -- no one finishes the remaining 20%.
I tried to resolve this in my 20% time at Google, but was rather constantly thwarted in the effort (the 20% time at Google is largely mythical) by providing an IDL in XML that would let you describe the interfaces, and then generate the JavaScript templates on one end, and the C code containers for the functions that needed to be written on the other, along with an "XDR" library for marshaling arbitrary data back and forth between the "C form" and the "externalized JavaScript" form.
Sadly, this project never came to fruition -- I was even, stupidly was writing it in Python, to make it politically acceptable to the people who were complaining the loudest, when I could have cranked it out in C in a couple of days -- Python is really slow/bad at XML, among other problem.
Personally, I think this deprecation and switch is a terrible idea.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Massively bad mistake.
The only saving grace is that I have no doubt that it will be "about as popular as NaCl/PNaCl", and it'll stop at 80% of the way to "people are now likely to use this thing to do their projects".
Not only does WebAssembly not require packages to be signed, it does not even provide a slot in its standard for signatures. When are software engineers going to learn that you don't do these things after the fact? I am sick of browsers being cesspools for executing random, uncontrolled and unattributable code.
Open Web FTW!
Why would anyone want JavaScript to run natively in assembly? Sounds like a ton of vulnerabilities waiting to happen. We should be going the opposite direction and eliminating JavaScript altogether.
I infer that the desire for native bytecode is so that malware from websites can run more efficiently and not hog our CPUs.
I don't know why you've been downmoded, You're absolutely correct. Expanding internet attack surfaces is possibly the worst idea since the US decided to fix the Middle East by invading Iraq. Getting rid of ALL scripting would be one modest step toward getting the digital world under control. Sometimes I think mankind has a deathwish.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Isn't it missing 3 oxygen atoms to be a chlorate?
Inheritance is the sincerest form of nepotism.
Should be phosphorus sodium chloride.
a,e,i,o,u and sometimes w and y (at be if of up cwm by)
I'm not convinced that client-side calculation is a good thing in the cases you list because what you call "a form submission and a full page reload" doesn't strike me as tedious, too long, or generally bad. I think that the most commonly used web browsers have made a horribly bad tradeoff by allowing ad-hoc downloaded code to be executed client-side and have full access to the user's computer. I'm distinguishing between code one has a chance to run, study, modify, and share (free software browser code) and free software one downloads ad-hoc as part of a webpage (for which no browser, not even free browsers, has yet given the user a chance to truly leverage the freedoms of free software before executing, despite license notification and add-ons to handle running only free software like LibreJS). Javascript and other client-side programming languages are too powerful to do what browsers commonly do today in default installs. This creates a lot of vectors for security problems akin to using insecure plugins which take unvetted input from a web server and run it. I don't think a round-trip page reload is problematic in light of the security risks that come with running what is realistically unvettable code. The successes I see with NoScript and friends tell me that not running code client-side by default is the right way to go.
I'd much rather take the path CSS appears (to me) to be taking: figure out what non-executing features people need and make CSS syntax do those jobs. If you need form validation, bring up your needs to people who discuss CSS and perhaps you can find a way to do regular expression-based validation with a regex parser that's not as powerful as PCRE but sufficiently powerful to tell if this phone number or credit card number is likely to be valid. But I'm not even convinced that server-side validation here is the problem you think it is.
I also don't think that walled garden censorship is an excuse for justifying that everything should be implementable on the web. Those are separate issues and neither acknowledges legitimate privacy and security concerns with modern browsing in default settings (which I believe is what most users use). Programmers have always accepted that not every program can run in every environment or be implemented with every programming language. It's time privacy and security get higher priority and people learn to say no due to considered tradeoffs. Technical limitations of this sort can be right and proper to have.
CSS doesn't bother me because (as far as I know) CSS has no way to do the things I don't like about running unvettable programs client-side such as reading/altering/deleting client-side files, doing stuff over the network, detecting client settings, and more. CSS is specification, not programming, but even if it were programming it wouldn't have to offer an API that lets programmers do the things programmers do with Javascript. Sure, some font and image handlers are broken and specially-crafted fonts or images can leverage that broken code taking advantage of an insecurity. But that's not CSS's fault. A font or image library fix and that security hole is patched, no changes to CSS are being made.
Digital Citizen
That's a question we can't answer without knowing more about the application and ultimately modern developers do develop for multiple OSes. One approach is to release the program as free software (users purchase the program and get a copy of the program licensed such that they may run, inspect, share, and modify the software) and users may help port the program to other systems and architectures. But ultimately your business needs are not more important than society's needs for not running any arbitrary program their browser is instructed to download and run. That's the model we have now and it's highly unsafe.
Digital Citizen
Who cares? If it runs, it's ultimately native. However virtual/interpreted/non-native it claims to be, you have to trust the vm / interpreter / native code it ultimately runs as to enforce the rules of the language and keep you safe. And we all know that's not gonna happen.
I'm sick and tired of this stupid shit going into my browser. I want better security and bug fixes. Not more code in my browser/operating system/etc.
Having a standardised replacement for the abysmal mess that is javascript is very welcome indeed. No longer will we have to use a mess of junk frameworks with lifespans measured in months, written in the worst language ever concieved.
One approach is to release the program as free software (users purchase the program and get a copy of the program licensed such that they may run, inspect, share, and modify the software) and users may help port the program to other systems and architectures.
For one thing, in the case of a computer program released as free software, how can the developer recoup the cost of feeding and housing himself over the course of development if the first person to purchase a copy goes on to exercise his rights under the license to share that copy with every single other prospective customer?
For another, many programs are for an audience who are not developers and would have no idea how to begin to build from source code a program that is already ported to his platform, let alone port it to a brand new platform.
But ultimately your business needs are not more important than society's needs for not running any arbitrary program their browser is instructed to download and run. That's the model we have now and it's highly unsafe.
Nor are my business needs "more important than society's needs for not running any arbitrary" native "program their" operating system's package manager "is instructed to download and run." What makes web applications any less safe than native applications in this respect, other than that a user is presumed safe from native applications that happen to have been designed for a different operating system?
There are plenty of legit reasons to hate on Ellison, but it's pure FUD to bitch that the Java license didn't allow you to call your product 'Java' unless it provided a defined base of stuff. Would you foam at the mouth about Larry Wall if he reacted negatively to a company releasing a language that was only half like perl but named 'perl 4'?
In the very early days other vendors (OK, mostly IBM) created their versions of Java and they're still at it. IBM's latest effort with its J9 Java VM is yet another independent and free distribution of Java that manages to run rings around Oracle's.
Getting rid of ALL scripting would be one modest step toward getting the digital world under control.
This means every form of interactivity on the Web that cannot be efficiently performed through form submission and full page reloads would have to move to a native app, and native apps are specific to one operating system. Good luck running a native Mac app on anything that's not a Mac.
You're telling me I could communicate faster on Fidonet than on the current internet? REALLY? I suppose having a video chat with 8 people was a snap of the fingers?
People with this mentality find text chat superior to video chat. Anyone over twelve without a serious learning disability can read silently faster than he can listen, which particularly helps when eight users are sending messages to a channel at once.
I would bet 1 million time machine dollars that by the time you had finished your modem hand shake I could order something with my voice without even turning on a screen.
It's called a voice call to Domino's over Plain Old Telephone Service.
The fact is, however, that you still want to go on Netflix and watch your programs
No, you would want to cancel Netflix, forgo its exclusive programs, and watch different programs that do not use digital restrictions management.
log into your bank account, buy stuff on Amazon
Which can in theory be done mostly server-side, with the client touching only HTTP, TLS, HTML, and CSS, not the larger attack surface of JavaScript or WebAssembly. Worse comes to worst, it could be done with an even smaller client attack surface over SSH, just as online banking and shopping used to be done over dial-up with a terminal emulator back when CompuServe was still hot $#!+.
You think that you can bring all this stuff back to plain HTML, and - what? - Perl on the CGI backend of a server and be immune? We thought that 20 years ago, it didn't work out.
It doesn't have to be Perl; it can be something more "modern" like Python or Java or C# or Go or whatever. But some see value in containing the attack surface on the server side rather than expanding it to the client.
At some point you have to take user input, or input from a remote website, and interpret it in a way that cannot possibly be compromised while letting the user accomplish what they want to
The server needs to authoritatively validate the user's input anyway. Why require the client to download code that only expands the attack surface while duplicating the validation effort?
Not only does WebAssembly not require packages to be signed
Every response sent over an HTTPS connection is signed by the TLS endpoint sending it. This includes js files and wasm files.
You are right, was a few decades ago I did chemistry.
Assume you refer to vowels by "a,e,i,o,u and sometimes w and y (at be if of up cwm by)", here it's "a,o,u,å,e,i,y,ä and ö" but never w. w and v are the same here.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
asdf
It is even better than that, provided that the JIT compiler is correctly implemented. If you implement an interpreter in a language that is being JIT compiled, then that program that is being interpreted will also be JIT compiled (due to transposition).
With the PyPy (Python) compiler they showed that can be true. The project is pretty insane though, hold on to your hats:
- They wrote a language that is a subset of Python which could be completely compiled. It has full type inference, and static typing.
- They added some JIT compile trickery, to recognise interpreter constructs.
- Then they wrote a Python interpreter in this subset-Python.
- Now any Python program that is being interpreted will be JIT compiled.
From the documentation, it says that if you make another language interpreter in this subset-Python, it will also get JIT compiled.
Of course, it only applies to English.
I was taught the "sometimes w and y" part in grammar school. I was surprised to discover decades later that w was no longer being taught, at least according to a couple of students I asked. The list is just to demonstrate that all of them can be the only vowels in words, but w is used in many diphthongs as well. (cwm is a very rare word)
a,e,i,o,u and sometimes w and y (at be if of up cwm by)
It's funny that I find out that the web runs on Phosphorus-enriched salt just as they get rid of it!
The PNaCL version didn't work right for a year, providing me with a number of support headaches. Not excited about doing that again.
I didn't even know that Phosphorus would bind with table salt.