pep financing proposal
phill at hallambaker.com
Fri Dec 4 14:46:55 UTC 2015
At the outset, let me say that I believe that a new Internet crypto
infrastructure is required and p≡p seem to be attempting to do the right
thing. What they are proposing is not entirely new and that is a good
thing. At present there are quite a few different projects aimed at the
same general goal. If different people are finding the same solutions it
does provide a level of validation of the approach.
However it is still a hard problem. Secure email is the hardest security
problem to solve because it is not only asynchronous, the sending and
receiving clients never rendezvous with each other or even with a server
that the other is connecting to. It is at minimum a four corner model and
the protocols you have to deal with are 30 years old and were written by
people who didn't know what they were doing because nobody did.
On Fri, Dec 4, 2015 at 3:45 AM, R. Kent James <rkent at caspia.com> wrote:
> Let me start by saying that I am overall quite enthusiastic about the
> technology developments from p≡p. All we have seen is a demo, but as far as
> we understand it, p≡p does some really great stuff to make PGP encryption
> occur with minimal user interaction.
That is a good goal. In fact that is exactly what I am working on at the
moment. The only difference being that I am working to enable PGP and
S/MIME rather than make it either/or. Forcing people to choose between
crypto formats is like forcing people to choose JPEG or PNG.
> The email client automatically generates a PGP key, that key is advertised
> automatically to people who receive messages from you, and then those other
> clients start to automatically send encrypted emails to you. Multiple
> clients have methods of syncing the automatically generated keys. If enough
> people are using p≡p, then pretty soon the whole world is sending emails
> encrypted. p≡p is right to push fairly hard for their technology to be
> enabled by default, as that allows it to spread virally.
I have proposed such things in IETF. It is a good idea (I think).
But it has to be standards based if it is going to get anywhere. This is
crypto code. It should be reviewed by the crypto community. Yes it is built
on OpenPGP but it is offering features that OpenPGP does not provide. So it
is going beyond the OpenPGP spec. We should know how and that needs to be
widely reviewed specifications, not "self documenting" code.
> Second, there are serious side effects of having this enabled. From what
> we understand already, (which is precious little, and that is part of the
> problem) at the very least this will cause surprises to many unsuspecting
> users who use multiple devices to read email.
That is a big drawback and the reason I pulled back from PrismProof email
18 months ago and started working on that specific problem. Right now the
only way that you can use any form of automated crypto is by setting up a
separate account for the encrypted-by-default mail and having some sort of
channel in the automation layer to differentiate encrypted by default from
encrypted on occasion.
So I now have two email accounts hallam at gmail.com and hallam.mesh at gmail.com.
If you want to send me a prismproof email, you send it on
hallam.mesh at gmail.com. But I will only be able to read it when I have
access to a Windows boxen because right now I only have integration for
Windows Live Mail.
> You need to have this technology installed on all of your devices, else
> the encrypted emails that people start sending you will be unreadable on,
> say, your Android email client. Now p≡p understands this, they are bright
> people after all, and have done an amazing job of making sure there is at
> least one client available with their technology enabled on all platforms,
> and even within subcultures (with Thunderbird being the open-source
It is more than that. How do I get my keys on all the devices?
Right now it takes 30 minutes to configure Thunderbird to do S/MIME and
that is when you know what you are doing. Now that is gratuitous, there is
no reason configuration should take any interaction if you only have one
device. But managing multiple devices is a problem.
Third, some users will be unhappy with this, and if this deal is presented
> as a quid pro quo transaction, we will have to deal with negative fallout
> from pushing a technology on them against their wishes in exchange for
> money. Originally I thought that we would be able to deal with p≡p from a
> position of each mutually wanting the same things and agreeing to work
> together. If we want better encryption (which p≡p offers us), and they want
> a viable desktop email client (which we can offer them), we are just
> working on the same goals. I would be much more comfortable if we
> negotiated these issues separately.
I had a discussion with Richard Barnes of Mozilla where I suggested that
what Thunderbird really needs is a business model and crypto products might
be the way to do that.
So for example, at Comodo we give away the anti-virus for free. This is
because the user doesn't actually care about their machine being virus free
or not. What the user wants is for their machine to 'work'. So we give the
anti-virus away for free and then make some money by upselling some of the
base to a GeekBuddy subscription where they get an online helper fixing
their problems. Or as quite often happens, someone else's problems, it is a
good gift for the technically challenged relatives who constantly ask for
If a billion people star using end to end encrypted mail, there is going to
be a large market for all sorts of crypto related services. We have been
giving the S/MIME certs away for years now and plan to continue but at the
moment we are below critical mass and there is no market for premium
If we get to the point where premium services are viable then Thunderbird
naturally becomes a valuable channel and the various providers of premium
services are going to be willing to cut an affiliate fee.
I think that is what Thunderbird needs in the long term. A one off payment
is not going to resolve the underlying structural issue.
Let me reject one counter argument, at least personally. I've been
> contacted privately by one key contributor, who wondered if the events in
> Paris should make us question our commitment to encryption. We had a long
> discussion here about end-to-end encryption a couple of months ago, and I
> ended with a consensus statement:
This has been debated to death. As folk in the community know, I don't
favor gun control, I support a complete prohibition. It works in the UK.
However I would not use Paris to make the argument for any level of gun
control for the obvious reason that ISIS is an adversary which approaches
nation-state capabilities even if it isn't recognized as a state. We don't
yet know where the guns came from but the attackers would obviously have
brought them in from Syria if they couldn't get them easily in Europe.
Suggesting that a group that can get hold of light arms in quantity can't
get hold of strong crypto is ridiculous. The reason most people don't use
crypto is that it is too much hassle. People who are willing to strap
suicide belts to themselves are going to be willing to put up with hassle.
What we have been seeing here is a pre-planned campaign that the intercept
proponents were waiting for an atrocity to roll out. And their objective
seems to have been to deflect criticism of the intelligence services for
failing to detect the attack as much as furthering any anti-crypto agenda.
But on to the issue of offers of support. In the long run, Thunderbird is
> going to live or die by whether we can develop ways to be supported by our
> users. One of the most exciting developments in Toronto last month was that
> Mark Surman offered the expertise of their donor team to work with us early
> next year to develop a donation campaign for Thunderbird. Whether that
> generates $10,000 or $500,000 will go a long way toward answering whether
> Thunderbird can be viable long-term or not.
There are two types of funding campaign, you can go for big donors or
little but they are different things. Both prefer to spend money on big
projects rather than running costs though.
Collecting money for Thunderbird is going to be hard. Collecting money to
put next generation crypto into Thunderbird is much easier. Look at the
foundations that have supported TOR.
> I do not believe long-term that we can rely on any outside organization,
> be it Mozilla or p≡p, to be our primary method of support. If we provide
> value to our users, they need to finance us. When people ask where we need
> help, user relations is always a key area, as that has to be our future.
Having PEP fund Thunderbird looks to me like having one donor funded
organization fund another. Yes, charities do that all the time, who
collects the money for a project and who is best placed to deliver are
often very different things.
Concerning p≡p, there has been some confusion on our side on exactly what
> they are offering. It appears now that the concrete offer is to hire some
> people themselves who will help with Thunderbird for a period of six
> months, with a declared value of $100,000. They have already started doing
> that, and one person has already started contributing patches. They have
> also offered to work with several European NGOs they are close to that
> could help us with some other needs. All of this help is greatly
> appreciated. There are also informal statements that this support or even
> more would continue for the indefinite future. All of which is great.
> The rub seems to be that this offer is contingent on us accepting their
> technology, enabled by default, ASAP in Thunderbird. And they believe that
> we verbally agreed to this in Toronto, so that any attempt to deviate from
> that is viewed as rejection of their assistance.
As far as I can tell the PEP folk are also new to this game. I suggest you
both go talk to the World Wide Web Consortium staff, it should set
expectations appropriately. Many members of W3C staff have been seconded
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning