<div dir="ltr">On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <span dir="ltr"><lcamtuf@dione.cc></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">other browsers are getting cross-domain XMLHttpRequest headers</div></blockquote><div><br>Using the W3C Access Controls spec, which I am suggesting to reuse here. If you're not familiar with that spec, it's here: <a href="http://www.w3.org/TR/access-control/">http://www.w3.org/TR/access-control/</a><br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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>".</blockquote>
<div><br>I'm suggesting just reusing the Access Controls spec for that.<br><br>So for example, the server could say:<br>Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes<br>Access-Control-Allow-Origin: <a href="http://example.com">http://example.com</a><br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 ;-).</blockquote>
<div><br>I don't understand why you think that. SSP (now Content Security Policy; I hope we're both talking about this <a href="http://people.mozilla.org/~bsterne/content-security-policy/details.html">http://people.mozilla.org/~bsterne/content-security-policy/details.html</a> ) 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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote>
<div><br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So what? The same goes for all your options --- slow browser migration delays the uptake of any client-side solution.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br>There is no way in the world that Microsoft would implement your option 3 in a security update to IE6.<br><br>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.<br>
<br>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 :-).<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>

</blockquote><div><br>You don't need a fully-blown SSP.<br><br>However, even implementing all the features in <a href="http://people.mozilla.org/~bsterne/content-security-policy/details.html">http://people.mozilla.org/~bsterne/content-security-policy/details.html</a> seems more palatable to me than implementing your option 3.<br>
<br></div></div>Rob<br>-- <br>"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]<br>

</div>