Re: Cookie controls?

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

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


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 04:42:15 UTC