W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2006

[whatwg] JSONRequest

From: Jim Ley <jim.ley@gmail.com>
Date: Sat, 11 Mar 2006 22:58:03 +0000
Message-ID: <851c8d310603111458j3c392d44y210e20448ce00054@mail.gmail.com>
On 3/11/06, Douglas Crockford <douglas at crockford.com> wrote:
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
>
> You can read about it here: http://json.org/JSONRequest.html

Unfortunately your security analysis is lacking some situations,
Indeed the statement

" It provides this highly valuable service while introducing no new
security vulnerabilities. "

is false, please remove it to avoid any confusion.

Accessing JSON resources on a local intranet which are secured by
nothing more than the requesting IP address.  Indeed you actually skip
over this pretending that there would only be legacy
data/documents/scripts available in such a situation, despite the
number of people who've been shipping such products for 6 years or
more.

In other non security areas, you don't define how the delay product is
reset - is it per window, per host, per instance?  That needs
defining.

The "not ok" needs to be refined to deal with proxy caches that may
return other codes, e.g. 304 or 206.

The Duplex claim is misleading, and you should specifically mention
that if you do use 2 connections, no other content would be
downloadable from the site in a conforming HTTP 1.1 implementation.

The cache rules are unworkable, please remove these and use standard
HTTP methods for suggesting the cacheability of a resource, forcing
them to be uncacheable is unworkable w.r.t. to proxy caches and
extremely unwelcome within the browser.

Most importantly is to actually make it safe to use.

cheers,

Jim.
Received on Saturday, 11 March 2006 14:58:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:45 UTC