W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2016

Re: [Proposal]: Set origin-wide policies via a manifest.

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 26 Jul 2016 17:41:55 +0000
Message-ID: <CAEeYn8j6d8VdMWCF=5Kb8E2-ZYEH1KQ-R4wMyrmTdANugV8aQw@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>, Mike West <mkwst@google.com>, public-webappsec@w3.org
I think there will likely be many versions over time, or customized to
specific user agents, as part of A/B tests, etc.  I like the idea of
versioning it with the hash, or an etag type mechanism; it seems there is
no need for an arbitrary, human-readable string.

Will there be distinctions on use of this in first-party vs third-party
contexts (hello, Safari team) as it is a cookie equivalent?  That does
complicate the operational model a bit for iframed application components,
but not too badly.

On Tue, Jul 26, 2016 at 10:03 AM Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike
>
> This is good, but it would help mitigate the privacy risk if the
> Origin-Policy request header value was limited in entropy, i.e. some small
> number of characters. How many versions of the origin manifest are there
> likely to be? Relying on users periodically deleting their entire cookie
> store to stop fingerprinting is not good.
>
> Mike
>
>
> From: Mike West [mailto:mkwst@google.com]
> Sent: 26 July 2016 15:35
> To: public-webappsec@w3.org
> Subject: [Proposal]: Set origin-wide policies via a manifest.
>
> Hello, webappsecians!
>
> I've thrown
> https://discourse.wicg.io/t/proposal-set-origin-wide-policies-via-a-manifest/1617
> up at WICG, but the folks in this venue are probably the ones from whom I'm
> most interested in getting feedback.
>
> https://mikewest.github.io/origin-policy/ sketches out a pinning
> mechanism for policies that apply to an entire origin. Among other things,
> it's meant as a replacement for the CSP Pinning mechanism this group just
> relegated to NOTE status.
>
> In a nutshell, the manifest contains a list of headers (and potentially
> other kinds of policy, CORS behavior, for instance) that are to be applied
> to each response from an origin, and the general flow is as follows:
>
> 1.  The user agent navigates to an origin.
> 2.  The server points the user agent to a manifest file along with the
> response.
> 3.  The user agent blocks navigation until it retrieves the manifest.
> 4.  The newly acquired manifest is cached, and applied to the current and
> subsequent fetches from the origin.
>
> I hope the examples in https://mikewest.github.io/origin-policy/#examples
> make the flow clear.
>
> General feedback is probably best sent to the WICG thread. Specific
> feedback is probably best sent as a GitHub issue.
>
> Thanks! Hopefully this concept isn't nuts.
>
>
> - -mike
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using gpg4o v3.5.54.6734 - http://www.gpg4o.com/
> Charset: utf-8
>
> iQIcBAEBAgAGBQJXl5cVAAoJEOX5SQClVeMPfOMP/1FPzlaftddSAhYsNpckSyEu
> R8Oo4BIPhsImutLkZquLC0L3/XUG01+DFSwqFVF5jw6enOt+qPZTu1XQI5Lj/d7x
> mhgFuda98OSsX6nQfPN+Ke1fQfr1+X+icHtZogJWJ5suffIJqifNy4nHN5qlKKlO
> Mn1HscgddZDbWpKH1otPSM4YGOu7zknDJXyj6gFXr/89aAzUW1Kt1OGU8BxrDwgm
> g16FtCT+sjiS1AZ9KkjK6YwwmkOoFtPyHPzoiKOkbney6GGY14/DE1yW8SJ/bH64
> slwE55dWDEE3k46qHV1p1GOP1ULS/tQcmIRJlqfc8nTqE/Q2G8iMvA9HU/4juWv1
> PJ4tB9RTnnOMtZell/WlLN21RcrybYBjSl4uV36uMrX37ZssjxrokF25CuE0Ys0+
> TQI4kvDZK04P/AGwssnDxWsrg6gYeVsWOqjbYPYO638i99n/+yXqEbZRnqkUkZH0
> JAhBjLI7akpHegSUHPhJv6dirq5KP1O/2KZtle0eoJiEPQ75olXxhww4ZjYKGS4z
> u4pls3BmwAtfk/VoCGh+KbSwIVsDGsT5fY6hWhJQC6uqsNTxgFsV5LxHj5YRyPob
> z00FQnnHRMBZGlCvUVuGZJLgD6nATchK9BzlErggX9gnTCZBiAQDR0VTfGkmEr++
> BDN0BCjZ3Xq3vv02vO0h
> =8GLs
> -----END PGP SIGNATURE-----
>
>
>
Received on Tuesday, 26 July 2016 17:42:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:20 UTC