Live data from Hacker News

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

andregarzia.com

351–360 of 927 posts

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

#351

Earlier quoted context omitted.

> they'd need to have me log in and send the config data to their servers You'd have to log in. That's a hurdle that involves implicit consent.

Respecting someone's privacy doesn't mean forcing them to "consensually" give up their privacy.

Thank you. I think this is very often overlooked. "Consent" gets thrown around alot but most of the time people basically have no choice if they want to, you know, participate in modern society. That's one of the reasons why an open web is so so so important and why I think Tim Berners Lee is working so hard to try to bring some part of that back as the "online world" (apps and internet) become more and more walled garden.

If you are coerced into giving consent, it isn't consent, and most of the time if you're doing it so you can be part of the world around you, it is coerced, whether people want to recognize that or not.

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

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

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

#353
post #321

Earlier quoted context omitted.

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.

Technically it's disallowing third-party JITs / executable data. Which is a good thing all-in-all.

Actually the guidelines specifically ban non-webkit rendering engines.

> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

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

#354
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" ;).

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

#355

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

> They have always favoured closed systems even if didn't provide privacy advantages Yes. > or as in this case was counter-intuitive for privacy I fail to see how this is counter-intuitive for privacy. > iCloud hack Targeted spearphising? > Apple's response to iOS vulnerabilities targeted by state actors https://news.ycombinator.com/item?id=20897368 > Newer Safari being incompatible with privacy extensions such as uB…

> I fail to see how this is counter-intuitive for privacy.

It makes it impossible to have an app that stores data in localstorage reliably, instead requiring it to be backed up on the app's servers.

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

#356

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

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

IndexedDB is also subject to the 7 day limit. Leaving no persistent storage for web apps at all.

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

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

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

#359

Earlier quoted context omitted.

I'm interested. As a iOS developer I always found that user want to skip the login page soon as possibile, if there is an FB button they press it. Do you have different experiences of it?

I run away from services that only allow social media logins. 1) I don't want social media to track me everywhere 2) If the people developing this app have taken this shortcut, what other bad, leaky implementations do they have on their site/app? -> No thanks, exit this way

Web-wide analytics (and our own, which have almost exactly the same stats), show about 30-40% of users still rely on email/password (and that's actually growing, as password managers become more ubiquitous especially when Apple implemented the built in credential manager in apps and in Safari on iOS).

We're actually getting rid of social login in our apps. And we're not alone, alot of platforms I use have recently moved the same direction, and I think for the same reasons.

Google, Facebook, Github, Twitter logins proliferated because

a) the cost of implementing an auth system is high, and those offered a turnkey solution that was cheap and quick to implement. This is no longer true, there are lots of options now to host your own auth while federating the hard work to someone else (e.g. Auth0, Cognito, et al)

b) for awhile, people LOVED the idea of having "an online identity" and a single login everywhere. Over time this has not really panned out, because it's the prisoner's dilemma; for it to work, everyone has to do it (which is why G and F have tried so hard to get everyone to use them). But also, because privacy questions have reduced the shiny appeal of that scenario in the first place. Combine that with easy to use password managers now, and it's much less necessary.

Post reply on HN