Discussion about using a Fallback server for the EasyGpg2016/PubkeyDistributionConcept or not.

Status: work in progress

In the originaly EasyGPG contract it is proposed to have a fallback server as second step in the asking for a pubcert, if the first one fails to get an answer from the mail-service-provider (MSP).

2. If the MSP does not support the request: Ask a central fallback server for all email addresses.

Original comments from EasyGpg2016/PubkeyDistributionConcept to that point: [ I do not like that approach because it shifts the responsibility from the mail address provider to some 3rd party. This raises all kind of problems and requires a central system for all users for all non-supportive mail providers. There are also legal problems with that, in particular in Germany -- Werner Koch 2016-05-04 16:12:19 ] [ I would like to move this to the discussion section and respond there. -- bernhard 2016-05-06 15:25:43 ] [ A wiki is not a useful service for developing ideas because you can't commment on topics. It is okay to use the for documents where there is a consensus - so, yes, please take this all to gnupg-devel -- Werner Koch 2016-05-09 13:41:26 ]

Central fallback server

What if some mail service providers are slow on the uptake of this concept?

Would our archetype users consider switching to another email provider? Bob probably would, but the others?

The idea of a fallback server is to enable users to participate in the concept without direct support of their mail service provider. This is a main advantage to provide first value quickly to many email users.

But it comes at a number of potential drawbacks:

1. A central service requires extra interaction for building the connection between email owner and corresponding cert. It basically becomes some sort of 'validating keyserver' with all of its security problems.
2. The more percentage of certs it holds, the more valuable it becomes making it more and more a target for attacks, a single point of failure and harder to operate.
3. It may diminish the motivation of MSP to implement the part of the service on their side, because it is already working.

Thus it is an open decision how to deal with a fallback server.

One path of action proposed by -- bernhard 2016-05-04 12:59:37 is to:

• operate the fallback server to bring value faster to people and show that the user experience side works on a wider scale.
• Publish statistics about the number of email addresses from certain mail user providers on the corresponding website.
• Approach mail service providers repeatedly if their email usage is growing over certain numbers.
• Put public limits in for the service in numbers and time. E.g. 2016-11-16: now that 100k user from example.com use the fallback server, we will provide access to them for another three month and after one month warning them of the discontinuing of the service. [ You missed the :-) ]

• Publicly announce mail service providers that are now offering the service on the same website.
• Help mail service providers to make it really easy to implement their part, e.g. by providing software components and migration support from the fallback server.
• (For being able to inform fallback server users of a change of service, there must be provisions when signing the users up that it is okay to do so later.)