W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

RE: MWABP for discussion: JSON parsing vs eval benchmarking.

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Tue, 19 May 2009 19:26:45 +0100
To: Jeff Sonstein <jeffs@it.rit.edu>, Adam Connors <adamconnors@google.com>
Cc: <public-bpwg@w3.org>
Message-ID: <E3EFFA0D-E6C2-4E47-983E-5AF8A80B0D46@mimectl>
There are business cases where to knowingly permit a security weakness to exist, especially given there is a secure alternative, would be breaking contract, breaking standards and potentially illegal. Whatever is decided here, one must not give the impression that using the less secure option is a best practice when such circumstances pertain. Furthermore, unless the impact of the parser performance is noticeable to the user (or has some other serious consequence such as a rapid running down of the batteries), it may be better to just leave the guidance as "use a parser" rather than unnecessarily recommending a fragile approach, despite the computational efficiencies.

At a minimum, adopters of the eval() technique should at least heed the suggestion in section 6 of RFC 4627 [1] that recommends the following regex-based protection (subject to regex being properly implemented on the mobile browser):
      var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
             text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
         eval('(' + text + ')');


[1] http://tools.ietf.org/html/rfc4627

From: Jeff Sonstein
Sent: Tue 19/05/2009 12:56
To: Adam Connors
Cc: public-bpwg@w3.org
Subject: Re: MWABP for discussion: JSON parsing vs eval benchmarking.

On May 19, 2009, at 7:44 AM, public-bpwg@w3.org wrote:

> There is a BP in the MWABP which states you shouldn't directly  
> eval() JSON data but should use a JSON parser instead for security  
> reasons... We came to this point after a number of more nuanced  
> iterations. However, feedback from a colleague in the office who did  
> some benchmarking suggests that JSON parsing is approx. * 10 slower  
> than direct eval(). So... I don't think we can really make a BP that  
> would require an app to run * 10 slower than it has to...

it would just be the "get and parse remote data" part
which would run slower...
the rest of the app should not be effected
I would think

> I propose:
> * Would somebody please volunteer to verify this figure and see if  
> it is still true. It was true on iPhone 1 and the gap may have  
> narrowed in 2.x, Android, or other platforms...

someone who has other-than-iPhones avail
should probably do this

> * If the gap has narrowed we should keep things as they are and  
> offer some comment on relative performance eval vs json parsing.

even if the gap is that bad and has not narrowed
this still seems an appropriate thing to do

> * If the gap hasn't closed I propose that we change this BP to state  
> that the preferred option is to use eval() but only on trusted data

makes sense either way

do you have a link to a benchmark?


"By the time you swear you're his,
  Shivering and sighing,
  And he vows his passion is
  Infinite, undying -
  Lady, make a note of this:
  One of you is lying."
- Dorothy Parker -

Prof. Jeff Sonstein

Received on Tuesday, 19 May 2009 18:28:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC