Thank you, this was a very helpful clarification.
Do webservers today default to rejecting requests that contain the extra
JSONRequest header? That's effectively what you need to preserve the same
restrictions that are expected today.
Brad
Jon Ferraiolo <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] 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
>
