We currently set the Expires attribute when sending cookies to clients. This has the downside of being an absolute timestamp, and thus places unnecessary importance on client devices being in sync with our datacenter clocks.
Cookies that are short-lived or otherwise time-sensitive, thus have have a significant chance of lasting too long, or expiring too soon.
For example, the short-lived cookies for Wikimedia-Rdbms' ChronologyProtector and Multi-DC (T91816, T91820) are meant to last approximately 10 seconds, to allow for cross-dc replication to take place during which the client remains "sticky" to the primary DC.
If the client device clock is ahead by even a few seconds, they will end up ignoring this cookie (as seemingly expired on arrival), and switch themselves back to secondary DCs before this process is finished. Conversely, if their clock is behind the cookie will needlessly impact their performance by remaining connected to the primary DC for longer than needed, as well as to keep instructing MediaWiki to look for ChronologyProtector positions that no longer exist (which then issues a warning in Logstash).
This isn't super bad per-se, but we can certainly do much better, by using the "Max-Age" attribute (which supplies the number of seconds a cookie is meant to last, to be interpreted by browsers). This is a progressive enhancement that old browsers simply ignore. It is currently supported by all major browsers (Firefox 85 , Safari 14 , iOS 14 , Chrome 88 , Edge, IE11 ).
See: