The main concern for me with native client is webgl and the exposure of 3D device drivers to the Internet. These drivers were not written with this use in mind there have been webgl vulnerabilities in the past: http://www.contextis.com/research/blog/webgl2/
While Google will be aware of these and actively working to provide a buffer with via validation and sandboxing, with pessimistic hat on, I can see this leading to a lot more security vulnerabilities.
That's a valid concern; I know another HN user who might chime in with more detail to back it up.
On the other hand, Google has built a particularly good security team for low-level systems code problems like this, and they've done things (like the NaCL security contest) to attract the right kind of attention from researchers.
I'm not the least bit concerned about NaCl's involvement here, but I'm still deeply scared by the potential for things to go very badly in the lower levels (but not enough so that I'm willing to disregard the benefits of these APIs, mind you).
What it comes down to is that current GPUs do whatever you want with no concern for security; that part depends on the driver and userspace 3d stack. This isn't necessarily bad, but GPU manufacturers can't write code. Bounds checking and all that are pretty well covered by things like ANGLE (translates OGL to D3D on windows and acts as a sanity checker and shader validator everywhere else) but that doesn't help you if, say, your driver improperly compiles valid-but-malicious code. Avenues like that are effectively not researched at all.
It's a concerned but it's something GPU vendors are claiming they are working on. There has been moves to improve driver security through the ARB_robustness extension and for the browser vendors there is the ANGLE's project as you have said but also plain blacklisting dangerous cards or drivers.
The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight.
In all, if we want a more capable web these are risk I feel are worth taking. But that's my personal view.
> There has been moves to improve driver security through the ARB_robustness extension
IMO, GL_ARB_robustness is almost completely worthless. The one thing it gives you is the ability to time out rendering, in effect, which of course prevents certain types of DoS attacks. There are many other provisions in the extension, but those are already universally implemented in ANGLE and the like; they don't do anything to help with the security of the lower level.
> The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight.
NaCl has the same issues regardless of the sandbox, but I agree entirely: hardware accelerated 3d on the web is worth the risk we'll be dealing with for the first couple of years. I've stopped writing desktop 3d software/demos entirely in favor of WebGL simply because I believe so much in it, but it's not stopping me from doing security research into it as well.
At the end of the day, I'm convinced that a reasonably skilled attacker could do terrible, terrible things to my system via WebGL. But the benefits outweigh the risks for me.
Virtualisation's rise in popularity has caused IOMMUs to start showing up even in some consumer chipsets. Do you think an IOMMU and a driver that supplies it appropriately restrictive page tables for the GPU will be enough or do we realistically need GPUs with some kind of native memory protection support that can somehow be intertwined with the CPU's process model?
Yes and no. So, it really depends on what you're defending against: if your concern is solely about an attacker using the GPU to compromise the CPU, then IOMMUs get you a lot in terms of restricting what's possible -- sure, an attacker could find some buffer somewhere in the accessible address space that they can use to attack the CPU, but it's another barrier. But if you think about what's on the GPU itself -- all your UI elements (in many cases), your webpages, etc -- it suddenly makes that data seem very important; if I can get you to go to a page that will let me grab all of your running windows, then suddenly I may very well have things like your passwords, credit card info, etc (all depending on when I grab the data and how often that data gets flushed out).
I think that proper protections should be put in from the hardware on up through the drivers, but it's going to take a lot of work and a lot of research to get it right.
I wonder how much Google feels comfortable with this level of risk due to the speed with which they are able to push out updates and the rate at which their clients autoupdate themselves.
> There's a BIG difference between "no one else will implement" and "no one else CAN implement."
That's true, but is it the right question?
Browsers could also have implemented ActiveX, back in the day. There was nothing stopping them - except that it would have been very bad for the web and for non-Microsoft OSes. Thankfully, other browsers did not implement ActiveX or else it would have still been used today.
The real issue is that no one but Google thinks NaCl is good for the web. In that sense it is similar to Microsoft with ActiveX. Of course, there are big differences too - NaCl is open source, so it would be easier to implement, if another browser changed its mind. Still, that is just a matter of technical convenience - if NaCl were closed source, the other browser vendors could still reimplement it. But again, the issue is that only Google thinks it is worth implementing in a web browser.
Kudos to Google for making it open source, but open standards are just as important for the open web.
> The real issue is that no one but Google thinks NaCl is good for the web.
Are you sure about that? I like NaCl. I don't know about depending on x86 instructions, but I like the idea of NaCl. I think it's pretty clear that the web needs some kind of low-level VM that's closer to the metal than JavaScript. It's been argued that LLVM isn't the answer, so maybe PNaCl is on the way out, but overall I think NaCl makes sense in Google's strategy: they want to see web apps take over. They want the web to replace Windows and OS X. Therefore it's natural that they want to download native or near-native code to the browser, and NaCl is just a way to do it safely. It's _not_ the same thing as ActiveX, I really believe that. However, it's clear that it's necessary to be extremely careful, and I'm not convinced they need to go 100% native -- I think a solution like PNaCl is more along the right lines. Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.
Sorry if I wasn't clear before, when I said "no one but Google thinks NaCl is good for the web", I was talking in the context of browser makers. I meant the fact that Google is the only browser maker that thinks NaCl is good for the web.
> Web apps and games are not going away, and I think it's clear that we need something easier to statically optimize than JavaScript as the runtime system for the web.
We can do that in a portable, standards-based way without a complete break like NaCl with its downsides.
Consider what the PyPy compiler does to RPython: It compiles RPython, a subset of Python, down to C, by statically discovering all the types and so forth. The same can be done for JavaScript, since the performance-sensitive code people are writing is almost always statically-typed (but implicitly, without writing types) anyhow, just like RPython.
In fact we are already moving towards that now, with technologies like the global type analysis in SpiderMonkey TI. With a few more years of work, that approach should make performance-sensitive JavaScript as fast as we need it to be. There is no technical impossibility here, it just takes time - we are half-way there, with things like RPython showing this is definitely feasible.
NaCl uses the NPAPI which is pretty standard, it's used for flash for example and is supported by Firefox, Opera and webkit. This means NaCl could be plugged in those browsers without being reimplemented.
You keep using that word. I do not think it means what you think it means. From Wikipedia:
"""Proprietary software is computer software licensed under exclusive legal right of the copyright holder. The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering."""
Nothing of this applies to Pepper API or NaCl. Mozilla can implement Pepper API and NaCl or can even just take NaCl as whole because it is, oh boy, oh boy, open source with a permissive license.
You think proprietary software is software that you can't use without license, but proprietary API is something other than an API that you can't use without license?
I mean the dictionary definition of "proprietary": controlled by a single proprietor, in this case Google. Google proposed the Pepper API on the plugin-futures mailing list a year or two ago, but Mozilla and Apple believed that it was unnecessary to maintain a parallel Pepper API for plugins to use when Web APIs were already there (and could be improved where they were not sufficient). Google implemented and pushed Pepper anyway. Thus, proprietary.
Likewise, Google is not open to input regarding the direction of NaCl, or whether it is a good idea for the Web. It is also proprietary.
Whether proprietary-but-open-source technologies are good for the Web is a separate discussion -- clearly, Mozilla and Google disagree. But it's unarguable that NaCl and Pepper are proprietary technologies.
An open source implementation is not the same as an open standard and is still not enough. By not having a separate standard oter browsers would either have to support bug-for-bug compatibility with NaCl or be forced to use the reference implementation without any changes (so it might as well have been distributed as a obfuscated binary).
You'd think it would be good to see the problems this will unleash on openness before it's too late and we have to say 2 years down the road, on the next embrace-extend move, that Google has a history of this.
Google is using their muscle to push for the adoption of a Google-exclusive technology in browsers that Google's competitors have said they cannot support because it is not truly open. If you can't see that this is embrace, extend & extinguish in action, then you're either naive or your memory is too short.
They are different, but both are true here, and they are related.
It's not truly open because it is not standardized, nor even proposed to be standardized, and it relies on other non-standard technologies (Pepper). Also, it is incompatible with the open web because it is not hardware-independent, which is another type of openness it lacks.
They do open up a lot of stuff, and provide a lot of free stuff too. They have a lot of talented people as well.
But their base strategy is to control our most powerful tool. For that you need to kill standards. And hey, talented people sure know how to put things on the right balance, at the right time.
I'm not sure who you think can compete with Google. For most people "the internet" is Google.com.
Google.com tells you to get Chrome.
Most top 10 downloaded software bundle Chrome, often with default optin and even default launch.
Companies which aren't big enough to fight are bought out.
See a trend?
What's funny is that my comment gets back to 0 or 1 then back to minus and so on.
What it shows is that this is controversial and many actually agree with my "wharrgarble". Maybe you should give it a deeper though. We'd be better in 5 years from now, if everyone though about such things with a little more criticism.
"I'm not sure who you think can compete with Google. For most people "the internet" is Google.com."
I thought the meme was that for most people facebook.com is the web?
All Google cares about is that whatever tech is out there doesn't prevent them from displaying Ads to as wide an audience as possible. This is a very different motive than what Microsoft has which is to control your entire PC experience.
Google has more or less been playing by the "open, free, web standards based" rules until it's browser got too big to fail.
Then started pushing out things like NaCl that aren't standard, and while open, very hard to implement in a way that stays compatible to Google (and arguably not something you want to implement if your focus is web standards of course).
To make sure of that, you buy how some game studios to release for that platform, and eventually only on that platform (See Bungie+MS, since you like these examples).
This is a lock-in, and that's the first extinguisher, and the worth part: it's only the tip of the iceberg we're starting to see.
Wanna wait til it gets bad for everyone just cause you like Google? Then you'll get in the "oh noes, Google deceived us" in 3-5 years?
Well, it'll be far too late. Better to voice things now (and it may already be too late).
For most people, the Internet is the site that gets them to things they want to see. This can be Google, Facebook, Bing, Yahoo, or even Digg. It all depends on what they're comfortable using.
Do you know what the solution was for XNA? The last time I checked, all the Mono XNA ports were in miserable shape. Considering Bastion makes use of shaders and mixed mode 2d/3d rendering, it seems like it must be running on a high quality port of a large portion of the XNA stack.
Replying to provide follow-up detail: I dug into the executables and it looks like it uses OpenTK for rendering and FMod to sound, instead of using a port of XNA. Both are freely available, so that's a pretty simple path to doing a similar port for other XNA games. Neat.
Regarding Native Client:
I don't think that Google is evil just because they try to move web technologies forward in non w3c standardized ways, and I don't even want to go into this discussion because there're (imho) valid arguments for both sides,
But:
For web developers, this whole process is suboptimal to say the least. It only adds to the already existing complexity of the web technology stack but enforces more browser checks and fallbacks.
Even worse, as soon as you're working for a customer who isn't technical, you'll land in a situation where he shows you a Native Client app and wants "something like that" on his website but running in Firefox or Safari or (even worse) Internet Explorer.
The advent of Native Client combined with this move means the Chrome Web Store is going to end up positioned as a direct competitor to Steam.
That's pretty interesting, honestly. It'll mean great things for consumers: I bet playing a game in your browser could be really convenient compared to downloading and installing Steam and then going through the motions for that platform. But Steam has 7 years on the Web Store with all kinds of great platform features like Steam Play, Cloud, Wallet, etc.
An exciting time to be a web and game developer, to be sure!
How does native client solve the ARM vs Intel issue? Can a fat binary be created so apps run on both an ARM Chromebook and an Intel PC? Finally, can native client be adopted by Opera and Apple for use in their browsers?
Native Client does not solve the portability issue. Portable Native Client is a research project trying to do that, but it is unclear whether it will succeed, and if it does, with what compromises (speed, security, etc.)
Native Client can in theory be adopted by other browsers, since it is open source, however no other browser has shown interest, the opposite in fact. Native Client is a nonstandard technology that will remain only in Chrome.
The main concern for me with native client is webgl and the exposure of 3D device drivers to the Internet. These drivers were not written with this use in mind there have been webgl vulnerabilities in the past: http://www.contextis.com/research/blog/webgl2/
While Google will be aware of these and actively working to provide a buffer with via validation and sandboxing, with pessimistic hat on, I can see this leading to a lot more security vulnerabilities.