Opened 4 years ago

Closed 16 months ago

#1454 closed defect (no response)

Susimail cache is a little TOO persistent...

Reported by: somewon Owned by:
Priority: minor Milestone: 0.9.19
Component: apps/susimail Version: 0.9.17
Keywords: cache, susimail, privacy, security Cc:
Parent Tickets:


Regarding #1255 ("Susimail: Add persistent cache"), it seems that the cache that was implemented is in fact permanent, or very close to it. Today I discovered that all emails sent and received with Susimail since the cache was implemented are still stored on disk, in various .tar.gz files found in /homedir/.i2p/susimail/cache/cache-[hash]=/cur/s_ . Of course, GPG protects the message contents where it is used, but the metadata (including nyms) are all clear.

While I know that this issue is perhaps a bit outside the scope of the I2P project ("users can use whatever mail client they would like/we're not responsible for keeping the data on users' disks secure"), I think that this would be a wise thing to change, or at least to offer a warning/option in Susimail about. This is indeed the sort of thing that the developers of many anonymity applications are very mindful of, to what extent they're able, and they have my deep gratitude for that.

The cache itself is of course useful, hence #1255, but I think that perhaps these files should be purged on a router shutdown, perhaps, or when the last Susimail tunnel is closed - probably the latter. Or maybe just every 12-24 hours. In any case, I don't believe that they're useful or wise to keep around for months or years after those email messages were viewed.

As always, my utmost respect to the I2P devs, and I hope to see more good news for I2P in the future!


Change History (6)

comment:1 Changed 4 years ago by zzz

  • Status changed from new to infoneeded_new

You saying you deleted them in the GUI and they weren't deleted on disk, i.e. there's a bug?

Or that you want a setting to automatically delete them after a while? People's expectation for an email client is that it keeps mail forever unless you tell it otherwise. I suppose we could implement it as an option, but certainly not by default.

comment:2 Changed 4 years ago by somewon

  • Status changed from infoneeded_new to new

Good points. No bug - I did not delete the messages in the interface. Thank you in advance for hearing me out and tolerating my own misconceptions.

I guess I had a different expectation of Susimai, that it's basically like a "webmail"-type portal, and I think that many people may also have this impression while using it. My expectation with such a service is that messages are not permanently stored on disk, perhaps just because of the fact that I don't expect _anything_ I do in a web browser to do such a thing without informing me (I think this is a common expectation), and because I made the assumption about it basically being "webmail".

Considering Susimail as more of an actual mail client/MUA that just happens to use a web interface makes all of this much more understandable, but I do worry that people may not be expecting the messages to be retained indefinitely on disk by default. This is doubly true with the fact that most computer users these days don't even know what a MUA even _is_. I think that this may be a good UX hurdle to smooth over for expanding I2P's user base from "die-hard techies" to the general public - and heck, even I, with a pretty high level of tech knowledge, was still thrown by this feature.

Also interesting is that I deleted the local susimail/cache/ directory to "remedy" this problem, and now I discover that of course, in classic POP3 fashion, my messages were not retained on the server (and indeed, had never been I suppose). This was also unexpected (though I have since found the Setting to configure this). Of course this is all based on my own (flawed) assumption that Susimail is analogous to "webmail", but again, I think this is probably a common (mis)conception, especially among less technical users.

Some potential ideas that I see to bring Susimail more in line with my (and I think _many_ users') expectations:

  1. Offer a clear message to users on the Susimail Login page that "messages are set to be retrieved from the server and then {deleted from the server, kept on the server} and {saved locally on disk, discarded locally after n minutes, discarded locally after n minutes without being saved on the server - warning, messages may become permanently lost, discarded locally on closing the POP3 tunnel, discarded locally on closing the POP3 tunnel without being saved locally on disk - warning, messages may become permanently lost} - click Settings, below, to configure" (see next point).
  1. Offer an additional option like delete.local.message.cache.after.minutes (with 1440 (24 hours) or 10080 (7 days) as default), or as in my original report, delete.local.message.cache.on.tunnel.close={true, false}.
  1. MAYBE make pop3.leave.on.server=true the default in Susimail (of course this should be discussed with Postman, and may require some code on Postman's end and perhaps in Susimail, to configure mailbox size quotas and warn about low quota space on the server, etc. if it doesn't exist)
  1. More difficult possible solutions that I wouldn't actually request might be real IMAP/IMAP+ support (ugh), an option to encrypt the cache on disk, etc.

Honestly, I think even with no changes beyond just giving a description of the current settings on the Login page as in (1), we could probably help to avoid the kind of confusion that I've succumbed to, here. My own personal request would be to implement both (1) and (2), as I think that gives the best "bang for our buck" in terms of improving user expectations _and_ improving security with a minimum of effort.

Caveats: Of course, it's only for some specific security models that a user might feel uneasy about mail being stored on their own disk, but have minimal issues with it being stored on mail.i2p, but I think among our user base it's not a terribly rare one. Security against things like border-crossing computer inspections, unexpected raids, etc. are definitely a part of the cypherpunk tradition, and for good reason in my opinion.

My sincere apologies for the very long comment, I already feel bad enough about taking up my beloved I2P developers' time as it is. Thanks again for all the wonderful work you do, and know that I've got your back in whatever ways I can offer!

comment:3 Changed 4 years ago by user

I haven't used Susimail in a while, but from when I used it it was my expectation that it only is a webmail frontend and NOTHING gets stored locally.

comment:4 Changed 4 years ago by zzz

re: comment 3, that was the way it used to work, big change was in 0.9.13.

re: comment 2, I don't know what the general expectation is, or whether people see it as 'webmail' (whatever that means) or an 'email client' (whatever that means). Or what the usual default for a POP client is. I suspect you're leaping too far from your mental model to a theory of what 'most people' think.

It's true that 0.9.13 did transition from simple webmail to more of a client. But that was almost a year ago and the only complaints were from (non-persistent) Tails people.

Without some consensus or at least support I'm not eager to mess with it.

Also, leave-on-server by default is unsustainable by postman long-term, without him moving to delete-by-default...

comment:5 Changed 3 years ago by zzz

  • Status changed from new to infoneeded_new

No response in one year. Setting to info-needed to get comments from OP or others.

comment:6 Changed 16 months ago by zzz

  • Resolution set to no response
  • Status changed from infoneeded_new to closed
Note: See TracTickets for help on using tickets.