On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:

> On Wed, Aug 28, 2013 at 10:19 AM, Allen Wirfs-Brock <allen at 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







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130829/5daa45ae/attachment.html>

On Aug 29, 2013, at 10:51 AM, Kevin Reid wrote:

> 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:

```js
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.