Uploading files to the cloud and Security

Jb Piacentino jb at mozilla.com
Fri Nov 25 17:44:04 UTC 2011

Hi Kai,

Thanks for your thoughts.. Some comments below.

On 24/11/2011 21:30, Kai Engert wrote:
> During MozCamp Berlin I listened to JB's presentation about TB.
> 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.
> I like that idea in general, but I would like to comment from a 
> security/privacy point of view, and give some additional inspiration.
> 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.
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.
'Publishing' is probably not the right term, imho.
> 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.
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).
Another way of reinforcing security is to ensure that server stored 
files can not be traversed. Not super easy though...
> 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.
That is true and we might give a special warning in that case.
Do you see another way of handling this case ?
> Because of these risks, I would like to propose to combine Cloud 
> uploading with some sort of automatic encryption.
With the positive mind of mine, I will not call this 'risks', but rather 
> Here is a proposal how it might work. On sending:
> - TB automatically creates a random symmetric key
> - TB encrypts the file using the key
> - TB uploads encrypted file
> - TB sends email that contains both an URL and the key required for 
> decryption
> This would retain the current point-to-point semantic of email, and 
> the current level of security.
> - 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
> - If an email is sent using S/MIME or Enigmail encryption, then the 
> password protecting the cloud file is protected in the same way
> The remaining question is about the receiving side.
> If the recipient uses TB, too, then TB can offer to automatically 
> download from the cloud and decrypt it.
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.
> In addition, for users not using encryption, the same could be 
> achieved using a Firefox Add-On for decryption.
> For example, the availability of Add-Ons like 
> https://addons.mozilla.org/en-US/firefox/addon/fire-encrypter/
> demonstrates that having an Add-On to decrypt a file should be doable.
> Receipients, not using TB, could be offered to download the file using 
> their preferred way, and use Mozilla+Add-On for decrypting.
We ought to provide a universal experience there... Limiting decryption 
to Mozilla applications seems a little too restrictive to me.
> Best Regards,
> Kai
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20111125/385a7ff4/attachment.html>

More information about the tb-planning mailing list