Login token cookies (set by MediaWiki core and by CentralAuth) have a 30-day expiration date, but we don't do anything to enforce that on the server side. If the goal of the relatively short expiration time is to limit the effect of stealing login cookies, we shouldn't rely on the client to be honest and honor the expiry date.
We could use something similar to Token::toStringAtTimestamp to issue tokens which include an expiration timestamp.
I think the reason is more that the old privacy policy specified a 30-day
maximum on cookies.
If we don't much care, should we decline the tas and remove custom policy, given that we use 1 year now on Wikimedia and half a year on default MW installs? @dpatrick any thoughts?
Reviewed at the Security-Team clinic today.
I'll do this now. This would be a good code hardening measure in the Security-Team's collective opinion, but without a confirmed vulnerability which becomes an increased threat within an additional 11-month period as opposed to a 30-day period, this doesn't seem quite as urgent. If such vulnerabilities do exist, we'd be happy to reevaluate this.