Safari now supports File System Access API with private origin

This is brilliant! Being called a “file system access” api will confuse many people into thinking it’s about traditional file storage for “people” to use, like a file picker&#x2F;save dialog. It’s not, this is about providing a block storage that can be used for other things.<p>The one I am most excited by is for persistent SQLite with proper acid transaction in the browser, not having to load the whole db into memory. Absurd SQL [0] currently does this by creating a VFS on top of IndexedDB. This would let it do it properly, and is likely to be upstreamed to SQL.JS which is the main SQLite WASM project.<p>0: <a href="https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jlongster&#x2F;absurd-sql</a><p>Many new in browser DB engines are going to get built on top of this. Others that I could see happing are:<p>- Relm from MongoDB being ported to WASM and use this for storage.<p>- If I were Supabase I would be looking to create a “Mini Supabase” for mobile, and make it work in browser too.<p>- Couchbase Mobile as an alternative to PouchDB

I’m curious how much use something like this would ever get; the Origin Private File System is basically just a file system implemented atop a database: it doesn’t provide any new fundamental functionality, but can be shimmed perfectly atop IndexedDB (though performance characteristics will probably differ). When people hear “file system access”, they’re going to expect that this means you can access arbitrary files and folders on the file system, whether unbounded or within a certain scope, but the <i>Origin Private</i> File System is not that. There need be no correlation between the file system this API exposes and your file system. (In theory there perhaps <i>could</i> be, but it’s not the preferred way and there’s no obvious reason to do it that way, and the question of valid file names would be rather messy, even if the spec kinda makes a weird half-compromise for backslash in file names; and I think the stuff about atomic operations could make it difficult to do sanely, too.) It doesn’t put things in a private folder so that you could open its contents in other locally-installed apps.<p>So this is basically the harmless but also fairly useless part of File System Access. The only real reasons I can think of straight away for it potentially being useful are (a) if it performs better than IndexedDB, and (b) for simpler API compatibility with something using the <i>dangerous</i> parts of File System Access, which Chromium has implemented but which Firefox and Safari are both utterly rejecting.<p>I’m also a bit concerned about browsers shipping this stuff given how much flux there still is in the draft spec, which is still thoroughly in its incubation phase and hasn’t been adopted by a working group.<p>In the end, I can’t understand why they’d implement this part of the spec. It will get some people’s hopes up, only to dash them, since they’re not implementing the useful but dangerous part which is what people actually want.

Unfortunately, this does not seem to be the &quot;local file access&quot; that Chromium offers and that Safari lacks.<p>With better browser support for the File System Access API, web applications that store their data in files might become a common thing.<p>Currently, when building a web application, you usually build some backend system that lets the user log in and then stores the data. Or you use IndexedDB and let the browser handle it. In both cases, the user does not have good access to the data.<p>If instead on the first run, the application asked the user &quot;Where do you want to store the data&quot; and the user selects a file or a directory, that puts the user in full control.<p>Then they later can backup the data however they like, edit it with other tools, version it etc etc.<p>The browser is an awesome platform. I love to write local tools in HTML. It is just so easy to tweak browser based applications to your needs. Open the html file, change a line or two, save - boom! you got what you want.

&gt; <i>It is very common for an application to interact with local files. For example, a general workflow is opening a file, making some changes, and saving the file. For web apps, this might be hard to implement. It is possible to simulate the file operations using IndexedDB API, an HTML input element with the file type, an HTML anchor element with the download attribute, etc, but that would require a good understanding of these standards and careful design for a good user experience. Also, the performance may not be satisfactory for frequent operations and large files.</i><p>&gt; <i>Based on the implementation of different browsers, one entry in the origin private file system does not necessarily map to an entry in the user’s local filesystem — it can be an object stored in some database. That means a file or directory created via the File System Access API may not be easily retrieved from outside of the browser.</i><p>Honestly, this makes no sense to me. The motivating example is exactly about being unable to interact with the <i>host</i> file system, but then they present a solution that does something completely different.<p>If this is supposed to be yet another storage API, then so be it, but this won&#x27;t be able to solve the UX problems that the first quote was talking about.<p>Edit: Aha, the spec clears this up a bit: The standard defines different implementations of the file system API. Two of them are the &quot;local&quot; [1] and the &quot;origin private&quot; [2] file systems. The former is indeed a view of the host file system, with picker and all, while the latter is completely independent of the host.<p>Looks like this feature announcement was exclusively about the latter.<p>(The motivating example still make no sense to me as that is a clear use-case for the &quot;local&quot; filesystem implementation, but that seems to be more an issue with the announcement, not with the feature itself)<p>Edit2: Another important distinction is that the local file system requires user interaction to use (with good reason) : You <i>have</i> to show a file picker before you can use it, and subsequently can only access the files and directories the user selected in the picker. So you cannot use this as a behind-the-scenes storage mechanism.<p>In contrast, the origin-private file system requires no permissions and no user interaction.<p>[1] <a href="https:&#x2F;&#x2F;wicg.github.io&#x2F;file-system-access&#x2F;#local-filesystem" rel="nofollow">https:&#x2F;&#x2F;wicg.github.io&#x2F;file-system-access&#x2F;#local-filesystem</a><p>[2] <a href="https:&#x2F;&#x2F;wicg.github.io&#x2F;file-system-access&#x2F;#sandboxed-filesystem" rel="nofollow">https:&#x2F;&#x2F;wicg.github.io&#x2F;file-system-access&#x2F;#sandboxed-filesys...</a>

I&#x27;ve read this a few times, but I don&#x27;t see how you can regard this as anything other than false advertising. In short, it&#x27;s basically a file-like wrapper around the hard-to-use IndexedDB. So it pretty much competes with localForage and idb-keyval.<p>The promise of File System Access API is in interop. There is no interop with Safari&#x27;s implementation.

<i>It is possible to simulate the file operations using IndexedDB API, an HTML input element with the file type, an HTML anchor element with the download attribute, etc, but that would require a good understanding of these standards and careful design for a good user experience. Also, the performance may not be satisfactory for frequent operations and large files. … Based on the implementation of different browsers, one entry in the origin private file system does not necessarily map to an entry in the user’s local filesystem — it can be an object stored in some database. That means a file or directory created via the File System Access API may not be easily retrieved from outside of the browser.</i><p>So what is the point of using this instead of IndexedDB, then? In IndexedDB we can even save private non-extractable keys!

Shameless plug for my soon to be outdated Safari iOS extension <a href="https:&#x2F;&#x2F;filepicker.app" rel="nofollow">https:&#x2F;&#x2F;filepicker.app</a> which implements these APIs through an extension.

In the document I don’t see how they plan to avoid this being used as storage for persistent evercookies.

At least this would allow a transparent download your files option which is a work around for safari on both mobile and desktop, since a user can prompt to download files in Safari (particularly useful on mobile).<p>However it still relies on the user knowing about this or the application having to somehow prompt it from the user, rather than transparently writing to the file system directly or mounting it as a drive.<p>Step in the right direction for sure, still way too much hassle though. This singles to me they just made sure not to provide a first class file handing option for web developers that would potentially compete with native apps, especially on iOS

This sounds like a possible solution to localStorage being cleared after 7 days of no user interaction on a site in Safari, though I&#x27;d guess this has some persistence limitations as well.

i felt previous coverage of this topic was much more on target. 11 points, 4 days ago, 6 comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30335261" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30335261</a>

Anyone know if it mentions a file size limit?

Will there be limits to the File System Access API in terms of file size and file persistence?

I wonder how symlinks work in this context.

What could possibly go wrong?

Do they limit using space based quotas or other systems?

Better late than never?