On Tue, Oct 18, 2016, 12:01 Richard Gibson <richard.gib...@gmail.com> wrote:
> On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <isiahmead...@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.
I'll also mention that the JSON website does claim to be "based on" a
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 <richard.gib...@gmail.com>
> 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 §220.127.116.11
> 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