- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 14 Apr 2008 19:17:39 +0200
- To: Kris Zyp <kris@sitepen.com>
- Cc: public-appformats@w3.org, "Web API WG (public)" <public-webapi@w3.org>, Jon Ferraiolo <jferrai@us.ibm.com>, "Close, Tyler J." <tyler.close@hp.com>, Chris Wilson <Chris.Wilson@microsoft.com>, David Ross <dross@windows.microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, Laurens Holst <lholst@students.cs.uu.nl>, Marc Silbey <marcsil@windows.microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Nikhil Kothari <nikhilko@microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Sunava Dutta <sunavad@windows.microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>
On 2008-04-14 10:59:27 -0600, Kris Zyp wrote: > AFAIK, Crockford's json.js library is effective in validating > javascript such that JSON data can be properly executed without > allowing arbitrary code execution. In addition, I would be > surprised if we don't see native JSON evaluaters in browers in > the next rev of browsers. Therefore, I don't think is a problem. > We have effective means for safely parsing JSON data, as long as > we have a mechanism for loading the text. The question is whether people are going to use these kinds of interfaces. If badly set defaults like the ones in the prototype.js JavaScript framework, the kind of code that's found all over the place in dashboard widgets, and the kind of howtos that are common online are any predictor of future behavior, then an API that just gives developers a string when they want structured data *is* going to keep the issues around. http://www.prototypejs.org/api/string#method-evaljson BTW, even json.org still presents eval as the first choice -- of course with some remarks about competent and trustworty data sources, but with an overall relatively weak admonishment. In any event, that's a side track. The point is that the XDR API will lead lots of Web developers down the slippery slope when that's simply unnecessary. > That being said, I would love to see XHR2 include an additional property > getter for "responseJSON" that provided access to safely natively parsed > JSON. It is kind of silly that XHR provides responseXML, when most modern > devs are using JSON. I don't know whether "most modern devs are using JSON", and I am not a hugesx fan of it as a format, but actually agree that it's common enough (and a common enough source of troubles) that it warrants attention in APIs. More generically, I don't think that new cross-origin APIs that "just return a string" (but are clearly intended for structured data) should be standardized (or shipped) given the experience that's available. Regards, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Monday, 14 April 2008 17:18:11 UTC