Google Native Client
Software entity
Uses Google Native Client sandbox to run a game on a web browser via C-like compiled code instead of being limited by things like Javascript and HTML5.
17
games
4platforms
Alternate name: NaCl
Currently only Chromium (Google Chrome) supports NaCl. Mozilla (Firefox) has no intention of supporting it, rather advocating pure web applications (via HTML5, JavaScript, and such), having culminated that ideology in Mozilla Prism project, though this does not preclude third-party NaCl plugins for Mozilla browsers. Opera seems to share this refusal with Mozilla (comparing it to the much older ActiveX by Microsoft and claiming it shares the same problems). It is unknown if Safari or Internet Explorer are going to support it.
NaCl, much like Java, runs via a browser through <embed> tag. This imposes some limitations as the browser functions as a minor layer in how the game can operate in terms of presentation.
NaCl creates a 'sandbox' within you computer and lets the game use it directly for the most part, introducing various restrictions in the code as well as preventing most system calls (OS specific code) and other operations deemed unsafe. Memory, file system and generally hardware access is severely limited within the sandbox, preventing (most) tampering with the actual system. Thanks to NaCl API developers don't need to be too concerned about Mac, Windows, Linux, or Android. All games run through a decompiler and validator before they're executed to make sure they don't try to break out of the sandbox.
This is by no means new, done before with things such as ActiveX. Its just been avoided due to the security concerns of letting web games run willy-nilly on a computer poking their data wherever they please and grabbing any information from your computer that it fancies. It is a huge security risk, the difference is the 'sandbox'. The game has access to much of your computer's resources, but only within the boundaries set by the NaCl sandbox. Any worms, viruses, or malware sneaking in with a NaCl game are constrained within the sandbox.
Portable NaCl (PNaCl) is being developed which removes the need to compile separately for x86, x86-64 and ARM by using intermediate bytecode instead of pre-compiled native code, much like other run-time environments do.
NaCl creates a 'sandbox' within you computer and lets the game use it directly for the most part, introducing various restrictions in the code as well as preventing most system calls (OS specific code) and other operations deemed unsafe. Memory, file system and generally hardware access is severely limited within the sandbox, preventing (most) tampering with the actual system. Thanks to NaCl API developers don't need to be too concerned about Mac, Windows, Linux, or Android. All games run through a decompiler and validator before they're executed to make sure they don't try to break out of the sandbox.
This is by no means new, done before with things such as ActiveX. Its just been avoided due to the security concerns of letting web games run willy-nilly on a computer poking their data wherever they please and grabbing any information from your computer that it fancies. It is a huge security risk, the difference is the 'sandbox'. The game has access to much of your computer's resources, but only within the boundaries set by the NaCl sandbox. Any worms, viruses, or malware sneaking in with a NaCl game are constrained within the sandbox.
Portable NaCl (PNaCl) is being developed which removes the need to compile separately for x86, x86-64 and ARM by using intermediate bytecode instead of pre-compiled native code, much like other run-time environments do.
Popular tags
actionadventure bink browser depthoffield download godgame mmog nonnative towerdefense ubuntu unity-engineParent groups
Games by year
The first Google Native Client video game was released on August 11, 2011.
Ubisoft, Fire Hose Games and Angry Mob Games published most of these games.
