6 ms·
Chromium Blog: A sneak peek at the Native Client SDK
- nissimk 16y agoHow does this differ from ActiveX controls in IE, aside from being cross platform?
- wmf 16y agoNaCl is sandboxed; ActiveX is not.
- nissimk 16y agoWill it work in non-chromium browsers?
- stuntmouse 16y agoIt is open source, and could be adapted by any browser, AFAIK.
- Androsynth 16y agoThere was a FF plugin that was included in the research bundle. (although it never worked for me)
- briansmith 16y agoActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl seems to leave no way to get out of the sandbox. I think Microsoft could easily add something very similar to NaCl to ActiveX, and then create a distinction in the UI between these sandboxed plugins and the current kind. Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox. There are some things they can do to reduce some of the default restrictions, but the most important ones always remain in place.
- stuntmouse 16y agoHow does ActiveX sandboxing work? As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...
- briansmith 16y agoAFAIK, there is no "ActiveX sandboxing" per se. It is the same as the sandboxing techniques that are available to all Windows executables. But, also Internet Explorer runs in "Protected Mode" by default, so many of these sandboxing techniques get applied--by default--to plugins. See http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx.
- stuntmouse 16y agoVery informative link. Thank you.
- stuntmouse 16y agoThis looks impressive for systems that are supported (Vista and up). I'm not entirely convinced that all attack vectors have been considered though. They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior. But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it. It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action. I must admit I am behind the times with regards to Windows system programming.
- briansmith 16y agoYes, one advantage of Chrome's system is that it can be more restrictive than the operating system. And, the pre-scanning is an extra line of defense. I won't attempt to explain the integrity system in Windows because I am not that familiar with it. But, Wikipedia says that read access can be blocked based on integrity level too. See http://en.wikipedia.org/wiki/Mandatory_Integrity_Control http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
- tptacek 16y agoActiveX itself isn't sandboxed, but modern IE (and it's plugin hosting environment) is. Your comment is misleading.
- wmf 16y agoYou're right; I should have said "ActiveX ca. 2000 when I and everyone else gave up on it". If MS has fixed the implementation maybe they should change the name, because the ActiveX brand is irredeemable.
- andreyf 16y agoNaCl hosts hacking contests asking people to break their sandbox: http://code.google.com/contests/nativeclient-security/ http://code.google.com/contests/nativeclient-security/ ActiveX asked users "are you sure you want to run this native code?".
- briansmith 16y agoWhat would be the difference if Microsoft disabled the prompts for ActiveX controls?
- tptacek 16y agoActiveX has no verifier.
- JeffJenkins 16y agoTo what degree does "Embrace and Extend" apply to what Google is doing?
- stuntmouse 16y agoThat's pretty vague. How does it apply to this situation? The code is open; part of the NaCL API is designed around Posix/Linux; the Plugin API is the familiar NPAPI and its extensions. Which part is proprietary or controlled by Google? To my mind, some more relevant questions are: Does this tie the web to x86 (and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can multiple implementations be made secure?
- papachito 16y ago> Can it be adapted securely to x86-64? FTA: "a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"
- stuntmouse 16y agoDone right, this will change the world. I'm currently working on porting an emulator. The major sticking point so far is the audio API, which seems rather primitive, but should be sufficient for my needs.
- equark 16y agoThis looks horrendous. Watch the video for the hello world example. It's probably 100 lines of unintelligible code. Miguel de Icaza's CLI for the web idea (http://tirania.org/blog/archive/2010/May-03.html http://tirania.org/blog/archive/2010/May-03.html) looks like a much better approach.
- valisystem 16y agoYou just have to port your CLI to native client and it's done, the ugly code is wrote once and then shared.
- weavejester 16y agoIt doesn't really matter that the code is unintelligible. One can use higher-level languages on top. What isn't so good is that NaCl targets the architecture of the host machine. So you're not going to be able to run a NaCl app compiled on x86 on a browser running under ARM. Someone please correct me if I'm wrong. Miguel suggesting CLI isn't exactly surprising ;), but personally I'd prefer to use a sandboxed VM based on LLVM. CLI makes too many assumptions about the architecture of your language, whilst LLVM is more low-level.
- nimrody 16y agoRegarding LLVM -- See the comment about PNaCl (Portable Native Code Client). This is portable code based on LLVM intermediate representation.
- Detrus 16y agoYou can compile your binary for multiple architectures, check the type of processor and give it the appropriate binary. They also have the LLVM option so that old binaries keep working on new architectures without recompiling and rewriting NaCl for them, but it has downsides http://blog.chromium.org/2010/03/native-client-and-web-portability.html http://blog.chromium.org/2010/03/native-client-and-web-porta... The reason they didn't go with LLVM as the main approach was performance. Google wants there to be no distinction between desktop and web apps, and for web apps to have even 60% of desktop performance is still unacceptable. 90+% is more like it.
- aidenn0 16y agoIt seems to me that while this would have been interesting a few years ago, it's tied to x86 just as people are starting to browse the web more and more on mobile devices.
- wmf 16y agoPNaCl is "write once, run on x86 and ARM". http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
- papachito 16y agoFTA: "The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"
- kixxauth 16y agoBrowsers are going to be getting closer and closer to the metal all the time. That's what this is telling us. It's like 1991 all over again.
- andywood 16y agoRight. And in 1991, applications achieved much more of the potential performance and capability due to the available hardware than web apps do today. So going back to 1991 is an improvement in that respect. The rise of the web has been a trade-off - well-known and significant benefits have been realized, but at the cost of devolution and dead-ends in areas like the developer experience and UI flexibility. (As an example, think about all the reasons why World of Warcraft is not a web app.)
- pinhead 16y agoAlso pretty interesting if you haven't read it (PDF): http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf http://nativeclient.googlecode.com/svn/data/docs_tarball/nac...