Live data from Hacker News

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

611–620 of 927 posts

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#611
post #501

Earlier quoted context omitted.

"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... 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. This is a baffling word salad. So they are tracking days of use of home screen web apps... which sounds like it means that if you do not use the app for seven days the cache will be deleted... but they don't expect a w…

Home screen installed PWAs are treated as a separate web browser.

For all web browsers, content is only deleted after 7 days in which you use that browser. So if you shut for phone off for a month, and then turn it on, and open safari, that whole month only counts as one day, since you did not use the safari browser during that month.

The same rules apply to PWAs installed to the home screen, which are being treated as seperate browsers. Of course, the count of days of use of this "browser" without using the main site will always remain zero.

But for third party cookies, or third party content from an iframe that uses local storage, those would get nuked if the home screen installed PWA is used on 7 different days without interacting with those domains.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#612
post #493

Earlier quoted context omitted.

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

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.

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?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#613

I ported Polar ( 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 th…

Hi there, I'm the product manager for PWAs on the Chrome team.

Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t

Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recently (https://web.dev/progressive-web-apps). Consolidating and adding docs is an active area of investment, and our goal is to create a well lit path for developers to succeed with PWAs.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

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

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#615
post #483

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…

Ok but OTOH Apple is not helping PWAs by hiding the "Add to home screen" in submenus and not having an official API to show a banner like Chrome has on Android.

Edit:

Also what about desktop?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#616
post #506
post #379

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

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 pa…

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]

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#617
post #449

Earlier quoted context omitted.

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 developer…

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 .

> If you want to make something local, make an app and distribute through the app store, that's what it is for.

Have you ever gone through the app review process? It can be frustratingly capricious, which makes it very expensive. We've had features in our app for years, displayed in plain sight, and then all of a sudden they decide to block an update because of these utterly innocuous features. No rhyme or reason, and now we've got to spend dev time fixing a "problem" that never was a problem before. And we have to delay our entire update because of it.

PWAs offer a way around that uncertainty and added cost. There's also the cost of a developer license, and the Apple hardware you have to buy to run XCode (and probably iOS devices too, so you can test IRL).

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#618

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.

I also don't understand the alarm. There is no hard limit on how long things will be stored. Data in localStorage might still be stored for weeks/months/years, as before. The only limit is on how long things will be stored if the user does not interact with the site/PWA . If you are a website, not a natively-installed app, that I haven't "used" in a first-party sense for 7 days or more, I don't think your data belong…

Aren't there websites you use less than once a week?

If one of those is using a JWT for auth in localStorage (something which is extremely common) you'd need to login every time you visit such site.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#620
post #594

Earlier quoted context omitted.

Well it needs to be downloaded from the internet at least the first time, so it's intrinsically going to be less secure than an app that you can guarantee never connects to the internet.

Has to come from somewhere . A pwa might have to come via http (I'm not sure) - but html+js+css can come from the (from a) filesystem too. Like an USB-c memory stick. Or from an extracted archive (much like a native app).

> A pwa might have to come via http

They can't, PWAs can only be served over https

Post reply on HN