Bugzilla

I (In reply to :Gijs (he/him) from comment #15)
> (In reply to Simon Friedberger (:simonf) from comment #14)
> > From a UX perspective it doesn't make a difference to people if they are opening
> > a) a website
> > b) a PDF on a website
> > c) a PDF which wants to be downloaded on a website
> 
> This just isn't generally true, even if it is for you. See e.g. bug 1756980 and everything linked to it, bug 1772569, a number of other bugs we wontfixed that are still unhappy because we show the PDF at all in case (c) and who just want it downloaded, not opened, but only in case (c).
I'm not saying people don't want something else other than "open PDF". I am saying IF we open it, it looks the same as the other cases. Which is why people are complaining about the "clutter". They didn't expect a download.

> > If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)
> 
> Could people just get used to them still being deleted in private browsing mode? :-)

I don't think it's appropriate to delete files from ~Downloads. /tmp is fine but ~Downloads is a regular folder and users don't expect their files to get deleted. Plus, if we start deleting files from ~Downloads a big chunk for the motivation to move from /tmp to ~Downloads applies again.

> > Private Browsing:
> > For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.
> 
> As noted above, we've made the decision in response to user feedback that this isn't viable, so now it's treated the same as "always open in [external app]".
I think the clearest solution here would be to just not open in external app but always be explicit about the download. But I doubt people would appreciate the difference in behavior from regular Firefox.

> > And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.
> 
> I mean, the what-ifs here I think aren't really helpful. "Don't do that" would be sensible advice in this case, not least because an attacker could probably overwrite executables you're in the process of downloading and think are benign, etc.
True, but as long as the applications which need access to the files can get them we could even create a new /fxtmp or similar with whatever strictest permissions are possible.

> > External Applications:
> > There is a case d) a file is automatically opened with an external application
> > In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.
> 
> What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?
The point is that the user should not be able to make changes to a file which will be deleted.
And honestly, if an external application has a file which cannot be saved in a different location because of file specific restrictions and still lets the user make changes to write protected files (which he then clearly cannot save) I think that's a bug in that application.

I (In reply to :Gijs (he/him) from comment #15)
> (In reply to Simon Friedberger (:simonf) from comment #14)
> > From a UX perspective it doesn't make a difference to people if they are opening
> > a) a website
> > b) a PDF on a website
> > c) a PDF which wants to be downloaded on a website
> 
> This just isn't generally true, even if it is for you. See e.g. bug 1756980 and everything linked to it, bug 1772569, a number of other bugs we wontfixed that are still unhappy because we show the PDF at all in case (c) and who just want it downloaded, not opened, but only in case (c).

I'm not saying people don't want something else other than "open PDF". I am saying IF we open it, it looks the same as the other cases. Which is why people are complaining about the "clutter". They didn't expect a download.

> > If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)
> 
> Could people just get used to them still being deleted in private browsing mode? :-)

I don't think it's appropriate to delete files from ~Downloads. /tmp is fine but ~Downloads is a regular folder and users don't expect their files to get deleted. Plus, if we start deleting files from ~Downloads a big chunk for the motivation to move from /tmp to ~Downloads applies again.

> > Private Browsing:
> > For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.
> 
> As noted above, we've made the decision in response to user feedback that this isn't viable, so now it's treated the same as "always open in [external app]".
I think the clearest solution here would be to just not open in external app but always be explicit about the download. But I doubt people would appreciate the difference in behavior from regular Firefox.

> > And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.
> 
> I mean, the what-ifs here I think aren't really helpful. "Don't do that" would be sensible advice in this case, not least because an attacker could probably overwrite executables you're in the process of downloading and think are benign, etc.
True, but as long as the applications which need access to the files can get them we could even create a new /fxtmp or similar with whatever strictest permissions are possible.

> > External Applications:
> > There is a case d) a file is automatically opened with an external application
> > In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.
> 
> What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?
The point is that the user should not be able to make changes to a file which will be deleted.
And honestly, if an external application has a file which cannot be saved in a different location because of file specific restrictions and still lets the user make changes to write protected files (which he then clearly cannot save) I think that's a bug in that application.

I (In reply to :Gijs (he/him) from comment #15)
> (In reply to Simon Friedberger (:simonf) from comment #14)
> > From a UX perspective it doesn't make a difference to people if they are opening
> > a) a website
> > b) a PDF on a website
> > c) a PDF which wants to be downloaded on a website
> 
> This just isn't generally true, even if it is for you. See e.g. bug 1756980 and everything linked to it, bug 1772569, a number of other bugs we wontfixed that are still unhappy because we show the PDF at all in case (c) and who just want it downloaded, not opened, but only in case (c).

I'm not saying people don't want something else other than "open PDF". I am saying IF we open it, it looks the same as the other cases. Which is why people are complaining about the "clutter". They didn't expect a download.

> > If we start deleting files from there, like in PBM, it's extra odd because people who actually want the file don't think about storing it anymore because the URL bar says it's already there. (:Gijs, I think that's the answer to your question why these issues are now popping up. People are getting used to the files being there.)
> 
> Could people just get used to them still being deleted in private browsing mode? :-)

I don't think it's appropriate to delete files from ~Downloads. /tmp is fine but ~Downloads is a regular folder and users don't expect their files to get deleted. Plus, if we start deleting files from ~Downloads a big chunk for the motivation to move from /tmp to ~Downloads applies again.

> > Private Browsing:
> > For private browsing, it's a bit more tricky than storing to /tmp. Ideally it would just live in memory with the rest of the private browsing session because if somebody looks at some distasteful PDF they probably don't want other users to see those PDFs in /tmp.
> 
> As noted above, we've made the decision in response to user feedback that this isn't viable, so now it's treated the same as "always open in [external app]".

I think the clearest solution here would be to just not open in external app but always be explicit about the download. But I doubt people would appreciate the difference in behavior from regular Firefox.

> > And this problem might actually be worse for ~/Downloads because the user might have deliberately set lax access rights there.
> 
> I mean, the what-ifs here I think aren't really helpful. "Don't do that" would be sensible advice in this case, not least because an attacker could probably overwrite executables you're in the process of downloading and think are benign, etc.

True, but as long as the applications which need access to the files can get them we could even create a new /fxtmp or similar with whatever strictest permissions are possible.

> > External Applications:
> > There is a case d) a file is automatically opened with an external application
> > In this case some kind of file is necessary to be passed to the external application. That file does however need to be thoroughly write protected so that nobody makes changes to it and gets confused when it is later deleted.
> 
> What does "thoroughly write protected" mean here? We have to write to the file, we're downloading it... do you just mean you want Firefox to set the file as read-only on Windows, and 0o400 on linux/mac, once we finish downloading? Do we know if that's actually safe, ie how many apps will break if they can read but not write to the file (e.g. to update file-format specific "last opened" timestamps or w/e) ?

The point is that the user should not be able to make changes to a file which will be deleted.
And honestly, if an external application has a file which cannot be saved in a different location because of file specific restrictions and still lets the user make changes to write protected files (which he then clearly cannot save) I think that's a bug in that application.