Re: Delete-Cookie header??

Specifically, the request was to use the same bounds already in place for
set-cookie. Registerable domain 1 should not have access to registerable
domain 2.

Multiple domains within a given registerable domain where set-cookie can
already access is the discussion point.

On Sun, Nov 3, 2024 at 3:12 AM רועי ברקאי <roybarkayyosef@gmail.com> wrote:

> So It shall be documented that domain1 should not have access to delete
> domain2 .
>
> On Sun, Nov 3, 2024, 09:57 Yoav Weiss <yoav@yoav.ws> wrote:
>
>>
>>
>> On Sat, Nov 2, 2024, 21:41 רועי ברקאי <roybarkayyosef@gmail.com> wrote:
>>
>>> Hey Steven
>>>
>>> For special SaaS you as the provider don't know the coockie name,  same
>>> for wix for example.
>>>
>>> Secondly in regards to damain1.com on domain2.com the functionality is
>>> desired by yoav ,
>>>
>>
>> It really isn't
>>
>> I wish to have a security feature for that to mitigate potential risk
>>>
>>
>>> On Sat, Nov 2, 2024, 21:05 Steven Bingler <bingler@google.com> wrote:
>>>
>>>> > as a parent domain may...attempt to delete any other domain cookie
>>>>
>>>> This is already possible and is in fact nearly trivial if a human looks
>>>> at their browser's developer tools to obtain the domain and path of the
>>>> cookie they want to delete. No guessing required.
>>>>
>>>> > Also some enterprises hold domain1.com and domain2.com and might
>>>> wish for domain1.com to delete domain2.com cookie this should be
>>>> allowed with relevant security features
>>>>
>>>> It's not currently possible for one registrable domain to target and
>>>> delete cookies of another registrable domain and I don't believe this
>>>> proposal is advocating for that ability.
>>>>
>>>> - Steven
>>>>
>>>>
>>>> ‪On Fri, Nov 1, 2024 at 5:46 PM ‫רועי ברקאי‬‎ <roybarkayyosef@gmail.com>
>>>> wrote:‬
>>>>
>>>>> well the thing is it does introduce new functionality as a parent
>>>>> domain may/ any other domain attempt to delete any other domain cookie in
>>>>> the current suggestion.
>>>>> I believe the current edit rights are abusive and many supply chain
>>>>> attack are carried with that.
>>>>> by lowering the complexity the attack would be more common and the
>>>>> options would larger for different domains.
>>>>> Also some enterprises hold domain1.com and domain2.com and might wish
>>>>> for domain1.com to delete domain2.com cookie this should be allowed
>>>>> with relevant security features
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 1 Nov 2024 at 22:38, Steven Bingler <bingler@google.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Browsers will send any cookies that a given request has access to
>>>>>> (i.e.: domain, path, secure-ness), meaning that any server that receives
>>>>>> these cookies also already has write access to all those cookies.
>>>>>>
>>>>>> Since the purpose of this proposal is to target “cookie crust” then
>>>>>> these are presumably cookies the server is receiving from the client. So,
>>>>>> imo, it follows that a `Delete-Cookie: foo` request should delete any
>>>>>> cookies that match the name “foo” regardless of their domain/path. Perhaps
>>>>>> this could be made more precise and require both the cookie’s name and
>>>>>> value to limit collateral damage?
>>>>>>
>>>>>> This isn’t dangerous as it doesn’t introduce new behavior, it’s just
>>>>>> a convenience so the server doesn’t have to guess all applicable
>>>>>> domain/path combinations (well, it could be a footgun). Any hosts worried
>>>>>> about malicious sub/super-domains should consider the public suffix list as
>>>>>> Yoav mentioned.
>>>>>>
>>>>>> But I question how useful this is and whether it’s worth the added
>>>>>> complexity. 6265bis has a requirement that all UAs limit the longest
>>>>>> specifiable expiry of a cookie to 400 days in the future. Chrome has had
>>>>>> this behavior for a couple of years now meaning that any orphaned cookies
>>>>>> with far-reaching expiry dates have since been deleted. It’s possible that
>>>>>> some orphaned session cookies still exist but Chrome and other UAs have
>>>>>> methods for deleting those as well.
>>>>>>
>>>>>> Given all that I believe it’s increasingly less likely for a server
>>>>>> to see any “cookie cruft” after a ~year and so I’m leaning against the
>>>>>> creation of a `Delete-Cookie` header given the complexity/usefulness
>>>>>> tradeoff.
>>>>>>
>>>>>> - Steven
>>>>>>
>>>>>> On Thu, Oct 31, 2024 at 11:53 PM Yoav Weiss <yoav.weiss@shopify.com>
>>>>>> wrote:
>>>>>>
>>>>>>> It seems to me that it would make sense to mirror the domain-based
>>>>>>> scope of cookies here.
>>>>>>> That is - if you can get these cookies in requests to your origin,
>>>>>>> you can also delete them.
>>>>>>>
>>>>>>> So, if b.example.com have set domain-wide cookies on example.com,
>>>>>>> a.example.com would be able to delete them. But it wouldn't be able
>>>>>>> to delete host-specific cookies for b.example.com. Does that make
>>>>>>> sense?
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 31, 2024 at 6:18 PM Rory Hewitt <rory.hewitt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yeah, the existing clear-site functionality has a big security risk
>>>>>>>> and massive blast radius.
>>>>>>>>
>>>>>>>> My thinking on subdomains is that if you own "
>>>>>>>> customer1.saasprovider.com" (and potentially own subdomains within
>>>>>>>> that, e.g. "d999.customer1.saasprovider.com") then there is
>>>>>>>> certainly the possibility that, for reasons fair or foul, your landlord ("
>>>>>>>> saasprovider.com") may send "Delete-Cookie: abc;subDomains=true"
>>>>>>>> and as a result *your* "abc" cookie in *your* "
>>>>>>>> customer1.saasprovider.com" domain is deleted, along with the
>>>>>>>> "abc" cookie in the "saasprovider.com" domain and maybe other
>>>>>>>> subdomains.
>>>>>>>>
>>>>>>>
>>>>>>> Arguably, saasprovider.com should be on the PSL
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> But...
>>>>>>>>
>>>>>>>> Presumably your landlord isn't malicious, so either this scenario
>>>>>>>> would happen because they're hacked or they make a stupid mistake. These
>>>>>>>> things obviously do happen, but is that reason enough to not allow
>>>>>>>> otherwise useful functionality. We're talking about cookies being deleted,
>>>>>>>> which is a low-ish risk, no?
>>>>>>>>
>>>>>>>> We could, of course limit this to certain cookies - perhaps no
>>>>>>>> "Sec-*" cookies or those without the "Secure" attribute or to those which
>>>>>>>> have a domain implicitly (i.e. it wasn't included when the original
>>>>>>>> Set-Cookie header was sent to create it.)
>>>>>>>>
>>>>>>>> To me, the benefits of allowing this subdomain functionality
>>>>>>>> outweigh the drawbacks. But that's just me.
>>>>>>>>
>>>>>>>> ‪On Thu, Oct 31, 2024 at 9:38 AM ‫רועי ברקאי‬‎ <
>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>
>>>>>>>>> A better mechanism for the clear-site-data would be
>>>>>>>>> to
>>>>>>>>> 1.delete only subdomains cookies that also hold that flag
>>>>>>>>> (allow-parent domain-deletion=true)
>>>>>>>>> 2.where the subdomain cookie has a list of domains allowed to
>>>>>>>>> delete this cookie.
>>>>>>>>> 3.a request should be sent to the subdomain web server to approve
>>>>>>>>> that  in which the approval logic would be on the subdomain server side.
>>>>>>>>>
>>>>>>>>> The same 3 suggested solutions are also security architectures for
>>>>>>>>> the feature you suggested (Yoav, Rory).
>>>>>>>>> That way you may add a parent to subdomain deletion without the
>>>>>>>>> risk of supply chain attack as that behavior is implemented by the
>>>>>>>>> subdomain.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ‪On Thu, 31 Oct 2024 at 18:18, ‫רועי ברקאי‬‎ <
>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>
>>>>>>>>>> Dear Patrick,
>>>>>>>>>>
>>>>>>>>>> You are correct that risk is also available in that sense as
>>>>>>>>>> well.
>>>>>>>>>> But two wrongs don't make a right. Do you believe this
>>>>>>>>>> supply chain risk is irrelevent?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 31 Oct 2024 at 18:13, Patrick Meenan <patmeenan@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I agree in principle to subdomains-only, but wouldn't the risks
>>>>>>>>>>> called-out also be a problem with clear-site-data which wipes out all
>>>>>>>>>>> cookies (including parent and horizontally to peers)?
>>>>>>>>>>>
>>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 12:02 PM ‫רועי ברקאי‬‎ <
>>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>>
>>>>>>>>>>>> Rory please read my response.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree with Rorry on most of the solution.
>>>>>>>>>>>> I believe an issue may be rissen when an authority example.com
>>>>>>>>>>>> may delete a cookie for a.example.com may have supply chain
>>>>>>>>>>>> attack vector possibilities therefore im against that solution.
>>>>>>>>>>>> As a tennant of a domain (owner of a subdomain) I wouldnt want
>>>>>>>>>>>> my landlord ie the domain the company I buy services from to delete the
>>>>>>>>>>>> cookies of my users.
>>>>>>>>>>>>
>>>>>>>>>>>> Take in mind that many subdomains that uses SAAS have their
>>>>>>>>>>>> scripts run as well from the parent domain. therefore a supply chain/DOS
>>>>>>>>>>>> attack may take place via removing access to users by deleting their
>>>>>>>>>>>> cookies.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 31 Oct 2024 at 17:45, Rory Hewitt <
>>>>>>>>>>>> rory.hewitt@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Since the "Delete-Cookie: abc, def" is a response header, then
>>>>>>>>>>>>> if sent from a server at e.g. bob.example.com, I would expect
>>>>>>>>>>>>> it to only delete the "abc" and "def" cookies in the
>>>>>>>>>>>>> bob.example.com subdomain. Allowing even a higher iste (i.e.
>>>>>>>>>>>>> clearing the "abc" and "def" cookies at the example.com root
>>>>>>>>>>>>> domain seems very dangerous. In a federated world, we have things like "
>>>>>>>>>>>>> customer1.saasprovider.com" who is completely unrelated to "
>>>>>>>>>>>>> customer2.saasprovider.com", and I wouldn't want either of
>>>>>>>>>>>>> them to to be able to delete cookies at the "saasprovider.com"
>>>>>>>>>>>>> root domain, since they could have been placed there by either customer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, allowing "Delete-Cookie: abc, def" sent from
>>>>>>>>>>>>> bob.example.com to be able to delete those cookies from both
>>>>>>>>>>>>> bob-example.com and all *.bob.example.com subdomains seems
>>>>>>>>>>>>> more reasonable, IF one assumes that the bob.example.com
>>>>>>>>>>>>> server in some way 'controls' its subdomains.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In short, the only thing that should be able to delete cookies
>>>>>>>>>>>>> from a domain is a Delete-Cookie header sent from that domain or a 'higher'
>>>>>>>>>>>>> (closer to root) domain.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course, the header could be enhanced in a similar way to
>>>>>>>>>>>>> HSTS:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Delete-Cookie: abc, def;subDomains. ghi"
>>>>>>>>>>>>>
>>>>>>>>>>>>> indicating that (if sent from bob.example.com), the following
>>>>>>>>>>>>> cookies should be deleted:
>>>>>>>>>>>>>
>>>>>>>>>>>>> * "abc" if it has a Domain of bob.example.com domain
>>>>>>>>>>>>> * "def" if it  has a Domain of bob.example.com domain or any
>>>>>>>>>>>>> subdomains of bob.example.com
>>>>>>>>>>>>> * "ghi" if it has a Domain of bob.example.com domain
>>>>>>>>>>>>>
>>>>>>>>>>>>> But that's getting into more complexity that maybe isn't
>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 4:55 AM Patrick Meenan <
>>>>>>>>>>>>> patmeenan@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm assuming the scope would be similar to clear-site-data:
>>>>>>>>>>>>>> "cookies" where, at least in w3c land, it clears across all of the
>>>>>>>>>>>>>> subdomains in the "registered domain" (
>>>>>>>>>>>>>> https://www.w3.org/TR/clear-site-data/#clear-cookies), just
>>>>>>>>>>>>>> with the ability to target a specific name instead of nuking everything.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Should it be limited to the direct hierarchy or should it
>>>>>>>>>>>>>> also impact same-level origins like clear-site-data does? i.e.
>>>>>>>>>>>>>> bob.example.com clears from bob.example.com and example.com
>>>>>>>>>>>>>> but should it be able to target deleting from
>>>>>>>>>>>>>> alice.example.com?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 6:57 AM Yoav Weiss <
>>>>>>>>>>>>>> yoav.weiss@shopify.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 11:49 AM ‫רועי ברקאי‬‎ <
>>>>>>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As a first party coockie holder you may set an expiration
>>>>>>>>>>>>>>>> date on the coockie you have created.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure, but since setting an expiration date requires
>>>>>>>>>>>>>>> predicting the future, we need a way to correct past predictions that
>>>>>>>>>>>>>>> didn't quite work out.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Allowing cross site coockie deletion would enable issues
>>>>>>>>>>>>>>>> for users as an attacker may remove all mostly used coockie names
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you expand on that? I wouldn't expect a server to be
>>>>>>>>>>>>>>> able to delete cookies that it can't receive, if that makes sense.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Oct 31, 2024, 12:39 Yoav Weiss <
>>>>>>>>>>>>>>>> yoav.weiss@shopify.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 11:15 AM Daniel Stenberg <
>>>>>>>>>>>>>>>>> daniel@haxx.se> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, 31 Oct 2024, Yoav Weiss wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> > `Delete-Cookie: name1, name2` as an example syntax,
>>>>>>>>>>>>>>>>>> which seems simple
>>>>>>>>>>>>>>>>>> > enough and can get the job done.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since cookies are hierchical, it should probably be noted
>>>>>>>>>>>>>>>>>> that this list
>>>>>>>>>>>>>>>>>> identifying 'name1' and 'name2' can in fact match
>>>>>>>>>>>>>>>>>> numerous cookies (for
>>>>>>>>>>>>>>>>>> different paths), not just two and there is no way for
>>>>>>>>>>>>>>>>>> this syntax to delete
>>>>>>>>>>>>>>>>>> just a subset of them.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's true. At the same time, the use case at hand is one
>>>>>>>>>>>>>>>>> where we want to delete cookies when we have no knowledge of their path.
>>>>>>>>>>>>>>>>> So I believe it's fine to delete all matching cookies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +Colin Bendell <colin.bendell@shopify.com> to keep me
>>>>>>>>>>>>>>>>> honest, as he's closer to this work.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   / daniel.haxx.se
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Rory Hewitt
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.linkedin.com/in/roryhewitt
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rory Hewitt
>>>>>>>>
>>>>>>>> https://www.linkedin.com/in/roryhewitt
>>>>>>>>
>>>>>>>