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 16:34:51 +0200
Message-ID: <CADnb78hjZ6NO45mniR_xyVFaeJ60374gMC75_dg2xgYsBEggyg@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 4:23 PM, Mike O'Neill
<michael.oneill@baycloud.com> wrote:
> The point I was making about cookies is that it up to the server, it can get the policy from the Origin-Policy header or the Cookie header, it makes no difference to it. Why add another mechanism for sending UIDs if it is not necessary?

Cookies are not origin-scoped.

> The reason using cookies is better is because there is already UI than shows them on a per origin basis. There are also browser extensions e.g. PrivacyBadger that manages them to give the user better privacy. They might not look themselves (I admit I am a bit different in that regard), but plenty people worry about privacy i.e. automated decisions made about them beyond their ken, so install an extension or use a more privacy oriented UA.

That UI is way too complicated. UAs should group storage-related
information in the UI as advocated by

> Of course the spec could require Origin-Policy headers to be covered by all the rules on cookies including the extension APIs but why go to all that bother?

It's not a lot of bother, we do it for lots of things. And cookies
have bad semantics as they're not origin-scoped.

Received on Thursday, 28 July 2016 14:35:20 UTC

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