path: root/wiki/src/blueprint/sandbox_the_web_browser.mdwn
diff options
Diffstat (limited to 'wiki/src/blueprint/sandbox_the_web_browser.mdwn')
1 files changed, 122 insertions, 0 deletions
diff --git a/wiki/src/blueprint/sandbox_the_web_browser.mdwn b/wiki/src/blueprint/sandbox_the_web_browser.mdwn
new file mode 100644
index 0000000..7be3a77
--- /dev/null
+++ b/wiki/src/blueprint/sandbox_the_web_browser.mdwn
@@ -0,0 +1,122 @@
+[[!toc levels=2]]
+Related pages
+* [[!tails_ticket 5525]]
+* [[blueprint/Mandatory_Access_Control]]
+* [[contribute/design/application_isolation]]
+* `feature/5525-sandbox-web-browser` branch
+* [nightly built images](
+## automated test passes
+* feature/i2p (unconfined)
+* feature/torified_browsing
+* feature/unsafe_browser (unconfined)
+* feature/windows_camouflage
+* open `https://` URL from Pidgin
+* relevant bits of feature/usb_install
+ - view persistent bookmarks, in read-only persistence mode ([[!tails_ticket 8787]])
+ - persistent bookmarks, RW
+* "Tails documentation" link on the Desktop ([[!tails_ticket 8788]])
+* default download directory is `~/Tor Browser`
+* HTML5 audio playback
+* WebM video and audio playback
+* download to amnesiac `~/Tor Browser`
+* read from amnesiac `~/Tor Browser`
+* default upload directory is `~/Tor Browser/`
+* `~/Tor Browser/` must always exist
+* there must always be a GTK bookmark to `~/Tor Browser/`
+* import OpenPGP key from website
+* printing to file
+* download to persistent `~/Persistent/Tor Browser`, in
+ read-write persistence mode
+* read from persistent `~/Persistent/Tor Browser`, in read-write
+ persistence mode
+* when `~/Persistent/` is persistent read-write, then
+ `~/Persistent/Tor Browser` must exist and there must be
+ a GNOME bookmark pointing to it
+## manual test OK
+(needs to be tested again with current status of the branch at some point)
+* add NoScript exception
+* change stuff in about:prefs
+* manually update AdBlock Plus lists
+* add a bookmark, with persistent bookmarks feature enabled, in
+ read-only persistence mode
+* install a Firefox add-on (this does not mean we actively support that, right? :)
+* read from persistent `~/Persistent/Tor Browser`, in read-only
+ persistence mode
+## manual test OK, maybe needs automated test
+## known issues
+## needs testing
+* printing to real printer
+<a id="ux"></a>
+User experience matters
+Until the `feature/5525-sandbox-web-browser` branch is merged, see the
+"User experience matters" section on
+Later, see [[contribute/design/application_isolation#ux]].
+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. `~/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/`, 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
+ realize while we were discussing these problems, by introducing
+ a persistent downloads directory, we somewhat break this design
+ goal. Of course, we've never even tried protecting against this
+ specific attack, so maybe we can just ignore it for now. And the
+ Tor Browser doesn't try either -- once they add sandboxing
+ profiles, I bet they'll need to think about that too, so one way to
+ do it would be to start a discussion with them about this problem,
+ and consider it as a non-blocker for now. One idea we had with
+ boyska was to add a confirmation dialog when one clicks the "New
+ Identity" button in the Tor Browser, that makes it clear what's
+ going to be lost (e.g. tabs and clipboard, which surprises a lot of
+ 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.
+ 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.