- From: Breno de Medeiros <breno@google.com>
- Date: Wed, 11 Feb 2009 13:46:38 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
- Message-ID: <29fb00360902111346w2552d405sbb2e3f9d014e0450@mail.gmail.com>
On Wed, Feb 11, 2009 at 1:26 PM, Adam Barth <w3c@adambarth.com> wrote: > > On Wed, Feb 11, 2009 at 1:04 PM, Breno de Medeiros <breno@google.com> > wrote: > > I have to say that the current known use-cases for site-meta are: > > > > 1. Security critical ones, but for server-to-server discovery uses (not > > browser mediated) > > > > 2. Semantic ones, for user consumption, of an informative rather than > > security-critical nature. These use cases may be handled by browsers. > > Why not address security metadata for user-agents? For example, it > would be eminently useful to be able to express X-Content-Type-Options > [1] and X-Frame-Options [2] in a centralized metadata store instead of > wasting bandwidth on every HTTP response (as Google does for > X-Content-Type-Options). I don't think anyone doubts that we're going > to see a proliferation of this kind of security metadata, e.g., along > the lines of [3]. I don't see the point of making a central metadata > store that ignores these important use cases. The current proposal for host-meta addresses some use cases that today simply _cannot_ be addressed without it. Your proposal restricts the discovery process in ways that may have unintended consequences in terms of prohibiting future uses. This is so that browsers can avoid implementing same-domain policy checks at the application layer? > > > Adam > > [1] > http://blogs.msdn.com/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx > [2] > https://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx > [3] http://people.mozilla.org/~bsterne/content-security-policy/<http://people.mozilla.org/%7Ebsterne/content-security-policy/> > > -- --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 Wednesday, 11 February 2009 21:47:24 UTC