Inline. On Tue, Oct 18, 2016, 12:01 Richard Gibson <[email protected]> wrote:
> On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <[email protected]> > 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 > <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 subset (the JavaScript object literal syntax), but there is a subtle distinction. 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 <[email protected]> > 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 > <https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers> > uses > *propKey*, which step 1 defines as "the result of evaluating > *PropertyName*", and evaluation of *LiteralPropertyName* in §12.2.6.7 > <https://tc39.github.io/ecma262/#sec-object-initializer-runtime-semantics-evaluation> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
