[Webkit-unassigned] [Bug 211775] New: ITP: 7-Day Cap on All Script-Writable Storage does not seem to be working

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=211775

            Bug ID: 211775
           Summary: ITP: 7-Day Cap on All Script-Writable Storage does not
                    seem to be working
           Product: WebKit
           Version: Safari 13
          Hardware: All
                OS: iOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: rowan at beent.je

Created attachment 399113

  --> https://bugs.webkit.org/attachment.cgi?id=399113&action=review

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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200512/efa24bcf/attachment-0001.htm>