- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 28 Jul 2016 16:34:51 +0200
- 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 https://storage.spec.whatwg.org/. > 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. -- https://annevankesteren.nl/
Received on Thursday, 28 July 2016 14:35:20 UTC