Project

General

Profile

Feature #8790

Feature #5525: Sandbox the web browser

Add a persistence feature for Tor Browser Downloads

Added by intrigeri over 4 years ago. Updated over 4 years ago.

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

100%

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

Related issues

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

History

#1 Updated by intrigeri over 4 years ago

  • 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 over 4 years ago

  • % 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 over 4 years ago

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

#4 Updated by intrigeri over 4 years ago

Why is this a subtask of #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 #5525 would introduce a serious UX regression. I'd rather avoid it.

But really, #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 over 4 years ago

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 #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, #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 over 4 years ago

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 over 4 years ago

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

#8 Updated by intrigeri over 4 years ago

  • 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.

Also available in: Atom PDF