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
* [[!tails_ticket 5525]]
* [[blueprint/Mandatory_Access_Control]]
* [[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
======
## 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
(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
above, so IMO this shouldn't block confining the Tor Browser
in Tails.]
The obvious (and easiest to implement) solution to this, from my
perspective, was to add a persistence setting for `~/Downloads/`
(called "Browser Downloads", subtitled "Downloads from the Tor
Browser", akin to the "Browser Bookmarks" we already have), and to add
a GNOME bookmark called "Downloads" when the Downloads persistence
feature is enabled. This is implemented in the
`feature/5525-sandbox-web-browser` branch, and can be tested using the
latest nightly built image from that branch:
<http://nightly.tails.boum.org/build_Tails_ISO_feature-5525-sandbox-web-browser/>.
Then sajolida submitted another idea:
> 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.
Indeed this would work. And then, the questions that are speficic to
sajolida's proposal are:
* What should be the _default_ download directory proposed to the
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)?
The obvious (and easiest to implement) solution to this would be to
add a persistence setting for `~/Downloads/` (called "Browser
Downloads", subtitled "Downloads from the Tor Browser", akin to the
"Browser Bookmarks" we already have), and to add a GNOME bookmark
called "Downloads" when the Downloads persistence feature is enabled.
However, having downloads be either always amnesiac or always
persistent (unless you restart or do stuff outside of the browser)
seems like a regression, since it breaks one of the core Tails
properties. And forcing it to be a persistent folder by default
actually has security issues since secure deletion don't work as
expected on flash memory. So, users should still have the option to
download either to an amnesiac (by default) or persistent place, like
it is the case now.
So we give Tor Browser access to:
* `~/Tor Browser files` (amnesiac)
* `~/Persistent/Tor Browser files`
Note that we don't call them "Downloads", because e.g. if someone
writes an ODT text and wants to upload it, having to move it to
a folder called "Downloads" sounds really weird.
Remaining questions:
1. What to do about alternative browsers (I2P and Unsafe Browser)?
We have [[!tails_ticket 8280 desc="a ticket"]] about allowing the
I2P Browser to access local files. Shall we use e.g.
`~/Downloads/Tor Browser/`, `~/Downloads/I2P Browser/` and
`~/Downloads/Unsafe Brower/` (the latter may make sense now that we
plan to move the LAN browsing support into the Unsafe Browser) —
and equivalently, if we go with sajolida's idea,
`~/Persistent/Downloads/Tor Browser/`, etc.?
If we go this way, IMO we should:
* have a single persistent feature for the persistent downloads
directory (`~/Downloads/` or `~/Persistent/Downloads/`)
* have a single bookmark to that directory
* _not_ allow a given browser to access files in other browsers'
own download directory (this would be too much of a linkability
and de-anonymization risk)
6. The "New Identity" problem. The Tor Browser tries hard to prevent
I2P Browser to access local files. Shall we use e.g. `~/Tor Browser
files/`, `~/I2P Browser files/` and `~/Unsafe Brower files/` (the
latter may make sense now that we plan to move the LAN browsing
support into the Unsafe Browser) — and equivalently,
`~/Persistent/Tor Browser files/`, etc.? or rather a single
shared namespace, with e.g. `~/Browser files/Tor Browser`,
`~/Browser files/I2P Browser`, etc.?
In any case, of course we should _not_ allow a given browser to
access files in other browsers' 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
data to persist once its "New Identity" button has been clicked, to
prevent activities performed before and after this action to be
linked with each other. As boyska (a Freepto developer) made me
......@@ -200,28 +183,14 @@ persistent `~/Downloads/` I've implemented, and the persistent
users in my experience, see [[!tails_ticket 7709]]), warns them
that their previous downloads will be deleted, or rather moved to
a directory where that the Tor Browser hasn't access to.
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
---------------
Another idea is to block the "New Identity" until the user has
themselves emptied the browser files directory, e.g.:
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?
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
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.
Food for thought.
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