Feature #15463

Remove "Downloads" shortcut

Added by sajolida 2018-03-27 17:44:41 . Updated 2019-05-08 14:15:30 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-03-27
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

In Files, Places, and the file chooser sidebar. As pointed out in “Downloads”, this folder is misleading as people can expect it to be where the downloads from Tor Browser go while it’s not the case.

How complicated would it be to remove it?

Subtasks

Related issues

Related to Tails - Bug #10790: Too many non-Tails folders on Nautilus sidebar In Progress 2015-12-23

History

#1 Updated by intrigeri 2018-03-27 18:25:54

  • Assignee changed from intrigeri to sajolida
  • QA Check deleted (Info Needed)

sajolida wrote:
> In Files, Places, and the file chooser sidebar. As pointed out in “Downloads”, this folder is misleading as people can expect it to be where the downloads from Tor Browser go while it’s not the case.

FYI we could easily make that shortcut point to the Tor Browser directory. If this solves the problem you’re tackling here, that’s probably cheaper than removing it. But various software use XDG_DOWNLOAD_DIR so if we do that we’re essentially giving access to Tor Browser to all downloads done in another app, which weakens our AppArmor sandboxing of Tor Browser.

> How complicated would it be to remove it?

Setting XDG_DOWNLOAD_DIR="$HOME" in ~/.config/user-dirs.dirs does the trick and it survives xdg-user-dirs-update. Next question is how we can integrate that in Tails. I see three options:

  • We ship a user-dirs.dirs file in the ISO with only that variable set, and we hope that on login xdg-user-dirs-gtk-update does what we want (beware of localization).
  • We run xdg-user-dirs-update --set ourselves during login in but that might race with the xdg-user-dirs-update command that’s already run at login time.
  • We set DOWNLOAD= (or comment it out) in /etc/xdg/user-dirs.defaults but I’ve no idea what the resulting behaviour will be.

To tell if one of those would work I would need to try, i.e. actually do most of the work.

Note that XDG_DOWNLOAD_DIR is used by various software so hiding that shortcut might harm usability in unexpected ways.

#2 Updated by sajolida 2018-04-07 14:37:47

  • related to Bug #10790: Too many non-Tails folders on Nautilus sidebar added

#3 Updated by sajolida 2018-04-07 15:05:35

  • Assignee changed from sajolida to intrigeri
  • QA Check set to Info Needed

Thanks for the technical insights: I think I understood!

Would it be easier to enforce a version of .config/user-dirs.dirs that points all shortcuts to $HOME leading to removing all of them? See also Bug #10790#note-8. Then we won’t have localization problems :)

I understand that we need ~/Desktop to set the launchers on the Desktop but I didn’t test if this breaks if we set XDG_DESKTOP_DIR=$HOME.

#4 Updated by intrigeri 2018-04-10 07:42:45

  • related to Feature #14544: Spend software developer time on smallish UX improvements added

#5 Updated by intrigeri 2018-05-29 07:37:52

  • Assignee changed from intrigeri to sajolida
  • QA Check deleted (Info Needed)

sajolida wrote:
> Would it be easier to enforce a version of .config/user-dirs.dirs that points all shortcuts to $HOME leading to removing all of them?

I’ve no idea, sorry: one would need to try it out (i.e. do most of the work) in order to answer this.

> I understand that we need ~/Desktop to set the launchers on the Desktop but I didn’t test if this breaks if we set XDG_DESKTOP_DIR=$HOME.

I’m pretty sure it would break our desktop icons (but I have a vague, crazy plan to move them to the Favorites + always display the Favorites sidebar on the desktop just like Ubuntu does, when the deprecated nautilus support for displaying icons on the desktop becomes too much of a maintenance hassle, so once we’re there that won’t be a problem anymore).

#6 Updated by sajolida 2018-06-01 18:43:51

  • Assignee deleted (sajolida)

I don’t want to spend more time on this myself until we have someone to write the code. See Feature #15028#note-11.

#7 Updated by sajolida 2018-06-01 18:44:15

  • related to deleted (Feature #14544: Spend software developer time on smallish UX improvements)

#8 Updated by intrigeri 2019-01-23 12:19:07

#9 Updated by sajolida 2019-05-03 11:32:46

Actually, we don’t we use the default “Downloads” folder for the downloads of Tor Browser (and OnionShare). I understand that the point of the “Tor Browser” folder is to only allow Tor Browser to access a very restricted part of the file system but would there be a serious security downside to using the default “Downloads” folder for that?

#10 Updated by intrigeri 2019-05-03 14:36:30

> Actually, we don’t we use the default “Downloads” folder for the downloads of Tor Browser (and OnionShare).

FTR the original discussion on this topic was: https://lists.autistici.org/message/20150129.153422.f9dd3882.en.html

“Downloads” was my original proposal. It seems it was rejected because of the potential for confusion: that’s also the folder where one needs to put files they want to upload. You seemed to concur, and after a couple iterations we ended up with what we still have nowadays. I personally think that the download use case is vastly more common than the upload one, so I’d rather optimize for downloads and solve the upload confusion via documentation. I don’t think that’s worse than the status quo for uploads: I bet most users won’t guess they need to place the files they want to upload in the “Tor Browser” folder, so they need to learn/read/discover already.

Another aspect was our desire back then to support more browsers, at least one for I2P. So having a way to distinguish their respective “downloads” folder seemed useful. I don’t think we should take this into account when designing now. If an I2P browser is reintroduced, we’ll see what we do about it, but let’s optimize for Tor Browser.

> I understand that the point of the “Tor Browser” folder is to only allow Tor Browser to access a very restricted part of the file system but would there be a serious security downside to using the default “Downloads” folder for that?

I can think of no big problem about that.

One thing is that some AppArmor profiles for other apps (e.g. Pidgin) give access to ~/Downloads. So if we move to what you’re suggesting, to avoid increasing the privileges of these apps, we’ll need to do something. That seems totally doable.

#11 Updated by sajolida 2019-05-08 14:14:44

> FTR the original discussion on this topic was: https://lists.autistici.org/message/20150129.153422.f9dd3882.en.html

OMG! So cool to read this! I didn’t even remember that this discussion
happened :)

> “Downloads” was my original proposal. It seems it was rejected because of the potential for confusion: that’s also the folder where one needs to put files they want to upload. You seemed to concur, and after a couple iterations we ended up with what we still have nowadays. I personally think that the download use case is vastly more common than the upload one, so I’d rather optimize for downloads and solve the upload confusion via documentation. I don’t think that’s worse than the status quo for uploads: I bet most users won’t guess they need to place the files they want to upload in the “Tor Browser” folder, so they need to learn/read/discover already.

Full ack! Now that we have huertanix’s reports and my experience from
usability tests, it’s clear that the potential advantages for people
downloading files will outweigh the potential downsides for the people
uploading.

If someone has managed to download already, which is very likely, they
will also be better educated to find out that they should use the same
folder to upload.

> Another aspect was our desire back then to support more browsers, at least one for I2P. So having a way to distinguish their respective “downloads” folder seemed useful. I don’t think we should take this into account when designing now. If an I2P browser is reintroduced, we’ll see what we do about it, but let’s optimize for Tor Browser.

Yes.

> One thing is that some AppArmor profiles for other apps (e.g. Pidgin) give access to ~/Downloads. So if we move to what you’re suggesting, to avoid increasing the privileges of these apps, we’ll need to do something. That seems totally doable.

From my very basic AppArmor skills, it seems like it’s only Pidgin. I’m
fine with removing Pidgin’s access to Downloads and be done with it.

#12 Updated by sajolida 2019-05-08 14:15:30

  • Status changed from Confirmed to Rejected

So I think that we should reject this ticket: we’re not going to remove the “Downloads” shortcut but instead use it to replace the amnesiac “Tor Browser” folder.