Re: Are we making a Category Mistake?

Mark,

The difference is subtle, but important.  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.

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.

Adam


On Fri, Dec 18, 2009 at 8:11 AM, Mark S. Miller <erights@google.com> wrote:
> [Really a new thread, so resending in a self contained way with a change of
> subject]
>
> In response to my question about preflight, Anne said:
>
> 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.
>
> Exactly. I agree that we should assume that an origin is a largely
> uncoordinated set of "different services maintained by different parties".
> We are not serving the interests of an origin by enabling an origin as a
> whole to opt-in by preflight, since an origin's interests lies in
> recognizing the diversity of interests, behaviors, and assumptions hosted at
> that origin. 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. The origin is
> not a unitary intentional entity that should either be or not be allowed
> access as a whole. Likewise, the intentional entities that should be allowed
> access are defined by internal coordination within the entity, not by origin
> boundaries.
> This group had the wisdom to avoid the "origin is a unitary intentional
> entity" category mistake in designing the preflight -- even though the cost
> of avoiding this mistake was high. We should exercise this same wisdom in
> deciding how to allow access to resources.
>

Received on Sunday, 20 December 2009 01:59:04 UTC