Comments on: Notes on Native Client & Pepper Plugin API What sort of security holes are we talking about, here? The only kind I can conceive of off the top of my head is exploiting bugs in the driver, like buffer overruns and stuff - but that's surely a problem with <em>any</em> system that the code is allowed to interact with, not just graphics code? The only other kind of thing I can imagine is stuff like accessing the front buffer to read what's on the user's screen or something. I guess I can see how that'd be a problem, but there's gotta be fairly easy fixes to that, surely - support for isolating a GL context so that it doesn't have read access to any shared resources, and only highly controlled write access...? What sort of security holes are we talking about, here?

The only kind I can conceive of off the top of my head is exploiting bugs in the driver, like buffer overruns and stuff – but that’s surely a problem with any system that the code is allowed to interact with, not just graphics code?

The only other kind of thing I can imagine is stuff like accessing the front buffer to read what’s on the user’s screen or something. I guess I can see how that’d be a problem, but there’s gotta be fairly easy fixes to that, surely – support for isolating a GL context so that it doesn’t have read access to any shared resources, and only highly controlled write access…?

]]>
By: Aras Pranckevičius/2011/06/02/notes-on-native-client-pepper-plugin-api/#comment-5172 Aras Pranckevičius Mon, 06 Jun 2011 07:23:42 +0000 Minor nitpick: "With a specially massaged compiler, some runtime support and careful native code validation it is possible to ensure native code, when ran in the browser, can’t cause harm to user’s machine." This stops being true as soon as you allow access to APIs like OpenGL ES. As soon as you're allowing the application to interact with the GPU, a whole new category of security holes are now possible. Native Client is still pretty cool, though :) Minor nitpick: “With a specially massaged compiler, some runtime support and careful native code validation it is possible to ensure native code, when ran in the browser, can’t cause harm to user’s machine.” This stops being true as soon as you allow access to APIs like OpenGL ES. As soon as you’re allowing the application to interact with the GPU, a whole new category of security holes are now possible.

Native Client is still pretty cool, though :)

]]>
By: moo/2011/06/02/notes-on-native-client-pepper-plugin-api/#comment-5121 moo Fri, 03 Jun 2011 13:59:45 +0000

Aggressive compiler optimizations are becoming more of a problem for those trying to write secure code. Google “dangerous optimizations and the loss of causality” for some eye-opening examples. Also read everything on John Regehr’s blog.

]]>
By: FF/2011/06/02/notes-on-native-client-pepper-plugin-api/#comment-5095 FF Thu, 02 Jun 2011 21:17:50 +0000

Doom running on java script, ohh yeahhh thats 20 years old stuff running now with 20 FPS…
Thats what I call “Back to the Future…”

]]>
By: Garett Bass/2011/06/02/notes-on-native-client-pepper-plugin-api/#comment-5092 Garett Bass Thu, 02 Jun 2011 20:32:28 +0000 That’s not exactly the same. C++ to Javascript cross-compiler means that your C++ code will run at Javascript speeds. Mandreel is not the only technology for such compilation, see Emscripten.

However, that still leaves you with a crazy big amout of Javascript code that takes forever to load, and tuns at least several times slower than C++. Yes, better than nothing, but hardly ideal solution.

Of course NaCl is Chrome only right now… However, I’d really like for others to adopt it as well. We’ll see how that goes.

]]>
By: Erwin Coumans/2011/06/02/notes-on-native-client-pepper-plugin-api/#comment-5090 Erwin Coumans Thu, 02 Jun 2011 20:25:10 +0000

]]>