sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Withdrawal of Service - keys.flanga.io


From: Neil Alexander
Subject: Re: [Sks-devel] Withdrawal of Service - keys.flanga.io
Date: Fri, 16 Nov 2018 19:35:36 +0000

> sadly we've had this situation happening several times in the past as
> well, the GDPR rules aren't actually novel in Europe. There is however a
> lot of FUD involved in it, and the actual legal action for a keyserver
> to be shut down has yet to be seen (in a non-voluntary basis). I'm happy
> to stay up for a while until we see any actual legal challenge to it.
>
> In any case, the discussions we've seen lately aren't really about
> security; nor really about privacy; they are about argumentum ad hominem
> against the operators of the traditional keyserver network, in favor of
> alternative communication channels and in particular certificate
> authorities in the form of "validating keyservers". I don't care much
> for them for various reasons, but I also don't mind them being a part of
> the ecosystem (as long as users understand their position).

If you don't mind my contributing an outsider opinion here, you do have a number
of technical problems, but they are all completely overshadowed by a larger
perception problem. That's that nobody really seems to know what the goals of
the keyserver network are, and no one seems to know what to expect when they use
them.

For example, the following things aren't clear to a new user:

- whether their keys and identifiable data will be stored forever
- to where their keys and identifiable data will be replicated
- whether revoking their keys will actually remove the original keys or their
  identifiable data (like email addresses) in any way
- whether updating the UIDs or metadata associated with their keys will actually
  remove the old identifiable data

Nor is it particularly obvious to someone who walks into the community whether
your goals include:

- being censorship or government-resistant
- being highly available
- verifying and guaranteeing data integrity
- respecting user wishes for data removal

... or even none of the above. Certainly I feel like I am asking those very
questions, both as a user and as someone who has stumbled across the mailing
list.

With that in mind, I am not wholly surprised to find that people react badly
when they find out they can't withdraw their data and they don't know where it
has been replicated to and there's nothing they can do about it. Equally I also
wouldn't be terribly surprised to find that there aren't many people stepping up
to develop SKS further when they don't know what they should be creating.

I am not even sure where to go to find out this information!

Furthermore, GDPR might not be "new" in essence but it has cast rather a lot of
light onto the issues of data custodianship and retention. If your goal is to
provide a public service then some consideration needs to be given to this, even
if the solution is just to somehow make it very clear to users what to expect
when submitting or requesting data from the keyservers.

As for the PoCs, well, those are more likely to create problems not particularly
for users but for server operators. Stability issues aside, if an SKS server is
accepting payloads with arbitrary and otherwise unverified data, replicating it
and then storing it indefinitely in an immutable fashion, then it suddenly
becomes very unsafe for someone to take the risk of running an SKS node. 

I understand that there is some reluctance to fix what seems mostly to be a
hypothetical legal scenario, but what has to be uploaded to the keyservers
before someone steps up, takes note and fixes the problem? More copyright
material? Revenge info like someone's phone # and home address? Child
pornography?

Looking at the mailing list, there have been a substantial number of operators
not willing to take that risk.

If the SKS network is going to be lasting and useful then I am not convinced the
community can afford to ignore these problems any longer.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]