On Thu, Nov 3, 2011 at 2:10 PM, John J Barton <johnjbar...@johnjbarton.com>wrote:
> On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem <tomvc...@gmail.com> > wrote: > >. Also, I heartily recommend the talks to > > those not entirely convinced of the necessity of private/const/frozen > > features. Mark makes a pretty good case for encapsulation as a necessary > > building block for ocap-based security > > If I understood Mark correctly, the features needed for SES are > already part of ES.5 and are shipping in browsers That is correct. Any browser on which < http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html> passes, which includes Chrome 16, FF Nightly 10, and WebKit Nightly r98831. Opera 12 alpha build 1116 and IE 10 preview 2 both fall short by only one bug that both teams are aware of and that test262 tests for, so I expect/hope the release of both will also be adequate. > (and hence don't bear upon future features). Did I misunderstand? These do bear on future features in three ways: 1) Future features could easily destroy all the security gains that ES5 achieved. As an example, for a long time it wasn't clear -- to me at least -- how "freeze" should affect the ability to mutate hidden own properties, i.e., own properties named by "private names". The two obvious answers are a) hidden own properties are treated just like normal own properties -- "freeze" makes them non-configurable and (if data) non-writable b) hidden own properties are completely exempt from the constraints imposed by "freeze". However, both of these answers would decrease rather than increase security. Further, #b introduces a capability leak, and so would be fatal for SES. The answer we settled on at the last meeting is c) hidden own properties that already exist are exempt from "freeze" and "seal" constraints. However, once an object is non-extensible (whether by "freeze", "seal", or "preventExtensions"), then new hidden own properties cannot be added to it. 2) The notorious Ch16 exemptions as stated in ES5.1 < http://es5.github.com/#x16>, renders all security reasoning necessarily unsound. For example, an implementation that introduced a non-configurable ambient method for deleting all the user's files would still be considered conformant. Going forward, we should make at least < http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable> normative. Beyond this, we need to understand what is the least additional Ch16 reform needed to enable security reasoning to be sound. 3) Although SES is *formally* an object-capability language, i.e., it has all the formal properties required by the object-capability model, it has bad usability properties for writing defensive abstractions, and therefore bad usability properties for use as an object-capability language or for serious software engineering. One example: In a SES environment, or, for present purposes, an ES5/strict environment in which all primordial built-in objects are transitively frozen, say Alice uses the following abstraction: function makeTable() { var array = []; return Object.freeze({ add: function(v) { array.push(v); }, store: function(i, v) { array[i] = v; }, get: function(i) { return array[i]; } }); } Say she uses it to make a "table" instance with three methods: add, store, and get. She gives this instance to Bob. Alice and Bob are mutually suspicious. All of us as programmers, looking at this code, can tell that Alice intended the table abstraction to encapsulate the array. Given just a table instance, can Bob nevertheless obtain direct access to the underlying array? If you've already seen this puzzle and know the answer, please don't post. If no one else has posted the correct answer in 24 hours, I will. Note that I don't see any realistic way to fix problem #3 in the ES.next language. My point is only that defensive programming is tricky even after you've gotten all the formal properties you need. As ES.next introduces various new abstraction mechanisms, whether classes, enhanced object literals, proxies, modules, or private names, the design of these can either help or hurt those attempting to write defensive abstractions. Any class abstraction that is only useful for making indefensible instances is worse than useless -- it is actively harmful, both to security and to serious software engineering. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
