<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#1F497D">
Hi Kai,<br>
<br>
Thanks for your thoughts.. Some comments below.<br>
<br>
On 24/11/2011 21:30, Kai Engert wrote:
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">During
MozCamp Berlin I listened to JB's presentation about TB.
<br>
<br>
He presented the idea, instead of sending large files by email, TB
could assist the user by uploading the files to a Cloud service,
and sending the email containing a link.
<br>
<br>
I like that idea in general, but I would like to comment from a
security/privacy point of view, and give some additional
inspiration.
<br>
<br>
Email is a point-to-point communication. Using a Cloud service
adds another party to the communication, and could easily lead to
unintentional publishing of information.
<br>
</blockquote>
You're right and we are paying attention in not misleading the user.
BigFiles is an alternative way of exchanging large files using
email. It is not meant as a replacement to file attachment and the
UI should make this very clear. Both mechanism remain valid options.
We might want to use 'attach' and 'share' to differentiate the two
options.<br>
'Publishing' is probably not the right term, imho.<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
I believe most email used today is unencrypted. But still, unless
there is a man-in-the-middle that is deliberately watching all
your communication, sending a personal email usually won't result
in automatic uploading or publishing.
<br>
</blockquote>
Again, we should make users aware of the sharing nature of BigFiles
and leave choice to attach or share. If users decide to share, they
do it in full knowledge, pros & cons. And again, we're not
talking of something automatic (whilst users might choose to make
BigFiles their default file exchange method).<br>
Another way of reinforcing security is to ensure that server stored
files can not be traversed. Not super easy though...<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
Worse, if the person is actually using encrypted email (either
using the built-in S/MIME or using an Add-On such as Enigmail),
the user might forget about the fact that the intended attachment
will travel without such protection.
<br>
</blockquote>
That is true and we might give a special warning in that case. <br>
Do you see another way of handling this case ?<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
Because of these risks, I would like to propose to combine Cloud
uploading with some sort of automatic encryption.
<br>
</blockquote>
With the positive mind of mine, I will not call this 'risks', but
rather 'issues'<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
Here is a proposal how it might work. On sending:
<br>
- TB automatically creates a random symmetric key
<br>
- TB encrypts the file using the key
<br>
- TB uploads encrypted file
<br>
- TB sends email that contains both an URL and the key required
for decryption
<br>
</blockquote>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">This
would retain the current point-to-point semantic of email, and the
current level of security.
<br>
- If an email is sent in plaintext, then the protection will be
identical to today - all receipients can find and access the file,
and a MITM can, too
<br>
- If an email is sent using S/MIME or Enigmail encryption, then
the password protecting the cloud file is protected in the same
way
<br>
<br>
The remaining question is about the receiving side.
<br>
<br>
If the recipient uses TB, too, then TB can offer to automatically
download from the cloud and decrypt it.
<br>
</blockquote>
That's a mechanism that might work very well fort TB to TB exchange:
TB can provide the tight integration to preserve the user
experience and hide the complexity. I, however, would consider it
for v2, or better yet, to leverage community effort, an add-on for
BigFiles, or an extension to encryption add-ons such as Enigmail.<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
In addition, for users not using encryption, the same could be
achieved using a Firefox Add-On for decryption.
<br>
</blockquote>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">For
example, the availability of Add-Ons like
<a class="moz-txt-link-freetext" href="https://addons.mozilla.org/en-US/firefox/addon/fire-encrypter/">https://addons.mozilla.org/en-US/firefox/addon/fire-encrypter/</a>
<br>
demonstrates that having an Add-On to decrypt a file should be
doable.
<br>
Receipients, not using TB, could be offered to download the file
using their preferred way, and use Mozilla+Add-On for decrypting.
<br>
</blockquote>
We ought to provide a universal experience there... Limiting
decryption to Mozilla applications seems a little too restrictive to
me.<br>
<blockquote cite="mid:4ECEA97D.7050703@kuix.de" type="cite">
<br>
Best Regards,
<br>
Kai
<br>
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
</blockquote>
</body>
</html>