Re: xB Mail: Anonymous Email Client

[Arrakis <arrakistor@xxxxxxxxx>]

> thanks for this idea and software. Many replies already in the archive of
> or-talk.

I'll look again. When I searched prior, I recall only seeing something
about stopping spam, written by phobos.

> Some suggestions.
> 
> I would devide the license question
> a) we need an open source GPL email client, which sends only PGP encrypted
> email

Which sends _only_ PGP encrypted email... I'll need to think about that
and talk with "noobs" about how PGP works to see if that is viable. The
main problem with enforcing that is that we have two segments that don't
seem to overlap. We have to write the software to cater to a specific
user schema. Here is the issue:

0. Asymmetric encryption is a difficult concept when first introduced
   to most people. Even PGP corporation can't figure out how to get people
   to understand PGP.

1. Anyone who knows how to send email anonymously already understands how
   asymmetric encryption works. A majority of these people use unix.

2. Anyone who doesn't know how to send email anonymously probably doesn't
   understand how asymmetric encryption works. A majority of these people
   use windows.

3. The former probably doesn't need software help. The latter definitely does.

4. It is my experience that it is nearly impossible to educate the user. They
   want something that just works, and will abandon anything that does not
   intuit and actively give positive feedback.

So we're left with either a spartan client for experts (which is easy), or
the staggering task of designing a client for the uninitiated. I posit that
there may not be enough HCI knowledge on this planet to accomplish the latter
but it would be a very exciting, frustrating, and noble task.

A more reasonable task may be a client that is encryption agnostic, but
focuses on obscuring context through anonymization. This allows for the experts
and novice to use, and is flexible enough to give the uninitiated a taste,
and to create an environment where they feel comfortable learning and trying
public key encryption.

> b) we need an underlaying mix network with outproxies, which is could be
> another license maybe.
> (as the mail is encrypted, then no matter which outproxy is used, if open
> soruce trasnport or not).
> The mixing network is hiding the original IP adress. Tor or mixmaster or i2p
> with recoded outproxies for one port for mail.

Exactly. The discussion of such how to implement requires some forethought.
First about utility, then about applicability. For tor, I don't know how
well it can handle smtp, imap, or pop protocols. Mixmaster seems to handle
smtp relatively fine, except for the delay. I2P is similarly suffering in
latency as a tradeoff for low observability. Will the user stand for that?
I don't know.

> There are 3 similar projects, which should be considered:
> 
> NUNTIUS LEO EMAIL
> http://nlcreator.sf.net
> is developing a Qt Email client, which is sending PGP encrypted emails.
> 
> RetroShare Email Client
> http://retroshare.sf.net
> QT as well and has PGP Key pair encrpyted Messaging, instant and offlline.
> The offline mail is queued until both clients are online for a handshake. So
> currently @-mail is not possible, as it is serverless.
> 
> -> Merge: As retroshare uses XPGP key currently, and a change is soon done
> to PGP keys, it is a good idea to add Nuntius Leo Email client as well to
> RetroShare Gui as integration or as a plugin.

I'll take a look.

> So the basic concept is, to have an adressbook, which pre-defines your
> Friends or Mailadresses.

Are you thinking of LDAP then? That would require a service provider,
which is unlikely to be supported in a non-commercial software.

> In one Email client, which is based on PGP Keys, you need to swap with your
> mail-partner the key.

> That is no lack, as you can send your PGP key as well over one first
> unencrypted email (into one special folder for approval it arrives).
> But I think it is better encryption is you have no end to end encryption but
> swapping keys.

I agree that we solve the context problem by enforcing per-message encryption,
but this again seems to push the user around in an experience they may not
be comfortable with, leading to abandonment.

> Mailinglists then need to be redefined, as you need from each participant
> the key, tha could be done as well over one first approval/joining email,
> which all participants sign.

so we could just use cryptographic termination: the users send using
a key that the mailing list can decrypt and recrypt, the mailing list then
sends out with keys it required when everyone first signed up.

This seems to focus on changing behaviors rather than adapting to them.
A group list who can decrypt seems slightly antithetical to protecting
both identity and content. Maybe not. But what it seems to do is to
create a crucible to temper only the experts into being able to use it,
who didn't need it anyway.

> Third there is SIMPLE-MAIL as a Firefox addon
> https://addons.mozilla.org/en-US/firefox/addon/5593
> Telega is the author and is currently coding a XUL gui for retroshare
> instant messenger, you find it here:
> http://retromessenger.sf.net
> This library is currently not open source, but the auther may think about
> that.
> XUL allows as well a standalone application.

I'll look at this as well.

> The idea, to join as well in XUL a mail client with PGP keys and the
> libretroshare Instant Messenger is already placed.
> 
> You see, 2 Projects, on its way bringing online and offline communication
> together, both based on PGP keys.
> 
> That is why you should be compatible to PGP key exchange. Does FirePGP
> provide this?

FireGPG provides selective encryption of text using GPG/OpenPGP. A better
approach, in my opinion, is the Thunderbird Enigmail extension, which
prompts but does not enforce PGP encryption, and has an integrated key
manager, and keyserver query engine built into it. I think this is an
excellent foundation to work with, if we can understand how to guide users
into such a harness.

> Do you really think, mixmaster has enough nodes? Do you really think that a
> tif-for-tat model is good, so that each one running the PGP-Email-Client
> should be as well at the same time an Outproxy for other mails? No..

That depends, really, if the client is designed for open or darknet
operation. My current interest is for open network operation, so the
client does not participate. If it was for a darknet, I would probably
say the client should participate.

> And: Regarding webmail: I want an email client, With Tor it is already
> possible to surf to webmail accounts.

Possible, but certainly not safe. We would need to browser portion to
enforce end-to-end encryption at all times, and only talk to servers
which were known to use end-to-end without blabbing a cookie in plaintext.

> Do you really want to make a new proxy network only for email-mixture?

I wouldn't mind adapting my current idea to darknet operations, but it
is not my current intent to reinvent the wheel, so we want to use networks
that already exist out there, like one of either tor or mixmaster.

> Thanks for a feedback, how you go on

Max, thank you for your contribution. I'll take your suggestions under
advisement in addition to researching the projects you've mentioned.

Thanks again,
Arrakis