1342563 - Allow downloads to specify a path outside of the downloads folder

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Andy McKay]

Currently all the downloads apis (download and onDeterminingFilename) do not allow you to write outside of the downloads directory. As a user when I download an add-on, I can choose a different directory to save a file too. But the user is making a concious and understandable choice about that directory.

This proposal would allow the downloads API to suggest a directory and if its outside the downloads the directory then the user must take some action and agree to the destination.

The primary concern here is that risk to the user is worth the value of the feature and I suspect that it isn't, but I'd really like some security and UX input on this.

How would the target destination be presented to a user?
Would it be too easy to obfuscate the destination?
Is the benefit worth the risk?

Comment 1

[Andy McKay]

(In reply to Andy McKay [:andym] from comment #0)
> As a user when I download an add-on
 
s/an add-on/a file/

Comment 2

[Markus Jaritz [:designakt] (UX)]

I do not see a user benefit here.
The user can either not trust that the location is the one they are used to - all the time, or they have to deal with additional dialogs on some of the downloads. Which adds a lot of complexity for the user if they can not rely on a consistent flow.

Comment 3

[Caitlin Neiman [:caitmuenster]]

This has been added to the agenda for the December 5, 2017 WebExtensions APIs triage meeting. If you are interested in this bug, please feel welcome to join the meeting! 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1vH4wqJJZt1jk-cpx5NOq67b1UNekeQog6bz2HFOHe5E/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 4

[Geoffrey De Belie (Smile4ever)]

A list of allowed save locations is maybe an option?

Comment 5

[Andy McKay]

Sorry, my fault, this bug is a pretty big one to discuss in that five minutes. It get's into lots of things.

Some of the concerns brought up in the meeting include:

* How would the extension know any path names? That sort of thing is hidden from the extension.

* The new saveAs option for downloads sort of does this, with some prompting, that's bug 1394851.

Mike, since this would require the sign off from multiple parties, perhaps we should leave this in the PM backlog instead.

Comment 6

[Mike Conca [:mconca]]

With the addition of the saveAs option (bug 1394851) that allows the user to select a location anywhere their system can see, this really comes down to allowing extensions to programmatically suggest a download location outside of the default download folder without showing the File Save As... dialog box.

Several of the security risks and UX issues have already been pointed out.  No benefits have been pointed out.  Can anyone identify a use case where this feature would provide some sort of value to the end user?  To date, I have not seen/heard any demand for this.

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

There were several addons to specify where a download/image/... should be saved, both manually and automated, e.g. https://addons.mozilla.org/firefox/addon/automatic-save-folder/ and https://addons.mozilla.org/firefox/addon/save-image-in-folder/

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I have an add-on that would benefit from this. It has a one click download feature, and I would like the user to choose where the files are saved. Right now, I have manually created a symlink in the downloads directory so I can put the files where I want them, but this is not a comfortable solution for the user.

What would be sufficient for my use case is if the user was able to select a download location once with a save as type dialog (e.g. in the add-on options), then the add-on would be allowed to save there forever. This is still a conscious decision, and doesn't require the save as dialog to pop up every time.

Comment 9

[Kathleen :Brade]

I am one of the authors of Page Saver and this is one of the most requested features by users of our web extension addon.  Users want to be able to specify the folder where their pages are saved or to have it remember the last location which the user selected.  Many just want to specify their "Desktop" but some want a folder specific for Page Saver images.  They are very accustomed to a workflow that was supported by pre-WebExtension add-ons but which is no longer possible. I think that the idea suggested by Philipp in comment 8 would meet the needs of our users and the users of many other add-ons.

Here is a sampling of recent feedback we have received from our English-speaking users:

* From an AMO review:
... I wish I could save the screenshots to my desktop instead of the downloads folder ...

* Feb 2018 email from B.:
... [I want to] be able to determine a default folder for the saved screen captures ...

* Dec 2017 email from J.:
... Using files is clumsy. ...

* Nov 2017 email from S.:
... In the Pre-Firefox-Quantum-Version of Page Saver there was the opportunity to define a specific download-folder. Will this function be a future feature in the WE-Version of the Page Saver? ...

* Nov 2017 email from J.:
... please can you add an option "remember last location for filesave" in your otherwise perfect ;-) product Page Saver WE? ...

* Nov 2017 email from D.:
... but now must deal with not being able to save, automatically, where I want to...

* Nov 2017 email from S.:
... it would be great if PS remembered the folder I keep saving images to until I change it. I have it set to prompt for filename but it always points to the download folder no matter how many times I save to something else. ...

* Oct 2017 email from R.:
... An irritating problem, is that it does not remember the name of the last folder where a file was saved ... It is annoying to have to be presented with an option to save in 'This PC->Downloads' folder all the time. I always save files in my own folders on a separate hard-drive. ...

* Oct 2017 email from R.:
... no custom directory...which is more important because I sync my snapshots with evernote ...

Comment 10

[jjl]

I've written a local bookmarking / web clipping extension (as yet unpublished).  It stores links and metadata (and maybe page content in the future).  It talks to a external local process over HTTP.  In order to prevent access by websites on the internet, all communication to the external process is via a capability URL, i.e. a secret URL containing an unguessable string.

The extension and the external app have to agree on the secret URL to use.  Either the external application can generate the URL, or the browser can.

Because of the design of the external app (which may start without any user interaction), having the external application generate the URL would involve two steps for the user: generate the URL using the external application, then cut and paste it into the browser extension (or introducing a currently non-existent UI just so you can drag and drop the capability URL to the browser extension -- which is also a complicated user interaction).  Having the user ask the browser to save the URL in the database directory (perhaps via a button on the config page) would be one step.  But this is probably only less effort for the user if I can suggest the default bookmark directory: otherwise they have to know where it's supposed to be saved and then click around to find that directory.

Comment 11

[jjl]

By the way, I'd just suggest using the Downloads directory as the bookmarks database directory, but I think people would object to that.

For example, I'm a user of my own extension, and I would find that awkward because I normally treat the content of Downloads as a personal cache: I know I can delete stuff in there whenever I like and I won't lose anything important.  I couldn't work that way any more if the database directory had to be in Downloads.

Comment 12

[dw-dev]

Andy,

I have two add-ons (Save Page WE and Print Edit WE) that would benefit hugely from the ability to:

- open the download 'Save As' dialog in the same directory as the last file saved by the add-on
- for this directory to be outside of the the default downloads directory hierarchy

I propose two enhancements to the downloads.download() API:

1. A new 'fileNameType' options property, which can take two values:
 
   - "relative" if the path in 'fileName' is relative to the default downloads directory (the default).
   - "absolute" if the path in 'fileName' is a full absolute path

2. A new 'savedFileName' parameter to the callbak function, which returns the full absolute path of the saved file.
   (possibly this could return an absolute or relative path depending on the value of 'fileNameType').

After the first save (which the user would have to navigate in the Save As dialog), the would allow the add-on to instruct the downloads.download() API to save the file in the same folder as the last saved file.

Is the design decision likely to be reviewed in the near future?

Comment 13

[Andrew Swan [:aswan]]

Regarding comment 10, it sounds like your particular application would be better served by native messaging:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging

(In reply to dw-dev from comment #12)
> Is the design decision likely to be reviewed in the near future?

Andy is no longer actively working on webextensions, redirecting your needinfo.

Comment 14

[jjl]

I was aware of the native messaging API.  Looking at it again now, these things still put me off:

* Practical: I believe I'd have to define a fixed path for a system executable.  This might seem to be almost the very same problem as occurs with Save As directory path suggestions (in order to save a file containing a capability URL as I describe in comment #10). In practice that's not the case I think: saving config data in a path relative to (and contained in) a user's home directory doesn't combine awkwardly with practices like software packaging on linux, nor with supporting all of mac, linux and windows.  Requiring a fixed path for an executable seems a more awkward constraint to support.  In my judgement that seems even more offputting to some potential users than an arbitrarily constrained poor UI in which one has to cut and paste in the capability URL.  In case there's a different expectation from readers here: I expect that my candidate users will prefer to install the 'native application' separately from the addon.

* Principle: Does this single API really need to be non-web?

* Practical consequence: In the environment of a web browser, as a lazy developer, the native messaging API smelled like a likely source of irritating development cul-de-sacs (because a non-web API -- still! -- seems likely to be or become a poor relation of web APIs).  Of course, that may be factually incorrect: after all here I am, now stuck in a *different* cul-de-sac: but that's exactly why this principled reason I'm pointing at is important.

Comment 15

[Mike Conca [:mconca]]

:ddurst, I'd like to get a security review of this, particularly the suggestion in Comment 12. Do we feel it is safe to allow extensions to specify a path to a download directory?

Comment 16

[Tomislav Jovanovic :zombie]

(In reply to dw-dev from comment #12)
> 2. A new 'savedFileName' parameter to the callbak function, which returns
> the full absolute path of the saved file.

I don't think we'll be passing absolute paths back and forth to extensions.

But allowing subsequent file SaveAs dialogs (after the first one) for the same extension to open in the same directory as the first one would be fairly safe, and cover most use cases.

Comment 17

[dw-dev]

This would be fine, but I think the downloads.download() API would need a new options property, so the add-on can choose whether to save to the default downloads directory or to the same place as last navigated by the user.

Comment 18

[Tomislav Jovanovic :zombie]

Yeah, that's what I had in mind too, something like `saveAs: true, useLastDir: true`.


(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #15)
> :ddurst, I'd like to get a security review of this, particularly the
> suggestion in Comment 12. Do we feel it is safe to allow extensions to
> specify a path to a download directory?

If we are ok with this approach, I don't think we need a formal sec review here.

Comment 19

[dw-dev]

Exactly - with useLastDir defaulting to false.

Comment 20

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Tomislav Jovanovic :zombie from comment #18)
> Yeah, that's what I had in mind too, something like `saveAs: true,
> useLastDir: true`.
> 
> 
> (In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #15)
> > :ddurst, I'd like to get a security review of this, particularly the
> > suggestion in Comment 12. Do we feel it is safe to allow extensions to
> > specify a path to a download directory?
> 
> If we are ok with this approach, I don't think we need a formal sec review
> here.

David asked me to look at this: FWIW I agree we don't need formal sec review here - I can't think of any particular risks of allowing an extension to re-use the last saved directory. 

The only risk I can think of here is disclosure of a sensitive path (/Users/name/somethingIdontWantShared/here). But IIUC the path is only disclosed if the download is started (i.e. the user chose to save the file in this location), and that's the existing risk profile of this API. So sounds fine to me.

Comment 21

[Judah Richardson]

Hopefully this gets implemented soon. DownThemAll recently returned as a WebExtension, but its inability to save directly to anywhere else but the Downloads folder is significantly reducing its usefulness.