Re: Cookie controls?

On Wed, Aug 29, 2018 at 8:01 PM Erik Nygren <> wrote:

> Two considerations I see:
> 1. Adding domains to the public suffix list is operationally scary as
> there's no way to introduce a domain slowly and/or roll things back if
> something goes wrong.  For domains with many thousands of heterogeneous
> production use-cases, adding an existing domain is likely to be
> unacceptably risky in some circumstances.
> 2. The PSL doesn't scale all that well, is an oddly centralized thing, and
> feels like a hack.  This is less pragmatic, but it would be better if we
> had mechanisms to allow getting to safer defaults for cookies without
> relying on the PSL.

I think you're perfectly right that the PSL is not scalable, kludgy and
awkward to use ;-) (and I certainly empathize with the deployment concerns
in a complex application ecosystem). The PSL does, however, have the
benefit of already being used in the wild, and I imagine that being able to
reliably depend on any new mechanisms across browsers might take longer
than you're comfortable with -- so I figured I'd at least mention it
because IIRC it didn't come up in the in-person discussion.

When it comes to a more sane design for this, it would kind of make sense
to me if it lived in Feature Policy (e.g. FP: only-host-cookies; or FP:
no-cookies or something of that sort) and could be turned on for the whole
origin by setting a default FP in the Origin Policy.


> Best, Erik
> On Fri, Aug 17, 2018 at 5:43 PM Artur Janc <> wrote:
>> Regarding alternatives, what are the constraints that prevent you from
>> putting the CDN domain on the public suffix list (
>> AFAIK many sites which have registrable
>> domains with subdomains hosting user-controlled content use the PSL to
>> prevent the cookie clashes you're talking about -- some prominent examples
>> include, and
>> Cheers,
>> -Artur
>> On Fri, Aug 17, 2018 at 12:38 AM Mike West <> wrote:
>>> 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.
>>> -mike
>>> On Fri, Aug 17, 2018 at 6:44 AM Devdatta Akhawe <>
>>> wrote:
>>>> 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 Wednesday, 29 August 2018 22:52:58 UTC