Re: Are we making a Category Mistake?

On Sat, Dec 19, 2009 at 5:58 PM, Adam Barth <w3c@adambarth.com> wrote:

> Mark,
>
> The difference is subtle, but important.


Indeed.



> I'm leery of starting
> another centithread on CORS, but I'll try my best to explain clearly
> in a single email:
>
> 1) On the client, if two URLs are within the same origin, they share a
> common security context.  This is because a document located at the
> first URL can inject script into a document located at the second URL.
>  By injecting script into the second document, the first document is
> able to do anything the second document can do.  Therefore, we cannot
> grant different privileges to different URLs in the same origin.
>

Although we agree that Caja asks us to revisit assumption #1 as you point
out below, that is not the issue I am raising here. Without tech like Caja,
and therefore without revisiting assumption #1, I agree that we cannot
support mutual suspicion within an origin. Under these baseline assumptions,
if any service within the origin is malicious, all other services within the
origin are vulnerable to it. Therefore, that is not the case I am concerned
about here, just as it is not the case motivating the per-resource preflight
in CORS.

I thought Anne stated the form of loose coupling within an origin that is a
concern quite well. Repeating:

We are concerned that a per-origin model would not be implemented correctly.
In addition it would be somewhat of a pain in case of different services
maintained by different parties hosted on a single origin which we expect to
be reasonably common.


And that is why in my response, I stated "For the same reason, we are not
*serving the interests* of an origin by adding that origin's name to the ACL
for a resource." [emphasis added] Say that grantor G seeks to grant
to service A at origin O permission P to access resource R. Say G does this
using the path of least resistance suggested by the CORS mechanism (and
repeatedly suggested as a sound practice in this thread) -- by adding O to
R's ACL. If service B at origin O is malicious, it can certainly steal P, so
that is not my present concern.

Rather, if A and B are both "services maintained by different parties hosted
on a single origin" O, where A and B are politely trying to stay out of each
other's way, then G inadvertently disrupts the correct operation of B by
causing permission P to be applied to B's requests merely as a side effect
of trying to grant P to A. This does not serve the interests of B, nor of
the origin serving as the host for such mutually trusting but separately
maintained services.

If G grants permission P to A by communicating authorizing information to A,
that A can choose to present or not when making a request, then if A and B
are coordinating, A can communicate this authorization to B, for B to
present, as part of the A-to-B coordination. A's permission P applies to B
when A and B arrange for it to. When they do not, it does not.




> 2) On the server, we have no such restriction.  That's why can we
> grant different access to different URLs within the same origin via
> XMLHttpRequest.
>
> For these reasons, CORS lets site operators assign different access
> policies to different URLs on the server but requires all URLs in the
> same origin to be granted thee same privileges on the client.
>
> Whether or not we prefer to live in a world where (1) is not the case,
> that's the world in which we currently live.  Some emerging
> technologies, like Caja, ask us to revisit assumption (1), which is
> one of the use cases for UM.  In these cases, the document containing
> the Caja gadget is going to great lengths to keep the gadget from
> accessing a number of objects that it could use to breach containment.
>  The container can simply grant access to UM and to block access to
> XMLHttpRequest.


Agreed. That is my plan once UM is deployed. But this is relevant only to my
case for UM -- which seems undisputed. It is not relevant to my case against
CORS.

-- 
   Cheers,
   --MarkM