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


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
Version: GnuPG v1
Comment: Using gpg4o v3.5.54.6734 - http://www.gpg4o.com/
Charset: utf-8


Received on Wednesday, 27 July 2016 09:04:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC