On Tue, Feb 2, 2010 at 9:20 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote: > I'm confused about the problem here.
See previous; hope that clarifies. > Here is where I think there's an important difference between the > style of isolation you want for different modules in the same software > product (maybe both written by me, but in separate areas of > functionality) and the style you want for really untrusted code, such > as code for ads on the web, or the program being edited in an editor, > or student programs in an auto-grader. As I argued previously, there does not exist a dichotomy of two extremes. There is a whole spectrum of possibilities, driven by both security and software engineering concerns. > For the latter, something much stronger is necessary - the code > shouldn't even be able to name the functionality that it shouldn't > get. But supporting the latter requires the sort of explicit > configuration that's a very hard sell in the general case, especially > for many of the use cases of EcmaScript. Fortunately, you provide a really good solution later on ... > Unfortunately, it's also really convenient. In an Emaker-style > language, libraries might develop the convention that everything takes > a free variable called 'dom', which gives access to the whole DOM. > That wouldn't be a good way to write secure code, but it would take > less thinking on the part of authors. There's nothing that's going to > force people to use the system in a secure way. ... and there it is! Libraries wishing to pass lots of authority may establish conventions whereby they arrange to do so. Libraries that need to pass less authority may also do so. And, crucially, a library that accepts the "dom" variable is known to have access to nothing *else*; nothing that could cause surprise later on. >> "Support a statically verifiable, object-capability secure subset." >> How does your proposal subset down this way? > > The same way that other scope and name management tools, such as > `function', do. The strawman provides a way to program without having > the mutable global object on the scope chain, and with lexical scope. Lexical scope whereby it is possible for any component downstream to "wormhole" through the authority graph by uttering the name of a module. In other words, with the surface syntax of lexical scope but foregoing its advantages in establishing division of authority (for security) and dependencies (for software engineering). > ... It also provides a name resolution mechanism, which resolves names to > bits of code - this is common to all of the proposals. Crucially, the 2nd class proposal resolves names to bits of code *and* shared mutable state with authority to affect the outside world. Ihab -- Ihab A.B. Awad, Palo Alto, CA _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
