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.
5 Comments RSS · Twitter
And it’s all for naught if it causes people to drop Safari. I’ve been using it since inception, but I’m this close to switching because of the cookie-logouts, auto-fill freezes, and because I’m constantly running into sites that simply don’t work in Safari.
The problem here is that the same features that enable powerful web applications by necessity also enable abuse. As long as people keep pushing new techniques for abusing these features, and browser manufacturers keep finding ways to disable these abuses, the end result will always be that honest web applications are hurt in the process.
This is not going to end well.
Instead, what is needed is a way for users to tell Safari "I actually trust this specific website." This doesn't need to be easily accessible, it shouldn't be a popup window that appears when you visit the website, or anything like that, it can be a whitelist where you manually add a websites, similar to giving accessibility rights to applications on OS X.
Apple in particular has an interest in limiting the power of web applications because they allow people to escape the app store and thus harm Apple's revenue. I'm trying to imagine the reaction if Apple implemented the same policy for iOS apps, that all your local data will be deleted after 7 days of not opening the app. Would anyone think that this was okay?
@Lucas, I think the "do you trust this site?" feature does need to be publicly facing. Otherwise, most people won't realize what's going on and their sites will just stop working after 7 days. Most people aren't savvy enough to go research a solution. They'll write off the site and move on.
Instead a site that requires storage beyond 7 days needs to ask for it explicitly and the browser needs to prompt. Even then, it's a stretch to assume the user will understand what's going on, why 7 days, etc.
This is a tough problem indeed.
That 1password article is a good example where Apple just goes too far with this.
Apple says: You cannot trust anyone, and that's what they act upon, by putting in limitations they deem justified.
However: I, a power user, can certainly decide for myself whom I can trust 100% and who I cannot. For instance, if I trust to run a password manager with all my secret data, there's no need to have Apple interject and tell me that I can't fully trust them by deleting its local data after 7 days of hibernation.
Same for dynamic sites, scripts and extensions I've installed locally or even written myself (which is the case for both a great open source web app for designing databases and an ad blocker that worked wonders with a pesky website I visit daily). All these don't or won't work any more even tough they worked just fine until then, with my full trust.
Apple needs to provide exceptions to keep things working as they did before, and let _us_ choose if we want.