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
middle)?

Also, slight clarification: if I am not wrong, a __Host cookie is still not
tied to origins. A __Host cookie on foo.bar.com will also go to
baz.foo.bar.com.

--dev



On 16 August 2018 at 19:17, Erik Nygren <erik@nygren.org> 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 <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
>>>
>>>
>>>
>>>
>>
>