Now we store the account token in iOS keyring and that works.
ref: https://stackoverflow.com/questions/32927070/complete-data-l...
It is not clear that a user coming to your website before the 7 days, even offline, is exempt of it.
Sisyphus says 'Hi!'
Server side, or if you need privacy, have the user export to / import from a local file.
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.
> 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!
If browsers asked approval before using localstorage, we wouldn’t have this decision.
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.
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.
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?"
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.
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.
Storing JWTs, game state data, etc.
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).
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.
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.
Not if the features allow for increased web tracking.
Fixed it for you. It's all about profit.
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.
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?
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)
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.
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.
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.
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.
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.
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.
> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.