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: Adam Barth <w3c@adambarth.com>
Date: Mon, 23 Feb 2009 09:57:19 -0800
Message-ID: <7789133a0902230957y3216e6caub80add7db1660650@mail.gmail.com>
To: Breno de Medeiros <breno@google.com>
Cc: Ben Laurie <benl@google.com>, Mark Nottingham <mnot@mnot.net>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
On Mon, Feb 23, 2009 at 9:44 AM, Breno de Medeiros <breno@google.com> wrote:
> On Mon, Feb 23, 2009 at 9:32 AM, Adam Barth <w3c@adambarth.com> wrote:
>> Security is often a "death of a thousand paper cuts" that eventually add up to
>> you being owned.
> I don't understand this reasoning.
> 1. The host-meta spec allows delegation to other domains/hosts
> 2. Secure app does not allow redirection to other domains/hosts
> 3. Secure app does not use host-meta and instead secure-meta, as apposed to,
> say, using host-meta and not following redirects to other sites?

What's the point of standardizing host-meta if every application will
require different processing rules to suit its own needs?
Applications will interoperate better by simply ignoring host-meta and
inventing their own metadata repository.

> For secure app to be secure re:no-redirect-rule it must in any way perform
> the check that the redirection is to another realm, surely?

To be secure, a user agent should not follow redirects to obtain
host-meta, regardless of where those redirects lead.

> There is enormous value in allowing redirects for host-meta. Applications
> with higher levels of security should implement their own security policies.

If you follow your current trajectory and continue to compromise away
security, applications that require security will implement their own
version of host-meta that is designed to be secure from the ground up
instead of trying to track down and patch all the gotchas in
host-meta.  Sadly, this will defeat the goal of having a central
metadata repository.

Received on Monday, 23 February 2009 17:58:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:07 UTC