- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 30 Apr 2021 09:00:48 -0700
- To: Rafal Pietrak <cookie.rp@ztk-rp.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CADYDTCDEiDfGBWWC=64wnNH=U7=FaNk5d8uEuB2daZGGWDvBFg@mail.gmail.com>
One thing that jumped out at me was the Viewport visibility overriding the specified Domain. Don't do that! Either make setting a too-broad domain an error and reject the cookie (as we did with __Host- prefixed cookies), or accept that the server knows what it's doing and honor the domain. If, as a web author, you restrict cookies to a viewport you still might have all kinds of sub-resource requests from sibling origins in the same domain. Why break that? It's the "Secure" attribute, not "SecureOnly" 4 different visibility levels sounds like a PITA to implement, or even define. If a site is using "Tabs" visibility and they do a window.open(<same-origin>), does it have the same cookies or not? That used to be a popup, so new window == no cookies. In the last decade or so browsers (only one kind of user agent) have converged on having that be a new tab in the same window (has cookies). If the author specifies size attributes then it's back to a separate window (no cookies). But that's not part of the HTML specifications, it's just conventions that User Agents have adopted. It would be better to define a cookie spec based on concepts that are specified somewhere and aren't just conventions. You need to come up with some compelling reasons for why each of the levels is necessary and when it would be useful. Please restrict this to "session" cookies (no set expiration time). I don't know how I'd store a "Viewport" cookie (on disk, between browser runs if it has a long expiration) that makes sense after you close that one viewport. Or tab, or window. Would your use-cases be served by the HTML "sessionStorage" feature? It's not sent in HTTP requests so it's definitely not the same, but that is explicitly scoped to the current document and not shared with other documents of the same origin (similar to your Viewport, but excludes same-origin frames). -Dan Veditz On Fri, Apr 30, 2021 at 4:37 AM Rafal Pietrak <cookie.rp@ztk-rp.eu> wrote: > Hi everyone, > > W dniu 29.04.2021 o 22:50, Soni L. pisze: > > > > > > On 2021-04-29 5:42 p.m., Daniel Stenberg wrote: > >> On Thu, 29 Apr 2021, Soni L. wrote: > >> > >>> We'd like to be able to specify a timeout value for WWW-Authenticate, > >>> in particular `timeout=0` so the HTTP authentication can be converted > >>> into session cookies rather than sending the password in plaintext > >>> (sure, it gets sent over TLS, but that doesn't matter) on every > >>> request. Would anyone be interested in such proposal? > >> > >> What should happen when the time runs out? Is that just an ask to the > >> client that it should drop the auth status at that point? > >> > >> I don't think this is enough to make people stop using cookies for > >> logged in session status even if you would get someone to adopt. > >> > > > > It's to stop using forms, not cookies. Cookies are more secure because > > they don't keep re-sending the password such that a malicious or > > compromised server could exfiltrate the plaintext. Using cookies for > > logged in session status is a good thing. > > > > Still, cookies have their problems. > > Would somebody be so kind and have a look at my proposal regarding > cookies at: https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/ > > ... and naturally give it a comment or two :) > > Best regards, > > -R > -- > RafaĆ Pietrak > >
Received on Friday, 30 April 2021 16:01:31 UTC