Commit 56a2eb1a authored by Tails developers's avatar Tails developers
Browse files

Update blueprint to reflect current status of the design process.

parent fd40c6d4
...@@ -6,10 +6,31 @@ Related pages ...@@ -6,10 +6,31 @@ Related pages
* [[!tails_ticket 5525]] * [[!tails_ticket 5525]]
* [[blueprint/Mandatory_Access_Control]] * [[blueprint/Mandatory_Access_Control]]
* [[contribute/design/application_isolation]] * [[contribute/design/application_isolation]]
* `feature/5525-sandbox-web-browser` branch
* [nightly built images](http://nightly.tails.boum.org/build_Tails_ISO_feature-5525-sandbox-web-browser/)
Status Status
====== ======
## code
* Create the persistent "Tor Browser files" when needed.
* Adjust bookmarks creation:
* a GNOME bookmark pointing to `~/Tor Browser files/`,
that's *always* present
* a GNOME bookmark pointing to `~/Persistent/Tor Browser files`,
that's only added when `~/Persistent/` is persistent read-write
* Adjust AppArmor profiles to support the new directory names.
* Configure Tor Browser to download to / upload from `~/Tor Browser
files/` by default.
## documentation
* Document where users can download files, e.g.
on [[doc/anonymous_internet/Tor_Browser]].
* Document that one should put files in that specific directory before
submitting them for upload in the Tor Browser.
## automated test passes ## automated test passes
(needs to be run again with current status of the branch at some point) (needs to be run again with current status of the branch at some point)
...@@ -105,84 +126,46 @@ long term we'll have even better solutions showing up, as explained ...@@ -105,84 +126,46 @@ long term we'll have even better solutions showing up, as explained
above, so IMO this shouldn't block confining the Tor Browser above, so IMO this shouldn't block confining the Tor Browser
in Tails.] in Tails.]
The obvious (and easiest to implement) solution to this, from my The obvious (and easiest to implement) solution to this would be to
perspective, was to add a persistence setting for `~/Downloads/` add a persistence setting for `~/Downloads/` (called "Browser
(called "Browser Downloads", subtitled "Downloads from the Tor Downloads", subtitled "Downloads from the Tor Browser", akin to the
Browser", akin to the "Browser Bookmarks" we already have), and to add "Browser Bookmarks" we already have), and to add a GNOME bookmark
a GNOME bookmark called "Downloads" when the Downloads persistence called "Downloads" when the Downloads persistence feature is enabled.
feature is enabled. This is implemented in the However, having downloads be either always amnesiac or always
`feature/5525-sandbox-web-browser` branch, and can be tested using the persistent (unless you restart or do stuff outside of the browser)
latest nightly built image from that branch: seems like a regression, since it breaks one of the core Tails
<http://nightly.tails.boum.org/build_Tails_ISO_feature-5525-sandbox-web-browser/>. properties. And forcing it to be a persistent folder by default
actually has security issues since secure deletion don't work as
Then sajolida submitted another idea: expected on flash memory. So, users should still have the option to
download either to an amnesiac (by default) or persistent place, like
> Then could we imagine giving the browser access to two places: a it is the case now.
> non-persistent place (~/Downloads) and a persistent place (maybe
> ~/Persistent/Downloads) and let the user decide when stuff gets downloaded? So we give Tor Browser access to:
>
> This is pretty much the case as of today: when I download something it * `~/Tor Browser files` (amnesiac)
> proposes to download to ~/Downloads by default but if I want to save it * `~/Persistent/Tor Browser files`
> for real I have to browser my myself to somewhere under ~/Persistent.
> Note that we don't call them "Downloads", because e.g. if someone
> Then we don't need a new persistence feature. writes an ODT text and wants to upload it, having to move it to
a folder called "Downloads" sounds really weird.
Indeed this would work. And then, the questions that are speficic to
sajolida's proposal are: Remaining questions:
* What should be the _default_ download directory proposed to the 1. What to do about alternative browsers (I2P and Unsafe Browser)?
user? `~/Downloads/` in all cases? `~/Persistent/Downloads/` iff.
this directory is persistent in read-write mode? I've not looked at
how hard it is to change this at runtime, but I guess it's easy.
* Implementation-wise, we have to create `~/Persistent/Downloads/`
whenever `~/Persistent/` is made persistent.
Now, here are some remaining questions that apply to both proposals.
Below, I'll use the term "persistent downloads directory" for both the
persistent `~/Downloads/` I've implemented, and the persistent
`~/Persistent/Downloads/` sajolida suggested.
1. Take a step back. Think. Do you see a better general solution to
this problem? [AFAIK no other Live OS has AppArmor enabled by
default, so there's no source of inspiration available.] Feel free
to dream awake: worst case I'll tell you that it's impossible, too
hard, or only good for the long term, and it'll still be useful.
2. Shall we display a Downloads bookmark in GNOME even if
`~/Downloads/` is not persistent? I guess we should not.
3. Shall we rename the bookmark pointing to the default persistent
downloads directory "Persistent Downloads"? But then users may lose
data by mistake when they use read-only persistence option,
believing it'll be persistent. OTOH, we have had a "Persistent"
bookmark for years, even in read-only persistence mode, and 1.
nobody complained; 2. the read-only persistence mode is barely used
at all anyway.
4. Shall we rename the persistent uploads directory and the
corresponding bookmark to include the "Uploading files" use case?
E.g. maybe we can find a name that conveys the "files shared with
Tor Browser" concept. See below for more bits about this uploading
files topic.
5. What to do about alternative browsers (I2P and Unsafe Browser)?
We have [[!tails_ticket 8280 desc="a ticket"]] about allowing the We have [[!tails_ticket 8280 desc="a ticket"]] about allowing the
I2P Browser to access local files. Shall we use e.g. I2P Browser to access local files. Shall we use e.g. `~/Tor Browser
`~/Downloads/Tor Browser/`, `~/Downloads/I2P Browser/` and files/`, `~/I2P Browser files/` and `~/Unsafe Brower files/` (the
`~/Downloads/Unsafe Brower/` (the latter may make sense now that we latter may make sense now that we plan to move the LAN browsing
plan to move the LAN browsing support into the Unsafe Browser) — support into the Unsafe Browser) — and equivalently,
and equivalently, if we go with sajolida's idea, `~/Persistent/Tor Browser files/`, etc.? or rather a single
`~/Persistent/Downloads/Tor Browser/`, etc.? shared namespace, with e.g. `~/Browser files/Tor Browser`,
If we go this way, IMO we should: `~/Browser files/I2P Browser`, etc.?
* have a single persistent feature for the persistent downloads
directory (`~/Downloads/` or `~/Persistent/Downloads/`) In any case, of course we should _not_ allow a given browser to
* have a single bookmark to that directory access files in other browsers' own download directory (this would
* _not_ allow a given browser to access files in other browsers' be too much of a linkability and de-anonymization risk)
own download directory (this would be too much of a linkability
and de-anonymization risk) 2. The "New Identity" problem. The Tor Browser tries hard to prevent
6. The "New Identity" problem. The Tor Browser tries hard to prevent
data to persist once its "New Identity" button has been clicked, to data to persist once its "New Identity" button has been clicked, to
prevent activities performed before and after this action to be prevent activities performed before and after this action to be
linked with each other. As boyska (a Freepto developer) made me linked with each other. As boyska (a Freepto developer) made me
...@@ -200,28 +183,14 @@ persistent `~/Downloads/` I've implemented, and the persistent ...@@ -200,28 +183,14 @@ persistent `~/Downloads/` I've implemented, and the persistent
users in my experience, see [[!tails_ticket 7709]]), warns them users in my experience, see [[!tails_ticket 7709]]), warns them
that their previous downloads will be deleted, or rather moved to that their previous downloads will be deleted, or rather moved to
a directory where that the Tor Browser hasn't access to. a directory where that the Tor Browser hasn't access to.
Another idea is to block the "New Identity" until the user has
themselves emptied the browser files directory, e.g.:
When I click on "New Identity" while there are files in one
of the downloads directories
Then I'm told "Tor Browser will be reset to a New Identity
once you have emptied folders $x and $y"
And then, once I have emptied the download directories
Then Tor Browser is reset to a New Identity
Food for thought. Food for thought.
7. Ideally, we should not need any documentation, but in this case
I believe we do: users _will_ try to download to directories that
the browser don't have access to, and wonder why the browser says
"No read permission" or similar. I guess that at least
doc/anonymous_internet/Tor_Browser should have a new section
about this.
Uploading files
---------------
Basically, the same problems apply as for downloading files. Is it
better to share a common directory with downloads, or to add
a different one to the whitelist?
In any case, I guess we have to:
* document that one should put files in that specific directory before
submitting them for upload in the Tor Browser
* make sure that this directory is selected by default when clicking
a "Browse" upload button on a website
I didn't think much about this uploading problem, so all ideas
are welcome.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment