Hacker News new | past | comments | ask | show | jobs | submit login

I really appreciate this link. I would have never seen this otherwise. It's kind of a disappointment for us on the enterprise side. Our main offering is an offline app where people are disconnected from the internet for weeks and we use localStorage to validate who they are. It's a bit vague about how this affects apps that don't use safari. Nevertheless, we might have to start to really think about the user experience here now that this update is out.

To be honest, HTML5 LocalStorage was always different on iOS when compared to other platforms. The iOS browser localstorage is stored in /caches so it is cleaned when the device goes low on disk space. I found out the hard way, had a cordova app which ran on Android and iOS (and web) and saved an account token in LocalStorage. Some iOS users kept on getting logged out, mostly users with smaller size iPhones!

Now we store the account token in iOS keyring and that works.

ref: https://stackoverflow.com/questions/32927070/complete-data-l...

How do you use the iOS Keyring from within a PWA or website in Safari?

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

Right, but Cordova isn’t PWA.

Sure! In a PWA, storing login tokens in the keyring would not be possible. So as I said, on iOS the localstorage (and cookies) would be cleared in low disk space conditions anyway. So the PWA experience was already not good!

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.

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.

There's one simple thing that Apple could do. Do not delete local data if user bookmarked page from that website (or pinned it to home screen for mobile devices). Now bookmarked website treated like an "app" with slightly less restrictions and some random website data will be eventually purged (although I believe that 7 days should be extended to few months).

This is a great idea. Long forgotten bookmarks now has a purpose. I wish someone pitched this to all browsers out there.

> 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.

I don't think that web tracking must be fought at expense of user UI. It's fine to fight web tracking by introducing measures that don't break honest websites. It's not fine to fight web tracking or anything by crippling user experience with honest websites.

> Not if the features decrease the need for the App Store

Fixed it for you. It's all about profit.

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.

Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins).

This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).

It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.

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.

Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy.

This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.

Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.

The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/.

Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.

Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.

Not sure about pinning, but bookmarking should not grant any extra rights. Even the useful websites should not be able to track me forever.

Look, we already have lots of website prompts, like camera and location. The best thing, privacy-wise, would be an explicit prompt: "this website wants to store information, possibly including tracking identifiers, forever. Allow?"

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.

I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely.

Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over.

I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.

I really liked the web when it was just documents.

> you didn't build an app, you built a web page

"Progressive web apps use modern web APIs"

The word application is there twice. I don't have to like it.

> they are just web pages that exist in a web browser for the lifetime of the tab they're in

Evidently not. My opinion doesn't matter.

> They shouldn't expect to have any persistent storage

2016 "With Chrome 52, we're introducing the ability to make storage persistent"

> ...a clear lifecycle of installation and deletion that the user has complete control over.

I've never asked for 7 days

> it will never be as good as native apps

I don't develop anything for walled gardens. I cant wait for my linux phone.

> it creates an expectation that every browser will expand its functionality until it is effectively a full operating system.

This already happened. Again, I don't have to like it.

> I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle

But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless?

I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound.

This is how it should work!

> 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!'

Yeah I've got a lot of users with very shaky internet and intermittent involvement with a given application (not using it for a month, more). This presents some serious challenges / impossibilities for those user's use of a web app when they're not online.

I hope they come up with some good options as this news settles. It's hard to see this as anything but even just a accidental push ('well you should always have written an app for the app store') to force folks to write a native app / participate in the app store.

If you're using Cordova or Capacitor this is why, at Ionic, we recommend never using localStorage for storing important data. Better to use an explicit filesystem storage solution like SQLite.

Yeah, as far as I understand, cookies is the only storage method that will be left to use for long-term storage of user data. If I'm wrong, someone please correct me.

Edit: getting downvoted without any reasoning provided, so I assume I'm incorrect, there are more/less ways of storing data in the future for Safari users?

Not sure if this answers that, but: https://webkit.org/blog/8613/intelligent-tracking-prevention...

Cookies can either be set in HTTP responses or through the document.cookie API, the latter sometimes referred to as client-side cookies. With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.

Cookies expire in the same way.

With cookies you can set the expire time yourself, as a developer. And looking at the list of the original blogpost from webkit (https://webkit.org/blog/10218/full-third-party-cookie-blocki...) it shows the following will be affected by the 7 day cap:

Indexed DB, LocalStorage, Media keys, SessionStorage, Service Worker registrations

Since cookies are not mentioned, I'm assuming it's NOT affected by the 7 day cap but will instead continue to work as normal (except for the fact that 3rd party cookies will stop working, which is a Good Thing)

If the cookie is set by http headers, yes. If it's set with client side js, though, it's capped at 7 days (since ITP 2.1).

Does this mean I'll soon be setting up an dummy "cookie maker" endpoint on my server that turns XHR body data into HTTPS cookie data as a workaround? :/

Interesting, I did not know that. Thanks for clarifying!

What if you have a cookie set by http and try to update it with js? Will it self-destruct now?

Technically, when you update it via js you're overwriting the existing cookie with a new one. And, from my understanding, it's then subject to the same restrictions as any other cookie set client side.

So in order to have a long-lived cookie, you essentially need to treat them as read-only client side, and push any and all update/write logic to the server such that it'll return a set-cookie header with any changes you require.

I would guess is works, but expiration is capped at today + 7 days.

Secure + HttpOnly do not expire at 7 days. These are invisible client-side.

great, sounds like we‘ll get to consent to storing cookies more frequently - everybody loves these banners. there’s even more fun to be had, thanks to GDPR dialogs with 73 nested toggles.

Have you considered porting to a native application?

I've considered just not supporting iOS.

IMO it is completely unacceptable to have a persistent permanent non-expiring store in the browser. The potential for abuse is too high.

Then why are first-party cookies okay? FTA:

> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

Unexpiring cookies shouldn't be okay either.

Users are using other than macOS/iOS devices too. Most of them are not willing to pay extra for native app that runs on only one of the platforms used.

Why would users have to pay extra?

If right now you have a web app with paying users, that means you have an accounting system of paying users.

You could publish a "native" app that simply serves that web app through a web view, using those same accounts.

The issue is elsewhere: you need to pay your developers to develop the second app. You would most probably need to bring in one more team, for each native platform.

Will you get new users from that? If yes, they will pay for that (in principle). If not, just some existing users would migrate? Then you just increased your cost without increasing your revenues. So you would need to gain enough new users to make it worthwhile.

* * *

In a nutshell, it is the same reason why Adobe won't port their apps to Linux. They already have all the users that need their software, and while it would be nice for some of their users to migrate, it won't bring anything to Adobe.

You don't need a dedicated developer to ship a WebView app. That's the whole selling point behind tech like Cordova. Most of your code can stay the same and most likely all of it will stay Javascript (or whatever you are transpiling to it).

Again, if you are actually affected by this issue right now, you have a web app that is more or less trivially ported to a web view app. Your user don't have to migrate, they already have accounts, they just need to download the app again, this time from the App Store.

> In a nutshell, it is the same reason why Adobe won't port their apps to Linux.

Linux is a non-market for Adobe apps. On the other hand, if you have an offline PWA right now, you most likely already have iOS users that you would probably lose if you start confronting them with this "7 days and your data is gone" bullshit.

Why is nobody mentioning that distribution of apps is behind apple's doors and they can stop you from distributing anything they don't like or want for any reason?

On android, you can side load apps. On iOS, you can't.

You have to pay 30% cut if you are doing payments.

You have to adhere to their reviews and design guidelines. Which is OK but not ok if you are a small team and your users are fine with somewhat lacking app.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact