On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:
> On Wed, Aug 28, 2013 at 10:19 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>
> wrote:
> The problem is that in ES<6 slice always returned a new Array instance using
> the Array of the realm associated with the invoked slice function. In ES6
> slice returns an object that is determine based upon the actual this value
> passed to slice. In the default case like above, this will be the a new
> Array instance using the Array of the realm associated with the this value.
>
> !
>
> This is a hazardous change for SES-style security. For example, I've just
> taken a quick look at our (Caja) codebase and found a place where
> Array.prototype.slice.call(foo) is used to obtain a “no funny business” array
> (i.e. doesn't have side effects when you read it) and another where it's used
> to obtain an array which must be in the caller's realm. These would be easy
> enough to replace with a more explicit operation, but I wanted to point out
> that this is not a harmless change.
In the Array.prototype.slice.call(foo) use case what is foo? Is it known to be
an Array? Are you saying this is how you clone an Array?
For you second use case, that sounds like it is contrary to what is implicitly
assume by ES5. For ES5, every built-in is assume to be associated with a realm
when it is created and any references to built-ins by a built-in are assume to
use the same realm as the referencing built-in. So something like:
var newArray = slice.call( [ ] );
in ES5, should return a new Array instances based upon the same Realm as the
slice function that was invoked. It is not necessarily the same as the
caller's realm.
Array literals are guaranteed to be create an array instance in the same realm
as the code that evaluates the literal.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
