- From: Mark S. Miller <erights@google.com>
- Date: Fri, 18 Dec 2009 08:11:49 -0800
- To: public-webapps <public-webapps@w3.org>
- Message-ID: <4d2fac900912180811p7e8c8a1ewfa969285ef57ffc@mail.gmail.com>
[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 Friday, 18 December 2009 16:15:23 UTC