[whatwg] Native JSON parsing API

[Adam Barth]

On Tue, Feb 12, 2008 at 5:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> Passing objects, or arrays of strings, arrays, or objects, is more
> complex, but as you point out, it can be done using JSON libraries. Since
> it is likely that JSON will be supported natively by UAs in due course, it
> seems better to wait for that support rather than adding type support to
> postMessage().

HTML 5 should expose a native JSON parser for web content.

Web content often wishes to translate strings into structured data.
For example, to send structured data via postMessage, content often
serializes the structured data into a string and expects the recipient
to deserialize the string.

For example, Facebook Chat is currently implemented using postMessage.
 Two frames from facebook.com communicate with each other by passing
JSON-serialized objects.  Upon receiving a message, a frame validates
the origin property of the message event and then calls eval() on the
received data to deserialize the message.  Some time ago, their
validation code had a bug and accepted any origin that ended in
"facebook.com" including "http://evilfacebook.com", leading to XSS.
Had the browser provided a native JSON parser as fast (or faster) than
eval(), this bug might not have been as critical.

JavaScript libraries, such as those available from <http://json.org/>,
exist for parsing JSON, but these libraries have limitations.
Libraries implemented without calling eval() are slow because
JavaScript string manipulation is not as fast as a native parser.
Libraries that eventually call eval() tend to validate their input via
regular expressions, but these implementations have had a history of
validation vulnerabilities.  A native JSON parser in browsers would
enjoy the security of a dedicated parser and the performance of a
native parser.

There appears to be some amount of vendor interest in implementing a
native JSON parser.  For example, Firefox 3 implements a native JSON
parser <http://developer.mozilla.org/en/docs/nsIJSON>, but only for
privileged JavaScript.  The JSON format itself is already specified.
What remains to be specified is a standard location for the serialize
and deserialize methods.

Adam

(Apologies if this has already been raised on this list.  I looked
through the issue tracker but couldn't find it there.)