
Private client-side-only PWAs are hard, but now Apple made them impossible - soapdog
https://andregarzia.com/2020/03/private-client-side-only-pwas-are-hard-but-now-apple-made-them-impossible.html
======
wubin
The source clarifies that this only applies to websites run within the Safari
browser.[1] PWAs added to the home screen aren't affected.

 _> As mentioned, the seven-day cap on script-writable storage is gated on
"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. If your web application does experience website data deletion, please
let us know since we would consider it a serious bug. It is not the intention
of Intelligent Tracking Prevention to delete website data for first parties in
web applications._

[1] [https://webkit.org/blog/10218/full-third-party-cookie-
blocki...](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-
more/#:~:text=A%20Note%20On%20Web%20Applications%20Added%20to%20the%20Home%20Screen)

~~~
untog
I don't think that's actually what it clarifies. Or at the very least it's
very confusing.

 _> have their own counter of days of use. Their days of use will match actual
use of the web application which resets the timer._

This makes it sound very much like homescreen apps will have their data wiped
after 7 days of non-use.

 _> We do not expect the first-party in such a web application to have its
website data deleted._

And this does not. It's a very confusing word salad.

~~~
gridlockd
Yes, it's confusing.

It's not 7 days of _non-use_ , it's seven days of application _use_ without
visiting the site.

Safari is one application, the homescreen app is a separate application.
Presumably, all the alt browsers or WebView apps are separate applications as
well.

Since you can't _use_ a homescreen app _without_ visiting the site, the 7 days
of not visiting the site can't happen.

~~~
rhizome
So this is a requirement that all webapps phone home, moreover that they have
a home to phone?

~~~
untog
No, this is all internal to the browser, no requirement to send a remote
request.

------
burtonator
I ported Polar ([https://getpolarized.io/](https://getpolarized.io/)) over to
a PWA about a year ago.

It's kind of a nightmare due to both Google and Apple messing things up.

PWAs could be an amazing platform but both companies are really messing it up.

Apple is trying to kill them by giving plausible explanations as to why they
can't have PWAs. Security this, blah blah blah. There's no reason they can't
have PWAs work well in Safari other than they want you to port your app to the
App Store and get locked into their native APIs.

Google's problem is, well, they're Google. Meaning things are somewhat
incoherent, docs are all over the place, they start new initiatives then
abandon them half way, etc.

Consumers are another problem. They have no understanding of PWAs and they go
to the app store, don't find us, and then complain we don't have an app..

The plan now is to use Google TWAs and port our PWA to Android.

We're going to do the same thing to Apple after we do the Android release BUT
I think there's a 50% chance that apple will just flat out block us.

I think we might have a chance of getting around it if we use mobile gestures
properly, use platform specific APIs like the camera, audio, and GPS that
aren't on web and try to really integrate into the platform properly.

For example, they have an API to detect dark mode now. IF that's on we're just
going to magically enable our dark mode in our app.

~~~
Razengan
> _... Consumers are another problem. ..._

You blame Apple, Google and your consumers, instead of just making native
apps. Why?

~~~
busymom0
As an iOS and Android developer myself, this doesn't effect me but I still
think Apple and Google making things harder for PWA is bad because Apple and
Google are the gate keepers for what goes on their native app stores. I can
cut some slack for Google as they at least allow third party app stores but
Apple doesn't.

Either Apple should stop being the gate keeper or stop making life harder for
web devs.

~~~
Razengan
Maybe Apple could offer a compromise and allow users to sideload apps, but
restrict non-App Store apps from accessing the file system or any kind of
personal identification (like location etc.)

And improve their documentation to lower the barriers to native development.

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

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

~~~
vbezhenar
User not coming to website 7 days can't be invalid use-case. Losing important
data simply because someone went on vacation is unacceptable.

~~~
im3w1l
So store this data on the server.

~~~
matsemann
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

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

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

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

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

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

~~~
roblabla
The standard is called "web app manifest". You can find it at
[https://w3c.github.io/manifest/](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.

------
reilly3000
This is really in response to the irresponsible use of APIs for trackers.
Evercookie is a stunning example of how far it can go... From their repo:

\- Standard HTTP Cookies \- Flash Local Shared Objects \- Silverlight Isolated
Storage \- CSS History Knocking \- Storing cookies in HTTP ETags (Backend
server required) \- Storing cookies in Web cache (Backend server required) \-
HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode) \-
window.name caching \- Internet Explorer userData storage \- HTML5 Session
Storage \- HTML5 Local Storage \- HTML5 Global Storage \- HTML5 Database
Storage via SQLite \- HTML5 Canvas - Cookie values stored in RGB data of auto-
generated, force-cached PNG images (Backend server required) \- HTML5
IndexedDB \- Java JNLP PersistenceService \- Java exploit CVE-2013-0422 -
Attempts to escape the applet sandbox and write cookie data directly to the
user's hard drive.

[https://github.com/samyk/evercookie](https://github.com/samyk/evercookie)

In short, everything and more can be used for tracking, and that has really
killed the party for the many people who have created responsible, useful
applications of these browser APIs.

~~~
schoenobates
“... abusing over a dozen technologies...” is this a proof-of-concept or a
real thing ? It just seems too horrendous to be real.

I think your comment really hits the nail on the head, IMHO the frustration
shouldn’t be directed toward Apple but more toward the groups who have pushed
the tracking practice so far to necessitate such draconian measures.

~~~
wmeredith
This is 100% correct. Being upset at Apple here is exactly like publishers
whining about ad blockers when they should direct their frustration and anger
directly at the ad creators (or themselves) for foolishly abusing their
audience.

~~~
brlewis
No, the two are different. Ads are only used for ads. localStorage has lots of
uses, tracking users being only one of them. Apple is throwing out the baby
with the bath water. Ad blockers merely throw out bath water with varying
levels of dirtiness.

------
robenkleene
I’m guessing that Apple will start hindering web apps because the new mouse
support in iPadOS is going to be such a boon to web apps. Because of
sandboxing, web apps are the only cross-platform apps that can run in their
full versions on iPadOS. I wrote a quick summary of the situation[0].

Therefore, since native apps are more of a platform differentiator than web
apps, moving forward we can expect Apple to start systemically hindering web
apps, especially on ones that are good on iPadOS, in order to boost native
apps.

(I’m not saying this necessarily the start of this, but I am saying I'm not
surprised. This is exactly the type change, targeting the exact type of app
I’d expect to be targeted.)

[0]: [https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-
su...](https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-support-will-
benefit-web-apps/)

~~~
cageface
_moving forward we can expect Apple to start systemically hindering web apps_

They have been doing this for quite some time now. Always ostensibly to
protect users but always also conveniently putting webapps at a permanent
disadvantage to native apps.

For my part I'm not interested in being a user of a platform so hostile to the
web that it disallows any third party browsers.

~~~
TheKarateKid
> _Always ostensibly to protect users but always also conveniently putting
> webapps at a permanent disadvantage to native apps._

This isn't always a bad thing though. For example, Safari has prohibited some
obnoxious behavior that Chrome has allowed: Autoplaying videos, tab
suspension, push notifications. These hog CPU and destroy battery life,
worsening the user experience.

Remember, making _everything_ a web app is Google's agenda because _they_
benefit most from it.

~~~
dzhiurgis
MacOS Safari autoplays YouTube videos with now way to disable...

~~~
Gaelan
Interesting. I can tell Safari to not autoplay videos on YouTube in its
preferences, but that doesn't seem to do anything. Seems more like a bug on
Safari's part and/or workaround on Google's part than anything deliberate.

~~~
TheKarateKid
Safari uses some sort of algorithm to determine whether you actually _want_
the autoplay to happen.

For example I've noticed that if you play a video on a website during that
session, it will allow autoplay from scripts on that page (not 3rd party) for
the rest of that session. Same for unmuting an autoplaying video.

This is all undocumented though and through personal observations, as Apple
seemed to stop posting Safari documentation years ago.

------
arghwhat
Better title: Apple restricts tracking by limiting browser storage, which
hurts my particular app.

Browsers _need_ to be severely limited due to them running arbitrary code from
the web. Doesn't matter if it's an offline web app. If you want more access,
make a native app (with or without web technologies).

~~~
fierarul
But browsers are severely sandboxed already. What the article is talking about
is:

> deleting all local storage (including Indexed DB, etc.) after 7 days

which I can see how it might help privacy (since you could be tracked via
local storage too) but also how it might break any potential web app that
might need data to last more than 7 days.

> If you want more access, make a native app

But then, everybody will complain about yet another Electron app, right? Not
to mention that you have to fork over $99 and go through the signing /
notarization hoops that change from one week to the other.

I think in the name of privacy and security only Apple and some select few
corporations will be allowed to make software in the future. macOS / iOS and
Windows 10 are evolutionary dead ends in many ways.

~~~
DagAgren
They do not "change from one week to another". They have changed, what, twice
ever?

~~~
fierarul
Two counterpoints:

* AdoptOpenJDK releases that were notarized some months ago are no longer accepted by Apple since they made the rules even more stringent. I had releases accepted by Apple that are not accepted today using the same AdoptOpenJDK binaries.

* Apple's notarization rules are not global. There's whitelists for given companies/institutions/apps/files which means the same dylib might not have to be notarized by a bigger player but will have to be codesigned by you.

The above happened to me in the span of less than 3 months I think?

Indeed, the scripts I use per se to do the notarization are about the same as
originally.

~~~
saagarjha
Do you have more details about this?

~~~
fierarul
I think I gave quite some details. Do you need the exact AdoptOpenJDK version
(11.0.5+10 for macOS)?

And I made a test about the non-global rules too (by trying to submit the same
binary and getting rejected).

~~~
saagarjha
Apple may have stepped up notarization requirements, but I never heard them be
inconsistent across developers. Are you sure you submitted the same binary?
Nothing different about the signing or bundle layout?

~~~
fierarul
Well, I would love to know how to change the bundle layout to have to sign
less.

My notes are here:
[https://www.patreon.com/posts/34472331](https://www.patreon.com/posts/34472331)

You can take the same Apache-NetBeans-11.3-bin-macosx.dmg and see how you
could submit it with your own key.

I guess there may be different rules on a .pkg vs .app in a DMG but it seems
silly since the user gets the same bits on disk.

------
finaliteration
I’m a little confused by this and maybe I’m missing something. Wasn’t
localStorage always intended to be treated as a volatile storage mechanism for
non-critical data and caching? The advice I’ve seen for several years says to
avoid storing sensitive or critical data there.

Can PWAs not switch to using IndexedDB which seems like it’s more purpose-
built for this use case?

No snark intended. I’m legitimately curious what the situation is and where
any blockers are.

~~~
judah
In the original post from Apple[0] announcing these measures, they've listed
all script-writable locations are subject to cache clearing:

\- Indexed DB

\- LocalStorage

\- Media keys

\- SessionStorage

\- Service Worker registrations (I guess this means service worker caches)

[0]: [https://webkit.org/blog/10218/full-third-party-cookie-
blocki...](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-
more/)

~~~
finaliteration
Thank you for outlining that! I missed the impact on Indexed DB in my original
read of the issue. It makes more sense, now.

------
vanderZwan
I would be OK with 7 days being the default with a permission model where I
can grant a website longer storage time.

Actually, I'd be even happier if _any_ form of offline storage required
explicit user permission anyway.

~~~
Aardwolf
> Actually, I'd be even happier if any form of offline storage required
> explicit user permission anyway.

Even offline storage that is only used locally? Say a game with savegames that
has doesn't use online connection to play it.

Another example: a password manager.

~~~
SkyBelow
I would say yes. The reason being is that exceptions will be abused, so it is
better to enforce rules that everyone has to follow than to depend upon good
behavior which the people we are trying to stop won't (almost by definition,
because we wouldn't be needing to try to stop them with rules if they were
already respectful of the social contract).

------
pat2man
Sounds like the solution is to add the app to your home screen. I don't think
its reasonable for a browser to let any site I ever interact with to store
data on my device indefinitely

~~~
soapdog
Even web apps that you add to your home screen are subjected to this.

~~~
redindian75
"Web applications added to the home screen are not part of Safari and thus
have their own counter of days of use."[1]

From WebKit: [1] [https://webkit.org/blog/10218/full-third-party-cookie-
blocki...](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-
more/)

A Note On Web Applications Added to the Home Screen

As mentioned, the seven-day cap on script-writable storage is gated on 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.

If your web application does experience website data deletion, please let us
know since we would consider it a serious bug. It is not the intention of
Intelligent Tracking Prevention to delete website data for first parties in
web applications.

~~~
iameli
> Web applications added to the home screen are not part of Safari and thus
> have their own counter of days of use. [...] We do not expect the first-
> party in such a web application to have its website data deleted.

I don't get it. Which of these statements is correct?

1\. "Web applications added to the home screen are not part of Safari and thus
have their own counter of days of use. Of course, that counter doesn't do
anything. It just sits there, counting, for no particular reason. We just love
counting things!"

2\. "We do not expect the first-party in such a web application to have its
website data deleted. Except, of course, if they don't use the web application
for seven days. In that case, that data will be _extremely_ deleted! Really
just wiped from the face of the earth."

~~~
kyralis
Neither.

The counter is per days of application use, so (2) is false. Not using the app
does not affect the counter.

The counter is also per domain, and so while the _first party_ domain for the
PWA (which is likely to, of course, be loaded on each PWA launch) is
effectively meaningless, if you visit other domains from within the PWA they
will be subject to the counter independently.

~~~
Dylan16807
So let's say I launch the zombocom app, then click a link inside the app for
"zombo updates" that goes to their twitter.

Then the next few times I switch to the app, I don't launch it from scratch, I
just look at the twitter.

Then I've gone seven days inside the zombocom app without touching their
actual domain.

Does everything except the twitter cookies get deleted?

~~~
iameli
I believe the first-party primary domain of the app will never have its data
wiped — though the article could certainly be clearer on the point. What would
be cleared in that case would be any _other_ domains — if there's also a
"Visit Zombo Facebook" link in there, and you only looked at Twitter for a
week, the Facebook cookies would be wiped.

------
Abishek_Muthian
I think looking at Apple as saviour of Privacy, is for lack of better term
just wrong. They have always favoured closed systems even if didn't provide
privacy advantages or as in this case was counter-intuitive for privacy.

I feel the comparison of Apple with data companies such as Google, Facebook is
by itself at fault. Apple like any computer company of 70's was not into data,
just because Internet itself didn't exist at that point like it does now.
'Apple didn't choose to be in data' is projected as altruistic, instead of
just a marketing ploy(they didn't choose, because it wasn't available).

Apple doesn't receive even the fraction of scrutiny Google, Facebook receive
(which they should). e.g. iCloud hack, Apple's response to iOS vulnerabilities
targeted by state actors, Newer Safari being incompatible with privacy
extensions such as uBO etc.

Personally I feel good that Apple is not into data, just because I feel if
they are into data; they might be more evil than Google or Facebook aided by
their walled garden.

~~~
Arnt
This is webkit, which is open source. Apple took an existing HTML/CSS/DOM
engine, rewrote it, renamed it, and opensourced its version, too.

It's compiled using LLVM, which also contains thousands of lines of open
source code by Apple.

Of course you might argue that these examples don't prove your sweeping
statement false, but please read
[https://en.wikipedia.org/wiki/No_true_Scotsman](https://en.wikipedia.org/wiki/No_true_Scotsman)
before arguing.

~~~
testtesttest
Open source is not the same as open. You can't run Firefox on an iPhone.

~~~
tekstar
Sure you can

[https://apps.apple.com/ca/app/firefox-private-safe-
browser/i...](https://apps.apple.com/ca/app/firefox-private-safe-
browser/id989804926)

~~~
summerlight
Sure you can't. That's not Firefox, but Firefox-branded Safari.

~~~
anticensor
You can run real Firefox too, if you jailbreak first.

------
alkonaut
Did PWA's take off? What are some famous/big PWA's now? I can't remember ever
"installing" anything in a browser as an app, or even being asked if I wanted
to do it. Am I misunderstanding what they are?

~~~
seanabrahams
PWAs haven't taken off because Apple won't implement full Push API support in
Safari thus forcing you to go through the App Store if your web site or
application needs push notifications. The App Store then complains if you try
to publish an app that just wraps your web site so that you can have push
notifications. It's... infuriating.

~~~
asadlionpk
Seeing all the "enable notifications" popups on every site I visit, I am happy
that Apple doesn't allow this for websites.

~~~
seanabrahams
Sites could easily only prompt this after you've added them to the home
screen. Browsers could, do?, also allow users to set a default of deny all
notification requests.

The problem is that developers have to spend a significant amount of time and
money to get on iPhones because of Apple's policy here. If browsers and
devices fully supported PWAs developers could "write once, run everywhere".
Instead we have to build separate apps and deal with separate release
processes. It's a huge productivity cost.

------
davweb
I think the original post is oversimplifying the new behaviour a little. If
you look at the other blog post on ITP 2.3 [1] it says:

> ITP 2.3 caps the lifetime of all script-writeable website data after a
> navigation with link decoration from a classified domain.

i.e. the 7 day timeout for local storage only kicks in if you've been
redirected from a domain that ITP has classified as one that tracks users. So,
for example, web apps that users navigate to directly will be unaffected.

[1]: [https://webkit.org/blog/9521/intelligent-tracking-
prevention...](https://webkit.org/blog/9521/intelligent-tracking-
prevention-2-3/)

~~~
BiteCode_dev
> website.example will be marked for non-cookie website data deletion if the
> user is navigated from a domain classified with cross-site tracking
> capabilities to a final URL with a query string and/or a fragment
> identifier, such as website.example?clickID=0123456789.

So my guess is you are fine most of the time, except if you allow other sites
to embed your content in their page. In that case, you should:

\- provide the embed on a separate subdomain

\- remove features requiring identification if the content is view embedded:
attempting to use them redirect to the real site.

Otherwise ITP will mark your domain as tracking and wipe you after 7 days if
your user don't interact directly with the site.

I have a hard time deciding if it's a good thing or not.

I guess it has the potential to be mostly a good thing, provided that:

\- I understood it correctly, which I'm not sure, as their wording is not
clear

\- It's implemented correctly. Once the deal is done, it's in the wild years,
fix or not.

\- It's implemented in good faith. Apple wants to promote the app store and
has shown to neuter web apps in the past.

I still have a strange bad feeling about this.

~~~
pier25
It's very confusing...

I still don't understand if Safari will delete a JWT in localStorage used to
talk to different microservices.

~~~
drkstr
JWT tokens are irrevocable by design, or it would defeat the purpose. I would
advise against issuing JWT token which are long-lived. Using "refresh tokens"
are generally more prefered, as this gives an opportunity to revoke a stolen
token in active use by the attacker. Even 7 days seems like an excessively
large session time. That is 7 days a stolen token can be used to forge an
authenticated session.

------
jwr
I have an app which isn't offline, but I wanted to make use of IndexedDB and
LocalStorage to make things faster for users. Now I wonder if it's worth the
effort to even try. I think this pretty much kills the utility of all local
storage initiatives.

My app is an inventory control system used by businesses that build
electronics ([https://partsbox.com/](https://partsbox.com/)). Deleting client-
side data after 7 days is ridiculous. You can't assume that people will always
log in every week, in small businesses or design/manufacturing companies there
are times when 2-3 weeks can pass without building new hardware or touching
inventory.

~~~
gok
Your demo page is 3.23 MB. ~500KB is javascript, ~500KB is CSS and another
~400KB is web fonts. The parts database is 24 KB. That's certainly not the
first place I would look for an optimization target, even for customers with
very large parts databases.

~~~
jwr
With respect, I believe you are mistaken about what my important use cases are
like.

Not going to go into details, but that JavaScript, CSS and fonts are all
immutable assets, never to be requested again, while the database is
_significantly_ larger for clients who run their businesses using this
software.

------
nicoburns
I really hope the outcry about this is big enough to get Apple / Webkit
reconsider. With service workers and improvements in browsers/cpus "PWA"s (aka
web apps) were just getting to the point where they could compete with native
apps for a number of use cases. And they had much better privacy / security
policies. This doesn't completely kill that, but it's a big setback.

~~~
JumpCrisscross
> _they had much better privacy / security policies_

Why is a PWA better from a privacy or security perspective than a native app?

~~~
judah
Security: it runs in the browser's sandbox. Native apps by contrast generally
have (or can request) full access to your system.

~~~
JumpCrisscross
> _Native apps by contrast generally have full access to your system_

This doesn't accurately describe iOS apps, the pertinent comparison with
respect to the article.

------
heynk
I'm an engineer at a platform that makes it easier to build privacy-friendly
apps. This means that all apps on our platform have app-specific private keys
stored on the client side (in localStorage), and they never touch a server.

With this change, you're essentially "logged out" after 7 days of inactivity.

This is pretty a bad user experience. I honestly am not sure how to mitigate
this. MacOS Safari might not be a massive market, but iOS Safari is.

Any thoughts about how we should address this change?

~~~
oefrha
Being logged out after 7 days of inactivity could be a little bit annoying but
I can live with that, as long as I can log in again.

I could be misinterpreting your comment but are you saying your keys are
simply destroyed upon this “log out”? Then I’m not really sure why your
platform was considered working in the first place, if it’s tied to a specific
browser of a specific device and won’t survive a clearing of storage which any
user can do at any time for a variety of reasons?

~~~
pier25
What if you don't have connectivity when localstorage is deleted and can't log
in?

Eg: in a classroom.

~~~
oefrha
What if someone accidentally erases everything because that’s what they’re
told when something doesn’t work right? Answer: it’s volatile storage in the
first place, and a tiny one at that. Heck some browsers can be configured to
erase everything when closed (when operating in non-incognito/private mode).

~~~
pier25
> _What if someone accidentally erases everything because that’s what they’re
> told when something doesn’t work right?_

The difference is that one situation is controlled by the user and the other
is not.

------
saagarjha
Related discussion from earlier today:
[https://news.ycombinator.com/item?id=22683535](https://news.ycombinator.com/item?id=22683535)

WebKit blog post from yesterday:
[https://news.ycombinator.com/item?id=22677605](https://news.ycombinator.com/item?id=22677605)

~~~
dang
I think we'll merge today's threads. Any reason not to? Edit: merged.

~~~
saagarjha
I can't think of any, they're all the same topic as far as I can see. The
WebKit blog post has a little bit about third-party cookies being blocked but
everyone quickly moved discussion to the script-writable storage cap.

------
jagged-chisel
I'm confused, or seeing confusion, over some things in the comments here. "We
don't use Safari in our app..." We're talking web apps: you know, web sites
with functionality. You don't exactly have control over which browser your
users use. And in iOS, everyone is using 'Safari' even if it's Firefox or
Chrome wrapped around the rendering control. This means you have to assume
that the policy affects any visitor from any web browser on iOS. Technically,
the other browser vendors can siphon the data into other storage to their
users' benefit, but I don't know how likely they are to do that, nor whether
Apple would approve them with such changes.

Do you mean that you deploy a 'native' app that's really just a wrapper around
a web view that would also be just Safari? Same policy applies, but now, you
have the option, in native code, to siphon off data and put it into Real
Storage.

------
rconti
> What are private client-side PWAs anyway?

(proceeds to not answer the question)

Found the answer: Progressive Web Apps[1]

1: [https://medium.com/@amberleyjohanna/seriously-though-what-
is...](https://medium.com/@amberleyjohanna/seriously-though-what-is-a-
progressive-web-app-56130600a093)

~~~
soapdog
Sorry, I wrote this blog post too fast because I was/am a bit angry and didn't
notice my usage of jargon without explanation.

It is a “Progressive Web App”. Sorry for the jargon usage without explanation.
Basically it is a marketing term used to place some new web APIs and best
practices into an umbrella of a “near native UX on a Web App”. What it usually
means is that your application is:

* Served from a secure context (a requirement for the other APIs anyway).

* Has an application manifest (this contains metadata about your web app and is used by browsers and OSs to add icons, names, themes, etc)

* Has a service worker (which enables your application to potentially work offline beyond what other cache solutions did in the past)

So with these in place, browsers can offer a “Install this site and an app”
feature which allows the site to open in its own window, with its own icon and
name on the launchers and home screens.

~~~
rconti
Thanks for your reply :) I recognize often articles are meant for a
specialized audience and shared here without the author even being aware of
the site, so it's unreasonable to expect that everything be described to a
total neophyte, but sometimes I have to laugh at the buzzword articles that
get posted here about how to implement foo in bar on baz, using a fizzbuzz
framework running blarg, and I have no idea what ANY of those things are,
having worked in tech for decades :D

~~~
soapdog
Also, I just updated the post with a definition and a link to learn more about
PWAs.

------
oefrha
The argument would be stronger if the post got into what privacy protection in
Safari isn’t available in the Apple News app. Instead there’s a seemingly
random plug for a content blocker app I’ve never heard about, which upon
further inspection happens to be sold by the author.

------
wolco
It doesn't scale from device to device for settings or items that should stay
for longer than a week.

Local storage should be treated as cache.. it may get refreshed.

What Apple did was fine. A backend isn't only for storage either.

~~~
soapdog
It is not fine if you're creating apps that don't have a backend.

~~~
finaliteration
Honest question - If you're creating an app like that, is a PWA really the
right way to go? Aren't there other options available (such as creating a
native app with a SQLite database)?

~~~
Cu3PO42
Sure you can do that. But now you need a Mac, probably an iOS device and pay
$99/yr to Apple. If you're just providing a small one-off solution for a
particular problem that you're not monetizing, the above may pose a serious
problem.

For example, I (used to) maintain a tool that is essentially a save file
viewer, but must store some data for decryption of said files. It's an
Electron app, but could work as a normal website for the most part as well. I
got a prototype of that up and it stores the required data in local storage. I
don't want to maintain and host a backend for it, and I'm not too hot on
paying Apple's developer fee for it, either.

You may say it's a fringe use case, and it probably is, but it's very much
legitimate. I don't know why they couldn't have made storage for longer than 7
days with an extra permission to be requested.

------
mr_toad
It’s _always_ been impossible to rely on local storage for long-term use.

Users clear their caches. They swap browsers. They swap machines. They use
their phone instead of their desktop. They use private mode, or sand boxing.
They re-install their OS. They buy a new machine.

Don’t be lazy. Using local storage without a backup is not acceptable.

And what kind of ‘progressive’ web app expects all the features in every
client? Have we forgotten what progressive means?

Don’t be entitled. You are not more important than your users.

~~~
lnanek2
Based on the blog, it sounds like he wants to downloaded RSS feeds to the
user's device, and not store them on his server to speed up development (all
those complaints about FAANG being able to develop at web scale and him not
wanting to run a backend).

Then, if the user clears cache or changes computers, they lose the stuff they
were following and have to wait for new items, but it's not the end of the
world. They might even expect it if you name/describe the app a certain way.

E.g. if you download an app called "Podcast Downloader" that says it just
downloads any new podcasts from feeds you follow for your later offline
consumption on your current device - you might not expect a podcast on your
phone to magically jump to your desktop without a re-download from the
original site.

Seems like it could be a valid trade off if it lets a front end only web dev
publish apps he couldn't publish otherwise because he can't/won't do backend.
Storing user media on the backend is not cheap. The company I'm at has spent
months of developer time moving over from Google to Amazon, for example, just
for infra cost improvements that come from serving terrabytes of data off one
instead of the other.

------
diegoperini
I already have a comment on this subject in a thread here but I believe this
should be stressed more explicitly.

Apple didn't kill offline web apps. You can always add an interaction to your
app which exports the stored data into a file which then can be saved by the
user. It can be done entirely on the client side as well. If anything died
here, it is the implicit consent by the user for allowing unnoticed storage
space consumption. Implementing an export function will automatically make
your app portable, which is always appreciated I believe.

Most data on local storage is some kind of structured tree, table or blob. All
can be exported with only little effort.

HTML5 games -> Prompt user with a dialog to download saves/assets after they
play the game for a while.

Productivity apps -> Detect "ctrl/cmd + s" to prompt a save dialog. Add save
buttons somewhere visible.

Map like apps -> Do nothing. If the user is not visiting the map for 7 days,
they don't need the map data persisted either. If necessary, allow explicit
save with UI buttons for people who travel often.

Apps/sites which use local storage for auth related artifacts -> Notify users
if they click "Remember Me" and explain them the caveats. Allow for encrypted
save if users ask for it.

Kiosks -> Use Electron or a similar tech.

I am open to counter arguments. I don't have any idea about how mobile
browsers behave for the scenarios stated above.

Edit: I use draw.io since last year and the experience there is as refreshing
as it can be in this SPA jungle. I use it as a good example to learn from for
my own web app projects.

~~~
donatj
This might technically work, but is an absurdly user-unfriendly.

Name a modern game that required you to manually manage game state files, let
alone didn’t have autosave. It’s a feature users expect, and they’re going to
have a bad time. I don’t want to play a quick game on my phone and have to
remember to save and where I am keeping my save files.

I’d argue a far better options would be just to treat local storage as a
permission like camera or microphones.

~~~
joeblau
I don’t even play games but I wouldn’t expect a web game to store all of its
metadata in my local storage. I would expect it to store data on their own
severs and only store active gameplay information locally.

My browser storage is not a game developers long term storage, its a cache.

~~~
gridlockd
It's not about metadata or "web games". It's about apps/games that can be used
offline. For that to work, _all the data_ needs to be stored client-side.

> My browser storage is not a game developers long term storage, its a cache.

IndexedDB is explicitly not a cache, it's long-term data storage for
significant amounts of data.

~~~
lstamour
Cookies can be used for storage for up to a year, but it’s commonly accepted
that browsers vary in implementation of this based on user settings. So why
wouldn’t user settings exist for other kinds of permanent or session storage?
Google Chrome is so dominant in both browser-making and standards-making that
we’ve forgotten the browser — and user — is always king when it comes to the
web. If users want permanent storage they will use alternative browsers for
those particular sites. And while site authors can block Safari with a prompt,
it’s then up to users to change browsers. Presumably for developers these will
have knobs to tweak so local storage can continue working in alternative
browsers on iOS the way it always has. Presumably Safari will eventually get a
config toggle for this setting if it isn’t already there. Users already don’t
notice when browser history is cleared, though advanced users will configure
this by following instructions on Google. Same here.

~~~
gridlockd
> Google Chrome is so dominant in both browser-making and standards-making
> that we’ve forgotten the browser — and user — is always king when it comes
> to the web. If users want permanent storage they will use alternative
> browsers for those particular sites.

No, they generally won't. There also aren't really any "alternative browsers"
on iOS, they're all Webkit-based.

> So why wouldn’t user settings exist for other kinds of permanent or session
> storage?

Nobody is saying there shouldn't be any settings or consent in this regard.
What we get here is not a setting, we get one major player deciding that there
will be no way to properly implement offline web apps on their platform.

~~~
lstamour
I disagree that there’s no way to implement an alternative to Safari, besides
Chrome there’s also iCab and other browsers that show not only a completely
different UI but also innovative new features. Even if WebKit makes it
impossible to remove this restriction, a third-party browser could find a way
to intercept calls and keep its own local storage, read and backup native
local storage, or provide other means to local storage via proprietary JS
APIs, and if that browser is Chrome, it will gain traction. Especially if
Apple changes iOS to allow users to change default apps.

------
WalterSear
This sounds like a death-knell for my personal project: a fully decentralized
collaborative task/wiki, built on ipfs, and encrypted against your blockchain
wallet. I had just migrated the backend from firebase, too, and was ready to
re-launch the beta next week.

Pretty much any PWA that was using ipfs as anything but a caching/distribution
layer is no longer viable. This is a huge blow to decentralization technology.

Sure, you can make a standalone app, but that is going to cripple already
difficult adoption.

This sucks :(

~~~
soapdog
I'm coming from a decentralization tech background as well and was working on
similar stuff. That's why I'm so angry at this arbitrary decisions by Apple.
This is just them breaking something that has been working well.

------
osrec
My comment from a similar article:

Rather than wiping local storage/indexed DB data after 7 days, could you not
just make it an opt in thing, like the camera or mic? For example, ask users
"Allow myapp.com to store app related data on your computer?". If they allow
it, then give access to local storage APIs, otherwise don't. That way users
can still have fully local PWAs if they wish.

As an ardent PWA developer, this change annoys me immensely.

------
true_religion
From the article...

> Heck, they could even go further and ban apps from corporations like
> Facebook, Inc., and Alphabet, Inc., that have violating your privacy as the
> core tenet of their business model.

If Apple were to ban the Gmail app (and obviously block web access via iOS too
because that would be a loophole otherwise), I would throw away my iPhone,
swear off business with Apple, and search dearly for a way to sue them.

I don’t love the walled garden iOS represents, I merely live with it in
exchange for great hardware and UX. If the bargain changes to be more
restrictive, I would turn against it in a heartbeat.

Thinking about that, is no surprise Apple is striking out early to make web
apps useless. If they wait too long, they will become entrenched, and people
will feel like they have lost something if access is restricted. Apple really
wants to jealously protect its control, and more importantly ability to take
30% tax of every transaction that they can perceive.

------
gfodor
We use local storage for features in hubs.mozilla.com when most sites would
use a database, because we want to minimize storage of data in our servers to
increase privacy. This basically will now force us to store this data in our
database for safari users, eroding their privacy.

------
jimpick
This is terrible...

I have a copy of my “DAT Shopping List” demo I last opened about 6 months ago
saved to my iPhone home screen... I opened it, and the data was still there.
I’ll be really sad when I open it again after iOS autoupdates and the data
will be nuked.

[https://github.com/jimpick/dat-shopping-list-
tokyo](https://github.com/jimpick/dat-shopping-list-tokyo)

------
andrewrothman
This is a serious problem for modern web experiences.

"After seven days of Safari use without the user interacting with a webpage on
website.example, all of website.example’s non-cookie website data is deleted."
([https://webkit.org/blog/9521/intelligent-tracking-
prevention...](https://webkit.org/blog/9521/intelligent-tracking-
prevention-2-3/))

Granted, this could turn out really well if the industry adopts another
standard which requires user permission, overcomes this limitation, overcomes
the existing limitation of LocalStorage on iOS getting automatically cleared
when a device is low on storage, and overcomes the problem of sites being able
to use up a lot of storage on users' devices without their knowledge.

I'd be very welcoming of such a standard. These could be good future
replacements if the industry can adopt them:

[https://chromestatus.com/feature/6428344899862528](https://chromestatus.com/feature/6428344899862528)

[https://wicg.github.io/kv-storage/](https://wicg.github.io/kv-storage/)

[https://chromestatus.com/feature/5715811364765696](https://chromestatus.com/feature/5715811364765696)

[https://storage.spec.whatwg.org/](https://storage.spec.whatwg.org/)

------
thehappypm
Maybe I'm being cynical here -- I'm not a web developer but have lots of
experiencing managing web-based products -- but if you want to have state you
should store it in the cloud, because local devices are volatile. Xbox Live,
for example, uses a fairly simple service for cloud saves for games; local
saves still happen but any developer has the option to push saves to the
cloud. The author definitely raises good points about how it's easier for
developers to not have to worry about it, but cloud saves have some hefty
benefits, like multi device support, user getting a new device, etc.

~~~
duxup
The problem is (at least for me) offline apps, or for customers who have poor
or intermittent / unpredictable internet access.

They threw LocalStorage and etc out with the bathwater that are cookies.

~~~
thehappypm
Rightfully so. We won't have a cookieless world if the entire tracking
industry basically just switches to LocalStorage when cookies finally die.
Enough whack-a-mole.

------
flixic
Safari already was lagging behind Chrome, Chrome forks and Firefox in a lot of
feature adoption. This will only make it more of a "new Internet Explorer", a
browser that sites recommend you NOT to use.

~~~
scarface74
Good luck with telling people not to use Safari (or more accurately WebKit) on
iOS....

~~~
EGreg
You’re right. Tell people not to use iOS

[https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-
io...](https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-
ios-13-iphone-cellular-data-problem-iphone-11-pro-max-u-iphone-xs-max-xr-
update/amp/)

You Apple users will put up with anything!

(disclaimer: iOS user)

~~~
megous
Lol, 50GB unexplained mobile data consumption. That'd be 3 months worth of
rent on my mobile data plan. Good luck ever getting out of debt if that
happened on some more expensive international roaming.

------
aazaa
The article doesn't exactly cut to the chase. Here it is:

> "...But deleting all local storage (including Indexed DB, etc.) after 7
> days..."

From the Apple announcement:

> Now ITP [Intelligent Tracking Prevention] 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. ...

[https://webkit.org/blog/10218/full-third-party-cookie-
blocki...](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-
more/)

------
judah
On one hand, I don't like this direction from Apple because it's meant to
boost Apple's proprietary app store business -- which directly competes with
the open web -- but masquerades as a privacy issue.

On the other hand, this direction keeps web devs honest: local storage,
service worker, cookies and other script-writable areas are meant to be
temporary.

~~~
fomojola
I see nothing in any of the specs that implies local storage was intended to
be temporary? You could argue cookies, maybe, but even that I'd dispute: it is
a user-agent, I should be able to tell it "don't delete my stuff". I already
have browser controls over my local storage: I can go into settings in every
reasonable browser and flush that down the tubes.

------
tarkin2
All moves of Apple's towards privacy are tempered with the knowledge that
smooth, successful webapps hurt the iPhone's business proposition.

Apple want to move you closer into their walled garden with the prospect of
enhanced privacy.

The idea that iPhone apps are more private than web app because Apple must
approve your apps is troublesome.

------
rs23296008n1
If privacy really is the thing, why can't I have an extension on ios to let me
expire various cookies/storages on a per domain name basis, eg so I can write
my extension to limit some cookies/storages to _minutes_ or even _seconds_
depending on how hostile or blacklisted such things are.

Other domains I'd actually prefer to be indefinite. I've got a notepad thing
that uses local storage and doesn't store its data on the server. There's no
excuse for deleting its data since its _user data_. Apple therefore has no
permission to delete that data. Do I have a non-cloud workaround for that?

~~~
hokumguru
Yeah, an App. They’re kneecapping the PWA to make apps more appealing.

~~~
rs23296008n1
I wonder whether my irritation over this is strong enough to App up
JustAnotherIOSWebKitBrowser with an extra API just for per site storage
explicitly controlled by user. Literally to run a notepad and some kind of
extension thing.

Its likely blocked by app store rules. Supporting extensions is probably
forbidden.

Anyone care to be more authoritative based on their AppStore
knowledge/experience?

------
Animats
_What are private client-side PWAs anyway?_

Good question. The definition of a "progressive web app" is vague. What they
seem to mean is a web page which, once you visit it, is cached locally, and
thereafter runs locally. The web page accesses various servers, not
necessarily ones from the same domain as the web page. Persistent state, if
any, is stored locally. The page gets its own icon on the home screen somehow,
so it sort of looks like an "app".

Apparently "progressive web apps" are supposed to have a browser service
worker so they can get notifications pushed to them from somewhere, although
it's not clear why that's essential. That would seem to depend on whether the
function performed requires being notified of something happening elsewhere.

Apple apparently dislikes this because they don't get to force people to use
their store, with their big cut of the revenue.

Is that about right?

Does this only apply to pages read through Apple's browser, or does it impact
Firefox, too?

~~~
JumpCrisscross
> _Apple apparently dislikes this because they don 't get to force people to
> use their store_

This is part of the motivation. The other is advertisers using persistent
local storage to track users [1].

[1] [https://clearcode.cc/blog/alternatives-to-cookie-
tracking/](https://clearcode.cc/blog/alternatives-to-cookie-tracking/)

~~~
oblio
Do they block native apps that track users?

~~~
frenchy
Only if you fail to use the Apple advertising ID. Tracking users is fine as
long as Apple holds the keys.

------
mattl
> By now, most people are aware of the amount of surveillance and tracking
> that their web usage is subject to on a daily basis and how this data can be
> used in ways that do not match their own personal values.

Sorry, but no way.

~~~
szc
The data for "Local Storage" is stored in ~/Library/Safari/Databases -- you
will need to give Terminal access to the Safari directory as the current
Sandboxing works both ways, Safari stores security config info in this
directory and scripted malware could / can exfiltrate data and change values
in this location.

To violate privacy (aka enable tracking) a sub-iFrame could be set up that
uses "local storage" with a parent page security policy that allows
communication across the iFrame boundary. Sorry, yes, I am being a bit vague.

Who cleans up ~/Library/Safari/Databases? I personally see crud in this
directory from 2011 that has been migrated from older systems.

Almost not relevant now, but Flash also had a "local storage" system that was
shared across all Flash Apps. It also allowed (before sandboxing) local apps
to proxy and communicate (via shared memory) with any standalone Flash App on
the system through any page that used the Flash plugin -- i.e any running web
browser, violating all attempts to have web compartmentalization rules.

~~~
szc
I think some threads have been merged. I am now seeing some posts that confirm
what I say above, but were made earlier in time that I had not seen. My
experience and perspective is from security and privacy defense, rather than
"find the loophole". [edited for clarity]

------
judge2020
Is there any evidence that local storage is being used as a pseudo-cookie way
of tracking users? If so, keeping local storage saved while regular cookies
are being deleted would defeat the purpose of deleting cookies for anti-
tracking reasons.

~~~
hosteur
This is exactly what it is about. I welcome the move from Apple. Web devs can
store state server side. They cry because tracking will be harder now.

~~~
soapdog
I'm the OP and I'm crying because I'm working on apps that don't have backend
so that your data is yours and never leave your computer. This is now
impossible for WebKit users.

~~~
vbezhenar
So you have to track Apple users now if you would implement backend storage.
How ironic.

~~~
chickenpotpie
Exactly. Now I'm working on PWA that stores address data locally and now I
have to have a backend db just for Apple users.

------
djsumdog
I love that the app he wants to build is an RSS reader. I just did a post on
why we should be making more use of RSS as individuals:

[https://battlepenguin.com/tech/rss-the-original-federated-
so...](https://battlepenguin.com/tech/rss-the-original-federated-social-
network-protocol/)

Interesting he ran into the CORS situation with PWAs. It makes sense. It feels
like even PWAs aren't that far off from Electron. Sure you're not launching
another browser and can share a browser engine, but you hit other limitations.

I'd rather have a real, lightweight, stand alone app most of the times
honestly. I wish people would write more stuff in Qt5. You can bundle
Python+PyQt5 together for a reasonable licensing fee. A great example is the
Resolve color/video editor is written in C++/Qt5.

------
throaway9aaaapp
Our company has started shaming iOS. We tell users that because of a
commercial policy aiming to increase their revenue from their App Store,
iPhones and Ipads "do not support the Web 2.0 technology enabling powerful
experiences for web sites and web applications, while Android and Windows
devices have been supporting this technology since 201x". We briefly explain
in one sentence that it would not be the best use of our resources to try to
bypass Apple's technological decisions but that they should contact Apple for
further information.

We then link them to a $30-$50 Android device that they can buy on Amazon and
use as a second device to use our services "if they are interested in a more
powerful web experience". We provide a basic version to all users, but put a
shamewall for advanced features. Best use of our time and resources.

It is time to push back, stop making Apple's problems your problems. Educate
people without ranting and offer them solutions, developers have the bad habit
of trying to cover up this kind of non-sense and taking the blame while really
Apple are the ones who should be ashamed. If people love your product/service
getting a $30 phone to be power users and make their life easier and their
experience richer will not be a big deal for them. It's all about educating
them the right way.

~~~
spzb
Obviously I have no idea what your product is but if I got that message I'd
just likely go to one of your competitors (assuming they exist). I wouldn't go
and buy another device unless it was for an absolutely critical application.

~~~
shadowgovt
> assuming they exist

And that's the real nature of the market, isn't it? If enough third-parties
aren't willing to play by Apple's rules, Apple will have to modify the rules.

They're a stubborn company, but it's happened before. They've also been burned
trying to own a standard when a common consensus exists they can't control
before.

------
arendtio
What did we expect? I mean how long is it now that Apple refuses to implement
the Push API properly (which in turn is a basic requirement for many PWA use-
cases). They clearly try to use their influence to defend their App Store
revenue. And to make it look good, they do it in the name of privacy.

------
themihai
Offline Web Apps were already weak(i.e. CORS restrictions). Now they are even
more useless with this storage limitation. You can't really blame Apple..
after all, Google claimed that offline web apps are nothing more than websites
so that's what we have... I don't mind if Safari deletes offline data stored
by websites every week so why would I complain about "offline apps" ?

My point is that Offline Web Apps (i.e. PWA) that are installed on user's
desktop should have a bit more permissions than websites but people in
charge(google, apple etc) seems to think otherwise.

[https://discourse.wicg.io/t/proposal-full-network-access-
in-...](https://discourse.wicg.io/t/proposal-full-network-access-in-
progressive-web-apps/3602)

~~~
pier25
Read the article, it's not only about offline PWAs. All local storage is
deleted after 7 days.

~~~
themihai
As for as "persistence" is concerned I really care only about offline PWAs.
Why would a website need offline data after 7 days? It would improve
performance, that's true but everything else should be "fresh" unless that
said website wants to actually behave like an "app". Maybe the "website"
should ask the client to be installed as "app" if the user wants to take
advantage of persistent storage(and other "app" features) . Asking the user to
install(which is actually just a kind of bookmarking for PWAs) isn't that much
of an effort if the user is planning to use it regularly.

~~~
dylan-m
I made one of these. We generally expected users to be offline for at least a
week. Probably using the app regularly on their respective devices (but
possibly not), and syncing data again when they had a good internet
connection. Uses Dexie and React, syncs with a horrible Drupal site. It's
always going to be uncertain to rely on a database held at arm's length by the
browser, but in practice it worked _incredibly_ well on all manner of devices.
I guess it won't anymore. (Thanks, Apple!).

This is absolutely a necessary change on some level, but I think if Apple
wasn't in complete control of a web monoculture (and obviously uninterested in
anything that doesn't sell more iPads), it would be possible to steer this API
towards that without breaking a bunch of peoples' stuff.

------
sidhanthp
I think this is a good idea. Developers should not be able to store something
on my computer indefinitely without my consent. This doesn't apply to
applications users add to their home screen.

This doesn't "destroy" the PWA ecosystem. Just makes a user's intention
explicit when they save a PWA to their home screen, rather than continuing to
use it within the browser.

From the WebKit Blog ([https://webkit.org/blog/10218/full-third-party-cookie-
blocki...](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-
more/)) "Web applications added to the home screen are not part of Safari and
thus have their own counter of days of use."

~~~
duxup
Your browser is already caching a whole lot of stuff that you don't know about
just by visiting a site.

A little LocalStorage isn't going to hurt you.

Cookies I get, but I don't know of any dark patterns with localstorage / the
benefits are pretty great.

~~~
judge2020
I asked about the dark patterns above and got answers confirming it
[https://news.ycombinator.com/item?id=22687214](https://news.ycombinator.com/item?id=22687214)

~~~
duxup
I'm not convinced that actually confirms much.

One of the pages linked there just says local storage is used to store
stuff... yeah? It's still not as wide open as cookies.

You could use local storage while doing other things, but i'm not convinced
it's a serious issue with tracking or etc. ... and if ANY storage is
considered an issue I think we're in for a big snowball effect on what we
should or shouldn't allow from ... anything, including native apps, etc.

------
awinter-py
push messaging also doesn't work for PWAs on ios

(it does on android)

I get that controlling the walled garden is apple's mobile strategy now, but
this is costing developers so much blood sweat & tears.

Both xcode and android studio are heavy + horrible compared to web, and the
fact that you have to use _both_ tools to release at scale makes them worse.
Shopify wrote a dev post a few months ago saying 'we're react native as much
as possible now' and claiming it makes life easier, but react native is worse
than PWA because you still have to build for mobile 2x and deal w/ app store
nonsense.

If PWAs supported push on ios, with or without cookie expiration, they'd be
the preferred launch strategy for most non-game apps.

~~~
p1necone
Hasn't aggressively controlling the walled garden _always_ been Apples
strategy? I don't see them changing any time soon. iOS didn't even _have_ an
app store initially, and it took a lot of pushing for that to happen (they
realized Android was going to eat their lunch if they didn't).

------
dennisy
This "feature" also invalidates the use case for WebCrypto API, since a user's
keys would be stored in IndexDB, which now means keys cannot be safely
persisted.

~~~
synfonaut
Exactly this. Most "non-custodial" web wallets will die as a result of this
change (some may even lose money/assets). Very unfortunate Apple!

------
yeahkapp88
Since when was software freedom synonymous with we should all want to use
PWAs?

I’d be happy if Spotify gave me an API key and essentially went away except
for a monthly bill.

But software has to be a product the masses get first to get made in our
world.

I’m glad some folks are having their itch scratched but free streams are more
than enough and I can wrap them for consumption as I choose.

Once again building your life around importing someone else’s priorities turns
into an exercise of despair from not learning how reality doesn’t stand still
no matter how hard you hope it will this time.

------
starbugs
Is this really that big of a problem? You had to be expecting that local
storage is deleted without any notice anyway, in every web app.

~~~
IvanK_net
I have many useful files in my computer, which I don't want to be deleted. You
are saying, that it is ok, if the OS deletes all files in my computer from
time to time.

A local storage is the only way webapps can store any data in your computer
(other than asking you to manually load / save some configuration file). Not
all webapps can afford cloud storage for all user.

~~~
starbugs
I am not saying that it is OK to delete all your files. I am saying it has
always been like that in the case of a browser's local storage.

As I said, that use case was out of the window long before. From the start, as
far as I know.

No browser has ever given you any definite promise on whether your local
storage data will be kept. That's also true for IndexedDB. So you need a
mechanism to restore that data, be it cloud storage or something else.

If you wanted to support Safari private browsing, you even had to deal with
local storage not being available _at all_.

~~~
IvanK_net
I disagree. The IndexedDB was introduced as a permanent way to store data
(which is not deleted after closing a website). As it is the only available
standard for permanent storeage, I think it should be deleted only if the user
asks to delete it (the same way you delete any other file in your computer).

Of course, browsers are free to do whatever they want. But the user can (and
will) switch to the software, which does what he or she wants.

~~~
starbugs
You disagree with the status quo implemented in browsers or you disagree with
the decisions that were made years ago (by browser vendors), because you
basically cannot guarantee for that (disk full, privacy settings, private
browsing, etc.)?

~~~
nicoburns
It's different if there is a technical limitation (disk full - computer tend
to barely function in this state anyway), or the user has opted in to
ephemeral storage. But to not give users the choice to store things
permanently is quite a severe restriction.

------
blauditore
Wait, does that mean that the only way to keep a login session for more than 7
days will be by using cookies? This seems like a terrible idea. Cookie
authentication doesn't make sense in several scenarios, especially when
working in a CORS context.

For webapps that keep a session token stored locally, this will be inevitably
wiped, so users will have to re-login after that time. I can already hear the
complaints coming. Should devs now build a back end just to keep the token,
and connect there with a cookie?

------
jchw
Actually, Apple has crippled non-PWA apps. I agree that Apple does seem to not
want PWAs to succeed based on my experiences with them on my iPhone, but on
the other hand this effectively does not apply to PWAs that are added to the
user’s home screen since the counter only runs every day Safari runs but
homescreen sites have their own counters.

I worry that 7 days is too short of a period even then, but I do agree
indefinite local storage does not make sense in most cases.

------
sandstrom
How would static "single-page" apps (HTML/JS/CSS) that store session tokens in
localStorage avoid 7-day auto-logout?

Perhaps using something like this: [https://developer.mozilla.org/en-
US/docs/Web/API/Credential_...](https://developer.mozilla.org/en-
US/docs/Web/API/Credential_Management_API)

Anyone know of other Web APIs that could be used?

~~~
aurbano
Cookies are a lot safer for authentication than localStorage. The only problem
with this change is persisting data for offline use, not authenticating the
user.

------
taway555
I'd rather use a native app than a PWA any day of the week. The experience of
a mobile web app is clunky, slow, typically ugly, and just a generally bad
experience.

------
est31
Offline web apps are direct competitors to apps from the Google play store and
Apple app store. You can't expect Apple to be fair to them if they are missing
out of their 30% for every USD of revenue on those web apps.

------
40four
This just sounds like a great reason to not use Safari. I switched to iOS
recently, but I’m a dedicated Firefox user, so I personally don’t touch it
except when I’m forced to by other apps opening links. (I was honestly REALLY
disappointed in Apple when I realized that you’re not allowed to set a default
browser besides safari, but that’s another story)

Forgive me, I’m a long time Android user, but do a lot of people _choose_ to
use safari as their main iOS browser, or are the usage numbers inflated
because of the vendor lock in?

~~~
hoten
All browsers on iOS are webkit (read: safari) under the hood. Firefox and
Chrome are just skins.

~~~
40four
Thanks for correcting my ignorance :) that makes more sense.

~~~
hoten
np! It's quite a frustrating state of things.

To be clear, only the rendering engine is fixed on iOS. Chrome, FF get some
leeway to build other bits of the browser themselves on iOS, such as the
netstack and the UI. But all new web features are limited to what webkit
supports bc, well, it's webkit.

------
KarlKemp
I don’t remember ever seeing this usage pattern in the wild? As far as I
understand, it would always have resulted in data loss whenever users chose to
clear browsing data. There also wouldn’t have been any natural way for backups
or synchronization.

A browser plugin might be one way to achieve something like this. Personally,
I really don’t care about the data my feed reader has, so I wouldn’t mind even
public data storage backends, like gist. Or steganographically encoding my
list of feeds and uploading it to porn sites :)

------
mathiasrw
Why not let users give access to that one site use data older than 7 days? So
data stays but its only being deleted if you click that it can access (first
time only - next time it remembers)

------
andrewrothman
I commented about this in a different thread about the same topic earlier
today, but I'll post here as well.

I can understand Apple's decision to do this, as there's a lot that can be
improved about offline storage on the web:

* asking for user permission (i've seen demos try to exhaust the users' storage, and trackers can use this to invade privacy) * async writes and reads

However, making a change like this with no suitable alternative leaves PWA
developers stuck in a hard place. I'm not sure what can be done in the short
term here.

There's a few web specs that address these issues. I'd love to see them come
further along, and maybe improve things for developers and users in the long
run. If anyone knows, is there anything that members of the community can do
to support these efforts?

[https://chromestatus.com/feature/6428344899862528](https://chromestatus.com/feature/6428344899862528)

[https://wicg.github.io/kv-storage/](https://wicg.github.io/kv-storage/)

[https://chromestatus.com/feature/5715811364765696](https://chromestatus.com/feature/5715811364765696)

[https://storage.spec.whatwg.org/](https://storage.spec.whatwg.org/)

------
sneak
A bit offtopic, but the following is my basis for interpreting privacy-related
claims from Apple.

I noticed a text editor I bought from the Mac App Store, iA Writer, includes
silent spyware that transmits your activity back to the developer without
notice or consent (thank you, Little Snitch). Apparently, I "consented" to
this in the Mac App Store ToS (right).

When I left a negative review on the app, their response was "we aren't doing
anything not permitted by Apple in the App Store".

I don't use App Store apps any longer, and I take most of what Apple says
about privacy with a huge grain of salt.

PS: OSX phones home to Apple in about a dozen different ways even with iCloud
_entirely_ disabled and _all_ reporting/telemetry/feedback options turned off
during the OOBE/setup. Try doing booting a fresh install of macOS with Little
Snitch, but _disable the Apple /OS exemption_ in Little Snitch's rules. I was
_astounded_. _Dozens_ of things.

I wonder if there's any major, widespread GUI OS in a default configuration
that does not transmit to your ISP and third parties (including government
snoops) when you open a local text file to write. I block all of these
requests; most do not.

I am reminded of Winston Smith's paper journal.

------
Aissen
There are still people who believe Apple cares about the web platform, 12
years after they forbade browser competition on iOS ?

------
megous
How does this make sense logically? Obviously the websites that you use the
most have the biggest potential and opportunity to track you. All local
storage should be deleted for the most used websites at random times, at avg.
several times a week, without any extensions caused by recent website usage.

If this is done for privacy's sake, that is.

~~~
quotemstr
> All local storage should be deleted for the most used websites at random
> times, at avg. several times a week, without any extensions caused by recent
> website usage.

No matter what browser vendors do, it will never be enough for "privacy"
activists.

------
dubcanada
I don't understand what the problem is.

I can easily go to the settings area and delete my entire browser cache
(Remove All Website Data), in fact if you are running low of space it even
tells you to do it.

Why are people assuming things stored on a browser are a good place to store
things. Nothing stored on a browser should be assumed to be forever.

~~~
beering
If you read the article, that's the issue the author was talking about: it's
basically impossible to make an app that can store its data locally, instead
of on some web server.

All apps that you download from App Store can live offline, where they're
usable without Internet or trusting some faraway web server.

You can't make a web app that can do that, and to some people it smells like
Apple trying to force developers to release through App Store.

~~~
mulmen
I don't really understand this. If you want to make something local, make an
app and distribute through the app store, that's what it is for. A _web_ app
on the other hand is connected by definition, no?

Apple forcing local apps to distribute through the app store is a _feature_.

~~~
untog
> A web app on the other hand is connected by definition, no?

No, not in the era of "progressive web apps", which is really just a little
bit of branding around interconnected APIs. The Cache API in particular means
that a webapp can be downloaded and made available offline on a permanent
basis. Unless it isn't actually permanent at all, which is what Apple are
doing here.

The web and the App Store are just delivery mechanisms for code with different
trade-offs built into them. Apple have added an extra trade-off on the web
side in the name of privacy.

~~~
munk-a
Having worked on a cross platform application that defined the UI via HTML I'm
still kinda confused about this use case - it's super trivial to wrap a set of
HTML + JS in an app that's essentially just a full screen webkit/whatever
window and distribute this.

The advantage of PWAs then seems to be the ability to dodge the app store
certification which, while onerous, is not a bad thing for your clients.

~~~
vially
> [...] is not a bad thing for your clients

Except when you have to pass some of the 30% Apple fee on to your clients.

------
chadlavi
If you want to make an app that someone can use offline on their device, why
are you making it as a website at all?

------
goofballlogic
While I agree with the concerns regarding arbitrary implementation of standard
APIs, there are still a bunch of useful applications of PWA technology to
enable temporary offline operation.

The more we use these, the more likely the APIs are to be fully implemented
(and hopefully have features added to them).

------
fredsted
Feels like Apple is just continually making the Safari browser worse.

I think they just want to push people towards native apps so they have full
control. Apple always wants control.

First they prevented plugins like uBlock, made it very expensive to create
your own plugins, and now they're messing up LocalStorage.

------
eyesee
Would it be possible for Apple to relax the 7 day limit for apps that are
strictly client side only? I.e. sandbox the apps to not allow access to any
remote resources? It seems to me the opportunity to exploit a user's privacy
would be very limited without exfil.

~~~
icebraining
Maybe, but it would only apply to a subset of PWAs. For example OP's RSS
reader must access remote resources.

------
_pius
This headline rewrite does a disservice.

It editorializes away the point of the post, which is that, according to the
author, "Apple just killed offline web apps while purporting to protect your
privacy [by forcing WebKit to delete all local storage after 7 days]."

------
homakov
Have a look at data: URI technique we developed to avoid Apple/App Store
altogether for critical apps:

[https://coins.github.io/secure-bookmark/](https://coins.github.io/secure-
bookmark/)

------
hawaiian
I know I'm in the minority, but I'm glad this change is happening. I simply
don't trust large tech companies to keep user privacy a top priority, and in
my mind, this outweighs whatever UX niceties an honest company may provide.

~~~
jeswin
The solution could be to give that option to users; a way to mark a website or
app as trusted or not. Apple's approach on the other hand really sets the web
apps back, which I (as a privacy concious individual) am more comfortable
using compared to apps.

If this encourages more apps to go the native route, we've done more harm than
good. Apps can gather a lot more data than websites, such as the dreaded
contact list access.

------
soapdog
OP here, I just posted an update section there with some extra information
that I decided to clarify upon after interacting with people here. Thanks a
lot for the responses, this has been quite great. I wish more people that are
affected by this or that have opinions about it would write more posts.

There is no change without applying pressure at Apple. If this is important,
we must speak about it, all of us. And yes, I understand that some people feel
that this is not important for them, that is OK, we have different values and
understandings, but if you have an opinion about this, please go out and post
to your blog, dev.to, medium, whatever, but post.

------
thosakwe
I don't understand why the title was changed - the focus of the article isn't
just on the fact that WebKit is changing how it handles local storage, but
also a criticism of Apple's motivations for this decision.

~~~
zeveb
_And_ the new title no longer has any relationship to the title of the post.
And no admin (from what I can see) even bothered to let us know why he
censored this.

edit: 17 minutes after posting this comment critical of moderation, I am
unable to submit a new story. Coincidence?

------
jrs95
Given that PWAs don't work particularly well with iOS anyways even if you have
a PWA you're probably better off deploying it to the App Store via Cordova and
prompting users to install it from there.

------
Andrew_nenakhov
The issue would be not that problematic if I could just run a real Firefox
browser on iOS, not a skin over Safari, which leads me to a question that
puzzles me for a long time.

Why Apple is not facing antitrust charges for not allowing competing browsers
on their platform? Microsoft didn't SHIP competing browsers, but allowed them
to run just fine on windows, and was fined nonetheless, but Apple somehow gets
away with not even allowing competing browsers at all!

I'm not from the US, so maybe I'm missing something about these antitrust
lawsuits. Can someone please explain?

~~~
Karunamon
This is a common misconception.

1\. Apple is not a monopoly player in the app market.

2\. Microsoft's antitrust fine was for forcing OEMs to not include any
competing browsers (Netscape) on threat of losing special pricing.

~~~
Andrew_nenakhov
> 1\. Apple is not a monopoly player in the app market.

Apple has a 100% monopoly in the app market by running the only AppStore
available for iOS devices, and that store review guidelines specifically
prohibits use of any other web rendering engine but WebKit [1]

> 2\. Microsoft's antitrust fine was for forcing OEMs to not include any
> competing browsers (Netscape) on threat of losing special pricing.

That's not the only lawsuit they faced. There was EU case that forced MS to
make a special installer [2] for alternative browsers.

I really can't perceive the meaningful difference between these cases. And I
believe it's about time to force Apple to allow installation of alternative
app stores, from where users would be able to install all the apps they want,
without being handcuffed by device manufacturer.

[1] [https://developer.apple.com/app-
store/review/guidelines/](https://developer.apple.com/app-
store/review/guidelines/)

[2] [https://cutt.ly/ztn4kxr](https://cutt.ly/ztn4kxr)

~~~
Karunamon
The critical bit here is "for iOS devices". The legal definition of monopoly
is interested in the broader market, not what the manufacturer of a device
with comparatively tiny market share does.

iOS with a 13.4% global market share as of 2019 does not even come close to
monopolist status. While I'd like to see iOS forced open as well, there is
currently no legal method to do so.

------
mfer
This whole thing is about trade-offs.

If tracking companies cannot use cookies they can use JS and local storage
instead. Then they can keep tracking people for long periods.

So, in the escalating war Apple alters local storage so that non-use for more
than 7 days doesn't keep data along. It becomes less valuable for use with
tracking.

The trade-off is that offline web apps become less capable and some use cases
go away (e.g., completely offline).

Which trade-off is better for whom and in general? I've not thought to know.
But, the trade-off is worth pondering. Whether we agree with Apple or not.

------
MaxBarraclough
As the article explains, _Offline Web App_ is being used to mean Progressive
Web Application (the standard terminology).

( _edit_ Turns out that's not quite right, see diggan's reply.)

From the article:

> You’d almost think they had an App Store to promote or something.

There's certainly a tension here. I'm still not sure why more vendors don't
make iOS PWAs to get around the App Store payment rules.

Perhaps related: Very roughly a year ago, something changed in iOS that broke
the _2048_ PWA. Its swipe-detection no longer works. A pity.

~~~
diggan
offline web apps are different than PWA. A PWA doesn't necessarily work
offline, but more is independent from the connection / loading of it. I do
think most PWAs do work offline, but doesn't mean it's a requirement to call
it a PWA.

Similarly, an offline capable web app is not necessarily a PWA, as PWA carries
a lot of features to it besides being offline capable.

~~~
lonelappde
What is an "off-line web app"? If an app _never goes online_ and is sandboxed
from other apps, then it never has any data at risk of exfiltration.

~~~
diggan
An offline web app is a frontend-only application (just HTML+CSS+JS or less)
that can be loaded from any medium (internet, usb stick, direct TCP via netcat
or any other transport) and work in your browser without requiring a remote
connection to allow usage of it's features.

So yes, this would mean it doesn't run the risk of ex-filtration or snooping
at the transport layer, as the data never leaves the specific website context
in your browser.

------
slaymaker1907
I agree, this is really stupid. Data should only be reclaimed when requested
by the user or if more storage is needed on the system on a LRU policy per
site.

~~~
olliej
Could you ask all the privacy abusers to stop using them to abuse privacy?

Seriously, you should browse the web for a bit and see just how many "client
side PWAs" you've used/installed, vs how many tracking identifiers have been
installed.

------
stcredzero
_Many web developers are turning to Electron in these cases but IMHO this is a
waste of resources as the Electron runtime is not shared among the different
apps running and there is only so many browser engines your computer can run
before it has impact on its performance_

Why? Why isn't the case that the code which runs Electron, and library code
JIT-ted by Electron can't be reused by other processes on the same system?

------
muneeb
Can decentralized (i.e., user owned) storage help here? Instead of keeping
data only at user device, it can be backed up in an encrypted and private way.

Gaia is one example:
[https://github.com/blockstack/gaia](https://github.com/blockstack/gaia) (I've
worked on Gaia so I'm biased but there are other such decentralized options as
well.)

------
gtsop
People complaining about how PWAs haven't taken off yet are extremely
ignorant. Go open up your dev tools and see how many websites you've visited
make use of at least some PWA features (most likely cache) without you even
noticing. PWA features have a lot to offer to the web experience even without
installing the app. You've been enjoying these features and you don't even
know it.

------
chrisfinazzo
An update from John Wilander would seem to confirm that this _could_ happen in
Safari - and they consider it a bug.

Of note, John’s replies also mention this policy does not apply to WKWebView
or UIWebView, because they lack ITP.

[https://twitter.com/johnwilander/status/1242882202301427712?...](https://twitter.com/johnwilander/status/1242882202301427712?s=21)

------
greyhair
It still comes down to the point that everyone wants you to load an app from
an app store. Which drives me nuts. Just give me the web, please.

PWA is about the web.

------
pgt
When suppliers do this, they put customers back into a buying position.
Instead of defaulting to buying another iPhone, I’m back in a buying position.
So let me ask: what is a good alternative to an iPhone Xs on the market? I was
also super close to buying an Apple Watch, but now I’ll defer that purchase.

I have already stopped building native apps because the App Store process is
so painful.

------
restoreddev
I guess this means Safari won't support persistent storage anytime soon. I was
looking forward to it becoming a standard API.
[https://developer.mozilla.org/en-
US/docs/Web/API/StorageMana...](https://developer.mozilla.org/en-
US/docs/Web/API/StorageManager/persist)

~~~
OJFord
Based on the table there it seems Edge had but removed support anyway?

------
nojvek
Unpopular opinion but this is the kind of shit that makes websites have a
banner “Safari browser will experience issues, use Chrome browser for the best
experience”.

I remember when Edge/IE was crap, I put up a couple of banners that
Firefox/Chrome/Safari are officially supported browsers and people did move
away from Edge. Had <1% of traffic from there.

------
franga2000
Not on the main topic, but since OP mentioned CORS being a pain: is there a
reason the browser doesn't let sites do cross-origin requests, but just
without any cookies etc.? Either through a separate API or just the default
behavior in the absence of CORS headers, is there a reason for that not being
a thing? I can't imagine nobody has thought of it?

------
bitL
The inability to save local files really hinders PWA and just allows all the
shady large players to enforce their self-serving rules.

------
jmull
Ah.. well, ok, but this is pure nonsense.

First of all, the various kinds of browser local storage have always been
volatile. It has always been a _bad idea_ to treat it as permanent storage.
Maybe it's a little more obvious now? Not exactly a bad thing.

> the PWAs I was building here might just be dead for iOS users

If so, it was already dead for your users, whether you realized it or not. I
guess you were going to implicitly promise something you could not deliver:
that your PWA would keep track of the feeds the user was subscribed to (and
perhaps also keep track of what had been read, and other user state). But you
were going to _screw your users_ , because a PWA without external persistent
storage could not do that reliably. It's really luck for your users that this
caught your attention and has you rethinking your app.

A partial list of things completely external to your app (not including this
change) that could cause your users to lose things important to them that you
stored in various local storage...

    
    
        * user switches browser
        * user has multiple devices 
        * user upgrades phone (or tablet, or workstation, or laptop)
        * phone (or other device) goes in for repair or upgrade
        * major change to browser (like Edge moving to chromium)
        * some OS updates
        * user clears browser data (as innumerable troubleshooting processes suggest)
    

It's wrong to think browser-based storage used to be stable but now isn't. It
never was. Browser-based storage was never going to be a good place to store
your user's important, persistent data.

------
booleanbetrayal
I can't seem to find whether or not these policies and storage caps are
implemented in a WkWebView context. Any idea?

------
pier25
Is this also going to affect web views?

For the past couple of years I worked on an education app where users are 90%
of the time offline. Users can remain offline for weeks. There the is no
reliable internet in most of the schools in Mexico.

I don't work on that company anymore but this is going to be a massive
headache.

------
ocdtrekkie
I find localStorage a bad crutch, when storage accessible to any browser or
computer would be better. I'm totally cool with this because magical storage
in your browser is just a bad idea, especially when it requires developer
tools to find and see what it is doing.

------
diminish
Apple is at war against the open web and tries to kill it at all cost.

Most apple apps are privacy hogs which don't have any way to turn off
tracking. In apps, Apple created a prison which noone can question and
everyone will allow them to do all abuse. Look at Apple News.

------
matlin
What we really need is a way for users to store their own data that has the
simplicity of local storage but the convenience of storing data in the cloud.

It does seem that Apple intends to cripple web technologies in order to move
developers to their native platform but this will likely do more damage to
privacy than anything. All of the alternatives to local storage for simple
mobile apps typically involve moving data to a third parties like Firebase,
AWS, etc.

Simple apps that didn't need a server and could just keep data or user-
preferences locally would now need to either create their own data service or
pay for a BaaS which means moving your data out of your control.

This behavior leads to companies like Under Armour to house data they
shouldn't have and puts everyone (150M people) at risk.[0]

[0] [https://www.wired.com/story/under-armour-myfitnesspal-
hack-p...](https://www.wired.com/story/under-armour-myfitnesspal-hack-
password-hashing/)

------
briandear
What’s wrong with a “normal” app? No server required and data stays only on
the device. The argument that the author is building a PWA because other
people abuse privacy (with apps) doesn’t make much sense. Why not build the
app, respect privacy, and be done with it?

LocalStorage is not a substitute for an actual database, it’s a cache. The
problem with the author’s technique is that privacy minded users clear their
browsers from time to time, so they would be inadvertently clearing data they
actually wanted to keep because who uses LocalStorage as a persistent data
store? Sure it could be used like that as an “off label” use, but generally
it’s used to cache what is persistently stored elsewhere or used as a means to
avoid multiple network calls in the process of doing something (such as saving
calculations, the results of which would be eventually persisted.) Local
Storage should be used as if it were a session store rather than something
persistent.

~~~
sj4nz
The problem with a "normal" app is now you are beholden to the
rules/regulations/evaluations of a third party that can easily decide without
recourse that your "app" should not be in their store. Even if your app "is
fine" every update and upgrade incurs a delay through the third party's
reviewing process before your users receive it.

If the web browsers would provide _some API_ for persistent storage without
yanking the carpet out from underneath developers this wouldn't be such a huge
problem. There _used_ to be a file-access API but it was removed.

Personally, I think web browsers are too large a surface area to secure/keep
secure and the world is probably going to swing the opposite direction to
native, downloadable applications without the interference of a third-party
store.

~~~
danans
> Personally, I think web browsers are too large a surface area to secure/keep
> secure and the world is probably going to swing the opposite direction to
> native, downloadable applications without the interference of a third-party
> store.

Wait, you think downloadable native apps without any intermediary to validate
them is more secure? What you're describing is basically the old shareware
system, which was riddled with security issues.

------
sebringj
That is terrible if you are working on a pwa game to cache assets offline.
There should be some opt-in approach similar to location tracking in the
background like some apps do. That seems way worse than simply having local
data be relied upon. Not cool.

~~~
icebraining
What's the problem with the client having to re-download those assets if they
don't play for a week? Seems long enough that I'd expect a patch download on a
typical gaming platform, for example.

~~~
bdefore
Offline iPad kiosks

------
jwiley
Is there anything to stop an application from touching the cache periodically
(in the Unix sense of updating modification timestamps without changing
values) on load?

If so, assuming the application is used more than once every 7 days, this
seems like less of an issue.

------
soapdog
OP here, I just posted an update section on the post that touches some of the
comments I've been seeing here. English is not my first language so I think
that sometimes I don't make my ideas clear enough or well explained enough.

------
pier25
This won't accomplish much in the long term. Ads networks will simply start
introducing server side SDKs. Websites that rely on ads will gladly use those
to keep their revenue even if that means more load on their server.

------
jka
At the time of writing, the first sentence of
[https://www.apple.com/privacy/](https://www.apple.com/privacy/) states:

"Privacy is a fundamental human right."

------
bovermyer
Maybe I'm missing something here. Why not just build a native app instead?

------
joeyspn
Well, wouldn't surprise me if Apple is now trying to kill aspects of the "open
web" they dislike. Ironic because they used "upcoming" web standards as
argument to kill Flash.

Apple will do whatever it takes to protect its closed ecosystem, and if that
means killing PWAs built with open web technologies they'll provide any
dubious excuse to justify it (security, privacy, blahblah). They did the same
back in 2010, killing a perfectly valid app platform that was picking up
momentum, but they didn't control. A platform that was 5-10 years ahead of the
"open web".

Looks like this time they won't use HTML5 as piss-poor excuse.

[https://en.wikipedia.org/wiki/Thoughts_on_Flash](https://en.wikipedia.org/wiki/Thoughts_on_Flash)

------
talkingtab
A previous HN discussion about PWA's replacing native apps:
[https://news.ycombinator.com/item?id=22554745](https://news.ycombinator.com/item?id=22554745)

------
AndrewBissell
Cedric Beust said on an episode of "Talking Kotlin" awhile back that he
thought the Achilles' Heel for the WebAssembly cross platform story would be
Apple moving to lock down their devices.

------
dang
Thread about the webkit.org post from yesterday:
[https://news.ycombinator.com/item?id=22677605](https://news.ycombinator.com/item?id=22677605)

------
Klasiaster
I don't think this will help against tracking because a the tracker has no
problem to refresh the identifier multiple times before the 7 day span would
kick in.

------
things
It's not super clear but, if I'm reading it correctly, the 7 days are 7 days
of use. So if you don't open the site for 3 days, the counter is still at 0.

------
40four
Anybody have an idea what the significance of the 7 seven day cutoff is? Can’t
imagine this magic number does anything to improve security. Seems kind of
arbitrary.

~~~
chadcmulligan
7 days is the side loading limit I think, so they're regarding these apps as
sideloaded? Everything has to go through the App Store as a guess?

------
pwinnski
So Apple can't really care about privacy because:

\- They have a News app

\- They haven't rejected apps from Google and Facebook

Can you imagine what would happen if Apple rejected apps from Google and
Facebook? Can you even fathom the outcry?

Apple News uses differential privacy and doesn't track user history, but yes,
they do provide personalized News I guess? They must not care about privacy at
all then!

If you're upset about a seven-day limit on local storage, okay. I get it. It
sucks. But to claim Apple's reasons for this are invalid because they allow
Facebook apps to exist, that's... weird.

------
endorphone
Posts like these are much more convincing when they simply make a case for
some allowance or some functionality, or point out the downsides. The moment
they go into whataboutism or grander claims of conspiracies or ill intentions
they fall apart.

Rational readers click back and move on. You end up just preaching to the
choir.

This particular complaint is paradoxical because Apple birthed web apps, and
has done more than anyone to make them a reality. Unfortunately they remain a
_very_ rare beast -- extraordinarily rare -- and are dwarfed by the privacy
concerns of people using iOS just to browse. So the team dealt with that.
Seems a fairly obvious pros and cons analysis.

Maybe they'll add an exception for installed to desktop webapps.

------
rvanmil
I do not understand why anyone would want to store anything other than
temporary/disposable data inside their browser.

------
garganzol
Pretty much an expected move from Apple in its current state, shape and form.
Security is such a sweet excuse for a tyranny.

------
z3t4
Apps added to the shelf should keep their data

------
andy_ppp
Am I right in saying this prevents any embedded widgets that need to show a
logged in version, i.e. comments or whatever...

------
chrisshroba
Does this also mean you'll have to re-login to websites every 7 days? (Sorry,
not very familiar with web tech!)

~~~
icebraining
No, you'll have to re-login only if you haven't been to the site in the last 7
days.

------
shireboy
Does this affect Cordova apps? They use WebKit and may store stuff like api
tokens in local storage

------
jjtheblunt
Perhaps this style of app, on iOS devices, drains more battery power than
deemed reasonable?

------
progx
Then data will stored online on servers, i cant see how this is better for
privacy.

------
cmsj
> deleting all local storage (including Indexed DB, etc.) after 7 days
> effectively blocks any future decentralised apps using the browser (client
> side) as a trusted replication node in a peer-to-peer network

Sounds good to me, I don't want websites turning my browser into a p2p node :)

------
p2detar
Why 7 days though? Why not 30 or 3? What are Apple basing this number on?

------
dirtylowprofile
I have an app on the App Store that uses WKWebView, should I be worried?

------
stwrong
Does this consider hybrid apps like ionic or Cordova to be part of this?

------
aww_dang
Supporting Safari reminds me of supporting Internet Explorer years ago.

------
simion314
Will this affect all browsers that in iOS are forced to use same engine?

------
Jach
Workaround: encode your app's state into window.location.hash

~~~
withinboredom
I've seen this before on an ecommerce site :sigh:

Wife: Hey, check out this! [link with embedded state]

Me: Wow, I'm logged in as you and can even see your payment information! Let's
not buy from this site!

Let's not do this. Ever.

~~~
recursive
Not all data is sensitive data.

------
rini17
This can't be prosecuted as anti-competitive practice?

------
bradgessler
Do any lawyers out there know if Apple's sabotage of PWA's by their inaction
or "features" like this could be considered anti-competitive behavior for an
anti-trust lawsuit?

~~~
yaktubi
Not a lawyer but probably not. There’s many ways to make an App for their
platforms. Just because people want to use web technologies is an implementors
decision.

------
rapind
It would be nice to eventually have a standard way (OS / browser specific) of
asking permission to use permanent storage with restrictions. Could be locked
down by domain etc.

------
tech_dreamer
PWA was an aberration - apple fixed it :)

------
arkanciscan
People who use WebKit deserve it

------
coffeefirst
Great... So all those "consent to cookie/GDPR/etc/subscribe to our newsletter"
popups will now reappear every time you go 7 days without visiting a site.

I'm 100% on team privacy but this isn't the right way to do it.

------
dirtylowprofile
I have apps using WKWebView should I be worried?

------
brainthomson808
it's really confusing

------
cjc19
Property Wisdom Adminstration

------
marta_morena_23
Whoever uses local storage as persistent storage doesn't understand what local
storage is. 7 days is enough. Local storage is supposed to allow your app to
temporarily navigate around connection issues, to not require "always on". You
can never rely on this storage to be permanent, there are just too many ways
to accidentally wipe it all and for the user there is no easy way to back it
up.

Your offline app should ALWAYS sync to the server whenever possible. The only
bad thing I can see here is that if you can't upload the data in time and the
user then doesn't use your app for 7 days, he will lose what he last worked
on, but such is life and why you should rather use real apps. Offline apps
needs to work differently, they need to get permanent storage just for that
app but only if the user explicitly choses to install it like that. Not every
random page should get permanent storage on your device. This is the right
move, Apple might just lack an alternative for apps you actually chose to
"install permanently" ;).

------
meesterdude
webkit is open source - can't this be changed (be it by fork, or a commit
proposal?)

~~~
matkalaukku
Sure it can be forked, but the problem is the millions of devices running
Apple's version of Safari/WebKit on iOS without any say in it except switching
to Android.

------
phkahler
IMHO adding more local storage via browsers was a huge step in the wrong
direction from the users point of view.

------
IvanK_net
It is related only to WebKit (Safari). So I think people will just switch to
other browsers.

~~~
diggan
Except for iPhones/iPads where you don't really have a choice. Also most
people don't give a shit which browser they use, they just use whatever
browser is available when they get their device, which makes sense. But those
users might soon have their data removed without really understanding why.

~~~
IvanK_net
So I guess more people will switch from iOS to other devices.

I am the creator of a photo editor www.Photopea.com and I see, that more and
more people care about their browsers. They spend a lot of time discussing the
issues of their browser with me, because they need to do a serious work in it.

~~~
foepys
You can install other browser frontends on iOS. People just don't know that
the backend is still Safari.

------
alexcroox
Are we absolutely sure they don't just mean the localstorage containers that
aren't part of the current domain? In the same way they are clearing cookies
from a different domain, and not the ones that belong to the current domain.

EDIT: Clarification from a Webkit dev
[https://twitter.com/alexcroox/status/1242559843354972161](https://twitter.com/alexcroox/status/1242559843354972161)

~~~
dangoor
Yeah, if you look at the section in question, they're talking about this:
"However, as many anticipated, third-party scripts moved to other means of
first-party storage such as LocalStorage."

Basically, the ad tech/tracker folks were using first-party site storage to
store identifiers, which is what Apple's trying to protect against.

------
floatingatoll
Perhaps the author doesn't realize that WebKit is open source. They could have
used their screed to propose to the WebKit team that a first-party page loaded
from a file:/// URI not have its client-side storage subject to the 7-day
purge, by setting the "firstPartyWebsiteDataRemovalMode" network connection
property to "none" — patch included! But they did not, which is quite
disappointing.

The new change to ITP is here:
[https://github.com/WebKit/webkit/commit/4db42c1571d821572ea9...](https://github.com/WebKit/webkit/commit/4db42c1571d821572ea91abe10aedf942b774562)

The cookie filtering logic specifically is located here:
[https://github.com/WebKit/webkit/search?q=filtercookies](https://github.com/WebKit/webkit/search?q=filtercookies)

The file:/// handler is implemented here:
[https://github.com/WebKit/webkit/blob/master/Source/WebCore/...](https://github.com/WebKit/webkit/blob/master/Source/WebCore/fileapi/File.cpp)

(I don't have anything to do with Apple or WebKit.)

~~~
DiabloD3
Apple does not use _that_ Webkit branch, however. They maintain their own
branch internally that cherry picks from upstream. Webkit could very well
accept a patch, and then Safari never ships that patch because they disagreed
with it for use in Safari.

Also, unrelated fun fact: Did you know Webkit still uses svn? That Github repo
you linked to is a clone of Webkit's own git repo (git.webkit.org), which is a
mirror of their actual repo (svn.webkit.org).

------
donohoe
I think it is worth noting that you can really say "Apple" is doing this or
"Apple" is doing that with decisions at this level.

The company is just too big and not working in unison.

The Apple Safari Team is killing/hurting offline apps. The author asks why
they don't take the same approach in Apple News - as if it is the same team
that is in charge. Different team with different priorities and likely not
talking to each-other.

I think the larger point is valid - but it better to understand that this
isn't some cohesive cross-company strategy at play. Its size-able teams
working on their own priorities within a larger roadmap (presumably).

~~~
diggan
As Apple is one of the most closed companies, it's hard to put blame on
anything Apple-related as you don't really know who the teams are. Sure,
WebKit contributors are visible as it's an open source project, but who is the
"Apple Safari Team" really? And who is the "Apple News" teams?

Easiest is just to put blame on the top-level entity, which is Apple. They
have control over their teams so they can redirect the blame if they feel it's
needed.

And if this change is to be able to force more developers to build native apps
on their platform, then it's for sure a cohesive cross-company strategy. But
we don't know if that's the case.

