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

so previous experience (pending a kind benchmarking volunteer) suggests that
there absolutely *is* a noticeable difference to the user...  which would
mean that a reader of the document might either: a) ignore this BP as
impractical for them; or b) implement it and never learn why their
application is so sluggish; or c) implement it and later discover that their
application runs much better when they substitute eval... (none of these
seem desirable).

so our options are:

a) return to a more nuanced wording (The regexp supplied is very useful,
thanks Rotan).

b) remain silent on the whole issue.

c) leave the BP as is.

I guess I favour (a), and will lean in the direction of favouring parsing in
the light of the sentiment on this thread... Though it would be still
helpful to do some updated benchmarking --- ?

adam.

On Tue, May 19, 2009 at 7:26 PM, Rotan Hanrahan <
rotan.hanrahan@mobileaware.com> wrote:

>  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 + ')');
>
>
> ---Rotan.
>
> [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...
>
> well
> 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?
>
> jeffs
>
> --
> "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
> http://www.it.rit.edu/~jxs/ <http://www.it.rit.edu/%7Ejxs/>http://ariadne.iz.net/~jeffs/ <http://ariadne.iz.net/%7Ejeffs/>http://chw.rit.edu/blog/http://ariadne.iz.net/~jeffs/jeffs.asc <http://ariadne.iz.net/%7Ejeffs/jeffs.asc>http://www.it.rit.edu/~jxs/emailDisclaimer.html <http://www.it.rit.edu/%7Ejxs/emailDisclaimer.html>
>
>