RESOLVED DUPLICATE of bug 212034 211775
ITP: 7-Day Cap on All Script-Writable Storage does not seem to be working
https://bugs.webkit.org/show_bug.cgi?id=211775
Summary ITP: 7-Day Cap on All Script-Writable Storage does not seem to be working
Rowan Beentje
Reported 2020-05-12 02:45:41 PDT
Created attachment 399113 [details] A text file containing the HTML, manifest, and third-party script used during testing After the release of iOS 13.4 and Safari 13.1, and the accompanying blog post at https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ , I ran some tests just to verify how much the website and web app I work on would be affected. After reading that blogpost, my expectations were: 1) In Safari [Mobile/Desktop], first and third party script-set cookies should be deleted after 7 days. 2) In Safari [Mobile/Desktop], first and third party script-set localStorage should be deleted after 7 days of Safari use without using those pages. 3) In Web Apps added to the iOS home screen, first and third-party script-set cookies should not be deleted after 7 days if the web app is not launched during that time. 4) In Web Apps added to the iOS home screen, first and third-party script-set localStorage should not be deleted after 7 days if the web app is not launched during that time. 5) In a WKWebView in an app, first and third party cookies and localStorage should persist regardless of usage. I set up some tests on 25th March on my personal iPhone, using domains I was not actively using; visiting a page in Safari, saving it to the homescreen, and navigating a WKWebView to it. (See attached files - very basic implementation of one static HTML page and a manifest on one domain, and a js file on another domain.) I then closed those tabs and did not visit those domains again, but used Safari daily for other tasks. On April 3rd, 9 days later, I navigated to the web page again, launched the web app, and navigated the WKWebView to check the results, which were: 1) In Safari [Mobile/Desktop], first and third party cookies were deleted. This matches expectations. 2) In Safari [Mobile/Desktop], first and third party localStorage still had stored values. I was expecting the localStorage values to have been deleted. 3) In the home screen Web App, first and third party cookies were deleted. This does not match what I was expecting, as https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ says "If your web application does experience website data deletion, please let us know since we would consider it a serious bug." 4) In the home screen Web App, first and third party localStorage still had stored values. This matches expectations but because of (2) and (3) I'm not sure which it's following. 5) In the WKWebView, first and third part cookies and localStorage all still exist. This matches expectations. Because I doubted my results, I then left the installations as they were to re-run the tests. Other things happened, and I only got around to retesting the installations on May 11th, over a month later. The same behaviour was observed - cookies deleted in Safari and home screen, localStorage persisting despite daily (or near-daily) Safari usage. So I think I'm seeing two strange bits of behaviour: a) In the browser, I would have expected localStorage to have been deleted once the 7-day usage counter was reached. This has not happened and localStorage seems to be persisting. Could anything else be causing this? b) In a home screen web app, I would have expected cookies to persist if I was not opening the web app, particularly for the first party domain the web app was for. I would consider this website data deletion. @johnwilander has clarified that cookies use a wall time expiry mechanism rather than a usage counter (https://mobile.twitter.com/johnwilander/status/1259854477047316484) so I wonder if this is the cause of this - and is this intended? It doesn't seem to match what the blog post suggests. Are there other contributing factors that could be affecting this behaviour?
Attachments
A text file containing the HTML, manifest, and third-party script used during testing (3.28 KB, text/plain)
2020-05-12 02:45 PDT, Rowan Beentje
no flags
A HTML file to be placed on a domain considered first party and visited as part of the test (1.86 KB, text/html)
2020-05-12 03:09 PDT, Rowan Beentje
no flags
A manifest.json file to be placed on the domain considered first party, to allow homescreen installation during testing (209 bytes, application/manifest+json)
2020-05-12 03:10 PDT, Rowan Beentje
no flags
A script file to be placed on a different domain considered third-party for testing. (864 bytes, text/javascript)
2020-05-12 03:12 PDT, Rowan Beentje
no flags
Rowan Beentje
Comment 1 2020-05-12 03:09:32 PDT
Created attachment 399114 [details] A HTML file to be placed on a domain considered first party and visited as part of the test
Rowan Beentje
Comment 2 2020-05-12 03:10:54 PDT
Created attachment 399115 [details] A manifest.json file to be placed on the domain considered first party, to allow homescreen installation during testing
Rowan Beentje
Comment 3 2020-05-12 03:12:01 PDT
Created attachment 399116 [details] A script file to be placed on a different domain considered third-party for testing.
John Wilander
Comment 4 2020-05-12 06:03:22 PDT
Thanks! Client-side cookies expire based on wall time since they have an explicit expiry function. So that behavior is expected. I will look at what’s going on with other script-writeable storage.
Radar WebKit Bug Importer
Comment 5 2020-05-20 15:08:22 PDT
Brent Fulgham
Comment 6 2022-02-12 21:01:34 PST
*** This bug has been marked as a duplicate of bug 212034 ***
Note You need to log in before you can comment on or make changes to this bug.