Workaround: encode your app's state into window.location.hash
That works as long as the user keeps the tab open, but if they use a bookmark (or just remember the domain), the hash part will be lost.
Private client-side-only PWAs are hard, but now Apple made them impossible
451–460 of 927 posts
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#452Did 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?
https://appsco.pe/ has popular PWAs. They don't need to be installed, they just look and work like an app on the browser.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#453Did 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?
The key is the 'P': Progressive. A PWA is just a web app, but one that takes advantage of features you'd typically see in a locally installed application like local storage, notifications, etc. This might mean it has metadata to make it "installable" in browsers that support that, but I wouldn't say that's a requirement to be considered a PWA.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#454How 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.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#455Did 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?
I'm the OP, I use a lot of PWAs. My main machine is a Surface Pro X and I don't have native apps (as in native aarch64 binaries) for many of the things I'd like to use. So, I'm using PWAs for Instagram, Twitter, Kindle, Pinafore (mastodon client), Spotify, and some of my own.
I was developing a feed reader that was supposed to be a client-side-only PWA but that's tricky.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#456Earlier 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 .
People keep wishing for a loophole. There isn’t one they won’t close sooner or later.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#457I’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 sys…
Which is strange, because they're already under scrutiny for being anti-competitive WRT their app ecosystem. Having good support for web apps could've softened that case a little bit.
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#458Earlier 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 .
A feature for who?
Not for users - now there's one less avenue for developers to get them something they want.
Not for developers - now they have to jump through additional hoops to make something that works cross platform.
Who exactly does this benefit?
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#459Did 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?
https://appsco.pe/ has popular PWAs. They don't need to be installed, they just look and work like an app on the browser.
they really “look” like an app
Re: Private client-side-only PWAs are hard, but now Apple made them impossible
#460Better 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).
> Apple restricts tracking by limiting browser storage But the argument that this will protect privacy in the first place seems really weak. Before this change in Apple's policy, an app could store my config data on my PC. After this change, they'd need to have me log in and send the config data to their servers. That seems like I've lost privacy, not gained it.
Wouldn't it be possible to retain the data with privacy by:
- Asking the user client side for a password
- Encrypt data as a blob using some symmetric encryption (AES)
- Push encrypted blob to the server with login attached
If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted for a "data" password for that particular site. Or would there be an easy way to build a pki/pin cert type of encryption to eliminate the password prompt? (I feel like this is essentially what Keyring!? would do but maybe not?)
Outside of implementation weaknesses which I feel could be mitigated by created standard libs to do this, what am I missing?
Bonus points for pushing the data diffs only or even a version controlled blob (data stored in a git repo where only the diffs are pushed in encrypted form).
Edit: Or how about a local hardware appliance for your network that stores all data like this encrypted and pulls from there.