Bug 219426 – What is the point of specifying a cookie's maximum age when ITP disregards it anyway?

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit API

ITP always sets the maximum age of cookies that are set in the first-party context to be 7 days. A website could have a valid reason for setting a longer maximum age, e.g. 30 days, but this will be ignored by ITP.

This goes against RFC 2965 section 3.2.2:

   Max-Age=value
      OPTIONAL.  The value of the Max-Age attribute is delta-seconds,
      the lifetime of the cookie in seconds, a decimal non-negative
      integer.  To handle cached cookies correctly, a client SHOULD
      calculate the age of the cookie according to the age calculation
      rules in the HTTP/1.1 specification [RFC2616].  When the age is
      greater than delta-seconds seconds, the client SHOULD discard the
      cookie.  A value of zero means the cookie SHOULD be discarded
      immediately.

The implication is that when a cookie has been set with a maximum age, then the user agent should respect it and expire the cookie according to that age. The user agent should not be setting expiries willy-nilly that disregards established specifications.

[John Wilander]

Hi! Thanks for filing.

First, only persistent cookies set through document.cookie and in CNAME cloaked HTTP responses get their expiry capped.

Second, user agents are allowed to block, delete, and expire cookies when they want. User agents act on behalf of the user, not on behalf of websites.

Finally, cookies set through document.cookie or in CNAME cloaked HTTP responses with an expiry shorter than 7 days will get the expiry stated by the website.

Thanks for the reply.

Personally, I don't agree with the conclusion derived from the understanding that user agents act on behalf of users: that user agents are given carte blanche to do what they want.

A very simple use-case is when after logging into a website, the user has the option of having his login remembered for the next 30 days (very common scenario in websites). If the user *does* want this benefit, he is actually denied this benefit by ITP.

To a layperson, if the website offers to remember his state for more than 7 days but he doesn't get it because ITP prevents it, he is more likely to blame the website rather than the browser.

There could be other use cases beyond remembering a user's login that calls for a longer-than-7-day cookie expiry.

[John Wilander]

(In reply to vpxxcucw from comment #2)
> Thanks for the reply.
> 
> Personally, I don't agree with the conclusion derived from the understanding
> that user agents act on behalf of users: that user agents are given carte
> blanche to do what they want.
> 
> A very simple use-case is when after logging into a website, the user has
> the option of having his login remembered for the next 30 days (very common
> scenario in websites). If the user *does* want this benefit, he is actually
> denied this benefit by ITP.

Login cookies are typically set in regular server responses which are not capped. In addition, login cookies should be set HttpOnly for security reasons which means they can’t be set through document.cookie at all.

> To a layperson, if the website offers to remember his state for more than 7
> days but he doesn't get it because ITP prevents it, he is more likely to
> blame the website rather than the browser.

People who are not experts in web technologies are exactly the ones who need their user agent to help them stay safe on the web by default. That’s why we build privacy features such as ITP.

> There could be other use cases beyond remembering a user's login that calls
> for a longer-than-7-day cookie expiry.