#598: Suggested file name and location for the File System Access API.

Visit on Github.

Opened Jan 22, 2021

HIQaH! QaH! TAG!

I'm requesting a TAG review of suggested file name and location for the File System Access API.

When initially shipping the File System Access API we shipped a bare minimum API surface for showing file and directory pickers. We're now proposing adding a couple of frequently requested (and commonly supported in other file picker APIs) options to let websites provide a couple more opportunities to influence the behavior of the file and directory pickers. In particular we want to let websites give suggestions for the name and location of files and directories that are being saved or loaded.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): unknown
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/file-system-access/pull/261
  • Major unresolved issues with or opposition to this design:
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Jan 1, 2021 (See Github)

Ken: Good explainer....

Ken: Left comment generally supportive.

Dan: Left comment asking about privacy issues.

Comment by @kenchris Jan 26, 2021 (See Github)

@torgo and I looked at this in our Virtual TAG F2F breakout.

Thank you for the great explainer and links to developer interest. The feature additions look very sensible to us.

Comment by @torgo Jan 26, 2021 (See Github)

I would like to see a bit more discussion in the explainer about why this does not present privacy issues for the end user? Reading between the lines, it seems to me that the web application would not gain additional information about the user's file system hierarchy - but for example could information about the existence of well-known starting locations be improperly exposed?

Comment by @tomayac Jan 26, 2021 (See Github)

For the file name, this is something that <a download="readme.txt"> already enables.

For the well-known directories, these would indeed map to the by-default ones that operating systems commonly have. Here's an example from macOS (the app would not learn that my home directory is called tsteiner):

<img width="146" alt="Screen Shot 2021-01-26 at 11 15 14" src="https://user-images.githubusercontent.com/145676/105832060-c600bd80-5fc7-11eb-8fc5-33d67ba8f50f.png">
Comment by @torgo Jan 26, 2021 (See Github)

For the well-known directories, these would indeed map to the by-default ones that operating systems commonly have. Here's an example from macOS (the app would not learn that my home directory is called tsteiner):

Thanks for the quick reply @tomayac! Just to clarify : I understand that the home directory name would be kept private but would the app be able to confirm the existence of "Downloads" or "Movies" (or something else) through use of this API?

Comment by @tomayac Jan 26, 2021 (See Github)

It is a suggestion, so if, for whatever reason, the user has deleted, for example, their ~/Downloads folder (the default folder for downloads on macOS), the picker would just open at another location (implementation-specific), unobservable to the website.

Comment by @hemeryar Jan 26, 2021 (See Github)

We had a look today during the chrome security/privacy triage and it was looking good overall. There was no real concern for any of the suggestions apart from /home/ that felt a bit too close to root. Is there specific use cases you're thinking about for this one or should we maybe remove it from the well known list?

Comment by @mkruisselbrink Jan 26, 2021 (See Github)

We didn't really have any specific use cases in mind for home, it just seemed like a nice to have one. But given your concerns, removing it from the well known list sounds good to me.

Comment by @yisibl Jan 28, 2021 (See Github)

Can the new design be recorded in the download list of the browser? (e.g. chrome://downloads/)

Comment by @mkruisselbrink Jan 28, 2021 (See Github)

Can the new design be recorded in the download list of the browser? (e.g. chrome://downloads/)

No, I think that would have to be a separate feature (I mean, technically nothing it stopping browsers from showing files picked via showSaveFilePicker in their "downloads" list, but not sure when/why it would make sense to do so).

Discussed Mar 8, 2021 (See Github)

Dan: good response on security.. can close?

Ken: we already looked at it and it was positive.. no further comments

Dan: close in plenary

Comment by @kenchris Mar 9, 2021 (See Github)

We don't have any further comments, so this looks good to us!

Comment by @Roaders Mar 25, 2021 (See Github)

Can the new design be recorded in the download list of the browser? (e.g. chrome://downloads/)

No, I think that would have to be a separate feature (I mean, technically nothing it stopping browsers from showing files picked via showSaveFilePicker in their "downloads" list, but not sure when/why it would make sense to do so).

In my use case (downloading reports in either pdf or spreadsheet format) it would be very useful to show the downloaded file in the footer of the browser as most of the time a user will want to immediately open the file after it has been downloaded.