<!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>