This evening, I integrated Crockford's JSON codec and collected a few numbers regarding its performance. I thought folks here might be interested in the results.
http://partcounter.blogspot.com/2008/10/debut-json.html Pete Gontier <http://pete.gontier.org/> On Oct 9, 2008, at 6:06 PM, Pete Gontier wrote: > I don't (yet) have an opinion on the relative merits of different > alternatives, but likewise I am perfectly willing to entertain the > possibility that eval should be ignored when untrusted data sources > are involved. I think the smart way to go, as another poster > mentioned, is to measure the alternatives to see if they have > significant disadvantages, and, if so, each developer can design > accordingly. > > Pete Gontier <http://pete.gontier.org/> > > P.S. Encryption does not imply trust. Identity might. > > > On Oct 9, 2008, at 2:02 AM, Simon Ask Ulsnes wrote: > >> >> Oh, I'm all for using JavaScript anywhere and all over the place! >> Especially now we have such an excellent interpreter for it. >> >> Data source trust issues are important to consider. It is, however, >> fairly irrelevant to the original criticism, which was related to the >> performance of parsing JSON structures using eval() in V8. >> >> Using eval() is always dangerous. But I fail to see the need for an >> external parser just for JSON. If you are exchanging data with an >> external source over an unencrypted connection, then yes, using >> eval() >> is a critical bug. But there are other ways. >> >> For instance, it would be fairly simple to implement an evalJSON() >> method that rejects all function calls. To obtain production-ready >> security, you probably need more than that, but I'm just throwing >> examples out there. >> >> - Simon >> >> 2008/10/9 David Champion <[EMAIL PROTECTED]>: >>> >>>>> It's not just for server-side JavaScript. There are any number of >>>>> conditions where an interpreter might parse JSON from an unknown >>>>> or >>>>> untrusted source. >>>> >>>> Can you mention an example or two? I'm interested, because I >>>> couldn't >>>> think of other examples. :-) >>> >>> I'll incorporate what Pete Gontier said by reference, then add that >>> you seem to be thinking of V8 only in terms of its role in Google >>> Chrome. Once you begin to think of it simply as an embeddable >>> ECMA-262 >>> implementation, the possibilities for this situation are endless. >>> >>> * People are talking about V8 as a scripting engine for games. >>> Consider >>> downloadable skins, extensions, modules, etc for such a game which >>> might >>> store certain data in JSON object files. >>> >>> * JavaScript could be a platform implementation language for >>> components >>> in any web application framework; JSON data might be loaded from >>> any data provision source (with or without an HTTP proxy involved). >>> Imagine, say, an analysis engine for electoral data which allows the >>> user to point the applicaton to any source of data accessible by the >>> browser. It need not necessarily be a browser (i.e., application >>> hosting platform) that provides standard XSS privilege limitations. >>> >>> * I might develop a GPS interface program that downloads tracking >>> data >>> from my GPS device and stores it in JSON format. Some visualization >>> product using V8 JavaScript as an internal implementation language >>> loads >>> that data and does something clever with it. >>> >>> I don't know, I just made those up off the top of my head. Keep >>> going, >>> it's easy once you stop thinking of JS as an exclusive property of >>> web >>> browsers. :) >>> >>> -- >>> -D. [EMAIL PROTECTED] NSIT University of Chicago >>> >>>> >>> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
