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

Thanks Mike, and Brad. I think you're right about the request header: since
we're committing to a synchronous request to obtain the manifest, there's
little value in advertising the currently cached manifest. We'll receive an
`Origin-Policy` response header from the server, and either download the
file if we don't already have it, or use the version we've cached. (As Brad
notes, though, we do need to advertise support for the feature generally,
otherwise the server won't know that it can omit 19k of headers).

Regarding the suggestion that we could have multiple files per origin, that
worries me, and I'd prefer to avoid it if at all possible. Setting a policy
for an entire origin is simple to understand, and maps well to the actual
capabilities that each resource on an origin has. Moreover, it's something
that we can implement a priori, without looking at response headers, which
means it can take care of things like bypassing CORS preflights, or HSTS.
It's not clear to me how either of those would work in a world where
multiple policies could be active for an origin.

One way of dealing with that would be to teach the manifest format about
paths, which is probably something that we could look at doing if there's
real demand for it. I'm a bit wary of going that route for the reasons
noted above. Without thinking about it too hard, I much prefer the notion
of a policy for an origin... That's straightforward in its impact.
Granularity beyond the origin seems like a(n attractive) footgun.

Also: I have no idea how this proposal squares with suborigins. Adding Joel
and Dev in so they can tell me how that should work. :)

-mike

On Wed, Jul 27, 2016 at 6:35 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I was pondering the same thing on the bus this morning.  If the server
> reports a hash of the policy it thinks should apply, the client can
> download if it needs, or not if cached.  (Though I still think a capability
> indication header is a good idea.)
>
> On Wed, Jul 27, 2016 at 2:07 AM Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I know, I will sign as mikeo from now on!
>>
>> Unless the browser indicates it somehow the user has no way of knowing
>> which origin is using the origin-policy request header to fingerprint, so
>> would be have to periodically purge all of them.
>> Cookie handling already has UI for informing users, and APIs for
>> extensions so that can do it, and they also have reasonably transparent
>> expiry attributes.
>> Cache based storage e.g. ETag/If-None-Else tends not to. I suppose this
>> could be asked for in the spec but is there a need for that complexity? Why
>> do we need the request header anyway. If the manifest hash is in the
>> response header would there be any point in bouncing it back in the next
>> request?
>>
>> mikeo
>>
>>
>>
>> From: Mike West [mailto:mkwst@google.com]
>> Sent: 26 July 2016 18:34
>> To: Mike O'Neill <michael.oneill@baycloud.com>
>> Cc: public-webappsec@w3.org
>> Subject: Re: [Proposal]: Set origin-wide policies via a manifest.
>>
>> Hi Mike!
>>
>> On Tue, Jul 26, 2016 at 7:00 PM, Mike O'Neill <
>> michael.oneill@baycloud.com> wrote:
>> 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 would this help? The tracking capability exposed is exactly the same
>> as cookies (less, if you want to be nit-picky, since the character set is
>> more limited). Reducing the entropy contained in this key while leaving the
>> entropy contained in those keys over there the same is not a net positive.
>>
>> How many versions of the origin manifest are there likely to be?
>>
>> Not many. However, one of the ideas floated in
>> https://github.com/mikewest/origin-policy/issues/1 was to enforce
>> integrity checks on the manifest by using it's hash as the name. That seems
>> like a pretty good idea to me.
>>
>> Relying on users periodically deleting their entire cookie store to stop
>> fingerprinting is not good.
>>
>> If the user isn't wiping the cookies stored for an origin, fingerprinting
>> is unnecessary, because the cookies are right there.
>>
>> "entire" jumped out at me, though: perhaps the language wasn't clear?
>> https://github.com/mikewest/origin-policy/commit/c5ed6d6f2e96e997d0bcf0d9280a978b35241865
>> is closer to what I thought I wrote.
>>
>> - -mike
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> Comment: Using gpg4o v3.5.54.6734 - http://www.gpg4o.com/
>> Charset: utf-8
>>
>> iQIcBAEBAgAGBQJXmHkUAAoJEOX5SQClVeMPHxIP/Ah1155hOwtLFNlU6218a3BU
>> 8RchLFWIrBAQDjuLGkcacf1hgc9iMZ7Lyv0wTNp0EIf7qHmPqkpLGuIyu3ACSYxE
>> zirfv5pgyoLngNDWxErfpr9+N7yN+G2BvMlOcbPseSC/f5YiyalzL4AHFiUOJkEh
>> 28n1Lr1SjkOXPhJDaXCgIVo4llv+Fik3r7yMX5OkMjX6nMH/829bV+2DJvj0sQ/M
>> F74o74pPRvcqu9v7uI2e3A8AacuxRuV+VoDZfr3R2DwsPl7oukzu3jxhw2FVOz0q
>> kqI9AwwLXIhXWVFTEcDqFvJS58aKXGHbu6JAml1q5f36TYAzF/yt+YShufCUbyJe
>> RPw8NTl5u4zZwimmld+e1Do4IxVmW/QjEwAdDPa8UfaaZhsQ8pfrlS3tymzIrvk0
>> NSQRtKNdoFjDGJo4/B16G+PjIWJgvze0SuZfSC4/l3bLs40U/wv9EJRR9cZLuotI
>> iexSkynf1UnSXxhg6qevLKe0Dk67bXdnNywYbaP6k3J1XpE5FKWkygOmCqWhFUYt
>> r9ZfsaS6P8Du40oYd+wjtd4wCgYSxfbYy5v1aSnw/ipou59krPMGqgtttUgpQD7w
>> oQMqT8WIgd9BH5WvFGMRkSvm+jzQcXmABUE1SU8uvWbxclzQBFox//jnllJc832P
>> L7XEJ6IEGdX0Nm/SuXHF
>> =ukDJ
>> -----END PGP SIGNATURE-----
>>
>