W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2018

Re: Cookie controls?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 16 Aug 2018 18:37:39 -0700
Message-ID: <CAPfop_1oC8jLZVokqiuzHp8boMGmChEmssAGADim6X61JycVog@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Erik Nygren <erik@nygren.org>
Hey Yoav

Would __Host cookies help here? Maybe I am missing something about the
problem but it feels like they should.


On 16 August 2018 at 01:41, Yoav Weiss <yoav@yoav.ws> wrote:

> Hello folks!
> Akamai has ran into some issues with cookies where Cookie Controls
> <https://w3c.github.io/webappsec-csp/cookies/> would've been extremely
> helpful. Digging up the issues that lead to its obsoletion didn't reveal
> much reasoning, so I'm wondering why is was rendered obsolete, and whether
> there are alternative proposed mechanisms to replace it.
> Our use case is providing customers traffic delivery in
> customer-controlled subdomain of an Akamai domain. An example of that would
> be cdnexampledomain.com where foo.cdnexampledomain.com and
> bar.cdnexampledomain.com are customer-controlled.
> The concern is that each of these subdomains can set cookies on the
> cdnexampledomain.com domain, polluting the shared namespace, and sending
> cookies to domains outside their control.
> While Akamai can filter header based cookies on those domains, it cannot
> prevent JS from adding such cookies.
> We would be interested in a header that we can set, and which can prevent
> those subdomains from setting cookies on the parent domain, while enabling
> them to continue to set whatever cookies they need on the subdomain itself.
> When mentioning this use-case on the call yesterday, suborigins
> <https://w3c.github.io/webappsec-suborigins> was raised as a potential
> solution for this use-case, but looking at the draft, I'm not sure how it
> would without making those subdomain documents cookie-averse, and make it
> so they can't set cookies from JS at all (which may not be compatible with
> current, non-malicious content on those domains).
> But it's fairly possible that I'm Holding It Wrong™.
> I also realize that we want to move away from cookies
> <https://github.com/mikewest/http-state-tokens>, which would be great,
> but in the {short,mid}-term they'd probably still be around, so better
> control mechanisms can be very helpful.
> To sum up, my questions are:
> * Why was Cookie Controls obsoleted?
> * Are there any alternatives? Otherwise, can it be revived?
> Cheers :)
> Yoav
Received on Friday, 17 August 2018 01:38:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:04 UTC