W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2009

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

From: Breno de Medeiros <breno@google.com>
Date: Mon, 23 Feb 2009 16:40:05 -0800
Message-ID: <29fb00360902231640q589f259cxed1992c375e274a7@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Mark Nottingham <mnot@mnot.net>, Ben Laurie <benl@google.com>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
On Mon, Feb 23, 2009 at 3:48 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Mon, Feb 23, 2009 at 3:05 PM, Breno de Medeiros <breno@google.com>
> wrote:
> > crossdomain.xml was introduce to support a few specific applications
> > (notably flash), and it did not take into account the security
> requirements
> > of the application context. Tough.
>
> I'm suggesting we learn from their mistakes instead of making the same
> mistakes ourselves.


I am saying that we do not have the application context here because this
spec is generic.


>
>
> > Because at this point there is no consensus what a general delegation
> > mechanism would look like. Quite possibly, this might be
> > application-specific.
>
> Why not handle delegation at the application layer instead of using
> HTTP redirects for delegation?


I am not saying that HTTP redirects are the same as delegation. I think to
treat them on the same level is a mistake. An application can decide whether
to follow a redirect or not based on its security model. For applications
that expect signed content, the only delegation happens via signatures, and
following HTTP redirects is a transport event that has nothing to do with
delegation.


>
>
> > The alternative is to write a spec that
> > introduces complexity to solve problems that we conjecture might exist in
> > yet-to-be-developed applications. The risk then is that the spec will not
> > see adoption, or that implementors will deploy partial spec compliance in
> > ad-hoc fashion, which is also a danger to interoperability.
>
> Great.  Let's remove the complexity of following redirects.


Or, from another point-of-view: Let's introduce restrictions on the spec
based on anticipated threats against non-existing applications.

However, I am tired of this argument. You haven't produced anything that
convinces me there is a need to be addressed here, and I have not managed to
convince you that this should be left to be specified when applications are
developed that show clear usage patterns to justify what is and what is not,
an acceptable restriction to be placed on the spec at a generic level.

My vote is that I think the spec is better left as is. Your vote is also
understood. See you in a future thread ...



>
>
> Adam
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
Received on Tuesday, 24 February 2009 00:40:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:30 GMT