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

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

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Wed, 27 Jul 2016 10:04:23 +0100
To: "'Mike West'" <mkwst@google.com>
Cc: <public-webappsec@w3.org>
Message-ID: <351b01d1e7e5$de92e170$9bb8a450$@baycloud.com>
-----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 09:04:56 UTC

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