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

On Mon, Feb 23, 2009 at 12:04 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> And I am already aware of one effort looking to add a trust layer to
> host-meta.

This seems heavy handed for dealing with very simple threats.

> Your suggestion of competing solutions fails simple test. It is
> easier to make the use of host-meta more restrictive (perhaps as you
> suggested) than invent a completely new one.

It's easier to build a secure metadata store by designing the store
with security in mind instead of trying to patch an existing insecure
store.

> Nothing in host-meta prevents you from implementing these restrictions
> (content type, redirections).

Let's imagine I have the following API for interacting with the host-meta store:

String getHostMetaValue(URL resource_url, String host_meta_key)

As an application programmer, its my job to use this API (i.e.,
host-meta) to implement, say, default charsets.  I make the following
API call:

var default_charset =
getHostMetaValue("http://tinyurl.com/preview.php", "Default-Charset");

Sadly, I can't use this API for this application because I'll get
hacked by redirects.

> By itself, host-meta includes no sensitive
> information or anything that can pose a threat. That will come from
> applications using it as a facility, just like they use HTTP.

So host-meta can wash its hands of all security concerns?

> We view standards architecture in a very different way. I want to create
> building blocks and only standardize where there is an overwhelming value in
> posing restrictions.

The end result will be that people who care about security won't use
host-meta.  We'll invent our own secure-meta that makes it easy to
store meta-data securely.

Adam

Received on Monday, 23 February 2009 20:30:26 UTC