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/]

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 <jferrai@us.ibm.com> wrote:  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
 >