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

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

> 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 []
> Sent: 26 July 2016 15:35
> To:
> Subject: [Proposal]: Set origin-wide policies via a manifest.
> Hello, webappsecians!
> I've thrown
> up at WICG, but the folks in this venue are probably the ones from whom I'm
> most interested in getting feedback.
> 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
> 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
> Version: GnuPG v1
> Comment: Using gpg4o v3.5.54.6734 -
> Charset: utf-8
> 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
> BDN0BCjZ3Xq3vv02vO0h
> =8GLs

Received on Tuesday, 26 July 2016 17:42:44 UTC