Re: the discussion is over, resistance time

On Thu, Jul 2, 2009 at 7:02 PM, Thomas Lord<lord@emf.net> wrote:
> On Thu, 2009-07-02 at 18:46 -0500, Tab Atkins Jr. wrote:
>
>> As I noted elsethread, Thomas, rootstrings are functionally identical
>> to same-origin restrictions.
>
> Wow, this is really tripping people up.
>
> No, they are not functionally identical.
>
> A server might be reasonably configured to
> refuse certain requests for a font.  Systems
> like CORS allow conforming browsers to
> streamline and simplify that server's right
> of refusal.

Unless I'm *completely* wrong (and I don't think I am, because Anne
has been very assertive in correcting people about how same-origin and
CORS works), you're wrong.

Same-origin restrictions do not affect the server *at all*.  If a
same-origin restriction is in effect, the *browser* enforces it,
*after* receiving the resource from the server.

In order for same-origin to be enforced on the server, as you
envision, it is necessary for the client to send the server the origin
of the page they are viewing.  This is a potential privacy breach, in
the exact same way that the Referer header is (in fact, it essentially
*is* a Referer header).  The server doesn't *need* to know the origin
of the page that contains the request in order to fulfill that
request, it just needs the IP of the client.

On the other hand, the browser is uniquely suited to enforce this
without a privacy breach.  It's the actor rendering the page that
includes the request, so it knows the origin that the request
originates from.  It also obviously knows the origin of the server
(that's contained in the request URL).  Thus it can compare the two
and decide whether same-origin has been violated.

Note, though - the browser *cannot* make this decision *before*
sending the request.  Doing so is to assume that the resource is
really *only* usable when requested from the same origin.  CORS
headers, which are sent with the response, may relax this requirement,
allowing a resource to be used when requested from a different origin.

So, the overall process looks like this:

1. Average user visits a page.

2. Page has a link to some resource which is covered by a same-origin
restriction (perhaps a font file is linked from a @font-face rule, or
a script on the page is making an XHR).

3. Browser reads the page, find this link, and makes a request to the
indicated server.

4. Server returns the requested resource, and potentially adds some
CORS headers to the response.

5. Browser receives the response, checks the page's origin against the
response's origin (or the origins in the CORS headers), and decides
whether or not to allow the page/css/script to use the resource.

Having the server make the decision requires checking the Referer
header or a functional equivalent, which some users may legitimately
not send.

> A system of rootstrings forbids a client from
> performing certain computations with a file that
> is already in hand, if the client is to be called
> conforming.  This refusal is in spite of the fact
> that no interop enhancement is thus obtained.
>
> Do you not see the difference?

As I explained above, same-origin/CORS also forbids the client from
using a resource which it has in hand.

~TJ

Received on Friday, 3 July 2009 00:20:21 UTC