Intent to Ship: Native File System

696 views
Skip to first unread message

Marijn Kruisselbrink

unread,
Aug 18, 2020, 8:52:51 PM8/18/20
to blink-dev

Contact emails

m...@chromium.org, natt...@chromium.org


Explainer


https://github.com/WICG/native-file-system/blob/master/EXPLAINER.md


Specification

https://wicg.github.io/native-file-system/


Docs


https://web.dev/native-file-system/


TAG review

https://github.com/w3ctag/design-reviews/issues/390


Summary

This API enables developers to build powerful apps that interact with other (non-Web) apps on the user’s device via the device’s file system. After a user grants a web app access, this API allows the app to read or save changes directly to files and folders selected by the user. Beyond reading and writing files, this API provides the ability to open a directory and enumerate its contents, as well as store file and directory handles in IndexedDB to later regain access to the same content.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/U4rXcm5CE4Y/discussion


Link to Origin Trial feedback summary

https://docs.google.com/document/d/13TYr9jPwO1av_ByYxtjdVmeKbc3S5bd6iX2r4YloPiQ/edit

During the second origin trial for these features we primarily focused in fine-tuning the shape of the API, better aligning with the rest of the web platform. A summary of these changes can be found at https://github.com/WICG/native-file-system/blob/master/changes.md.


Risks



Interoperability and Compatibility

If no other browsers end up implementing this API, websites using it won't work in them. Usage of a wrapper such as https://github.com/GoogleChromeLabs/browser-nativefs will let websites use this new API while falling back on other (less user friendly) approaches when not available.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/154)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-August/031347.html)


Web developers: Positive (https://discourse.wicg.io/t/writable-file-api/1433)


Activation

Wrapper libraries such as https://github.com/GoogleChromeLabs/browser-nativefs will make it easier for websites to take advantage of this feature, while gracefully degrading to what was possible without this API in browsers that don't yet support it.


Security

Letting websites write to (and read from) arbitrary files on disk is inherently dangerous. This risk is mitigated by blocking access to particularly sensitive/dangerous locations (such as those containing chrome, or operating system files). Additionally all written files are run through safe browsing checks in exactly the same way regular downloads are. More details in https://wicg.github.io/native-file-system/#privacy-considerations and https://wicg.github.io/native-file-system/#security-considerations.



Debuggability

No additional devtools or other debugging support has been added specific to this feature. 

For debuggability purposes it would be nice to expose more about handles than is exposed to script (such as what actual files on disk a handle corresponds to). Additionally we have a long-standing bug (https://crbug.com/256067) to bring devtools support to the sandboxed/private file system API.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No This API is currently only supported on Desktop platforms (i.e. Windows, Mac, Linux and Chrome OS). Mobile platforms have moved away from the model of having multiple applications share a file system to  interact with the same data in favor of Share actions, and as such the current entry points this API defines are a poor fit for Android. In the future we might introduce other entry points using the same interfaces that are a better fit for Android/mobile platforms.


Is this feature fully tested by web-platform-tests?

Most of the API surface has tests: https://wpt.fyi/results/native-file-system?label=experimental&label=master&aligned In addition to the tests listed on wpt.fyi we also have manual tests that exercise the API surface the host operating's native file system as opposed to the sandboxed/origin private file system, and in chrome these manual tests are also run automated. Actual integration with file dialogs on various platforms is not currently testable in an automated fashion.


Tracking bug

https://crbug.com/853326


Demo links


https://github.com/GoogleChromeLabs/text-editor

https://googlechromelabs.github.io/text-editor/


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6284708426022912


This intent message was generated by Chrome Platform Status.



Joshua Bell

unread,
Aug 19, 2020, 1:54:48 PM8/19/20
to Marijn Kruisselbrink, blink-dev
Spec mentor (newly minted!) weighing in here - 

Like most specs, the work is never quite done. The remaining spec issues called out inline and on github - covering normative and non-normative TODOs - are unlikely to affect interop with sites. In particular, it could use Accessibility and Internationalization Considerations sections added, and integration with other infrastructure specs such as Storage is ongoing, but I wouldn't consider those blocking for shipping. 

 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVZpphZcq2YP4DV94YvrqBPxERf8%2BZyc8rANvSHDPuyiSA%40mail.gmail.com.

Chris Harrelson

unread,
Aug 19, 2020, 9:22:39 PM8/19/20
to Joshua Bell, Marijn Kruisselbrink, blink-dev
On Wed, Aug 19, 2020 at 10:54 AM Joshua Bell <jsb...@chromium.org> wrote:


On Tue, Aug 18, 2020 at 5:52 PM Marijn Kruisselbrink <m...@chromium.org> wrote:

Super-nit: the first sentence of this explainer says "are yet to be decided" - presumably it's been decided now? :)

Otherwise I like this explainer, it was easy to read and understand.
 
To what extent has this spec changed greatly since the last review from TAG, other vendors, or others in the W3C / WHATWG community? Your last comment on the TAG review mentions "a number of API changes in response to feedback we received", have some of those happened very recently and so might need some time for re-review? You also explicitly called out two issues about the API shape (issues 210 and 192) that you want TAG review on. If those change it's definitely breaking, so it would be very good to get feedback on those issues before shipping.

Similarly, the Mozilla standards position issue was first opened quite a while ago, then re-pinged two weeks ago.
 

Marijn Kruisselbrink

unread,
Aug 19, 2020, 10:20:24 PM8/19/20
to Chris Harrelson, Joshua Bell, blink-dev
On Wed, Aug 19, 2020 at 6:22 PM Chris Harrelson <chri...@chromium.org> wrote:


On Wed, Aug 19, 2020 at 10:54 AM Joshua Bell <jsb...@chromium.org> wrote:


On Tue, Aug 18, 2020 at 5:52 PM Marijn Kruisselbrink <m...@chromium.org> wrote:

Super-nit: the first sentence of this explainer says "are yet to be decided" - presumably it's been decided now? :)
Good catch, fixed.
 

Otherwise I like this explainer, it was easy to read and understand.
 
To what extent has this spec changed greatly since the last review from TAG, other vendors, or others in the W3C / WHATWG community? Your last comment on the TAG review mentions "a number of API changes in response to feedback we received", have some of those happened very recently and so might need some time for re-review?
Most of the API changes were directly or indirectly incorporating earlier TAG feedback (i.e. integration with the permissions API, multiple separate file/directory picker methods as opposed to one method with a bunch of options/different return types). Most of these changes were made ~a month ago. 217 was a change that was made very recently (this week), in response to Mozilla feedback that getOriginPrivateDirectory was not a very good name.
 
You also explicitly called out two issues about the API shape (issues 210 and 192) that you want TAG review on. If those change it's definitely breaking, so it would be very good to get feedback on those issues before shipping.
Re 210, I'm fairly confident of the decision we ended up making there. Every version of the spec (i.e. any version the TAG would have looked at) has had file picker methods directly on the global, which was never raised as a concern. I also discussed this with a former TAG member, who expressed a preference for keeping things that way rather than introducing some kind of namespacing. So I think what we ended up doing (i.e. keeping file picker methods directly on the global) is the right choice.

Re 192, is API surface wise just a single method, behaving fairly similar to the various existing methods to get drag&drop data. So with that in mind it seemed simple enough to include, as it doesn't seem like there is much room to do anything different there. But I can see the argument that perhaps we should delay shipping the drag&drop integration until people have had a bit more of a chance to play with this/provide feedback, as this is functionality that hasn't been part of the origin trials (it has been one of the top requests during the origin trial though).
 
Similarly, the Mozilla standards position issue was first opened quite a while ago, then re-pinged two weeks ago.
FWIW, from discussions at TPAC last year it seemed that some people at Mozilla were fairly supportive of the direction we were taking with this API, but those are different people from the people that have participated in the standards position discussion.

Yoav Weiss

unread,
Aug 20, 2020, 2:35:52 AM8/20/20
to Marijn Kruisselbrink, Chris Harrelson, Joshua Bell, blink-dev
LGTM1


On Thu, Aug 20, 2020 at 4:20 AM Marijn Kruisselbrink <m...@chromium.org> wrote:


On Wed, Aug 19, 2020 at 6:22 PM Chris Harrelson <chri...@chromium.org> wrote:


On Wed, Aug 19, 2020 at 10:54 AM Joshua Bell <jsb...@chromium.org> wrote:


On Tue, Aug 18, 2020 at 5:52 PM Marijn Kruisselbrink <m...@chromium.org> wrote:

Super-nit: the first sentence of this explainer says "are yet to be decided" - presumably it's been decided now? :)
Good catch, fixed.

Thanks for the explainer! I left a bunch of comments on ways in which I think the code examples can be improved (but not a blocker in any way)
 
 

Otherwise I like this explainer, it was easy to read and understand.
 
To what extent has this spec changed greatly since the last review from TAG, other vendors, or others in the W3C / WHATWG community? Your last comment on the TAG review mentions "a number of API changes in response to feedback we received", have some of those happened very recently and so might need some time for re-review?
Most of the API changes were directly or indirectly incorporating earlier TAG feedback (i.e. integration with the permissions API, multiple separate file/directory picker methods as opposed to one method with a bunch of options/different return types). Most of these changes were made ~a month ago. 217 was a change that was made very recently (this week), in response to Mozilla feedback that getOriginPrivateDirectory was not a very good name.
 
You also explicitly called out two issues about the API shape (issues 210 and 192) that you want TAG review on. If those change it's definitely breaking, so it would be very good to get feedback on those issues before shipping.
Re 210, I'm fairly confident of the decision we ended up making there. Every version of the spec (i.e. any version the TAG would have looked at) has had file picker methods directly on the global, which was never raised as a concern. I also discussed this with a former TAG member, who expressed a preference for keeping things that way rather than introducing some kind of namespacing. So I think what we ended up doing (i.e. keeping file picker methods directly on the global) is the right choice.

Re 192, is API surface wise just a single method, behaving fairly similar to the various existing methods to get drag&drop data. So with that in mind it seemed simple enough to include, as it doesn't seem like there is much room to do anything different there. But I can see the argument that perhaps we should delay shipping the drag&drop integration until people have had a bit more of a chance to play with this/provide feedback, as this is functionality that hasn't been part of the origin trials (it has been one of the top requests during the origin trial though).
 
Similarly, the Mozilla standards position issue was first opened quite a while ago, then re-pinged two weeks ago.
FWIW, from discussions at TPAC last year it seemed that some people at Mozilla were fairly supportive of the direction we were taking with this API, but those are different people from the people that have participated in the standards position discussion.

I read through the concerns raised on that thread, and they seem focused on privacy concerns where files can be used as a cross-origin communication channel.
That seems already possible to some extent with downloads and FileReader. Also, actually pulling it off requires the user to do a lot of work to make that happen (e.g. pick the same file across origins, to enable them to read it). As such, I don't think this is particularly troublesome.

 
 
Spec mentor (newly minted!) weighing in here - 

Like most specs, the work is never quite done. The remaining spec issues called out inline and on github - covering normative and non-normative TODOs - are unlikely to affect interop with sites. In particular, it could use Accessibility and Internationalization Considerations sections added, and integration with other infrastructure specs such as Storage is ongoing, but I wouldn't consider those blocking for shipping. 

 
Love the dialog between y'all and the TAG. Seems like a productive review and we ended up with a better API thanks to it!
 

Chris Harrelson

unread,
Aug 20, 2020, 6:18:18 PM8/20/20
to Yoav Weiss, Marijn Kruisselbrink, Joshua Bell, blink-dev
LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjpOzHp%2BG_uM6bOLxdSrNrw63OXyatDo7zkJxEjKYeAWg%40mail.gmail.com.

Daniel Bratell

unread,
Aug 21, 2020, 5:24:53 AM8/21/20
to Chris Harrelson, Yoav Weiss, Marijn Kruisselbrink, Joshua Bell, blink-dev

I like the single/multiple file handle parts of this. The directory parts make me nervous. I hope to hear some about what the security review considered and how they see this.

/Daniel

Mike West

unread,
Aug 25, 2020, 1:51:20 PM8/25/20
to blink-dev, Chris Harrelson, Yoav Weiss, Marijn Kruisselbrink, Joshua Bell, Daniel Bratell
LGTM3.

There are very reasonable concerns about the security properties of the API, which I think are more or less completely wrapped up in the way that the user is involved in the process of exposing a given file or directory to a given origin. The feature's security model document for Chromium is nicely detailed, walking through a number of considered risks and mitigations built into the implementation we'd ship. We have confidence in the chooser model generally, and believe that users can understand the implications of granting access to a given file or set of files via a combination of that chooser, subsequent permission prompts, and usage indicators. The API is flexible enough to allow us to shift these indicators, prompts, and choosers over time as we learn more about how it's used in the wild. I'm happy with where this ended up, and appreciate the iteration it took to get us there.

-mike


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e93d902e-3bf8-8aec-d5b0-54cd50bb5b25%40gmail.com.

Theodore Olsauskas-Warren

unread,
Sep 1, 2020, 11:21:50 AM9/1/20
to blink-dev, mk...@chromium.org, Chris Harrelson, yo...@yoav.ws, Marijn Kruisselbrink, Joshua Bell, Daniel Bratell
Just wanted to draw attention to this line in the draft spec: 

"User agents also are encouraged to provide a way for users to revoke permissions granted. Clearing browsing data is expected to revoke all permissions as well."

In particular the last half. The tying of permissions to clearing browsing data AFAIK is a Chrome specific choice. Even the term "Clearing browsing data" I believe is a Chrome specific combination of various deletions, including the more well defined "Clear Site Data". As an example, Firefox includes an option for clearing permissions as part of a "History" clearing operation. 

Is this line really required? It seems fairly well covered by the preceding paragraph (although it too conflates browsing data and site data). If it is, would it be possible to change the phrasing to be more implementation agnostic?

Theo.

Marijn Kruisselbrink

unread,
Sep 1, 2020, 12:23:28 PM9/1/20
to Theodore Olsauskas-Warren, blink-dev, mk...@chromium.org, Chris Harrelson, yo...@yoav.ws, Joshua Bell, Daniel Bratell
Good question, I agree that that sentence probably is not needed. https://github.com/WICG/native-file-system/issues/136 tracks cleaning up that entire section a bit, I'll keep this in mind when I get to that.

Marijn Kruisselbrink

unread,
Sep 17, 2020, 6:56:50 PM9/17/20
to Mike West, blink-dev, Chris Harrelson, Yoav Weiss, Joshua Bell, Daniel Bratell
We'd like to ask for permission to extend the origin trial for some time after M86 goes to stable. Currently the origin trial is set to expire one week before the expected stable release data, however we have partners that would like to start sharing sites using this API more widely sooner rather than later, and the week (+ however long it takes for users to upgrade to M86) interruption would make that a rather unpleasant user experience.

Given that the API is shipping in M86 anyway (and is significantly different from what was available as origin trial, so breakage will happen for websites that don't pay attention anyway) there don't really seem to be any downsides to skipping the one week breakage in this case, so I'd like to request an extension of the origin trial by a couple of weeks.

Yoav Weiss

unread,
Sep 21, 2020, 5:30:36 AM9/21/20
to Marijn Kruisselbrink, Mike West, blink-dev, Chris Harrelson, Joshua Bell, Daniel Bratell
Hey Marijn,

The API owners discussed this last week. Do y'all have strong evidence from the trial that matches what we'd like to see for a "gapless" OT?

Cheers :)
Yoav

Marijn Kruisselbrink

unread,
Sep 21, 2020, 8:17:36 PM9/21/20
to Yoav Weiss, Mike West, blink-dev, Chris Harrelson, Joshua Bell, Daniel Bratell
We have a number of internal and external partners that are very supportive of the API we're shipping in M86. There have been plenty of requests for additional functionality, but none that would require breaking changes to the API we're shipping.

Thomas Steiner

unread,
Sep 22, 2020, 3:57:45 AM9/22/20
to Marijn Kruisselbrink, Yoav Weiss, Mike West, blink-dev, Chris Harrelson, Joshua Bell, Daniel Bratell
On Tue, Sep 22, 2020 at 2:17 AM Marijn Kruisselbrink <m...@chromium.org> wrote:
We have a number of internal and external partners that are very supportive of the API we're shipping in M86.

Excalidraw is one example.

Yoav Weiss

unread,
Sep 22, 2020, 4:18:16 AM9/22/20
to Thomas Steiner, Marijn Kruisselbrink, Mike West, blink-dev, Chris Harrelson, Joshua Bell, Daniel Bratell
LGTM to ship without an OT gap for developers that already have their tokens.

On Tue, Sep 22, 2020 at 9:57 AM Thomas Steiner <to...@google.com> wrote:
On Tue, Sep 22, 2020 at 2:17 AM Marijn Kruisselbrink <m...@chromium.org> wrote:
We have a number of internal and external partners that are very supportive of the API we're shipping in M86.

Excalidraw is one example.

That's exactly what I was looking for. Thanks! 

Rodney Ding

unread,
Sep 24, 2020, 11:26:22 PM9/24/20
to blink-dev, yo...@yoav.ws, Marijn Kruisselbrink, mk...@chromium.org, blink-dev, Chris Harrelson, Joshua Bell, Daniel Bratell, Thomas Steiner
Friendly note that developers with existing tokens will have to renew their tokens after the extension is rolled out. The expiry date set on those tokens are fixed.
Reply all
Reply to author
Forward
0 new messages