Add a mechanism to fix cookies with invalid future createdAt timestamp
Categories
(Core :: Networking: Cookies, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox114 | --- | fixed |
People
(Reporter: emz, Assigned: valentin)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(3 files)
For Bug 1827669 we've seen cookies being created which have a createdAt timestamp that is very far in the future. The exact cause and potential regressor of this is currently unknown.
We should add a check in the persistent cookie storage that either deletes or clamps these invalid cookies timestamps to the current date.
Whenever we find cookies with a createdAt timestamp far in the future we can collect telemetry. This is to determine how many users are affected.
|
Reporter | |
Comment 1•2 years ago
|
||
Some more notes from today's meeting:
On cookie import on startup we should perform the following checks:
createdTime: if > PR_NOW + threshold => set to PR_NOW
lastAccessed: if > createdTime(new) => set to createdTime(new)
Expiry: Don’t touch, if it’s expired it will be cleaned up already, if its in the future (even far) that’s allowed
If we performed any of the above actions, send telemetry. Telemetry should ideally include metadata about the state of the cookie db.
Do we mess up the monotonic time increase behaviour?
This is used for comparing cookies
Before landing a patch we need to find out why or if we need the monotonic behavior. See bug 1828131.
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 2•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 3•2 years ago
|
||
Depends on D175589
|
|
Assignee | |
Comment 4•2 years ago
|
||
|
||
Comment 5•2 years ago
|
||
Comment on attachment 9330028 [details]
data-review for bug 1828126.md
PRELIMINARY NOTES:
This is a Glean collection so you might find ./mach data-review useful to generate your data collection review request for you.
DATA COLLECTION REVIEW RESPONSE:
Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes.
Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. This collection can be controlled through Firefox's Preferences.
If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, :valentin is responsible.
Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical.
Is the data collection request for default-on or default-off?
Default on for all channels.
Does the instrumentation include the addition of any new identifiers?
No.
Is the data collection covered by the existing Firefox privacy notice?
Yes.
Does the data collection use a third-party collection tool?
No.
Result: datareview+
|
|
Assignee | |
Comment 6•2 years ago
|
||
(In reply to Chris H-C :chutten from comment #5)
This is a Glean collection so you might find
./mach data-reviewuseful to generate your data collection review request for you.
Thanks, I'll use that in the future 🙂
|
||
Comment 8•2 years ago
|
||
Backed out for causing xpcshell failures in test_timestamp_fixup.js.
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | netwerk/cookie/test/unit/test_timestamp_fixup.js | xpcshell return code: 0
|
|
||
Comment 9•2 years ago
|
||
Ah, dangity dang. This is bug 1752139
To unblock, just skip-if android on this test and reference bug 1752139. Sorry about that.
|
|
Reporter | |
Comment 10•2 years ago
|
||
(In reply to Chris H-C :chutten from comment #9)
Ah, dangity dang. This is bug 1752139
To unblock, just skip-if android on this test and reference bug 1752139. Sorry about that.
skipping the entire test on android might be too risky. I suggest we only skip the telemetry parts of this test instead. But I'll leave that to Valentin do decide.
|
||
Comment 11•2 years ago
|
||
Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/2f28d4c36797
|
||
Comment 12•2 years ago
|
||
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4460342f6491
https://hg.mozilla.org/mozilla-central/rev/3ae7b3be5bb7
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 14•2 years ago
|
||
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_timestamp_fixed_count/explore
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_creation_fixup_diff/explore
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_access_fixup_diff/explore
I think we should check back in a few releases to see if the number of clients affected by this is high or low.
|
|
||
Comment 15•2 years ago
•
|
||
Might be worth using the reminder feature of autonag?
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 16•2 years ago
|
||
a month ago, valentin placed a reminder on the bug using the whiteboard tag [reminder-test 2023-08-15] .
valentin, please refer to the original comment to better understand the reason for the reminder.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 17•1 year ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_timestamp_fixed_count/explore
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_creation_fixup_diff/explore
https://glam.telemetry.mozilla.org/fog/probe/networking_cookie_access_fixup_diff/exploreI think we should check back in a few releases to see if the number of clients affected by this is high or low.
I've addressed this in bug 1828131 comment 4. About 0.5-1.5 million clients per release are still affected.
Description
•