Hacker News Reader

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

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.

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

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 wouldn't really say that I've missed much any of what you've described in my day-to-day work, so it's hard to take this criticism seriously. Meanwhile the things listen in TFA have real practical use cases pretty much across the whole web. Why are those specific items so important to you?

Because they move the frontier of PWAs forward in a big way. They aren't simply quality of life improvements, which the vast majority of these things are (sans the popover attribute, which will make a host of things easier once browser versions are sufficiently updated past the point of worrying about using it or not)

I want to be able to persist to the filesystem of the user, for instance, because the software we make is all about editing files, and currently, the user has to upload their files to us and crucially we then have to store them on a server. I'd like to remove that server requirement, for a multitude of reasons, and be able to have read / write permissions to a sandbox directory that lets me do just that.

Not everyone is making apps that benefit from this, but the ones that do, really do and they tend to be big. Our app has 400K+ users for instance

>I'd love to know what internal Apple politics around web standards made them focus so much on CSS and a few quality of life things, but completely ignores what developers have been clamoring for in many respects.

Is this not just completely on-brand for Apple? Focusing on the sizzle and not the steak?

Ha what. Developers clamor for things that solve actually day-to-day problems like sticky and has, which Safari led the pack on. Not to mention subgrid, color functions, filters, etc.

> Not to mention subgrid, color functions, filters, etc.

Firefox led both subgrid and filters.

Color functions seems a bit weird to bring up since back then Apple were the only ones using higher gamut displays making the color functions useless for everyone but them, while also doing their best to hamper the web making the color functions useless for everyone including them.

To add some context on the rest of the industry... everyone else focused their improvement efforts not on deeper color bit-depth, but on improved framerates to reduce eye-strain, flicker issues and latency discomfort.

It's only going to be over the next few years as QLED/MicroLed/etc... displays get cheap enough to be commercially viable that the color functions (relative color possibly excluded) will start to become useful.

I don't really count Apple's current displays since they have been pasting multiple displays together to try and get desktop resolutions to the detriment of frame rate (which from a health perspective is much more important).

Firefox lagged on filter and backdrop filter, and Chrome lagged on subgrid.

And color functions don’t need displays with better color to work. They’re about better ways to describe colors, to mix colors, and to choose colors.

And Apple did nothing to prevent others from using displays with better color, nor does enhancing the web hamper the web.

> Color functions seems a bit weird to bring up since back then Apple were the only ones using higher gamut displays making the color functions useless for everyone but them, while also doing their best to hamper the web making the color functions useless for everyone including them.

Totally false.

In Apple's blog post "Wide Gamut Color in CSS with Display-P3" (posted March 2, 2020), Apple includes the fact that non-Apple devices shipped with wide gamut displays:

- Google Pixel 2 XL

- Google Pixel 3

- HTC U11+

- OnePlus 6

They even provided a Wikipedia link [2] that links to an article with addition devices.

The hardware wasn't the issue; Chrome and the other browsers that ran on Android back then didn't support wide gamut displays. That's not Apple's fault; they were going out of their way to promote wide gamut/Display P3 as something good for the web.

Finally, Safari/WebKit has wide gamut support starting in 2016 [3] by implementing web standards that Google, Mozilla, etc. have access to.

[1]: https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...

[2]: https://en.wikipedia.org/wiki/DCI-P3#History

[3]: https://trac.webkit.org/changeset/207442/webkit

The mobile displays we've received in the last few mobile generations have had wider-gamut displays than the displays that came before... but, I wouldn't necessarily call them wide-gamut.

To call it wide-gamut (without a slight wince while doing so), we'd need:

- 1000 nit brightness minimum (some are here and above)

- 99.99% P3 color conformity minimum (although if we're moving color spaces, why not reach for Rec2020)

- No dimming issues (if you've ever tried using a white mouse cursor on a black display, you know how annoying the lighting smear around it can be)

Right now, displays can support those different points and surpass them, but very very few can do all three at the same time.

There are miniLED displays that can support all three, but there's other issues that can pop up that can make them not worth it (e.g. viewing angle, and sometimes still weird dimming).

Then there's the newer microLED displays which avoid those problems, but there's still some production issues.

We're really close to the wide-gamut age, but I still think we need two things before we can cross that threshold and truely say we're in the wide-gamut age.

1. microLED becomes cheap enough to be the norm

2. iOS, and Android remove their "feature" where they oversaturate photos to simulate wide-gamut.

We're nearly there...

Safari has been absolutely crushing things in terms of standards and general shipping velocity for nearing on 3 years now. Your comment would be 100% true 3 years ago, but today is basically completely incorrect. A sibling comments corrects some of it, but needless to say the endless FUD around this is bad.

Safari is an incredible browser - standards wise - but also way faster and more efficient than Chrome.

I use it for everything except the dev tools and switching to Chrome always feels like I'm using a gas car vs electric - clunky, slower, heavier.

They have done a ton on the CSS side in particular, I agree with that, and its in a better place than it was 3 years ago, no doubt about that either.

My point still stands on interop though: They aren't picking anything where the interop is divergent and tricky for developers to navigate, and most of this was on their roadmap as going to implement soon anyway. They aren't tackling any thorny issues like OPFS, which is where developers want them to figure out interoperability for consistency because it moves the entire platform forward in big meaningful ways (for instance, makes PWAs more potent alternatives to native apps)

I applaud their CSS and HTML work though, that's been nice to see.

Interop is a joint initiative between all three browsers though, not just Safari. Its not just Safari that picks these focus areas.

It is Apple throwing up objections to focusing on other things as far as interop goes though. They have alot of weight in the discussion at hand.

I know Google throws some up too (JPEG XL much) but Apple is somewhat notorious for this.

I should also mention, there was an episode of the ShopTalk Show podcast where their developer evangelist was pushing for most of the things in this list when talking about Interop, which makes me believe they had their minds pretty well decided going into the whole thing.

Whenever I see people complain about this, it always seems to be specs. that aren’t on the standards track. Which basically means that it’s a spec. that Google wrote and both Mozilla and Apple rejected.

It takes only two independent implementations to make something a standard. If it’s not on the standards track, it means Google couldn’t convince anybody else to implement it.

This is not Apple throwing up objections. This is Google trying to push bad stuff unilaterally and nobody else going along with it.

> makes PWAs more potent alternatives to native apps

You will need to be specific about what missing API will magically make this true.

Because all I see people on here ask for are things like MIDI support which are nice and all but have been used by companies to track you. Which is why Google who is fully supportive of this has no issues adding it in without any thought to privacy.

Filesystem persistence removes a whole host of complexities from applications

For instance, I would no longer have to store files on a server, I could simply save them locally for the user, which makes it easier for them to have portable files, use it with other apps etc.

It also reduces the startup cost of some apps. If for instance I wanted to make a photo editing app, its going to be cheaper to store edited photos back onto the users device, than it is for me to upload them to a server and store them, especially over time.

It removes alot of developer overhead and it has benefits for the user (IE, the files are more portable, since they're on your machine, not someone elses).

Currently we are perpetually stuck with having to re-create virtual representations of file systems and they aren't the same thing, not by a long shot.

But it also makes tracking much easier, right?

Not by default. It’s not inherent to it at all. I’m honestly not sure how it does, given the idea would be to restrict FS access to only files the user grants permissions to read / write, so they can’t write arbitrary things to the file system. There’s other techniques they can use to make it blind / privacy focused as well

Where's "here"? As far as I can tell, yours is the only mention of MIDI in these comments. Arguing against MIDI is a total strawman.

When you ask people about "what PWA standards are you talking about" people inevitably bring up Chrome's half-baked non-standards half of which both Safari and Firefox are in opposition to.

WebMIDI is just one such example. Safari and Firefox were against it. Then Firefox relented and implemented it, and ran into tracking literally the day after they released it.

Others are WebUSB, WebHID, WebSerial etc.

It's refreshing to see people discussing something else like Origin Private Filesystem for a change.

Safari has supported OPFS for some time. But Interop isn’t mainly a “please implement this” list, it’s a list of priority areas for browsers to become consistent with each other and with standards. If you think there’s a problematic lack of cross-browser consistency for OPFS, then definitely nominate it as a focus area for Interop 2025. Anyone is welcome to propose work items.

> but I'd love to know what internal Apple politics around web standards made them focus so much on CSS and a few quality of life things, but completely ignores what developers have been clamoring for in many respects.

This is stuff that developers are clamoring for, but maybe just different developers than you.

(-webkit-)backdrop-filter was such a godsend, and a massive pain that it took so long to go through the standards process after Apple was shipping it fine. Even then Google's implementation was still pretty buggy for a while.

CSS Scroll Snap is great, removing the need for weirdo javascript carousels, giving more native scrolling experiences on the web.

The ironic part is that despite the criticism, I think capabiltiies make websites feel more 'native' than JSON Module Scripts. My impression is the Apple focuses on web APIs that impact the user experience, which generally leans more on the CSS side.

Don’t get me wrong I appreciate all of this, but this is Interop, not just shipping standards and I want them to focus on the thorniest problems possible

It's obvious that Apple's incentives around developing more standards (that make PWAs more potent) directly conflict with their walled garden (AppStore) revenues.

In this regard, they are remarkably similar to Microsoft's Internet Explorer situation, only in this case there seems to be little to no interest in pursuing an investigation.

Strange then that Firefox is siding with Apple when it comes to many of these "standards"