- From: Tyler Close <tyler.close@gmail.com>
- Date: Tue, 7 Apr 2009 17:55:34 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps@w3.org
On Tue, Apr 7, 2009 at 5:29 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Apr 7, 2009 at 4:16 PM, Tyler Close <tyler.close@gmail.com> wrote: >> On Tue, Apr 7, 2009 at 3:57 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> My point is that having two APIs that are identical and intended to be >>> used for basically the same thing, except for that they use different >>> security models, is a security bug waiting to happen. >> >> So you do of course realize that this is exactly what the WG is >> currently proposing, right? Browser version X will have an XHR with >> one security model and browser version X+1 will have an identical XHR >> API with a different security model. > > But it's for a limited time. In a few years hopefully all browsers > supports cross site XHR. So, in your words, for "a few years" we have "a security bug waiting to happen"? I'm also skeptical that it's just a few years, since it's not just the browser upgrade cycle, but the web-application upgrade cycle. By definition, all the XHR code out there today is written to a different security model than the one this WG proposes. This WG further proposes to substitute its more liberal security model, without opt-in from the existing application code. > You are proposing a model where there's two types of XHR objects. One > where we specifically tell users that you can rely on the request > won't be sent cross site, and one where you can't. I'm proposing that we leave the existing security model in place and provide a switch that applications must flip in order to swap in the new security model. I've proposed a design where flipping this switch requires minimal changes to existing application code. There's nothing radical about this proposal, it's just the way things are done when you're being careful. --Tyler
Received on Wednesday, 8 April 2009 00:56:13 UTC