Preliminary Community Review: text/json

[Philippe Le Hegaret]

It seems that it would be better for JSON to be in application rather
text. As the document says, it is a portable representation of
structured data, ie not meant for human consumption even if it happens
that a human can makes some sense from it. RFC 3023bis, if it sees the
day of light, will deprecate the use of text/xml for that same reason.

Philippe

On Thu, 2006-02-09 at 16:21 -0800, Douglas Crockford wrote:
> The section on Security Considerations addressed this directly.
> 
>    Security considerations:
> 
>       Generally there are security issues with scripting languages.
>       JSON is a subset of JavaScript, but it is a safe subset that
>       excludes assignment and invocation.
> 
>       A JSON text can be safely passed into JavaScript's eval()
>       function (which compiles and executes a string) if all of the
>       characters not enclosed in strings are in the set of characters
>       which form JSON tokens.  This can be quickly determined in
>       JavaScript with two regular expressions and calls to the test and
>       replace methods.
> 
>       var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
>              text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
>          eval('(' + text + ')');
> 
> 
> ----- Original Message ----
> From: Graham Klyne <GK at ninebynine.org>
> To: Douglas Crockford <douglas at crockford.com>
> Cc: ietf-types at iana.org
> Sent: Thursday, February 9, 2006 4:14:33 PM
> Subject: Re: Preliminary Community Review: text/json
> 
> Douglas Crockford wrote:
> > This is notice of a potential media type registration. 
> > The details may be found here:
> > 
> > http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-02.txt
> > 
> 
> I have some limited experience of using JSON with TurboGears, and I think this
> registration is useful and appropriate.  I haven't read the technical spec in
> great detail, but didn't see any major problems on cursory reading.
> 
> However, I think there is an important issue that is missing from the security
> considerations:
> 
> Because JSON is a subset of Javascript, and is sometimes used as a way of
> communicating information to Javascript programs, there is a possibility for
> implementers to simply treat the JSON expressions directly as Javascript source
> code (e.g. via Javascript eval()).  This is safe if the expression is known to
> conform the the JSON specification, but if this is not checked there is a
> possibility that executable code inject side effects into a running Javascript
> program.  Therefore, applications that receive JSON expressions need to ensure
> that they are processed in such a way that ill-formed expressions have no
> possibility of causing unexpected side effects or distorting the information
> that is displayed to users.
> 
> There is one other thing I noticed.  The proposed MIME type is text/json.  I
> think that, based on comments I have seen made previously, that application/json
> would be more appropriate.  My understanding is that text/... is intended for
> textual information that is suitable for display to a general human audience;
> e.g., it has been suggested that text/html was a mistake, which should not be
> repeated.
> 
> #g
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20060209/bdd16cab/attachment.bin