On Mon, Feb 23, 2009 at 12:04 PM, Eran Hammer-Lahav <[email protected]> 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
