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

Thinking a bit more, doing this based on an etag like system has the
additional benefit that user agents might be able to cache more than one
manifest for an origin.  Every variant would need to set the same fallback
policy to get the benefit of that mechanism, but you could use this to
serve different baseline policies for different logical apps. (without
having to go all the way to suborigins)

On Wed, Jul 27, 2016 at 9:35 AM 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-----
>>
>

Received on Wednesday, 27 July 2016 16:47:46 UTC