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.
On Sun, Oct 16, 2016, 22:08 Richard Gibson <richard.gib...@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. > On Fri, Sep 30, 2016 at 2:43 AM, Claude Pache <claude.pa...@gmail.com> > wrote: > > Besides U+2028 and U+2029, there is also the __proto__ key, which has a > special meaning in JS as implemented in browser. That prevents definitely > to "safely" embed arbitrary JSON within JS. > > —Claude > > Le 29 sept. 2016 à 23:21, Richard Gibson <richard.gib...@gmail.com> a > écrit : > > ECMAScript claims JSON as a subset twice in > https://tc39.github.io/ecma262/#sec-json.parse , but (as has been > well-documented) that is not true because it JSON strings can contain > unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR while > ECMAScript strings cannot. Mark Miller alludes to a pre-ES5 push for > allowing them (which ultimately failed) in > https://esdiscuss.org/topic/json-stringify-script#content-17 , and posits > that a repeat today would also fail. Having never seen a windmill that > didn't need slaying, I hereby make the attempt. > > Aside from slightly simplifying the spec (by eliminating the need for a > production specific to JSON.parse) and retroactively validating its claims, > such a change to _DoubleStringCharacter_ and _SingleStringCharacter_ would > allow safely embedding arbitrary JSON directly within ECMAScript, a request > which has been made before in the context of source > concatenation/construction. > > User-visible effects from the change would be limited to the absence of > SyntaxError s from code like `eval(' "\u2028" ')` or its raw-text > equivalent. > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
