Feature Request: Make ECMA262 a superset of JSON

Isiah Meadows isiahmeadows at gmail.com
Tue Oct 18 12:57:29 UTC 2016

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.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.

> On Fri, Sep 30, 2016 at 2:43 AM, Claude Pache <claude.pache at 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.gibson at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161018/f7bbdcfa/attachment.html>

More information about the es-discuss mailing list