Feature #8790

Add a persistence feature for Tor Browser Downloads

Added by intrigeri 2015-01-24 16:33:40 . Updated 2015-02-04 17:26:30 .

Status:
Rejected
Priority:
Normal
Assignee:
intrigeri
Category:
Persistence
Target version:
Start date:
2015-01-24
Due date:
% Done:

100%

Feature Branch:
persistence-setup:feature/8790-downloads-preset
Type of work:
Code
Starter:
Affected tool:
Browser
Deliverable for:

Description


Subtasks


Related issues

Related to Tails - Feature #8821: Design how to deal with downloads and uploads in sandboxed Tor Browser Resolved 2015-01-29 2015-02-04

History

#1 Updated by intrigeri 2015-01-24 16:35:07

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to persistence-setup:feature/8790-downloads-preset

#2 Updated by intrigeri 2015-01-24 18:38:53

  • % Done changed from 10 to 20
  • Blueprint set to https://tails.boum.org/blueprint/sandbox_the_web_browser/

Works fine. Next step is to think about UX. Preliminary thoughts on the blueprint, I’ll complete it and ask feedback on tails-ux@ soon.

#3 Updated by sajolida 2015-01-25 10:43:33

Why is this a subtask of Feature #5525? Couldn’t we imagine a sandboxed browser without persistent download, like it is the case currently for Tor Browser?

#4 Updated by intrigeri 2015-01-25 16:44:04

> Why is this a subtask of Feature #5525? Couldn’t we imagine a sandboxed browser without persistent download, like it is the case currently for Tor Browser?

Good question! If there’s not enough free memory to store the downloaded file, and the browser is sandboxed and can’t save stuff anywhere else than in ~/Downloads/ (e.g. on the persistent volume), then Feature #5525 would introduce a serious UX regression. I’d rather avoid it.

But really, Feature #8790 is merely a proof-of-concept I wanted to implement before I start a discussion about this on -ux@. The details are by no means final yet, and I’ll need help to get it right.

#5 Updated by sajolida 2015-01-27 20:57:45

> Good question! If there’s not enough free memory to store the
> downloaded file, and the browser is sandboxed and can’t save stuff
> anywhere else than in ~/Downloads/ (e.g. on the persistent volume),
> then Feature #5525 would introduce a serious UX regression. I’d rather avoid
> it.

Understood.

Then could we imagine giving the browser access to two places: a
non-persistent place (~/Downloads) and a persistent place (maybe
~/Persistent/Downloads) and let the user decide when stuff gets downloaded?

This is pretty much the case as of today: when I download something it
proposes to download to ~/Downloads by default but if I want to save it
for real I have to browser my myself to somewhere under ~/Persistent.

Then we don’t need a new persistence feature.

> But really, Feature #8790 is merely a proof-of-concept I wanted to implement
> before I start a discussion about
> this
> on -ux@. The details are by no means final yet, and I’ll need help to
> get it right.

Ok, so I won’t anticipate stuff. I’ll wait and see. Tell me if you need
help to brainstorm.

#6 Updated by intrigeri 2015-01-28 16:52:53

> Then could we imagine giving the browser access to two places: a
> non-persistent place (~/Downloads) and a persistent place (maybe
> ~/Persistent/Downloads) and let the user decide when stuff gets downloaded?

> This is pretty much the case as of today: when I download something it
> proposes to download to ~/Downloads by default but if I want to save it
> for real I have to browser my myself to somewhere under ~/Persistent.

> Then we don’t need a new persistence feature.

Thanks, I’ll include this idea on the blueprint.

#7 Updated by intrigeri 2015-01-29 15:37:35

  • related to Feature #8821: Design how to deal with downloads and uploads in sandboxed Tor Browser added

#8 Updated by intrigeri 2015-02-04 17:26:30

  • Status changed from In Progress to Rejected
  • % Done changed from 20 to 100

After discussing this on tails-ux@, we’ve decided not to do that. Some details are on the blueprint and will then be moved to the design doc.