Linked by Thom Holwerda on Fri 14th May 2010 18:28 UTC
Google "Today, we're happy to make available a developer preview of the Native Client SDK - an important first step in making Native Client more accessible as a tool for developing real web applications. When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes."
Permalink for comment 424488
To read all comments associated with this story, please click here.
RE: Comment by Kilogramm
by ssokolow on Fri 14th May 2010 21:05 UTC in reply to "Comment by Kilogramm"
Member since:

ActiveX was completely un-sandboxed. That's why it was such a horrible mistake.

There are two working approaches to the problem of native code in the browser:

1. Don't let sites push native code to you and let them pick what functionality they want, not what specific code they want. (This is how NPAPI and Konqueror's KParts-based plugin API work)

2. Let sites push you stuff, but sandbox it. (This is how Flash, Java Applets, and Native Client work, though Native Client is the first to try it with native machine code)

Native Client focuses more heavily on designing a failsafe sandbox than Flash and Java though, since the potential harm from a breach is higher. (It also helps that Native Client can just reuse existing libraries rather than having to cook up a new set the way Flash and Java did)

Edited 2010-05-14 21:18 UTC

Reply Parent Score: 2