Pseudo-JSON with unquoted property names

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Jun 5 15:57:39 PDT 2009


Brendan Eich wrote:
> Thanks very much. Not very ha-ha funny, but I LOLed at points ;-).
> 
> These seem old enough (two years), and otherwise flaky enough, to reject
> as strong precedent.

Only the Ruby on Rails example is two years old.
<http://www.uize.com/reference/uize.json.html#2_2_7> and
<http://simile.mit.edu/wiki/Exhibit/Creating,_Importing,_and_Managing_Data>
are current.

Also, this is just what I found in a few minutes of Googling for cases
that were easy to search for. There's obviously no way to do a simple
web search for applications of JSON that just work at the moment with
parsers that accept unquoted names, but *would* fail with a stricter parser.

It's a bit odd that we are on different sides of the argument than usual,
with me emphasizing the risk of incompatibility even with relatively
sparse evidence. Actually this is just my usual emphasis on security:
my main concern is that if the JSON API doesn't work for a developer who
has to parse a given source of JSON, they will fall back to using eval --
or not switch from using eval to using the JSON API.

Accepting unquoted names is pretty harmless from a security point of view,
and does not add signficant specification or implementation complexity
(because an ES5 implementation must already be able to parse
IdentifierNames), whereas using eval is likely to open up, or miss an
opportunity to fix, significant XSS vulnerabilities. Also, I am with
MarkM and the Caja project in not trusting implementations that do
filtering using a regexp, followed by eval.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



More information about the es5-discuss mailing list