W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

From: Mark S. Miller <erights@google.com>
Date: Fri, 18 Dec 2009 08:08:45 -0800
Message-ID: <4d2fac900912180808r17056a2btf54f71987e25dada@mail.gmail.com>
To: Kenton Varda <kenton@google.com>
Cc: Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
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

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

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:12:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC