Re: Configurable setting to avoid storing email on disk in thunderbird

[Dan Mosedale]

[Cross-posted to mozilla.dev.apps.thunderbird; followups redirected there]

Nathanael Hoyle wrote:
>
> Greetings all,
>
> I want to make sure that there is not some capability which I am
> currently missing to tell Thunderbird not to cache/store emails or spool
> information on the local disk (this obviously makes most sense with IMAP
> servers and other servers that store the email server-side).
>
> Ideally, solid disk/filesystem encryption makes this mostly a non-issue,
> but this is not always possible. I would like to be able to access email
> without leaving copies of email subjects or bodies cached anywhere on
> the local disk. Failing that, I would like to be able to securely
> encrypt them at the application-layer. The emails are being retrieved
> across an IMAPS encrypted IMAP session, so transport 'should' be secure,
> and the paging/swapfile is turned completely off on the system to avoid
> the possibility of sensitive information being cached from memory on disk.
>
> First off, is there currently a way to do this that I'm missing?

So far as I'm aware, there is currently no way to do this.

> Assuming that there is not, does anyone have an idea roughly what the
> level of effort involved in creating this capability is? Is this do-able
> with a plugin, or would it require changes to the base source tree?
>
> I am prepared to dive into coding the changes myself if need be, but
> dislike re-inventing working wheels where they already exist.

I suspect this is going to be at least a moderate amount of work, if not
more and would probably require changes to the base source tree. It's
conceivable that you could get a some part of the way there by
overriding the various XPCOM messsage-db components, though. I'm hoping
David Bienvenu will see this in m.d.a.thunderbird and chime in as well,
as I'm sure he has a better feel for the scope than I do.

Dan

[Mark Banner]

Dan Mosedale wrote:
> [Cross-posted to mozilla.dev.apps.thunderbird; followups redirected there]
>
> Nathanael Hoyle wrote:
>>
>> Greetings all,
>>
>> I want to make sure that there is not some capability which I am
>> currently missing to tell Thunderbird not to cache/store emails or spool
>> information on the local disk (this obviously makes most sense with IMAP
>> servers and other servers that store the email server-side).
>>
>> Ideally, solid disk/filesystem encryption makes this mostly a non-issue,
>> but this is not always possible. I would like to be able to access email
>> without leaving copies of email subjects or bodies cached anywhere on
>> the local disk. Failing that, I would like to be able to securely
>> encrypt them at the application-layer. The emails are being retrieved
>> across an IMAPS encrypted IMAP session, so transport 'should' be secure,
>> and the paging/swapfile is turned completely off on the system to avoid
>> the possibility of sensitive information being cached from memory on
>> disk.
>>
>> First off, is there currently a way to do this that I'm missing?
>
> So far as I'm aware, there is currently no way to do this.

The only way that I could think of getting close to this at the moment
would possibly portable Thunderbird.

http://portableapps.com/apps/internet/thunderbird_portable

So you'd put Thunderbird on a USB stick which would also store your
profile. This would mean nothing on the local disk at least.

Standard8

[David Bienvenu]

Dan Mosedale wrote, On 5/15/2008 5:41 PM:
>> I want to make sure that there is not some capability which I am
>> currently missing to tell Thunderbird not to cache/store emails or spool
>> information on the local disk (this obviously makes most sense with IMAP
>> servers and other servers that store the email server-side).
>>

>> First off, is there currently a way to do this that I'm missing?

No, there's nothing like that now. However, for IMAP, by default, we
never store the message bodies on disk (that default will most likely
change in 3.0), and we don't use the necko disk cache for IMAP. But we
do store information like subject, sender, etc, in the .msf file on
disk, and there's no way to turn that off.

In the IMAP case, it would be fairly easy to tweak the msgdb code to
never actually commit the .msf file, and everything would most likely
keep working, because Mork works all in memory. We would end up
downloading the headers from the imap server very frequently, however.
And I don't know if Sqlite can work that way, so if and when we replace
Mork with Sqlite, that trick would be obsolete.

I think the POP3 case is really hard, and would require a lot of changes
to the core code, along with adding the ability to have pluginable mail
stores.

The long term answer is probably pluggable mail stores along with
pluggable message header databases;

I like Standard8's answer of portable Thunderbird :-)

- David

[Ron K.]

Mark Banner keyboarded, On 5/16/2008 3:18 AM :

The USB stick is a good solution with a strong Pro of easy high security
storage. It's weakness is ease of loss due to the small size. There are
USB security softwares that install to the USB root to create an
encrypted partition to install an application into. The "Windows
Secrets" newsletter covered this topic earlier this year. Link to article:

http://windowssecrets.com/2008/04/24/02-Nine-must-have-freeware-apps-rise-to-the-top

--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!

[Nathanael Hoyle]

Dan,

Thanks for rescuing my post from moz.dev.security. I'm a first-time
poster on these groups and would not have realized (at least for some
time) that the more active discussion was over here
(moz.dev.apps.thunderbird), and the post would have continued to linger.

I will reply independently to the other suggestions now in the new thread.

-Nathanael

[Nathanael Hoyle]

Mark,

I considered this approach, and it has merit. The primary downside in
my view is that Portable Thunderbird is only available for Windows
platforms, a much narrower target platform than Thunderbird itself is
available for. The proviso to that statement is that the use of a
properly-configured Wine environment may make this possible, but this is
an extremely 'heavy-weight' dependency and is difficult to justify.

The other, less significant, 'con' is the introduction of the USB flash
drive as a system requirement. In certain, secure, environments, it
becomes an issue to track the movement of portable storage devices (such
as flash drives) into and out of the environment. It would be difficult
to train security personnel to readily identify 'authorized' flash
drives from unauthorized ones, as 'readily available' flash drives are,
unfortunately, readily available (a malicious user could easily purchase
an unauthorized device with the appearance of the issued/authorized one).

In many Windows-only shops however, or for personal use, I believe this
approach is sound, assuming strong encryption on the flash drive filesystem.

Thanks,
Nathanael

[Nathanael Hoyle]

David,

Thanks for the information, and the thoughts. It is good to know that,
at least for the IMAP case, the 'quick fix' (not saving the .msf file
back to disk) would be relatively simple. It sounds like it would also
be a kludge/hack which would not be reasonable to add (even as a
configurable option) to the base source tree, because it would not make
sense in a general context and not be very future-proof.

It is necessary for ongoing security that it be possible to update to
newly released versions which correct defects in security. With this
requirement, it is not feasible to apply 'one-off' custom source code
modifications on all future-released versions (particularly once a
back-end storage format change requires reimplementing a new solution).
This means that whatever changes are effected to achieve the desired
operation need, logically, to either 1) be implementable solely within
the scope of a plugin which can survive minor-revision bug fix upgrades,
or 2) be general, useful, and sound enough from an engineering
standpoint as to be committed back to the main source tree. It sounds
like pluggable mail stores are definitely the 'real' solution here.

I envision a standardized interface (used in the sense of a
Java-language interface, or simply exported API) which a plugin could
implement to create a specific storage capability. Examples would be
plugins to store to sqlite, a full-on Oracle database, an AES-encrypted
file, in memory only, or over the network via an XML-RPC mechanism.

One possible consideration here is whether to separate the API into two
layers. I see a separation between the storage format and the storage
location. It might be possible to layer two levels which could have
independent pluggable replacements. Example: cleartext or various
cipher implementations, or even a natural language translation layer
atop the underlying store, which could be flat file, RDBMS, the above
network XML store, etc. This has obvious advantages. Ideally, the
translation/conversion layer would be stackable, such that one could
layer a english->spanish conversion plugin atop a cipher implementation
before reading/writing to and from a backend database. This is
obviously a fairly aggressive engineering goal, but I do not believe it
is beyond what is possible, and I think it has several possible benefits.

If there is any community interest in pursuing this type of layered
pluggable architecture, I would be interested in contributing to the
design and implementation thereof.

Thoughts?

-Nathanael