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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 28 Jul 2016 15:03:31 +0200
Message-ID: <CADnb78i-LmfN==ZTrRXsE=U0tCn+72pWHj-oF386JnXfYn=1sQ@mail.gmail.com>
To: "Mike O'Neill" <michael.oneill@baycloud.com>
Cc: Mike West <mkwst@google.com>, Brad Hill <hillbrad@gmail.com>, Patrick Toomey <patrick.toomey@github.com>, Joel Weinberger <jww@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
On Thu, Jul 28, 2016 at 2:58 PM, Mike O'Neill
<michael.oneill@baycloud.com> wrote:
> Giving a privacy aware user potentially worse performance is problematic, though I expect it would be rare. But this still suffers from the transparency argument, how does the user know that an origin has made the Origin-Policy response have a  UID in it. An alternative maybe to use the cookies. If the cookies are present (not blocked) then one of them could be Cookie: __Origin-Policy: I-want-this-one then the server sees that and supplies that version along with its hash in the request header. The user is no worse off privacy wise because they can use the browser UI to see what’s happening, and there hasn’t been yet another possible fingerprint vector created.

I don't see how that's an alternative. If they are blocked you still
get worse performance.


-- 
https://annevankesteren.nl/
Received on Thursday, 28 July 2016 13:03:57 UTC

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