<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 3/12/2010 3:41 PM, Anne van Kesteren wrote:
<blockquote cite="mid:op.u9f2bera64w2qv@annevk-t60" type="cite">On Fri,
12 Mar 2010 08:35:48 +0100, Brett Zamir <a class="moz-txt-link-rfc2396E" href="mailto:brettz9@yahoo.com"><brettz9@yahoo.com></a>
wrote:
<br>
<blockquote type="cite">My apologies if this has been covered before,
or if my asking this is a bit dense, but I don't understand why there
are restrictions on obtaining data via XMLHttpRequest from other
domains, if the request could be sandboxed to avoid passing along
sensitive user data like cookies (or if the user could be asked for
permission, as when installing browser extensions that offer similar
privileges).
<br>
</blockquote>
<br>
Did you see
<br>
<br>
<a class="moz-txt-link-freetext" href="http://dev.w3.org/2006/webapi/XMLHttpRequest-2/">http://dev.w3.org/2006/webapi/XMLHttpRequest-2/</a>
<br>
<a class="moz-txt-link-freetext" href="http://dev.w3.org/2006/waf/access-control/">http://dev.w3.org/2006/waf/access-control/</a>
<br>
<br>
?
<br>
</blockquote>
<br>
I have now, thanks. :) Though I regrettably don't have a lot of time
now to study it as deeply as I'd like (nor Michal Zalewski's reference
to UMP), and I can't speak to the technical challenges of browsers (and
their plug-ins) implementing the type of sandboxing that would be
necessary for this if they don't already, I was just hoping I could
articulate interest in finding a way to overcome if possible, and
question whether the security challenges could be worked around at
least in a subset of cases.<br>
<br>
While I can appreciate such goals as trying "to prevent
dictionary-based, distributed, brute-force attacks that try to get
login accounts to 3<sup>rd</sup> party servers" mentioned in the CORS
spec and preventing spam or opening accounts on behalf of users and the
like, I would think that at least GET/HEAD/OPTIONS requests should not
be quite as important an issue.<br>
<br>
As far as the issue Michal brought up about the client's IP being sent,
I might think this problem could be mitigated by a client header being
added to indicate the domain of origin behind the request. It's hard to
lay the blame on the client for a DoS if it is known which server was
initiating. (Maybe this raises some privacy issues, as the system would
make known who was visiting the initiating site, but I'd think A) this
info could be forged anyways, and B) any site could publish its
visitors anyways.) I'll admit this might make things more interesting
legally though, e.g., whether the client shared some or all
responsibility, for DoS or copyright violations, especially if
interface interaction controlled the number of requests. But as far the
burden on the user, if the user is annoyed that their browser is being
slowed as a result of requests made on their behalf (though
I'm not sure how much work it would save given that the server still
has to maintain a connection), they can close the tab/window, or maybe
the browser could offer to selectively disable such requests or request
permission.<br>
<br>
I would think that the ability for clients to help a server crawl the
internet might even potentially be a feature rather than a bug,
allowing a different kind of proxy opportunity for server hosts which
are in countries with blocked access. Besides this kind of "reverse
proxy" (to alter the phrase), I wouldn't think it would be that
compelling for sites to outsource their crawling (except maybe as a
very insecure and unpredictably accessible backup or caching service!),
since they'd have to retrieve the information anyways, but again I
can't see what harm there would really be in it, except that addressing
DoS plans would need to address an additional header.<br>
<br>
I apologize for not being able to research this more carefully, but I
was just hoping to see if there might be some way to allow at least a
safer subset of requests like GET and HEAD by default. Akin to the
rationales behind my proposal for browser support of client-side
XQuery, including as a content type (at
<a class="moz-txt-link-freetext" href="http://brett-zamir.me/webmets/index.php?title=DrumbeatDescription">http://brett-zamir.me/webmets/index.php?title=DrumbeatDescription</a> ), it
seems to me that users could really benefit from such capacity in
client-side JavaScript, not only for the sake of greater developer
options, but also for encouraging greater experimentation of mash-ups,
as the mash-up server is not taxed with having to obtain the data
sources (nor tempted to store stale copies of the source data nor
perhaps be as concerned with the need to obtain republishing
permissions).<br>
<br>
<blockquote cite="mid:op.u9f2bera64w2qv@annevk-t60" type="cite">
<blockquote type="cite">Servers are already free to obtain and mix in
content from other sites, so why can't client-side HTML JavaScript be
similarly empowered?
<br>
</blockquote>
<br>
Because you would also have access to e.g. IP-authenticated servers.
<br>
<br>
</blockquote>
<br>
As suggested above, could a header be required on compliant browsers to
send a header along with their request indicating the originating
server's domain?<br>
<br>
best wishes,<br>
Brett<br>
<br>
</body>
</html>