Hacker News new | ask | show | jobs
by yohannparis 2273 days ago
Webkit's website says: "[..] deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site."

It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.

2 comments

User not coming to website 7 days can't be invalid use-case. Losing important data simply because someone went on vacation is unacceptable.
Not allowing important data to be downloaded for cold storage is unacceptable.
Ok, allowing, then what? I still don't want to deal with export/import as a user.
You want all your important apps to migrate to a platform where their data is all tucked away in inscrutable filesystem locations that don't expire ever?
I have a few suggestions in the comment section you may or may not find agreeable.
With all due respect, this comes off as apologizing for Apple's disagreeable design choice.

If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful. Your suggestions might as well be aimed at browser vendors, who could conceivably offer user friendly controls for local storage (e.g. import/export without the dev panel). But as is usually the case each of the browser vendors has these little annoying ways that they cripple the browser to protect their business models. Apple is no exception to this. Look at how they've hampered the WebGPU process. Look at the history of their PWA support.

I strongly oppose Apple's anti-consumer practices in their App Store policy, PWA policy (non-existent) and similar places. I just believe this (localStorage policy) is not one of those cases.

Agreeing with Apple's disagreeable design choices isn't an apology, it's an honest opinion. If these choices are disagreeable, which I believe they are, they must be also agreeable by definition.

> If anything, it should be on Apple and the browser vendors to make local storage more useful by default, not less useful.

Not if the features allow for increased web tracking.

So store this data on the server.
But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked
For your app, maybe.

But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.

There are many legit uses for localStorage.

Storing JWTs, game state data, etc.

I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.
why to store JWT in local storage. Localstorage can be accessed by CDN scripts also. Please don't put risk on ur users data.
It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss.

Server side, or if you need privacy, have the user export to / import from a local file.

This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.
The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent.

If browsers asked approval before using localstorage, we wouldn’t have this decision.

This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.
> have the user export to / import from a local file.

Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.

If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)
Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.
Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.
Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.
The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.
You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.
Yea, we actually don't use safari at all in our app. So this might not have an effect but it's pretty vague.
If you don't use Safari you can patch webkit to change the policy, right? Change 7 to 10000000
Apple only allows apps to use their webkit implementation.
Even for other browsers. Chrome, Edge, Opera etc. on iOS all use webkit under the hood.
You could...but it's a change that the Webkit project would never accept and you would be forever diddling this value every time an update came along.

Sisyphus says 'Hi!'