- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Thu, 16 Aug 2018 18:37:39 -0700
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Erik Nygren <erik@nygren.org>
- Message-ID: <CAPfop_1oC8jLZVokqiuzHp8boMGmChEmssAGADim6X61JycVog@mail.gmail.com>
Hey Yoav Would __Host cookies help here? Maybe I am missing something about the problem but it feels like they should. --Dev 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