Add support for capping the maximum life-time of client-side cookies
Categories
(Core :: Privacy: Anti-Tracking, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox67 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
WebKit has added support for capping the maximum lifetime of cookies set through document.cookie to 7 days in ITP 2.1: https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/. We were already considering doing this for third-party script callers but this approach is much cleaner and simpler, so let's add support for doing the same thing to Gecko.
|
Assignee | |
Comment 1•7 years ago
|
||
|
|
Assignee | |
Comment 2•7 years ago
|
||
Depends on D20780
|
||
Comment 3•7 years ago
|
||
Thanks Ehsan! I think this is a step in the right direction. A couple thoughts:
-
Third parties can still use first-party localStorage to store cross-site identifiers read from query strings. At least in that case, the identifiers will be scoped to the current origin (as opposed to the eTLD+1, which is possible with cookies). Similarly, identifiers stored in localStorage won't clutter future HTTP requests. However, third parties can continue to track almost just as well. We may then consider adding a short life time to these other locations, but I suspect that will cause issues with interactive first-party apps (i.e., a game that stores saved states in localStorage).
-
I wonder how effective a 7 day timeout will be. If I'm a tracker with a script embedded in the main context of the page, I would just touch the cookies on every page visit to extend the lifetime by another 7 days. As long as the user visits regularly then I can continue to track. The extreme case here is just to make these cookies session-only to prevent lifetime extensions. Do we have a sense for the types of use cases that a 7 day window will support that wouldn't be supported by going session only? I.e., why not just go session-only from the start?
|
|
Assignee | |
Comment 4•7 years ago
|
||
(In reply to Steven Englehardt [:englehardt] from comment #3)
Thanks Ehsan! I think this is a step in the right direction. A couple thoughts:
- Third parties can still use first-party localStorage to store cross-site identifiers read from query strings.
That's right.
At least in that case, the identifiers will be scoped to the current origin (as opposed to the eTLD+1, which is possible with cookies). Similarly, identifiers stored in localStorage won't clutter future HTTP requests. However, third parties can continue to track almost just as well.
I wouldn't say just as well, almost as well. Cookies provide goodies that other storage capabilities don't, since they're transmitted as part of all HTTP requests and don't require relying on running active code. (Think of third-parties which can only be embedded as pixels not scripts in some cases.)
We may then consider adding a short life time to these other locations, but I suspect that will cause issues with interactive first-party apps (i.e., a game that stores saved states in localStorage).
Yes indeed.
- I wonder how effective a 7 day timeout will be. If I'm a tracker with a script embedded in the main context of the page, I would just touch the cookies on every page visit to extend the lifetime by another 7 days. As long as the user visits regularly then I can continue to track.
This is only a concern for a portion of users and a portion of sites, who would revisit the site regularly. Indeed, this protection isn't a systematic fix, but rather nudging things in the right direction.
The extreme case here is just to make these cookies session-only to prevent lifetime extensions.
Even if we did that, for a portion of our users who choose to restore their sessions at startup, their session cookies will get resurrected after a restart, so the life-time of such cookies would get extended that way. And of course there are those few users who restart their browser every month.
I'm bringing these examples to show that even if we were opting for the extreme end of the spectrum there would still be users who wouldn't be protected.
At any rate, this patch itself doesn't define a pre-determined window of protections. I think it would probably make sense to start testing with 7 days (a rather arbitrary number) and see where that takes us but I'm definitely open to other ideas!
Do we have a sense for the types of use cases that a 7 day window will support that wouldn't be supported by going session only? I.e., why not just go session-only from the start?
I don't have any good examples off the top of my head. One case I can think of is ad measurements where you've clicked on an ad today, then decide to go and buy the product tomorrow, and there would be no way of knowing that you had seen the product by clicking on the ad today (not sure how realistic this is, and to what extent users would care...)
Once the patch lands you can experiment with that by setting the pref to a negative number and browse around to see what breaks. It would be interesting to see. :-)
|
|
||
Comment 5•7 years ago
|
||
(In reply to :Ehsan Akhgari from comment #4)
At least in that case, the identifiers will be scoped to the current origin (as opposed to the eTLD+1, which is possible with cookies). Similarly, identifiers stored in localStorage won't clutter future HTTP requests. However, third parties can continue to track almost just as well.
I wouldn't say just as well, almost as well. Cookies provide goodies that other storage capabilities don't, since they're transmitted as part of all HTTP requests and don't require relying on running active code. (Think of third-parties which can only be embedded as pixels not scripts in some cases.)
I'm not sure I follow. This only impacts cookies set with document.cookie, which requires script access. The only passive resources that will receive these cookies in HTTP requests are first-party resources.
|
|
Assignee | |
Comment 6•7 years ago
|
||
(In reply to Steven Englehardt [:englehardt] from comment #5)
(In reply to :Ehsan Akhgari from comment #4)
At least in that case, the identifiers will be scoped to the current origin (as opposed to the eTLD+1, which is possible with cookies). Similarly, identifiers stored in localStorage won't clutter future HTTP requests. However, third parties can continue to track almost just as well.
I wouldn't say just as well, almost as well. Cookies provide goodies that other storage capabilities don't, since they're transmitted as part of all HTTP requests and don't require relying on running active code. (Think of third-parties which can only be embedded as pixels not scripts in some cases.)
I'm not sure I follow. This only impacts cookies set with
document.cookie, which requires script access. The only passive resources that will receive these cookies in HTTP requests are first-party resources.
I meant that those cookies will be exposed for example to network observers for non-secure first-parties.
|
||
Comment 8•7 years ago
|
||
Backed out for mochitest failures on test_documentcookies_maxage.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/68e3a5f4e4e3e352ae3e3c8ed57fd5f59eff14cb
Push link: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&selectedJob=230545540&revision=d8ec58f95f80e67432601ad43e0ea492e9d09b73
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=230545540&repo=autoland&lineNumber=12026
|
||
Comment 10•7 years ago
|
||
|
|
||
Comment 11•7 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4a2df9ca56e1
https://hg.mozilla.org/mozilla-central/rev/db866e98d64e
Description
•