485645 - Write a web-tech blog post about making JS object/array literals not call user-defined setters

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

I've been working on a web-tech post for a bit about how we made JS like |var x = { foo: 3 }| not call any setters which might be defined on Object.prototype as XSS prevention and general sanity technique.  Here's what I have so far; thoughts, comments, etc. before I post it?

Comment 1

[Jeff Walden [:Waldo]]

Oh, the current working title is:

Object and array literals are conceptually data, not code, so let's make it so

which works but is kinda rather horrible.  Thoughts on a better title also appreciated.

Comment 2

[Brendan Eich [:brendan]]

ES3 calls these things initialisers (Ecma uses British spelling in its specs), not literals. They are not produced by the Literal non-terminal in the grammar. So I think it's best to write "array initialiser" and "object initialiser".

The "conceptually data, not code" words aren't true for initialisers of the form

var obj = { foo: bar() + baz() };

which is perfectly fine JS, just not JSON. I suggest being precise in title and elsewhere. Something like "Object and array initialisers now safe from property setter attacks". How's that grab you?

/be

Comment 3

[Jeff Walden [:Waldo]]

Attachment: v2

(In reply to comment #2)
> ES3 calls these things initialisers (Ecma uses British spelling in its specs),
> not literals. They are not produced by the Literal non-terminal in the grammar.
> So I think it's best to write "array initialiser" and "object initialiser".

I don't mind changing to be closer to the spec, but this isn't written for an audience that reads the spec.  The spec term works as well, modulo the incorrect spelling, so "initializer" it is.

> The "conceptually data, not code" words aren't true for initialisers of the
> form
> 
> var obj = { foo: bar() + baz() };

There was an implicit assumption that the topic was JSON-y objects and not generalized object literals with side-effect-ful property value expressions, but I modified the language to make it clearer the issue lies in the implicit setting.

> Something like "Object and array initialisers now safe from property
> setter attacks". How's that grab you?

I primarily take the CSRF view that sites should check for the presence of an unforgeable header when returning sensitive JSON data (or some similar defense against cross-site script sourcing), so I would prefer to avoid phrasings that emphasize that this functionality change prevents attacks.  Not without reason do I lead in noting the solution by saying current behavior goes against developer expectations.  How about this alternative?

Object and array initializers should not invoke setters when evaluated

Comment 4

[Jeff Walden [:Waldo]]

I randomly had the feeling Joe might be interested in reading/commenting on this, of course no idea whatsoever why I might have had that feeling... ;-)

Comment 5

[Jeff Walden [:Waldo]]

Comment on attachment 369851 [details]
v2

Comments from others still welcome, just want to reach some sort of resolution on the comments I *do* have already...

Comment 6

[Brendan Eich [:brendan]]

Comment on attachment 369851 [details]
v2

I would change <strike>feature</strike>bug to "characteristic" and avoid picking fights. It really is well-motivated that JSON is a subset of JS (and of Python). It also has a sharp edge toward self.

The blame paragraph at the end is also a bit off in tone. In particular, cross-site script loading is a foundational element of pre-Google advertizing on the Web! How could we not have it? :-P

Suggest losing the blame paragraph altogether.

/be

Comment 7

[Jeff Walden [:Waldo]]

(In reply to comment #6)

I made those changes, semi-reluctantly (still think given the obvious affordance that JSON being nearly JS is a mistake) but probably for the best, and added a sentence to the new last paragraph to better close out the article.

https://developer.mozilla.org/web-tech/2009/04/29/object-and-array-initializers-should-not-invoke-setters-when-evaluated/

Done!

Comment 8

[Brendan Eich [:brendan]]

Comment on attachment 369851 [details]
v2

Forgot to note r+ with comments.

/be