> 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. _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel