Investigate: Stop using email as a key in our api

[davefrey]

Yesterday I crossed something on twitter that I can't yet find again, but the context was participatory platforms and the assertion was that assuming "one email = one person" is problematic, it's a barrier to having family members participate.

I can't remember more; for the moment I'm putting an issue as a tickler so the question is validated and addressed, or determined to be not an issue.

Email is also GDPR-sensitive data, and it's also an attribute that changes. We are already wired to allow IDs or emails...perhaps we can consider backing off using emails as identifiers in our service?

[oliverbarnes]

Converted into a discussion, until we have a clear issues or tasks.

So, to put things into context: emails were chosen as external identifiers when the scenario of using the api independently of a platform was a thing. Such as when using a browser extension that would let a blog post become votable, for instance. In this case, there's no session to get another identifier from, so a person could self identify through their email, and we could even authenticate them by sending an email confirmation. Emails worked like external urls, in that sense.

Now, even when integrating with platforms emails are still useful as shared external identifiers, letting us avoid using the platform's internal user id, and the api its own. If we weren't to use emails, we'd have to establish another shared identifier, while also avoiding coupling between the api and the platform.

Using an external decoupled shared identifier also lets us not have to store any other info about the user, letting the platform handle that, and minimizing how much personal data is duplicated across the two layers.

It also allows our API to identify a user cross-organization, cross-platform, with the potential of providing them (and our system) with intelligence about their voting patterns, were we to extend the API's functionality to provide stats. And if we were to do that, we'd have to get the users' clear consent.

Privacy wise, I don't really see an issue using people's emails for authentication: most login systems rely on emails. The problem arises when that's exposed, and that's what we're addressing with liquidvotingio/decidim-module-liquidvoting#100, though database ids might also be an issue (liquidvotingio/decidim-module-liquidvoting#100 (comment)). Post requests to the API including the email are encrypted with SSL.

Regarding uniqueness, I'd have to see the rest of the problem statement. I can see the scenario where family members share email addresses, but I'd have to see a viable alternative. I have the impression family members might share any kind of login, even ones using biometrics (think siblings doing stuff for their parents on their phone, and getting their face ids by showing them the phone screen), and I don't really see a way around that sort of identity ambiguity. And in the end, the authentication system is really the platform's concern.

Regarding emails being an attribute that changes, I'd argue that it's hard to have an unique id that never changes: db ids can change, for instance. Databases get migrated (though uuid addresses this), users delete and recreate accounts with different logins, etc. Only things that are even harder to change than emails are government ids, and that's some serious personal data there

That all said, we do have a problem if a platform chooses to use another identifier. With anonymous evoting, for instance.

@niklaslong had brought up the idea of having encrypted identifiers right when joined, too. Perhaps when we get to evoting, we can investigate this further, and the implications for stats?