Skip to main content

The rfc6265bis document - the updated #cookie spec - is now in draft-14: ietf.org/archive/id/draft-ietf…

It has been in the works for almost a decade by now!

Cookies: HTTP State Management Mechanism

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP pr…
www.ietf.org
#cookie
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •

a fun change in this draft compared to the RFC:

"The user agent MUST limit the maximum value of the Max-Age attribute. The limit SHOULD NOT be greater than 400 days (34560000 seconds) in duration. The RECOMMENDED limit is 400 days in duration, but the user agent MAY adjust the limit. Max-Age attributes that are greater than the limit MUST be reduced to the limit."

This entry was edited (6 months ago)
in reply to daniel:// stenberg://

Stefan Eissing
Stefan Eissing
• •
400, hu? So that cookies from Santa Claus have a chance to still be there next year?
in reply to Stefan Eissing

daniel:// stenberg://
daniel:// stenberg://
• •

"Why 400 days? The goal was to get close to 13 months so that functions one might perform annually (e.g., selecting insurance benefits for the next year) would work even as specific dates varied slightly"

(quote from the original PR with text that was eventually merged)

github.com/httpwg/http-extensi…


Standardize maximum Expires/Max-Age by arichiv · Pull Request #1732 · httpwg/http-extensions

The current spec is ambiguous on (1) what the maximum Expires/Max-Age attribute values can be and (2) whether the two must be consistent. This resolves both by requiring: The maximum attribute val...
GitHub
This entry was edited (6 months ago)
in reply to daniel:// stenberg://

daniel:// stenberg://
daniel:// stenberg://
• •
my own little contrib that shows in -14 came via this: github.com/httpwg/http-extensi…

Multiple Cookie: headers vs RFC 9113 · Issue #2541 · httpwg/http-extensions

In the original 6265 as well as in the latest 6265bis draft, this paragraph exists: When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. ...
GitHub
in reply to daniel:// stenberg://

Koos van den Hout
Koos van den Hout
• •
still with wildcard cookies (those for .example.com that match *.example.com). I really do wonder what the use-cases for those are that don't involve tracking for advertising.
in reply to Koos van den Hout

daniel:// stenberg://
daniel:// stenberg://
• •
@KHoos cookies are basically always wildcard since they tailmatch. They were made to work like that in the 90s, long before cookies tracked users. Also, without "third party cookies", it is hard to see how they can actually track users successfully.
@Koos van den Hout
in reply to daniel:// stenberg://

jub0bs
jub0bs
• •

@KHoos I'm not sure what you mean by "cookies are basically always wildcard since they tailmatch"... 🤔

A cookie's Domain attribute determines its scope. In the case of a cookie set without a Domain attribute, browsers only include it in requests to the host that set it.

Am I missing something?

@Koos van den Hout
This entry was edited (6 months ago)
in reply to jub0bs

daniel:// stenberg://
daniel:// stenberg://
• •
@jub0bs @KHoos sure, but the domain property always existed and has been used widely since the beginning
@Koos van den Hout @jub0bs
in reply to daniel:// stenberg://

Jeroen Massar
Jeroen Massar
• •

@KHoos they got javascript execution on each ad "display", and fingerprinting is a thing (and chrome has the new "Topics" or whatever they call it today); IP addresses are mostly not unique especially in combo with even a light fingerprint.

Disabling third party cookies is good, but only disadvantages those who do not build browsers and control what they load up in there.

@Koos van den Hout
⇧