Re: Are Jon's comments from IBM, the OAA, citizen Jon, ...? [Was: Re: Review of http://www.w3.org/TR/2007/WD-access-control-20071126/]

public-appformats-request@w3.org wrote on 01/09/2008 09:54:38 AM:

> > I believe there are a straightforward waysto extend JSONRequest to
> > accommodate XML in addition to JSON.
>
> I'd like to understand better what this mechanism might look like as
> I'm not sure I agree that you could extend it without doing
> something nearly equivalent to what the access-control specification
> requires.

One approach that I suggested in an earlier email was that the JSONRequest
implementation support XML by examining the content that comes back within
the HTTP response. If it is a JavaScript object (e.g., first non-whitespace
character is "{"), then parse it with a JSON parser. Otherwise, parse it
with an XML parser. In both cases, strict parsing is required. Invalid
content (e.g., executable JavaScript or markup that is not well-formed)
would produce an error. In both cases, the JSONRequest implementation
produces a JavaScript object to remove the temptation to do a JavaScript
eval() on the JSON content or innerHTML on the XML content.

>
> JSONRequest seems to be operating under the assumption that current
> browsers don't have access to any protected JSON data inside
> protected network zones.  This works because corporate IT
> departments aren't typically storing confidential information in
> JSON blobs sitting on their web-server.  The universe of existing
> JSON data that relies on existing protection mechanisms is small
> (and the protection mechanisms don't exist.)

I wouldn't say that exactly. I have heard of Enterprise companies using
JSON for large datasets because of the performance advantages, sometimes
with approvals required do the worry about using eval().

Existing JSON servers wouldn't work if JSONRequest is implemented properly
on the client because the server is required to add a new HTTP header that
sets the content type to application/jsonrequest. This is parallel to the
"opt-in" approach for Access Control. In both cases, something new has to
be done on the server for cross-domain access to work.

>
> The universe of existing XML data that needs protection is large and
> there are well-established protection mechanisms already in place
> that need to continue to work.

I agree, but I don't think either Access Control or JSONRequest impact
existing XML data because both require the server to be changed in order to
use either of the proposed new features.

> > 3) I have lots of concerns about Access Control as currently
formulated.
> > Others share these concerns, which seems likely to inhibit adoption if
the
> > spec stays as it is. If it does get adopted in its current form, I'm
not
> > sure how much the industry benefits from the new features and how much
it
> > will be harmed by the security issues and other costs.
> I have to admit I'm not clear at this point as to what "the security
> issues and other costs" you're referring to are.  I've seen an
> argument that you disagree with the process and that you disagree
> with the solution, but I'm missing what the security issues and
> costs that concern you with the solution as proposed are?

The main security worry is due to passing cookies, which opens up the
possibility of CSRF attacks. I described one such scenario in a previous
email.
http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0072.html

In terms of costs, I was referring to industry-wide cost/benefit analysis.
There are large industry-wide costs whenever a new technology is added to
the web world in terms of implemeentation within browsers, changes to web
servers to take advantage of the technology, and educational costs. I'm not
sure that Access Control as currently defined would benefit the industry
sufficiently to justify these costs.

>
> I'm trying to understand if you're saying "access-control is a bad
> idea for technical reason X and Y" or if you're just saying "this
> solution is a better solution" to which I'm trying to point out that
> enabling access to XML documents is a well-stated goal that
> JSONrequest doesn't seem to support and preserving the current
> border-protection security mechanisms that rely on browser
> sandboxing and are widely employed by most corporations is still
> necessary for the time-being.

Access Control isn't bad, but I don't like some of the ways that it is
designed today. I believe that policy enforcement belongs on the server,
not the client. I don't understand why there is a language for whitelisting
and blacklisting domains that are allowed and expect most people would use
either * (allow everyone) or allow other subdomains within their own
domain. I think it would be better if cookies were not transmitted to
domain B from a web site on domain A because of CSRF risks. Because of
these various issues, I'm not sure that Access Control as it is designed
today is a win for the industry.

Recent discussion has shined the light on JSONRequest as an alternative. I
have looked again at JSONRequest because of that discussion, and my
analysis it that it looks more attractive to me as the basis for allowing
cross-site access to data. One big advantage with JSONRequest is that it is
possible to deliver an implementation of it via JavaScript today, where the
implementation can look at the browser to see if JSONRequest is implemented
natively, and if not, then insert a dynamic script tag under the hood to
accomplish the same result. That means that if the community rallied around
JSONRequest as the right way forward, then they could start posting web
services that supported JSONRequest as soon as a JSONRequest JavaScript
library were made available. (Probably about 100 lines of JavaScript.) Kris
Zyp has a JavaScript implementation of JSONRequest at
http://code.google.com/p/crosssafe/. Access Control as currently designed,
on the other hand, can't be used on a broad basis until it ships with
high-marketshare browsers and large numbers of the communities upgrade to
those browsers.


>
> --Brad
>