Preliminary Community Review: text/json
Philippe Le Hegaret
plh at w3.org
Fri Feb 10 01:59:48 CET 2006
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
More information about the Ietf-types
mailing list