13 ms·

Safari now supports File System Access API with private origin

230 points by jvican 5y ago

rektide 5y ago
i felt previous coverage of this topic was much more on target. 11 points, 4 days ago, 6 comments: https://news.ycombinator.com/item?id=30335261 https://news.ycombinator.com/item?id=30335261
darinf 5y ago
Better late than never?
- JimDabell 5y ago
  Why are you saying this is late? The specification is a draft, the only other rendering engine to support it is Blink, and Firefox isn’t going to implement the full spec.
  - darinf 5y ago
    Because over a decade ago the Apple devs poo-poo’d all over the premise of this API when it was first proposed. I’m referring to its earlier incantation that we added to WebKit and shipped in Chrome but could never get Apple devs to support. I’m delighted to see it supported now. I just think of all the lost time for the web and what could have been.
    - JimDabell 5y ago
      Who is the “we” you are referring to? > I just think of all the lost time for the web and what could have been. This doesn’t seem like it enables anything new though? It’s a convenience.
      - jefftk 5y ago
        > Who is the “we” you are referring to? Darin used to be something like my boss's boss's boss's boss when I worked in Chrome.
    - dmitriid 5y ago
      > Because over a decade ago the Apple devs poo-poo’d all over the premise of this API when it was first proposed. What I read is: Apple devs came back with a list of problems and issues as long as Jupiter's equator, Chrome said "we don't care" and shipped it? > I just think of all the lost time for the web and what could have been. With Chrome not rushing it's own broken insecure implementations of internal APIs, not pretending they are standards and not gaslighting other browser vendors? Oh, the Web would be a much, much better place.
  - throw_m239339 5y ago
    Cause Chrome implemented that eons ago. Of course Firefox isn't going to implement anything, Firefox has been a thorn on the side of web standards for a good decade now, thanks to Mozilla's management.
    - chrismorgan 5y ago
      Chrome implemented and shipped an early draft and has, I believe, broken it multiple times since. What it shipped has significant security implications that are handled poorly at best (mostly not at all). Firefox and Safari have said “you what!? No way we’re implementing that as it is”. And Safari are now implementing the safe and boring part of the spec, not the part that people actually want.
    - JimDabell 5y ago
      > Cause Chrome implemented that eons ago. Of course Firefox isn't going to implement anything If Chrome matters, Firefox doesn’t, and Safari is measured against when Chrome supports something rather than when the specification becomes stable, it sounds like you think the web is defined by “whatever Chrome supports, whenever Chrome supports it”.
      - throw_m239339 5y ago
        Good web standards are whatever simplify my work as a developer. Firefox used to be at the forefront of web standards. I can guarantee you Firefox will eventually be running Blink because Mozilla has no vision for the future of the web anymore. Mark my words.
        JimDabell 5y ago
        Do you remember the last time we had a near monoculture for browsers? People with attitudes like yours were all too happy to think of Internet Explorer as the only browser that mattered. Microsoft decided they had won and mothballed Internet Explorer development. We then had a dark ages for web developers with five years of no progress in browser functionality. Positioning Chrome as the definition of the web is incredibly harmful for the long-term health of the web. A web independent of a single vendor is vital.
  - The_rationalist 5y ago
osy 5y ago
Shameless plug for my soon to be outdated Safari iOS extension https://filepicker.app https://filepicker.app which implements these APIs through an extension.
- kmeisthax 5y ago
  Fortunately for you this shouldn't be outdated for a little while longer, since this only covers "origin private" filesystems. Which, in other words, are just a file-structured IndexedDB and not actual local file access.
- llui85 5y ago
  This is fantastic! How haven't I heard of this before? Does anyone know if there's a list of small, little-known extensions just like this?
- DanAtC 5y ago
  This is awesome. What other web apps are out there that use this API that I've been missing out on?
mg 5y ago
Unfortunately, this does not seem to be the "local file access" that Chromium offers and that Safari lacks. With better browser support for the File System Access API, web applications that store their data in files might become a common thing. 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. If instead on the first run, the application asked the user "Where do you want to store the data" and the user selects a file or a directory, that puts the user in full control. Then they later can backup the data however they like, edit it with other tools, version it etc etc. 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.
- notyourwork 5y ago
  > that puts the user in full control. This is entirely contingent on the format used. Netflix or any other media streaming company would store DRM compatible formatted content locally. I think the feature in of itself opens up interesting possibilities but not sure how it will get used.
- dmitriid 5y ago
  > If instead on the first run, the application asked the user "Where do you want to store the data" and the user selects a file or a directory, that puts the user in full control. It doesn't, not realy. Both Safari and Firefox are now very wary and weary of asking the user for anything. There are so many things browsers already ask the user for: camera, location, notifications, microphone... In case of Chrome, additionally: USB, Serial, HID, ... All the discussions about such features inevitably boil down: it's impossible to properly explain to the user what the hell is going on and what the implications are. At one point the user will just click "ok" without reading.
  - a9h74j 5y ago
    Yes, so many potential dialogs. But I sure as heck want to be able to store my work product by some means which gives me the most control.
chrismorgan 5y ago
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 Origin Private 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 could 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. 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 dangerous parts of File System Access, which Chromium has implemented but which Firefox and Safari are both utterly rejecting. 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. 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.
- hutzlibu 5y ago
  "since they’re not implementing the useful but dangerous part which is what people actually want." I want it like this. There are lots of use cases for a file system to store user data locally in a safe way. Even though it all can be also done with indexedDB, too - it makes this task incredibly more complicated. I did basically this, implement a file system on top of indexedDB - but with great pain. and I did, because there was no other option - but only with great unnecessary pain.
  - 5y ago
divbzero 5y ago
Will there be limits to the File System Access API in terms of file size and file persistence?
th3iedkid 5y ago
Do they limit using space based quotas or other systems?
samwillis 5y ago
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/save dialog. It’s not, this is about providing a block storage that can be used for other things. 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. 0: https://github.com/jlongster/absurd-sql https://github.com/jlongster/absurd-sql Many new in browser DB engines are going to get built on top of this. Others that I could see happing are: - Relm from MongoDB being ported to WASM and use this for storage. - If I were Supabase I would be looking to create a “Mini Supabase” for mobile, and make it work in browser too. - Couchbase Mobile as an alternative to PouchDB
- chrismorgan 5y ago
  I don’t see how this is fundamentally any different from IndexedDB: both are asynchronous transactional key-value databases. One is byte-oriented and the other object-oriented, but it looks to me like they’re essentially completely equivalent in what’s possible with them—except insofar as File System Access may allow you to avoid loading the entire thing into memory. (I say may because you can’t control the browser’s implementation; my feeling is that it’s not unlikely that the browser may keep the full thing in memory in FSA where I wouldn’t expect it to with IndexedDB, which if so would return them to basically the same position.) Implementing SQLite on top of this would require that a commit write the changes, close the file, and then reopen it, since writes are only performed when you close the file. That could perform tolerably or terribly (there’s no way of knowing), but certainly won’t be as good as what you get natively, where you can truly write only part of a file, especially once you get to large databases where it will certainly be drastically slower. If you want performance out of any of these sorts of things, you’re going to need to stop putting everything in one “file” and split it into many, so that you can avoid touching most of them on most writes.
  - samwillis 5y ago
    I haven’t had a chance to dig into the details of what part/version of the spec Safari have implemented so far, and I’m aware the spec is somewhat a moving target. But I do know the developers working on the type of projects I’m talking about are talking to the working group behind the spec to ensure the spec meets these type of needs. The point of this over “abusing” IndexedDB, jlongster who created Absurd SQL had to perform some pretty unholy hacks to get it to work. When porting these db engines to WASM they expect a FS to look and behave like a FS, that’s what this does that IndexedDB doesn’t. Quite true you could build a new SQL/DB engin on top of IndexedDB with a storage architecture designed for it. But that’s not what the existing engines are expecting.
tinus_hn 5y ago
In the document I don’t see how they plan to avoid this being used as storage for persistent evercookies.
- hutzlibu 5y ago
  In the same way, indexedDB has to be manually cleared by the user across all browsers? (and safari does this automatically after some idle time, I think)
camhart 5y ago
Anyone know if it mentions a file size limit?
xg15 5y ago
> 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. > 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. Honestly, this makes no sense to me. The motivating example is exactly about being unable to interact with the host file system, but then they present a solution that does something completely different. If this is supposed to be yet another storage API, then so be it, but this won't be able to solve the UX problems that the first quote was talking about. Edit: Aha, the spec clears this up a bit: The standard defines different implementations of the file system API. Two of them are the "local" [1] and the "origin private" [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. Looks like this feature announcement was exclusively about the latter. (The motivating example still make no sense to me as that is a clear use-case for the "local" filesystem implementation, but that seems to be more an issue with the announcement, not with the feature itself) Edit2: Another important distinction is that the local file system requires user interaction to use (with good reason) : You have 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. In contrast, the origin-private file system requires no permissions and no user interaction. [1] https://wicg.github.io/file-system-access/#local-filesystem https://wicg.github.io/file-system-access/#local-filesystem [2] https://wicg.github.io/file-system-access/#sandboxed-filesystem https://wicg.github.io/file-system-access/#sandboxed-filesys...
- jonnycomputer 5y ago
  Thanks for clarifying this for me. I'd gone through some of the specs of the File System API, but not nearly thoroughly enough to pick up on this distinction.
nixpulvis 5y ago
I wonder how symlinks work in this context.
- chrismorgan 5y ago
  Not applicable; Private Origin File Systems are just a key-value store made to look a bit like a file system, and symlinks don’t exist. (There is also the rest of the spec which provides real file system access, and that will require decisions on what to do with symlinks, but only Google has implemented that—Mozilla and Apple have strongly rejected it as a currently-unfixable security hazard.)
jgalt212 5y ago
I've read this a few times, but I don't see how you can regard this as anything other than false advertising. In short, it's basically a file-like wrapper around the hard-to-use IndexedDB. So it pretty much competes with localForage and idb-keyval. The promise of File System Access API is in interop. There is no interop with Safari's implementation.
- meepmorp 5y ago
  I understand the desire to have file access as a developer, but as a user, Safari and Firefox's decision to not implement the rest of it is a great decision. It's not worth the attack surface.
  - funstuff007 5y ago
    Firefox is not implementing. Safari is misleading people about what they have actually implemented. Big difference.
phillipseamore 5y ago
This sounds like a possible solution to localStorage being cleared after 7 days of no user interaction on a site in Safari, though I'd guess this has some persistence limitations as well.
- phillipseamore 5y ago
  Damn, "its storage lifetime is the same as other persistent storage types like IndexedDB and LocalStorage". So a maximum of 7 days if the users doesn't return to the site. Not very useful.
  - ec109685 5y ago
    Gross. Imagine going on vacation for a week and not using a particular website during that time, and losing all your data. Safari should have a big warning on top of that blog post saying, “all files will be deleted after 7 days unless these API’s are being used within a PWA”.
    - ec109685 5y ago
      Also, if this API behaves like Local Storage, it’s not backed up to iCloud either.
  - jefftk 5y ago
    Safari's rules on storage persistence are aimed at limiting tracking. For it to be effective, they need to apply that limit to all forms of client side storage.
    - phillipseamore 5y ago
      I understand that perspective but in reality it does way more damage to those of us who want to provide services that are specifically trying to protect privacy by not having user accounts or storing user data server-side - and our users. There is no way for me to safely store user data, for a site that most users interact with once or twice a month, without having to store that data server-side and requiring some way to authenticate them to retrieve it when the come back. If Safari provided an API to store data longer after a user prompt I would be more understanding. It seems many apps these days contact more trackers than a typical website[0]. And the apps manage to circumvent most of the counter measures despite Apple PR on privacy. [0] https://blog.lockdownprivacy.com/2021/09/22/study-effectiveness-of-apples-app-tracking-transparency.html https://blog.lockdownprivacy.com/2021/09/22/study-effectiven...
EGreg 5y ago
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. So what is the point of using this instead of IndexedDB, then? In IndexedDB we can even save private non-extractable keys!
no_wizard 5y ago
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). 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. 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
jonnylynchy 5y ago
What could possibly go wrong?

230 points by jvican 5y ago

i felt previous coverage of this topic was much more on target. 11 points, 4 days ago, 6 comments: https://news.ycombinator.com/item?id=30335261 https://news.ycombinator.com/item?id=30335261

darinf 5y ago

Better late than never?

JimDabell 5y ago
Why are you saying this is late? The specification is a draft, the only other rendering engine to support it is Blink, and Firefox isn’t going to implement the full spec.
- darinf 5y ago
  Because over a decade ago the Apple devs poo-poo’d all over the premise of this API when it was first proposed. I’m referring to its earlier incantation that we added to WebKit and shipped in Chrome but could never get Apple devs to support. I’m delighted to see it supported now. I just think of all the lost time for the web and what could have been.
  - JimDabell 5y ago
    Who is the “we” you are referring to? > I just think of all the lost time for the web and what could have been. This doesn’t seem like it enables anything new though? It’s a convenience.
    - jefftk 5y ago
      > Who is the “we” you are referring to? Darin used to be something like my boss's boss's boss's boss when I worked in Chrome.
  - dmitriid 5y ago
    > Because over a decade ago the Apple devs poo-poo’d all over the premise of this API when it was first proposed. What I read is: Apple devs came back with a list of problems and issues as long as Jupiter's equator, Chrome said "we don't care" and shipped it? > I just think of all the lost time for the web and what could have been. With Chrome not rushing it's own broken insecure implementations of internal APIs, not pretending they are standards and not gaslighting other browser vendors? Oh, the Web would be a much, much better place.
- throw_m239339 5y ago
  Cause Chrome implemented that eons ago. Of course Firefox isn't going to implement anything, Firefox has been a thorn on the side of web standards for a good decade now, thanks to Mozilla's management.
  - chrismorgan 5y ago
    Chrome implemented and shipped an early draft and has, I believe, broken it multiple times since. What it shipped has significant security implications that are handled poorly at best (mostly not at all). Firefox and Safari have said “you what!? No way we’re implementing that as it is”. And Safari are now implementing the safe and boring part of the spec, not the part that people actually want.
  - JimDabell 5y ago
    > Cause Chrome implemented that eons ago. Of course Firefox isn't going to implement anything If Chrome matters, Firefox doesn’t, and Safari is measured against when Chrome supports something rather than when the specification becomes stable, it sounds like you think the web is defined by “whatever Chrome supports, whenever Chrome supports it”.
    - throw_m239339 5y ago
      Good web standards are whatever simplify my work as a developer. Firefox used to be at the forefront of web standards. I can guarantee you Firefox will eventually be running Blink because Mozilla has no vision for the future of the web anymore. Mark my words.
      - JimDabell 5y ago
        Do you remember the last time we had a near monoculture for browsers? People with attitudes like yours were all too happy to think of Internet Explorer as the only browser that mattered. Microsoft decided they had won and mothballed Internet Explorer development. We then had a dark ages for web developers with five years of no progress in browser functionality. Positioning Chrome as the definition of the web is incredibly harmful for the long-term health of the web. A web independent of a single vendor is vital.
- The_rationalist 5y ago

osy 5y ago

Shameless plug for my soon to be outdated Safari iOS extension https://filepicker.app https://filepicker.app which implements these APIs through an extension.

kmeisthax 5y ago
Fortunately for you this shouldn't be outdated for a little while longer, since this only covers "origin private" filesystems. Which, in other words, are just a file-structured IndexedDB and not actual local file access.
llui85 5y ago
This is fantastic! How haven't I heard of this before? Does anyone know if there's a list of small, little-known extensions just like this?
DanAtC 5y ago
This is awesome. What other web apps are out there that use this API that I've been missing out on?

mg 5y ago

Unfortunately, this does not seem to be the "local file access" that Chromium offers and that Safari lacks. With better browser support for the File System Access API, web applications that store their data in files might become a common thing. 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. If instead on the first run, the application asked the user "Where do you want to store the data" and the user selects a file or a directory, that puts the user in full control. Then they later can backup the data however they like, edit it with other tools, version it etc etc. 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.

notyourwork 5y ago
> that puts the user in full control. This is entirely contingent on the format used. Netflix or any other media streaming company would store DRM compatible formatted content locally. I think the feature in of itself opens up interesting possibilities but not sure how it will get used.
dmitriid 5y ago
> If instead on the first run, the application asked the user "Where do you want to store the data" and the user selects a file or a directory, that puts the user in full control. It doesn't, not realy. Both Safari and Firefox are now very wary and weary of asking the user for anything. There are so many things browsers already ask the user for: camera, location, notifications, microphone... In case of Chrome, additionally: USB, Serial, HID, ... All the discussions about such features inevitably boil down: it's impossible to properly explain to the user what the hell is going on and what the implications are. At one point the user will just click "ok" without reading.
- a9h74j 5y ago
  Yes, so many potential dialogs. But I sure as heck want to be able to store my work product by some means which gives me the most control.

chrismorgan 5y ago

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 Origin Private 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 could 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. 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 dangerous parts of File System Access, which Chromium has implemented but which Firefox and Safari are both utterly rejecting. 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. 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.

hutzlibu 5y ago
"since they’re not implementing the useful but dangerous part which is what people actually want." I want it like this. There are lots of use cases for a file system to store user data locally in a safe way. Even though it all can be also done with indexedDB, too - it makes this task incredibly more complicated. I did basically this, implement a file system on top of indexedDB - but with great pain. and I did, because there was no other option - but only with great unnecessary pain.
- 5y ago

divbzero 5y ago

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

th3iedkid 5y ago

Do they limit using space based quotas or other systems?

samwillis 5y ago

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/save dialog. It’s not, this is about providing a block storage that can be used for other things. 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. 0: https://github.com/jlongster/absurd-sql https://github.com/jlongster/absurd-sql Many new in browser DB engines are going to get built on top of this. Others that I could see happing are: - Relm from MongoDB being ported to WASM and use this for storage. - If I were Supabase I would be looking to create a “Mini Supabase” for mobile, and make it work in browser too. - Couchbase Mobile as an alternative to PouchDB

chrismorgan 5y ago
I don’t see how this is fundamentally any different from IndexedDB: both are asynchronous transactional key-value databases. One is byte-oriented and the other object-oriented, but it looks to me like they’re essentially completely equivalent in what’s possible with them—except insofar as File System Access may allow you to avoid loading the entire thing into memory. (I say may because you can’t control the browser’s implementation; my feeling is that it’s not unlikely that the browser may keep the full thing in memory in FSA where I wouldn’t expect it to with IndexedDB, which if so would return them to basically the same position.) Implementing SQLite on top of this would require that a commit write the changes, close the file, and then reopen it, since writes are only performed when you close the file. That could perform tolerably or terribly (there’s no way of knowing), but certainly won’t be as good as what you get natively, where you can truly write only part of a file, especially once you get to large databases where it will certainly be drastically slower. If you want performance out of any of these sorts of things, you’re going to need to stop putting everything in one “file” and split it into many, so that you can avoid touching most of them on most writes.
- samwillis 5y ago
  I haven’t had a chance to dig into the details of what part/version of the spec Safari have implemented so far, and I’m aware the spec is somewhat a moving target. But I do know the developers working on the type of projects I’m talking about are talking to the working group behind the spec to ensure the spec meets these type of needs. The point of this over “abusing” IndexedDB, jlongster who created Absurd SQL had to perform some pretty unholy hacks to get it to work. When porting these db engines to WASM they expect a FS to look and behave like a FS, that’s what this does that IndexedDB doesn’t. Quite true you could build a new SQL/DB engin on top of IndexedDB with a storage architecture designed for it. But that’s not what the existing engines are expecting.

tinus_hn 5y ago

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

hutzlibu 5y ago
In the same way, indexedDB has to be manually cleared by the user across all browsers? (and safari does this automatically after some idle time, I think)

camhart 5y ago

Anyone know if it mentions a file size limit?

xg15 5y ago

> 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. > 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. Honestly, this makes no sense to me. The motivating example is exactly about being unable to interact with the host file system, but then they present a solution that does something completely different. If this is supposed to be yet another storage API, then so be it, but this won't be able to solve the UX problems that the first quote was talking about. Edit: Aha, the spec clears this up a bit: The standard defines different implementations of the file system API. Two of them are the "local" [1] and the "origin private" [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. Looks like this feature announcement was exclusively about the latter. (The motivating example still make no sense to me as that is a clear use-case for the "local" filesystem implementation, but that seems to be more an issue with the announcement, not with the feature itself) Edit2: Another important distinction is that the local file system requires user interaction to use (with good reason) : You have 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. In contrast, the origin-private file system requires no permissions and no user interaction. [1] https://wicg.github.io/file-system-access/#local-filesystem https://wicg.github.io/file-system-access/#local-filesystem [2] https://wicg.github.io/file-system-access/#sandboxed-filesystem https://wicg.github.io/file-system-access/#sandboxed-filesys...

jonnycomputer 5y ago
Thanks for clarifying this for me. I'd gone through some of the specs of the File System API, but not nearly thoroughly enough to pick up on this distinction.

nixpulvis 5y ago

I wonder how symlinks work in this context.

chrismorgan 5y ago
Not applicable; Private Origin File Systems are just a key-value store made to look a bit like a file system, and symlinks don’t exist. (There is also the rest of the spec which provides real file system access, and that will require decisions on what to do with symlinks, but only Google has implemented that—Mozilla and Apple have strongly rejected it as a currently-unfixable security hazard.)

jgalt212 5y ago

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

meepmorp 5y ago
I understand the desire to have file access as a developer, but as a user, Safari and Firefox's decision to not implement the rest of it is a great decision. It's not worth the attack surface.
- funstuff007 5y ago
  Firefox is not implementing. Safari is misleading people about what they have actually implemented. Big difference.

phillipseamore 5y ago

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

phillipseamore 5y ago
Damn, "its storage lifetime is the same as other persistent storage types like IndexedDB and LocalStorage". So a maximum of 7 days if the users doesn't return to the site. Not very useful.
- ec109685 5y ago
  Gross. Imagine going on vacation for a week and not using a particular website during that time, and losing all your data. Safari should have a big warning on top of that blog post saying, “all files will be deleted after 7 days unless these API’s are being used within a PWA”.
  - ec109685 5y ago
    Also, if this API behaves like Local Storage, it’s not backed up to iCloud either.
- jefftk 5y ago
  Safari's rules on storage persistence are aimed at limiting tracking. For it to be effective, they need to apply that limit to all forms of client side storage.
  - phillipseamore 5y ago
    I understand that perspective but in reality it does way more damage to those of us who want to provide services that are specifically trying to protect privacy by not having user accounts or storing user data server-side - and our users. There is no way for me to safely store user data, for a site that most users interact with once or twice a month, without having to store that data server-side and requiring some way to authenticate them to retrieve it when the come back. If Safari provided an API to store data longer after a user prompt I would be more understanding. It seems many apps these days contact more trackers than a typical website[0]. And the apps manage to circumvent most of the counter measures despite Apple PR on privacy. [0] https://blog.lockdownprivacy.com/2021/09/22/study-effectiveness-of-apples-app-tracking-transparency.html https://blog.lockdownprivacy.com/2021/09/22/study-effectiven...

EGreg 5y ago

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. So what is the point of using this instead of IndexedDB, then? In IndexedDB we can even save private non-extractable keys!

no_wizard 5y ago

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

jonnylynchy 5y ago

What could possibly go wrong?