search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
669 stars 66 forks source link

Permission checks should always display the full path #293

Closed slaymaker1907 closed 3 years ago

slaymaker1907 commented 3 years ago

The security of the current permission check for Chromium browsers is not ideal. Here is the current workflow in question:

  1. User visits ide.example.com and selects some directory to write to.
  2. ide.example.com saves the directory/file handles to IndexedDB to avoid excessive file prompts on reload.
  3. User doesn't visit ide.example.com for a few days.
  4. User goes back to ide.example.com and is prompted to authorize ide.example.com to read/readwrite file/folder.
    • Since this is just a permission check, there is no way for the user to know precisely which file/folder is in question.

I'm not sure if it is common practice to specify what information should be available to users for permission checks, but this seems like a good idea to have in the spec given the sensitivity of these APIs. Even if hidden under "advanced details" or something, users should be able to know precisely which files/directories are being written to.

This is particularly pernicious on shared machines since the current user may not have originally selected the file/directory to begin with. It is also a usability issue for when users have the same file located in multiple places, maybe having different versions in different directories or something.

ftreesmilo commented 3 years ago

I've seen users ask for help finding previously granted access. If I'm re-prompting for permission to a saved handle, it would help the user if they could see the whole path in the browser.

ftreesmilo commented 3 years ago

I think that this might be solved along the same lines as #282 if chrome were to show the full path in the UX interaction flow via chrome, and in dev tools. Can one of these be closed?

mkruisselbrink commented 3 years ago

I think this is more an implementation concern rather than a spec concern (although perhaps there should be some non-normative text around this in the spec). Would you mind filing a bug on crbug.com/new for this? Then we can take that to our UX and privacy/security teams and figure out what they think of displaying the full path in certain circumstances (like re-prompting for access). I believe in our current implementation the full path is visible in a tool-tip when hovering the file name, but that is not very discoverable, and I'm not sure if it actually works everywhere a name is displayed.