5 ms·
> Origin Private FileSystem Question that is both on and off topic. Is the Origin Private FileSystem permanent on Safari? Apple released an update a few years
by apatheticonion 3y ago
> Origin Private FileSystem
Question that is both on and off topic. Is the Origin Private FileSystem permanent on Safari?
Apple released an update a few years ago the cleared the contents of localStorage and indexeddb for an origin if the user hadn't visited in 14 days.
This makes it hard for purely offline PWAs to store data offline.
e.g. I wrote an offline only exercise tracker PWA (akin to "Strong" on Android) that used indexeddb to keep records and required no account. The 14 day policy makes it basically DOA for iOS clients.
Is the OPFS a viable alternative?
- streptomycin 3y agoLast I looked into it, it's not permanent in any browser. If you're low on disk space, stuff will get deleted. https://twitter.com/tomayac/status/1613605318407094275 https://twitter.com/tomayac/status/1613605318407094275 It kind of makes sense, given the constraints the browser devs have given themselves. Since there's no way for users to see/manage these OPFS files directly, there is no good alternative except automatically deleting stuff if disk space is low. What would really be nice would be if we could just create normal files and let users control them, but that doesn't seem to be in the cards. And it sucks. The #1 question I get for my PWA is "how do I stop it from sometimes deleting all my data?" and there's really no good answer.
- thayne 3y agoThere is a big difference between deleting when disk storage is low, and deleting if you haven't opened the app in 14 days.
- acdha 3y agoYes, but that is also the difference between it being used as a replacement for tracking cookies. There’s a reason why every browser not made by an ad network is more concerned about privacy.
- thayne 3y agoHow would it be used as a replacement for tracking cookies? The data is only accessible from a single origin (hence the name Origin private file system). This feature can actually benefit privacy, because it allows creating web apps that don't have to send data back to a server to store it.
- acdha 3y agoIt’s a potential long-term persistent identifier. Safari already deletes first-party cookies from sites you don’t regularly access so they need to review any other storage mechanism to ensure it doesn’t turn into a replacement with different policies. That’s also why they have a different policy for a PWA, where the user has expressed a stronger intention to use that site regularly. In this case, they implemented it following the same storage standard for everything to avoid inconsistencies. https://storage.spec.whatwg.org/ https://storage.spec.whatwg.org/ > This feature can actually benefit privacy, because it allows creating web apps that don't have to send data back to a server to store it. It’s more convenient in some cases than the other APIs for doing that, but it’s held to the same privacy policies. If you want persistent storage, you have to ask the user for it.
- streptomycin 3y agoYes, but they are both symptoms of the same problem. Ultimately as a PWA developer I'd love to just be able to save a file to disk and be able to rely on it the same as a native app can. And currently there are also other situations where browsers will delete your data, in addition to low disk space and the weird iOS usage requirements.
- lioeters 3y ago> no good alternative except automatically deleting stuff if disk space is low The good alternative is to use navigator.storage.persist(), which requests the user for permission to use persistent storage. Unlike other browsers, WebKit/Safari ignores this. Instead of asking the user for permission, it automatically grants or refuses permission based on website heuristics.
- streptomycin 3y agoThat is definitely not a good alternative. Three major problems I've had with it: 1. That heuristic is not just in Safari, it's in Chrome too. Firefox is the only one with a normal permission dialog. And the heuristic is really confusing for users! They come to me and say "how can I stop my data from being deleted?" and I have no answer if the heuristic says they can't enable persistent storage. 2. It only helps with eviction (deleting data due to low disk space), not other scenarios where data may be deleted. Such as clearing the "browser cache" without realizing what that implies, which may even be done automatically or through some third party app. 3. I have a place in my app settings page where users can see their persistent storage setting and also enable it if they want. I have many reports of users who enable it, then check back some time later, and somehow it's disabled. So the persistent data setting seems to not be persistent.
- lioeters 3y agoI've been working on a local-first web app, and ran into some of the same issues. Good to learn about these other pain points.. All of these make the so-called "persistent" local storage unreliable and impractical. I don't understand how browser vendors expect people to use such a feature where the data can be deleted at any time, where neither the developer nor the user has any control over how that happens.
- streptomycin 3y agoI don't think there is a real plan, I think it's just the current state of the power struggle between two competing factions. Some browser devs prioritize web apps being as good as native apps. And some browser devs prioritize not causing problems for users (such as using too many resources). Seems like sometimes one faction sneaks something past the other to advance their cause a bit, and in total the result is incoherent.
- no_wizard 3y agoThe broader spec that OPFS is part of is (was?) suppose to give you just that: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access https://developer.chrome.com/docs/capabilities/web-apis/file... This is another instance where Apple threw up their rails, and Firefox also seized the opportunity to throw up some rails. I don't think all their concerns were justified because you can control with very fine permissions what is and isn't exposed to the browser, which was the main source of contention. No alternative was presented. I believe this can be done in a privacy friendly way (the main stay of the objections). These are smart engineers, some of the best and the brightest, who supposedly are good at solving thorny problems. Simply, I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this. Then we'll know once and for all if its a grand conspiracy or not, I suppose
- threeseed 3y agoApple did the right thing by blocking this. Because for every one PWA app there are dozens of websites who would use the local storage to store re-targeting metadata for advertising. It has nothing to do with the App Store and everything to do with basic tracking prevention. You can't block cookies and then allow local storage. Developers aren't stupid.
- no_wizard 3y agoThere are ways to make sure that doesn’t happen, like making sure only the origin the file was written from can open and see the files. They should have put out a counter proposal. They certainly didn’t show it’s technically infeasible
- threeseed 3y agoEverything has been moving to first party especially during the last year. So the origin is the one storing the tracking data, capturing it and sending it to Meta etc. Which is what makes this so hard as there is no difference between a PWA and a rogue website.
- JimDabell 3y ago> Apple released an update a few years ago the cleared the contents of localStorage and indexeddb for an origin if the user hadn't visited in 14 days. > This makes it hard for purely offline PWAs to store data offline. That restriction doesn’t apply to installed PWAs, only websites.