Re: Cookie controls?

I think my primary use-case is covered if we define a way to allow servers
and/or origins to force Cookies to conform to the Origin model.  (Being
able to indicate that cookies are prohibited on an Origin is perhaps a
secondary use-case.)

Providing an ability to constrain cookies to the Origin model for a given
Origin (and/or to prohibit them entirely) would help normalize some of the
pain associated with cookies.
Defining a simple header focused specifically on this use-case as part of
6265bis might be be one possible path, and that aligns with some of the
other goals of 6265bis (eg, the introduction of __Host cookies).  For
example, a response header of:

    Limit-Cookies: origin
    Limit-Cookies: none

that would either be a sticky attribute to that origin and/or host (likely
up to some expiry) or would apply to any active content resulting from the
object associated with that response header.

The challenge is that there's no way for a server to constrain all cookies
to be __Host cookies (or otherwise be same-origin cookies) as javascript
running within that origin context can choose to set cookies on something
broader than the Origin.

       Erik



On Thu, Aug 16, 2018 at 9:37 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> 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
>>
>>
>>
>>
>