Re: Cookie controls?

To answer Yoav's questions:

1.  I stopped working on CSP's cookie controls because I thought it would
be folded into Feature Policy. That didn't happen.
2.  There are no alternatives that I know of which give you the guarantees
you're looking for. Perhaps we should build some.

This seems like a reasonable kind of problem to address, but if we build
something, let's not put it into CSP. I'm very interested in calling CSP3
done, and never touching it again. :) Erik's `Limit-Cookies` header sounds
fine (I'd prefer for it to live in origin policy, actually, but that's
something of a mid-term project in itself).

Dev's suggestion that we lean on prefixes sounds reasonable to me. That is,
the limits we express could be prohibitions against sending/setting
non-prefixed cookies (or setting cookies at all). I'd caution against
saying that we could "constrain cookies to the Origin model", though:
cookies don't respect ports, and given the not-terribly-enthusiastic
response that got,
I expect that `__Host-` is going to be the best that we can do.


On Fri, Aug 17, 2018 at 6:44 AM Devdatta Akhawe <>

> Not sure I understand. Javascript can't set a __Host cookie that is
> broader context than the current host either. Do you want to do this for
> applications where changing the application to use __Host cookies is not
> possible (and thus, you want a header that can be added by a proxy in the
> middle)?
> Also, slight clarification: if I am not wrong, a __Host cookie is still
> not tied to origins. A __Host cookie on will also go to
> --dev
> On 16 August 2018 at 19:17, Erik Nygren <> wrote:
>> 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 <>
>> 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 <> wrote:
>>>> Hello folks!
>>>> Akamai has ran into some issues with cookies where Cookie Controls
>>>> <> 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 where and
>>>> are customer-controlled.
>>>> The concern is that each of these subdomains can set cookies on the
>>>> 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
>>>> <> 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
>>>> <>, 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 07:36:25 UTC