Can't open downloads folder due to containing "system files"

[bradisbell]

On Chrome, I can't even open my Downloads folder so that an app can save several files at once, because it allegedly contains "system files". (It doesn't.) This is due to section 6.1:

The default directory for downloads, if the user agent has such a thing. Individual files inside the directory again should be allowed, but the whole directory would risk leaking more data than a user realizes.

This specification is far too conservative in what it allows users to do on their own computers, and with their own data. By all means, users should be informed of dangers, but the user agent cannot truly know the intent of the user, nor the application they're using. The user agent should work on behalf of the user, not block them for reasons that often do not apply.

I propose that all items listed in section 6.1 be allowed, following a warning message and confirmation by the user.

[jimmywarting]

I have been in the same boat

I have also found it to be quite annoying and unnecessary restrictive.
like you i have also tried to select a folder that do not contain system files at all (it was an empty folder). so the error message is confusing. it's just b/c of

risk leaking more data than a user realizes

if that is the case then it should say so...! not b/c it contains system files (which it dose not do)

anyway there is a round about way to select a folder \w drag and drop files into the browser and it dose not have the same limitation, then you could use DataTransferItem.prototype.getAsFileSystemHandle

[mathieu-fournier]

Can we re-open this issue, since both issues #381 and #380 have been closed without a response.

Also, I would like to know more the drag and drop workaround, is there an example somewhere I could look at ?
Thanks

[jimmywarting]

Also, I would like to know more the drag and drop workaround, is there an example somewhere I could look at ?

https://developer.mozilla.org/en-US/docs/Web/API/DataTransferItem/getAsFileSystemHandle

[mathieu-fournier]

I would like to reopen this issue.

I feel like the drag and drop workaround can be counter intuitive in some cases.
Ex : Selecting a download location, by opening the file manager manually and drag and droping the file into the browser, feels unusual and overcomplicated.

Since the folder can be accessed with the drag and drop API, I think this API should allow it as well.
I propose to have 3 options in the alert message :

• Edit (unsafe)
• Choose a different folder
• Cancel

Thanks (:

[guillaumebrunerie]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1405817 for the misleading error message, as it is a browser bug, not an issue in the specification.
Disallowing the user to choose the Downloads folder does seem very reasonable to me, though, why would someone want to give read access to everything they ever downloaded?

[jimmywarting]

why would someone want to give read access to everything they ever downloaded?

Simply put: To save files & folders... not to necessary read the content of it.

isn't it weird that you can have read or read/write access but not just write access as a mean to just download multiple files and folders?
sure if you got just one file that needs to be downloaded then you could use the good old save techniques

you could maybe perhaps build some kind of ccleaner or daisydisk to figure out what takes space. so they often require a lot of read access

[guillaumebrunerie]

Write-only access is probably trickier because of the risk of collisions. What should happen if you want to save a file that already exists? Should it be automatically renamed to something else? (in that case you can basically already do batch downloads with existing mechanisms). Should it silently replace existing files? That feels weird and a potential security risk.

A lot of people are very much used to the workflow:

• Click on a button that says "Download"
• A file picker opens in the Downloads folder, click OK
• The file is now downloaded

In the current state of the spec, allowing access to the Downloads folder would make it very easy for a malicious webpage to pretend that you are about to download a file, but they suddenly can read all your downloads, your latest bank statements, your upcoming flight tickets, your identity documents that you scanned and downloaded from your email, and so on.

On the other hand, requiring drag and drop for accessing such "sensitive" directories is pretty reasonable, as dragging and dropping your whole Downloads folder into a webpage is a pretty weird thing to do by accident.

[bradisbell]

why would someone want to give read access to everything they ever downloaded?

@guillaumebrunerie Simply put, that's up to the user to decide. The user agent should follow the user's intention.

We don't need to enumerate use cases to justify that the user should be in control of their data and how it's used. The user agent can certainly have guardrails, but those guardrails are to ensure user intention, not to prevent them from doing something.

[bradisbell]

Write-only access is probably trickier because of the risk of collisions. What should happen if you want to save a file that already exists?

When saving, the user can choose where to save and what to name the file. Perhaps that name is simply what to name the directory in which the application can write into.

[bradisbell]

In the current state of the spec, allowing access to the Downloads folder would make it very easy for a malicious webpage to pretend that you are about to download a file, but they suddenly can read all your downloads, your latest bank statements, your upcoming flight tickets, your identity documents that you scanned and downloaded from your email, and so on.

The alternative is that people having to make native apps which allow access to far more than a downloads folder, while also being a poor user experience that limits platform choice. Please consider this framing.

On the other hand, requiring drag and drop for accessing such "sensitive" directories is pretty reasonable, as dragging and dropping your whole Downloads folder into a webpage is a pretty weird thing to do by accident.

Accidental dragging/dropping happens regularly. In fact, it happens to me with dirty touch screens, interference with wireless mice, and with finger control problems due to hand injury.

[mathieu-fournier]

Giving Read access to the download folder can be used to verify if some files have already been downloaded into a floder.
Thus allowing to resume a download where it have been left.

I`ve never experienced any download that asked to drag and drop a folder to set the download location. This is poor UX imo.
We should let the user decide wether or not the content or their download folder is sensitive or not.
They can always empty the folder if they want.

If we still dont want to allow read/write access to the download folder.
I suggest to allow the creation and to get an access to a sub-folder within the download folder.
That way, we would be able to download at the download location, but we would be restricted to our own download folder.

[guillaumebrunerie]

I`ve never experienced any download that asked to drag and drop a folder to set the download location. This is poor UX imo.

That's my point exactly, so that's why the API does allow access to the whole Downloads folder when dragging and dropping, because it doesn’t feel like you are setting a download location. Such a UX would make a bit more sense for a disk analyzer app for instance.

If we still dont want to allow read/write access to the download folder. I suggest to allow the creation and to get an access to a sub-folder within the download folder. That way, we would be able to download at the download location, but we would be restricted to our own download folder.

Yes, this already works in Chrome and is explicitly mentioned in the spec as a safe way to use this API to download many files without having to give read access to sensitive folders.

[jimmywarting]

the drag and drop loophole for blocklisted directories to be accessible will be closed soon

What a grate way to break the web, Thought so strongly the moral was to never ever break any backward compatible of what is compatible of today no matter how bad/legacy it's, what is next? blocking those folder too in classic `input[type=file][webkitdirectory]`?

"hey user, you must run chrome with disabled security check flags turned on."

if user really REALLY want do select the download, home, cookie folder or anything to be selected and they are sure about what they are really getting them self into with proper prompt notification, then let them?

how else are we suppose to be able to write kickas ccleaner, disc analyzer programs?
My little program i have built a while ago is going to find out what takes space on a HDD is going to stop doing wonders.

I know there is a risk of user selecting more than what they realize, there are both pro and conn to each side. and user will keep asking tech support why they can't pick folder xyz or how to get around it.

i probably now also realize that chrome is not ever going to allow those folder b/c of security risk.

the only thing i can hope for now is that you can mitigate some of the concerns some developers have about being able to download files.
I hope you will be able to write files to OPFS and being able to copy those files into clipboard and then user can paste this file on the HDD wherever they want.

I also belive something like a showSaveDirectoryPicker could be useful to help mitigate some concerns as to be able to download many multiple files. into one directory of the user own choosing
it would be a little bit like

• idea - allow websites default directory access to $HOME/Downloads/<domain.name> #235

but you would be able to suggest your own name and location and you would get read & write access to that newly created folder without the need of any additional prompts for the browser session.

const dirHandle = await showSaveDirectoryPicker({ suggestedDirectoryName: 'photopea' })

instead of asking to pick a folder to save things in you would instead ask the user to create a new folder in which you would get allowed read & write access to that newly created folder.

or if you could perhaps be able to just simply be able to download a list of file/directory handles

globalThis.download([
  directoryHandle,
  fileHandle,
  fileHandle2
])

this will only deal with saving stuff but not reading...

[tomayac]

@jimmywarting The CL that introduced this drag and drop change was quickly reverted. I have deleted my previous comments.