intrigeri:
> I need help from you folks.
>
> The kind of sandboxing we're going to use is basically built from
> a set of per-file or per-directory allow/deny rules: e.g. the Tor
> Browser will only have read and write access to a specific set
> of directories.
>
> I've summed up the problem, ideas, solutions and remaining questions
> on the blueprint:
> https://tails.boum.org/blueprint/sandbox_the_web_browser/#ux
>
> Please consider commenting on it in the next few days.
We discussed this a bit together with tchou. Since I already have a
proposal included in the blueprint, I'm reluctant to argue much more in
that direction (even if tchou would go in my direction as well).
To summarize our position, we think that people should still have the
option to download either to an amnesiac (by default) or persistent
place, like it is the case now. This seem to be a core feature of Tails
and changing this to force downloads to be either always amnesiac or
always persistent (unless you restart or do stuff outside of the
browser) seems like a regression. 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.
But we're still missing a smart way of structuring and naming those
folders :)
To answer some of your questions:
"- What should be the default download directory proposed to the user?"
I would say the amnesiac one by default, like it is the case now. Better
safe than sorry. But I'm open to change that if we have a good reason.
Tchou also pointed out that this is a bit problematic right now
actually, people new to Tails might be surprised by this (even if it's
out motto I agree). He proposed having a warning when first saving to
this folder. I would propose to name it something that makes it clear
that it is amnesiac, "Downloads (amnesia)" or something...
"1. Take a step back. Think. Do you see a better general solution to "
"this problem?"
Not really :) But we mentioned the idea of displaying information about
those folder and isolation mechanism to the user when first interacting
with the file system from the browser.
"2. Shall we display a Downloads bookmark in GNOME even if ~/Downloads/
is not persistent?"
This is already the case right now, so I'd leave it like this
personally. On top of that I would make it explicit which folder is
amnesiac and which folder is persistent. People might want to download
stuff to RAM even if they have persistence enabled. Same as before:
secure deletion don't work as expected on flash memory.
"3. Shall we rename the bookmark pointing to the default persistent
downloads directory "Persistent Downloads""?
Yes, or to something else that makes it explicit that this is a
persistent folder.
"...users may lose data by mistake when they use read-only persistence
option, believing it'll be persistent..."
Couldn't we mount those folders as read-only when they are supposed to
be read-only? Because, indeed, it sounds weird to be able to write to a
read-only folder or loose file written to a "persistent" folder :)
But this is a more generic problem and not only in the browser, right?
"5. What to do about alternative browsers (I2P and Unsafe Browser)?"
I would add to that "what about other applications that we might sandbox
in the future"? Aren't we going to sandbox, let's say the email client
for example to protect against targeted viruses? So we should find a
solution that's generic enough and can scale to 5 to 10 apps.
"...have a single persistent feature for the persistent downloads "
directory..."
I'm still not convinced that we need a new persistent feature for that.
I'm actually quite concerned about having to many persistent features.
We already have 14 right now. With my proposal in mind (having a
dedicated folder under ~/Persistent), we're already covered by the
"Personal Data" feature.
"7. users will [...] wonder why the browser says "No read permission""
Can we even prevent them from moving out of the restricted folder, or
from seeing the structure of the other folders?
"Uploading files: Is it better to share a common directory with "
"downloads, or to add a different one to the whitelist?"
I would say that it is ok to use a single folder for persistent
downloads and uploads, and a second one for amnesiac downloads and uploads.
But then tchou was worried about having it called "Downloads", when it
can be used for uploads as well. Several things can happen:
1. Someone download a file from site A and uploads it to site B.
Then it's probably all-right to look for it in a folder called
"Downloads".
2. But if someone writes an ODT text and wants to upload it, having
to move it to a folder called "Downloads" sounds really weird. And
that scenario can happen for both files that are made persistent
and files that are meant to remain amnesiac.
While writing that email, the most satisfying proposal I came up with
was to have those two folders:
- ~/Tor Browser files (amnesiac)
- ~/Persistent/Tor Browser files
If the second folder could appear as "Tor Browser files (persistent)" in
the GNOME shortcuts then I would be super happy.
"6. The "New Identity" problem"
Could we force them to clean the "Tor Browser files" folders before
changing identity?
--
sajolida
