The Internet Engineering Task Force, has released a new draft titled Cookies: HTTP State Management Mechanism, which outlines the proposed functionality of cookies at a standards level, and provides insight into the direction the technology may go in the future.
Draft 10 has a few interesting comments related to privacy, in section 7 which I think are worth examining.
No Common Viewpoint
It is too early to declare consensus on which specific mechanism(s) should be used to mitigate cookies’ privacy impact; user agents’ ongoing changes to how they are handled are best characterized as experiments that can provide input into that eventual consensus.
Instead, this document describes limited, general mitigations against the privacy risks associated with cookies that enjoy wide deployment at the time of writing. It is expected that implementations will continue to experiment and impose stricter, more well-defined limitations on cookies over time.
The above indicates that collectively, as a standards body, no agreement has been reached as to the ‘correct’ way to handle cookies from a privacy perspective. It does however fully expect that the existing state for cookie handling will continue to fragment in the short term. It’s going to get worse, before it gets better.
This is important because it will drive up development time, or force specific technical architectures in order to account for the differences in how browsers handle cookies. Teams supporting websites may be well served by building in additional time for development where cookies are involved, or seeking additional training in how cookies are presently being treated. Quality Assurance should factor in additional time to ensure cross-browser behavior works as expected.
Third Party Cookies
While this document does not endorse or require a specific approach, it is RECOMMENDED that user agents adopt a policy for third-party cookies that is as restrictive as compatibility constraints permit. Consequently, resources cannot rely upon third-party cookies being treated consistently by user agents for the foreseeable future.
The draft stops short of saying browsers should outright block, or prevent transmission of third-party cookies, but does indicate that functionality should be as limited as possible where it exists. More importantly, it highlights that development teams and websites can not rely on consistent functionality across browsers when it comes to third-party cookies.
Taken another way, it could be seen as if a solution requires 3rd party cookies – one could expect it won’t work at least some of the the time based on the browser the user is using. This means any solution requiring third-party cookies is facing a uphill battle in terms of cross-browser compatibly.
Cookie Policy
The recommended cookie expiry upper limit is 400 days. User agents may set a lower limit to enforce shorter data retention timelines, or set the limit higher to support longer retention when appropriate (e.g., server-to-server communication over HTTPS).
This is notable because some existing analytic platforms set cookie duration for two years, which is roughly 730 days. At 400 days, this would be would be approximately 13 months. After 13 months of inactivity, the user’s cookies are deleted and the analytic platform would consider them a new user.
Blink (Chrome, Edge) have already announced an intent to ship support of the feature. Gecko (Firefox) and Webkit (Safari) have announced support for the concept of a upper limit, but may ultimately decide on a different day count.
The critical take away from this is that cookies will soon not last as long as they used to, and that will have downstream impacts to anything that expects to be able or monitor behavior for years via cookie use. Actual impact to day to day operations will vary depending on use case and I suspect be mostly related to efforts to reengage lapsed buyers.