I've now posted another set of numbers (on the same page) which make a lot more sense.
Pete Gontier <http://pete.gontier.org/> On Oct 19, 2008, at 10:22 PM, Pete Gontier wrote: > 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 -~----------~----~----~----~------~----~------~--~---
