- From: Mark S. Miller <erights@google.com>
- Date: Fri, 18 Dec 2009 08:08:45 -0800
- To: Kenton Varda <kenton@google.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
- Message-ID: <4d2fac900912180808r17056a2btf54f71987e25dada@mail.gmail.com>
On Thu, Dec 17, 2009 at 8:43 PM, Kenton Varda <kenton@google.com> wrote: > > That said, I personally don't actually expect that there's any chance of > stopping CORS, or even that doing so is necessarily the best way to break > the cycle. > Hi Kenton, if you expect that, then I don't understand what you are debating. As I understand it, the one controversy is between two positions (which I think Maciej labelled A and B). Paraphrasing: A. Do UM and not CORS. B. Do UM and CORS. Tyler and I are arguing for A. From your statement above, you are among those arguing for position B. Since no one seems to be advocating anything other than A or B, if your position is B, I don't understand why you are putting in the energy explaining the advantages of UM. Since you seem to share our skepticism that CORS actually adds any value, and seem to agree on many of the ways it subtracts value, I'm a bit puzzled by your expectation. I expect the A outcome for two simple reasons: 1. I believe CORS is technically unsound and damaging for all the reasons previously stated. 2. I observe good faith, open mindedness, and willingness to debate issues on their merits by all the parties involved. We are having a healthy debate here. Thus, if there is a clearly correct answer once we are all adequately informed, I believe we will converge on that. -------------------------------- I asked my question about preflight in order to make a further contribution to that clarity. In response, 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. -- Cheers, --MarkM
Received on Friday, 18 December 2009 16:12:17 UTC