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

On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 17 Dec 2009, Tyler Close wrote:
> > X-FRAME-OPTIONS: *.example.com
> > Access-Control-Allow-Origin: *
>
> Why is this better than:
>
>   Access-Control-Allow-Origin: *.example.com
>
> ...?
>

I think Tyler missed on this one.  X-FRAME-OPTIONS looks to me like the same
thing as CORS, except that it doesn't pretend to provide security.

In a capability-based world, when the user accessed your site, you'd send
back the HTML together with a set of capabilities to access other resources
on the site.  These capabilities would expire after some period of time.
 Want to allow one particular other site to use your resources as well?
 Then give them the capability to generate capabilities to your resources --
e.g. by giving them a secret key which they can hash together with the
current time.

I know, your response is:  "That's way more complicated than my one-line
.htaccess change!"

But your one-line .htaccess change is leveraging a great deal of
infrastructure already built around that model.  With the right
capability-based infrastructure, the capability-based solution would be
trivial too.  We don't have this infrastructure.  This is a valid concern.
 Unfortunately, few people are working to build this infrastructure because
most people would rather focus on the established model, simply because it
is established.  So we have a chicken-and-egg problem.

You probably also question the effect of my solution on caching, or other
technical issues like that.  I could explain how I'd deal with them, but
then you'd find finer details to complain about, and so on.  I'm not sure
the conversation would benefit anyone, so let's call it a draw.

On Thu, Dec 17, 2009 at 5:56 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 17 Dec 2009, Kenton Varda wrote:
> > On Thu, Dec 17, 2009 at 12:58 PM, Ian Hickson <ian@hixie.ch> wrote:
> > >
> > > With CORS, I can trivially (one line in the .htaccess file for my
> > > site) make sure that no sites can use XBL files from my site other
> > > than my sites. My sites don't do any per-user tracking; doing that
> > > would involve orders of magnitude more complexity.
> >
> > I was debating about one particular use case, and this one that you're
> > talking about now is completely different.  I can propose a different
> > solution for this case, but I think someone will just change the use
> > case again to make my new solution look silly, and we'll go in circles.
>
> The advantage of CORS is that it addresses all these use cases well.
>

There are perfectly good cap-based solutions as well.  But every
capability-based equivalent to an existing ACL-based solution is obviously
not going to be identical, and thus will have some trade-offs.  Usually
these trade-offs can be reasonably tailored to fit any particular real-world
use case.  But if you're bent on a solution that provides *exactly* what the
ACL solution provides (ignoring real-world considerations), the solution
usually won't be pretty.

Of course, when presented with a different way of doing things, it's always
easier to see the negative trade-offs than to see the positives, which is
why most debates about capability-based security seem to come down to people
nit-picking about the perceived disadvantages of caps while ignoring the
benefits.  I think this is what makes Mark so grumpy.  :/


> > > How can an origin voluntarily identify itself in an unspoofable
> > > fashion? Without running scripts?
> >
> > It can't.
>
> I don't understand how it can solve the problem then. If it's trivial for
> a site to spoof another, then the use case isn't solved.
>
> > My point was that for simple non-security-related statistics gathering,
> > spoofing is not a big concern.
>
> None of the use cases I've mentioned involve statistics gathering.
>

It was Maciej that brought up this use case.  I was responding to him.


> > > I have no problem with offering a feature like UM in CORS. My
> > > objection is to making the simple cases non-trivial, e.g. by never
> > > including Origin headers in any requests.
> >
> > Personally I'm not actually arguing against standardizing CORS.  What
> > I'm arguing is that UM is the natural solution for software designed in
> > an object-oriented, loosely-coupled way.
>
> CORS is a superset of UM; I have no objection to CORS-enabled APIs
> exposing the UM subset (i.e. allowing scripts to opt out of sending the
> Origin header). However, my understanding is that the UM proposal is to
> explictly not allow "Origin" to ever be sent, which is why there is a
> debate. (If the question was just "should we add a feature to CORS to
> allow Origin to not be sent, then I think the debate would have concluded
> without much argument long ago.)
>

I think the worry is about the chicken-and-egg problem I mentioned above:
 We justify the standard based on the existing infrastructure, but new
infrastructure will be built based on the direction in the standards.  Mark,
Tyler, and I believe the web would be better off if most things were
capability-based, but for that to happen this cycle needs to stop somewhere.

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.


> > I'm also arguing that loosely-coupled object-oriented systems are more
> > powerful and better for users.
>
> "Powerful" is not a requirement I'm looking for. "Simple" is.
>

I do honestly believe that UM is simpler than CORS in the average case.
 ACL-based systems may appear simpler in the simplest of use cases, but they
do not scale or age well.