Feature Request: Make ECMA262 a superset of JSON

Richard Gibson richard.gibson at gmail.com
Tue Oct 18 16:01:00 UTC 2016

On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <isiahmeadows at gmail.com>

> I'll point out that encoding and evaluating JSON literally can easily
> become a potential security issue, anyways (consider if a user can encode
> `--></script>` in the relevant data). But you might have a point if you
> consider JSONP.

This feels like it's drifting a bit. I'm asserting that the "the
alternative definition of *DoubleStringCharacter*" required for JSON.parse
can in fact become the *only* definition of that production, retroactively
validating the currently-false claims in §24.3.1
<https://tc39.github.io/ecma262/#sec-json.parse> of JSON being a subset of
ECMAScript literals. U+2028 and U+2028 would still be line terminators for
purposes of ASI/line numbering/etc., but would be allowed unescaped in
string literals.

On Sun, Oct 16, 2016, 22:08 Richard Gibson <richard.gibson at gmail.com> wrote:
>> Allow me to clarify: permitting U+2028 and U+2029 in ECMAScript strings
>> would allow safely embedding arbitrary JSON in the precise sense that such
>> embeddings would always be syntactically valid and evaluatable Literal,
>> ArrayLiteral, or ObjectLiteral expressions. That is already true of
>> "__proto__" keys, even though their evaluation results in web browsers
>> don't exactly match JSON.parse.
> By the way, `"__proto__"` is intentionally different than `__proto__` to
> avoid a gaping security hole for those using objects as dictionaries
> (untrusted code causing prototypes to change is bad). The string version is
> no different from any other property, while the identifier version either
> gets or sets the prototype.

While irrelevant to the proposed change, that appears to be false (though
it would certainly be beneficial if true)—the special check for "__proto__"
in Step 5 of §B.3.1
*propKey*, which step 1 defines as "the result of evaluating *PropertyName*",
and evaluation of *LiteralPropertyName* in §
not preserve a distinction between *IdentifierName* and *StringLiteral*
forms in its result. I also observe equal treatment of quoted and unquoted
"__proto__" object literal properties in SpiderMonkey, V8, and Chakra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161018/8705e3dd/attachment-0001.html>

More information about the es-discuss mailing list