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

[mkruisselbrink]

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.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/file-system-access/blob/main/SuggestedNameAndDir.md
• Security and Privacy self-review²: https://github.com/WICG/file-system-access/blob/main/security-privacy-questionnaire.md
  • And specifically Update security-privacy-questionnaire.md for suggested name/dirs. WICG/file-system-access#270 contains changes made to this document for these features.
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/file-system-access
• Primary contacts (and their relationship to the specification):
  • Marijn Kruisselbrink (@mkruisselbrink), Google
• Organization/project driving the design: Google/Chromium
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/6013006146174976

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: Add initial explainer for suggestedName, startIn and related options. WICG/file-system-access#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

[kenchris]

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

[torgo]

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?

[tomayac]

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

[torgo]

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?

[tomayac]

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.

[hemeryar]

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?

[mkruisselbrink]

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.

[yisibl]

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

[mkruisselbrink]

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

[kenchris]

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

[Roaders]

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.