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

On Tue, Jul 26, 2016 at 11:46 AM Brad Hill <hillbrad@gmail.com> wrote:

> 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.
>

Exactly. When I proposed the hash solution I was mainly thinking of
ensuring consistency between policy updates and the header response. By
making it a hash it is trivial to add application logic to ensure an
auto-updating header response. If it was manually versioned you would have
to concern yourself with ensuring “V5” means what you think it means. But,
as noted in the GitHub issue, it has the nice side effect of also letting
the browser validate that the policy it got was what was intended (i.e. the
hashes match).


> 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-----
>>
>>
>>