Chris,
Thanks for the email. A few points below:
>This message is not attempting to set forth in detail all the
objections we have had; Sunava will >deliver that in a concise form.
Can you give us a ballpark ETA on this?
>For example, today the current XHR draft proposes to block a list of
headers that are unsafe >only in a cross-domain context; however, this
is difficult to deploy since XHR has already >shipped, and challenging
to imagine that there are no other headers in use by servers anywhere
>around the world that might not be good to access.
Microsoft feedback on proposals such as
http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html
are welcome. Also, I'm not averse to discussing a restricted list of
headers that the XHR API *should* support rather than a block list.
>There are fundamental cross domain security principles that we firmly
believe need to be >guaranteed by a cross domain solution; otherwise,
our experience leads us to believe there will >be exploits found over
time. Cross-domain access in Flash has had a trail of bugs for these
>reasons [1]. Sunava will detail these security principles;
*In particular* what is the direct parallel you are drawing between the
Flash approach and the XHR2+AC approach? Sunava's commentary eagerly
awaited. In this message
http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html
you suggest we look at "DNS Hardening" for "clues." Can you be a bit
more specific here, if possible?
>Even if current vulnerabilities like exposure to Time of Check, Time
of Use, >DNS Rebinding >attacks, and URL path canonicalization issues
can be patched (rather than >ignored),
I think we ought to make spec. language and related docs. good for
server-side deployment of the Access-Control scheme as well, and
encourage good Web architecture. DNS Rebinding is a generally powerful
attack that creates a fair number of vulnerabilities outside the scope
of XHR+AC, and we should encourage servers to respect origin headers
and/or use TLS, but I'm still trying to figure out your notions of a
demonstrable vulnerability that is specific to our approach within XHR2+AC.
Regarding URL Canonicalization, a proposal to address URL
canonicalization problems by disabling Access-Control-Policy-Path:
http://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html
has been put on the table.
> For example, is there a blocklist of headers? If so, how will this be
maintained as the list of >discovered headers grows?
Again, feedback on an "acceptable headers to exchange" component of AC
is welcome. Also again: I'm not averse to discussion of using a
restricted list of headers in lieu of blocked ones, if you think that
will help.
>XDR is not intended to be a competitor >to XHR2+AC; it is different by
design, and is >focused on a much smaller set of cross-domain >access
needs.
<snip />
>I do want to be clear, since there was some confusion based on a
conversation between Charles >and Michael Champion – we will be shipping
our XDR implementation in IE8 (modified by >any fsafeedback we might get
before we must lock down for release). As we’ve said, we'd >welcome
feedback on XDR [18], and if it is timely enough, it could be
incorporated into our >IE8 product.
All things being equal, it is likely that XDR and XHR2+AC will co-exist,
and the major JS libraries can probably straddle the difference. Of
course, I'd prefer it if we had a single API that addressed the more
robust needs of web applications, including Cookies, etc. :)
But IE8 beta does support postMessage, just as other UAs do. And it
would seem that postMessage will be used for cross-site requests because
of the widespread support across UAs, modulo caller/callee understanding
across sites (e.g. there's likely to be a propagation of iframe-based
APIs which can be requested with Cookies, Auth, etc. and on which other
sites will call .postMessage). This would have well-known limitations.
Coming to the table and commenting on proposals will create better
solutions for developers.
>We will of course continue to participate in the Web API WG’s work on
cross-domain access, >and I hope that work can be made secure to our
satisfaction (and therefore implementable in >IE); but we simply cannot
implement APIs that we believe expose customers to security >exploits.
We desire interoperability; we cannot enable that at the expense of
security.
We desire this also. Specifics help illustrate points best.
-- A*
