Safari 13.1: Third-Party Cookie Blocking and 7-Day Script-Writeable Storage
Cookies for cross-site resources are now blocked by default across the board. This is a significant improvement for privacy since it removes any sense of exceptions or “a little bit of cross-site tracking is allowed.”
[…]
Safari continues to pave the way for privacy on the web, this time as the first mainstream browser to fully block third-party cookies by default.
[…]
Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site.
[…]
That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted.
The existing cookie restrictions have been really frustrating. There are many sites that I visit monthly, and so I need to enter my username and password every single time. I don’t understand why cookies, of all things, don’t have site-specific settings in Safari. I don’t like cookies in general, but there are some sites that I want to trust. Sometimes I wonder whether I should write a script to auto-open them weekly to keep the cookies warm.
I love the WebKit/Safari teams’ continuing work on limiting third-party cookies and other forms of tracking. I hope they tackle first-party tracking next.
Of the hundreds of websites I visit, I really only want to allow a handful to set cookies, and then perhaps only for a short time.
Safari now has 11 categories of site-specific configuration. It’s strange thatookies/local storage is not one of them.
On the face of it, WebKit’s announcement yesterday titled Full Third-Party Cookie Blocking and More sounds like something I would wholeheartedly welcome. Unfortunately, I can’t because the “and more” bit effectively kills off Offline Web Apps and, with it, the chance to have privacy-respecting apps like the prototype I was exploring earlier in the year based on DAT.
[…]
If I use the app in Safari on iOS without adding it to Home Screen and leave it for seven days, will my shopping list be deleted?
If I do the same thing on Safari for macOS (which doesn’t have a Home Screen), will my shopping list be deleted?
Andre Garzia (via Hacker News):
There is a huge opportunity for the creation of private client-side-only PWAs in the world but developers wanting to build such apps are in for an uphill battle against the status quo and now against Apple as well.
[…]
I want to remind everyone that installing to the home screen is not what makes a PWA, it is an optional step. A PWA is still a PWA if the user access it only occasionally by typing the URL on the browser or keeping a bookmark. I access many PWAs on my phone but they are not in my home screen because I like to keep it clean. My browser “new tab” lists them for me, they are still as much a PWA as the ones in your home screen.
Saying that you should build a native app is not an answer. Native apps need to go through gatekeepers, the web does not. The web is the only mass communication media where we all have publishing access (to some degree at least), native iOS apps are not like this. There is a reason Mozilla can’t ship Firefox with Gecko on iOS and the reason is not because they don’t know how to do it. Apple is doing this in the name of privacy but what it actually does is force developers closer to their app store.
At 1Password we are concerned about the sudden announcement that LocalStorage will expire after 7 days, and want to provide our use case of browser storage and how this will cause harm to our users (including irreversible data loss to some).
We have a full featured web app at 1Password.com that allows users to signup for an account, access their vaults, and perform admin functions for their business.
[…]
The Secret Key is a randomly generated string generated locally during signup and stored on devices users have previously used. This key is required for users to decrypt their vaults. Given that most signups occur in a web browser, that is the first place we store this critical piece of data. While we do try to encourage users to install our native applications, for some (unknown) number of users out there LocalStorage in their browser will be the only place they have this key saved, and in 7 days may now become irreversibly locked out of their 1Password vaults.
Previously:
- Information Leaks via Safari’s Intelligent Tracking Prevention
- The Success of Intelligent Tracking Prevention
- The Hotel Cupertino Clause
- Intelligent Tracking Prevention 2.3
Half of me knows I’ll rarely use and never prefer a PWA on iOS over a native app, so I know that none of this really matters nor will affect me.
The other half of me wants everyone to adhere to the platonic ideal of the web and thinks Apple should stop doing this shit.
When you set up the 1Password apps, your Secret Key will be saved in the apps. So if it gets removed from Safari, you’ll still be able to access your account. It’s an important first step, but there’s more you can do to protect your account.
I’ve seen a new bug since updating to Safari 13.1: specifying Finder tags when using File ‣ Save As in Web Archive format doesn’t actually add the tags to the file.
WebKit/Safari announcement to delete local storage after 7 days of non-use is a terrible thing since it doesn’t mention file:// origins nor UX overrides, particularly per-site settings. Apart from big, public issues like password managers, what about internal tools?
Deleting local storage after 7 days without any user control has the possibility to lose valuable user data. It also kills an entire class of applications. Users do actually want web apps that are able to store some data locally, under the user’s control.
