On Tue, Oct 18, 2016, 12:01 Richard Gibson <> wrote:

> On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <>
> wrote:
> 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
> <> 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.

I'll also mention that the JSON website does claim to be "based on" a
subset (the JavaScript object literal syntax), but there is a subtle

I'll admit my original statement was probably not fully on topic, though (I
was uncertain whether I should've said it or not).

> On Sun, Oct 16, 2016, 22:08 Richard Gibson <>
> 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
> <>
>  uses
> *propKey*, which step 1 defines as "the result of evaluating
> *PropertyName*", and evaluation of *LiteralPropertyName* in §
> <>
>  does
> 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.

I tested it myself earlier, and took back my initial statement in another
email, since I think someone else beat you to it (it's computed vs not).

es-discuss mailing list

Reply via email to