- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Wed, 19 Feb 2025 13:15:51 -0800
- To: Rory Hewitt <rory.hewitt@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Yoav Weiss <yoav.weiss@shopify.com>, HTTP Working Group <ietf-http-wg@w3.org>, Johann Hofmann <johannhof@google.com>, Matt Metzger <matthew.metzger@shopify.com>
> To be clear, this requirement applies to the server, but you're implementing it by adding code in the client (browser) to disallow the cookie from being created in the first place? Yes, which exactly how the existing HttpOnly attribute works now > I also agree with Anne's points, and I'm not sure how the various __Secure-* and __Host-* cookies would play with __HttpOnly-* cookies proposed by Yoav. Would this end up with cookie names like "__HttpOnly__Secure-string"? You wouldn't repeat `__Secure-`, it would simply always require the secure attribute the way the `__Host-` prefix does. But I do think it will require two separate prefixes. __Host- cookies are the only defense against sibling-domain cookie injection and I don't want to give that up, but in practice even more people would want to enforce HttpOnly on their existing domain cookies without having to rewrite their web application. We can't change __Host- semantics to require HttpOnly without breaking existing uses. So maybe `__HttpOnly-` and `__HostHttpOnly-` would do. I liked `__HostOnly-` but it's a bit ambiguous. -Dan Veditz
Received on Wednesday, 19 February 2025 21:16:21 UTC