Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Parent Full thread

> Origin Private FileSystem

Safari’s had that for more than two years. (Chromium, more than three, Firefox, almost one.)

> Import Assertions

An excellent example of why Firefox and Safari tend to be more reserved in what they ship, in contrast to Chromium which is much more fond of shipping immature stuff.

Import assertions are dead, superseded by import attributes. V8 has deprecated import assertions and will remove them soon. See https://v8.dev/features/import-assertions for more info on why.

Chromium shipping immature stuff is, from time to time, a real pain, because it makes it harder to fix problems in the spec as you sometimes have to avoid breaking real usage. Sometimes this basically makes things worse forever, because of naming things. I can’t remember a specific case in browsers, but know they exist; but a similar case is how we have some methods named includes instead of contains like they should have been because of Mootools touching stuff it shouldn’t have, and so now everyone suffers for that mistake.

I believe you meant to link this: https://v8.dev/features/import-attributes

That page actually explains the change:

> V8 shipped the import assertions feature in v9.1. This feature allowed module import statements to include additional information by using the assert keyword. This additional information is currently used to import JSON and CSS modules inside JavaScript modules.

> Since then, import assertions has evolved into import attributes. The point of the feature remains the same: to allow module import statements to include additional information.

> The most important difference is that import assertions had assert-only semantics, while import attributes has more relaxed semantics. Assert-only semantics means that the additional information has no effect on how a module is loaded, only on whether it is loaded.

NB: The above quotes have been edited to just the most relevant notes. See the link above for more information.

You are correct, that is the link I meant.

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

Last 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

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.

There is a big difference between deleting when disk storage is low, and deleting if you haven't opened the app in 14 days.

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

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

It’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/

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

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

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

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

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

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

The broader spec that OPFS is part of is (was?) suppose to give you just that:

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

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

There 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

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

Now we're getting into the fundamental fact that some websites have lots of tracking and such, and some don't.

This is no different than having to send the files to a server owned by the website. I fail to see any meaningful difference here. Should we also not allow HTTP requests? I don't see how this is different.

We are talking about storing data on user's computers.

If you allow PWA apps to do this. You also allow websites to use it for tracking.

Hence why Apple restricted this feature.

Storing data with user permissions, not permission-less. Its in no way like local storage or indexdb. Those permissions could be scoped to only allowing explict read/write of certain files (IE, the ones the user initiated) and not allow for arbitrary writing of files to the filesystem, for instance.

We already do this with the file upload API

Exactly, requiring installation for long term persistence mitigates usage of the API for tracking and prevents storage usage from slowly snowballing over time as sites store random things the user probably doesn’t even care about.

Should PWA installation be more obvious/straightforward than it is currently? Sure, but that’s a separate issue.

You can read about the privacy concerts the community group published [1].

[1]: https://wicg.github.io/file-system-access/#privacy-considera...

> Apple did the right thing by blocking this.

In order for a specification to become a web standard, it needs two independent implementations. No single organisation is capable of blocking it – it means that Google couldn’t convince anybody outside of Google to implement it.

> 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

What actually happened: Mozilla rejected it on security grounds, then Apple agreed with Mozilla. How are you blaming Apple for Google putting together a bad spec. that no other browser vendor can accept?

This happens time and time again. Google publish a specification that is not acceptable, both Mozilla and Apple reject it on privacy or security grounds, Google ships it in Chrome anyway, then people like you complain about Apple being mean.

Here is Mozilla’s position: https://github.com/mozilla/standards-positions/issues/154

Here is Apple’s position: https://github.com/WebKit/standards-positions/issues/28

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

Idk what happened to it but there was momentum at one point to ship internal modules for browsers like node now has, where you would write the import as “std:lib” (much like the recent “node:fs” etc) which would completely side step these issues

I'm really confused because the import assertions link doesn't say that they're deprecated at all, let alone why. (It's also possible I'm being served something different than you were because I'm on mobile?)

Import Assertions being replaced, thats cool (its replacement perhaps should have made the list if the spec is done)

but OPFS is not widely supported. Its partially supported. Its not on the same interoperable standard as Chrome, for instance. hence for Interop 2024 it would have made sense to include, to close the gaps between the browsers.

Reply on news.ycombinator.com