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

Re: CORS versus Uniform Messaging?

From: Mark S. Miller <erights@google.com>
Date: Sun, 13 Dec 2009 13:29:18 -0800
Message-ID: <4d2fac900912131329n1f212a31u9a6300ccbc3267f3@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, Tyler Close <tyler.close@gmail.com>, Ian Hickson <ian@hixie.ch>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller <erights@google.com>
> wrote:
> > On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth <w3c@adambarth.com> wrote:
> >> I agree with Jonas.  It seems unlikely we'll be able to
> >> design-by-commitee around a difference in security philosophy dating
> >> back to the 70s.
> >
> > Hi Adam, the whole point of arguing is to settle controversies. That is
> how
> > human knowledge advances. If after 40 years the ACL side has no defenses
> > left for its position, ACL advocates should have the good grace to
> concede
> > rather than cite the length of the argument as a reason not to
> resolve the
> > argument.
>
> I seriously doubt we're going to advance the state of human knowledge
> by debating this topic on this mailing list.  The scientific community
> is better equipped for that than the standards community.
>
>
AFAICT, the last words on this debate in the scientific literature are the
Horton paper <
http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf> and
the prior refutations it cites:

Because ocaps operate on an anonymous “bearer right” basis, they seem to
make reactive control impossible. Indeed, although many historical
criticisms of ocaps have since been refuted [11, 16, 10, 17], a remaining
unrefuted criticism is that they cannot record who to blame for which action
[6]. This lack has led some to forego the benefits of ocaps.


The point of the Horton paper itself is to refute that last criticism.

[11] Capability Myths Demolished <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf>
or <
http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/>

Referee rejection of Myths at <
http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html>. Read
carefully, especially Boebert's criticisms.

[16] Verifying the EROS Confinement Mechanism <
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577>

[10] Robust Composition <http://erights.org/talks/thesis/>. Notice in
particular the counter-example to Boebert's famous claim in seven lines of
simple code, in Figure 11.2.

[17] Patterns of Safe Collaboration <http://www.evoluware.eu/fsp_thesis.pdf>,
which does a formal analysis of (among other things) confused deputy,
Boebert's claim, and my counter-example.

[6] Traditional capability-based systems: An analysis of their ability to
meet the trusted computer security evaluation criteria. <
http://www.webstart.com/jed/papers/P-1935/>


If you know of any responses to these refutations in the scientific
literature, please cite them. If you believe (as I do) that the lack of
responses is due to ignorance and avoidance, then either
1) the scientific community has shown itself less well equipped to engage in
this debate than those who are actively engaged in it -- such as us here on
this list,
2) that the case against these alleged refutations are so obvious that they
need not be stated, or
3) that the members of the scientific community that cares about these
issues have found no flaw in these refutations -- in which case they
legitimately should stand as the last word.

In either of the first two cases, since you are a member both of the
scientific community and of this standards committee, if you don't respond
in the scientific literature, please don't cite merely the lack of response
in the scientific literature in support of your points.


-- 
   Cheers,
   --MarkM
Received on Sunday, 13 December 2009 21:29:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT