- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sun, 28 Sep 2008 23:32:25 +1300
On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <lcamtuf at dione.cc> wrote: > other browsers are getting cross-domain XMLHttpRequest headers > Using the W3C Access Controls spec, which I am suggesting to reuse here. If you're not familiar with that spec, it's here: http://www.w3.org/TR/access-control/ Now consider that "I-Do-Not-Want-To-Be-Loaded-Across-Domains" is also > inherently incompatible with mashups, content separation, gadgets, etc, and > there is a very vocal group of proponents and promotors for these > technologies (which is why browser vendors are implementing cross-domain > XMLHttpRequest to begin with). So we would probably rather want to say > "I-Want-To-Be-Loaded-Only-By: <list_of_domains>". I'm suggesting just reusing the Access Controls spec for that. So for example, the server could say: Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes Access-Control-Allow-Origin: http://example.com If we do that, then we are not far from the (IMO half-baked) site security > policy concept. Some other person then adds several extra checks to prevent > XSRF on top of this, and you have a system indistinguishable from SSP ;-). I don't understand why you think that. SSP (now Content Security Policy; I hope we're both talking about this http://people.mozilla.org/~bsterne/content-security-policy/details.html ) is about using HTTP headers to constrain the behaviour of pages you serve. You can't use it to stop other random sites from loading resources from your server. Which is not to say much, just explaining why I made the leap. There would > probably be a temptation to come up with a coherent and unified design, > which may result in some bloat. I have to admit I haven't fully thought through my suggestion here. But so far I think by reusing Access Controls the "bloat" is minimal. > So what? The same goes for all your options --- slow browser migration >> delays the uptake of any client-side solution. >> > > Not really; minor versions usually have better uptake rates, thanks to > auto-updates, etc (it's far from perfect, but it's nowhere near the > estimated, if I recall published stats correctly, 20% of people still using > MSIE6 after a year of MSIE7?) - not to mention, not having a change shelved > until the next major version of a browser 2-4 years from now, means that > even with poor uptake, it would be broadly available sooner. There is no way in the world that Microsoft would implement your option 3 in a security update to IE6. Obviously I can't *prove* that but it's true. Microsoft is incredibly conservative in their maintenance updates to Trident. Your option 3 would definitely break the user experience in some sites, therefore they would not do it. Furthermore the invasive changes to layout, rendering and event handling would raise unacceptable risks of extra unintended regressions. Furthermore it would be a ton of engineering effort; you're talking about three different implementations (IE6-Trident, IE7-Trident, IE8-whatever-the-new-engine-is-called) and two of them in basically dead codebases. Look at it this way ... get a written commitment from Microsoft to ship some version of your option 3 in an IE6 update, and I promise to implement it in Firefox myself :-). Complex changes often get deferred, so any feature that is easy to smuggle > in a minor version is probably better than a feature that needs to wait for > MSIE 9, Firefox 4 (now, #3 is still considerably cheaper than a fully-blown > SSP). > You don't need a fully-blown SSP. However, even implementing all the features in http://people.mozilla.org/~bsterne/content-security-policy/details.htmlseems more palatable to me than implementing your option 3. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080928/b40cee17/attachment.htm>
Received on Sunday, 28 September 2008 03:32:25 UTC