Hi,
[I subscribed to the list for now, so no need to Cc me in this thread.]
sajolida wrote (01 Feb 2015 14:33:53 GMT) :
> 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.
Full ACK. Thanks, I love changing my mind sometimes :)
I'll sum it up in the design doc so that we remember why we went
this way.
> "- 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.
Agreed.
> 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...
I have to say I don't like these ideas much.
a) They open a can of worms (we have this very same problem for
*every* application's "Save As" feature) I'd rather avoid to deal
with right now. I don't see how the Tor Browser is different, and
why users would assume that Tails is amnesic by default, except its
Tor Browser.
b) If we make it more explicit to users that Tor Browser's downloads
are amnesic by default, then I'm afraid that users may be confused,
and especially new users may believe that everything else is
persistent by default, because oh well, otherwise why would we
bother telling them that the downloads are amnesic?
c) Whenever possible, let's avoid teaching people to click through
pop-up warning. The blog posts of the GNOME Safety folks are
enlightening in this respect, by the way :)
=> Apparently we have a problem to solve in this area, that is
a general Tails problem: "how do we convey to new users the message
that anything that's not explicitly persistent will be forgotten?" And
also "how do we make it clearer to the users which folders are
persistent read-write, and which ones will see their content forgotten
after reboot?" I'm happy if people start thinking about solving this
problem globally (and actually I have a few crazy ideas in this area
myself, e.g. color-flagging persistent folders somehow in file
dialogs), but I'll consider it as out of the scope of my current
"sandboxing the Tor Browser" deliverable.
> "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.
Thanks. That's not realistic for Tails 1.3 (I warned you ;) and IMO it
also applies to all other applications, see above.
> "2. Shall we display a Downloads bookmark in GNOME even if ~/Downloads/
> is not persistent?"
> This is already the case right now,
I can't reproduce this: after booting Tails 1.2.3, there's no
"Downloads" link in Places, nor in the GTK "Save As" dialog.
What happens instead for me is: when one clicks "Save Page As" in Tor
Browser, the Downloads folder is created, but there is still no
GNOME bookmark.
> 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.
So, the idea would be:
* a GNOME bookmark pointing to "~/Tor Browser files/" (or similar),
that's *always* present
* a GNOME bookmark pointing to "~/Persistent/Tor Browser files" (or
similar), that's only added when ~/Persistent/ is persistent
(read-write?)
> "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.
OK.
> "...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 :)
I'm pretty sure that this would break most of our persistence
features, and I'd rather avoid having e.g. ~/Persistent/ behave
differently from ~/.gnupg/ when read-only persistence is enabled.
> But this is a more generic problem and not only in the
> browser, right?
Indeed. It's quite clear that the read-only persistence feature didn't
get enough UX thought as it should have when it was introduced.
Oh well, back then we didn't even know what "UX" meant :]
So I still don't really know what to do wrt. this read-only
persistent thing for the downloads. I now tend to think we should
*not* add the GNOME bookmark to "~/Persistent/Tor Browser files" in
that case.
> "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?
Indeed.
> So we should find a solution that's generic enough and can scale to
> 5 to 10 apps.
Maybe. Unless the better general upstream solutions land soon enough.
Not clear. In the meantime, for most apps the blacklist approach we
currently have e.g. for Evince, Pidgin and Totem is probably good
enough in the context of Tails (where most people don't save stuff in
folders with unpredictable names), and should avoid going as far as "5
to 10 apps".
Anyway, I agree we should be careful about it, and that's a reason why
I thought that putting the 3 browsers' directories in a dediced
namespace would be better. With "your" current proposal, we would need
a folder for each of it at the root of $HOME. Not sure if we'll regret
it later..
> "...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.
I'm now convinced and will drop that. Thanks.
> "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?
Not without patching the GTK that Tor Browser uses (no, please), or
moving to using containers or Linux namespaces (not mature enough yet
IMO for our needs).
So:
* very much unrealistic for Tails 1.3, so the question still holds,
and I guess the best we can do for now is what I proposed
(documentation);
* once we're at the sophistication level of patching GTK, there are
better solutions we can think of than this one.
> "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.
OK.
> 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.
ACK.
> While writing that email, the most satisfying proposal I came up with
> was to have those two folders:
> - ~/Tor Browser files (amnesiac)
As argued above, I don't find it sound to single-out this specific
directory and calling it "amnesiac", while all the rest of the
filesystem exposed to the user really is amnesiac too.
So I guess that gives us "~/Tor Browser files", unless my reasoning
above wrt. the 2 other browsers lead you to think that calling it e.g.
"~/Browser files/Tor Browser" would be better (the GNOME bookmark
could still be called "Tor Browser files" by the way :)
> - ~/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.
Sounds perfect to me.
> "6. The "New Identity" problem"
> Could we force them to clean the "Tor Browser files" folders before
> changing identity?
(Assuming that "them" means "users".) I guess we could do that indeed,
especially since we have this Tor control port filter proxy, so we can
refuse to send the New Identity command to Tor until these folders
have been emptied. I like this idea, as I believe it might satisfy the
TBB dev team too when they confine it on their side (=> *they* might
write the Torbutton code needed to implement that).
Not sure it's realistic for 1.3, but let's see how it should look
like. Something like the following?
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
Now, I'd like us to:
* about what we've discussed, that I didn't put aside as unrealistic
on the short term: reach a consensus ASAP (ideally, by Wednesday
evening), so I can implement it;
* about the longer-term ideas: casually discuss it a bit more (it's
exciting!) and then I'll file tickets and fill the blueprint
as appropriate.
Thanks again!
Cheers,
--
intrigeri
