Consider GDPR implications of creating guest users with email addresses

[rmunn]

At the moment there is one way to create guest user accounts with an email address, through the bulk-add tool on project pages. Once #736 is merged, admins will also have a "Create User" button that can create an account. Are there GDPR implications to creating an account using someone's PII without their prior-given consent?

One possible solution would be to add some text on the verification email to say something like "If you do not want to use Language Depot, click here (link) to delete your account". And/or change the text of the verification email to include GDPR-compliant language saying "Click here to confirm your email address and consent to using your email address as your Send/Receive login". Wording to be figured out later, of course.

[hahn-kev]

The way we handle invites when inviting a single user to a project is that we don't record anything in the DB and we send an email to invite them, this contains authorization to also add them to the project which happens when they complete registration. I'd like to do the same thing for both bulk add and admin invite, that way we don't record anything without permission of the person with the email address.

It's unfortunate that this means that we'll be taking away a feature from the create user from admin page because the user won't exist until they accept the invite.

[myieye]

I talked to GPT4 about this:

• If we want to be GDPR compliant then we can't store any PII without consent. That includes: first names, last names, usernames and email addresses. So, I don't think we gain anything by handling the email-address case differently than the login/username case.
• We need to get consent if we want admins to be able to create users at all
• A confirmation email to gain consent from the actual user would be best

Considering:

• A checkbox for the admin to click is mostly/almost sufficient
• We can't always get consent from the actual user, becuse we don't always have contact info for them
• We don't really expect accounts to be created for people covered by the GDPR, because Europeans are generally tech-savvy enough

I think we should just add a "I have consent" checkbox. E.g.
I confirm that I have obtained consent from the user to store and process their personal data as per our <a href="/privacy-policy">Privacy Policy</a>.

[hahn-kev]

So it sounds like the Bulk add is just fine, assuming the usernames are anonymous, as there's no proper name, or email. And for our invite we don't record anything and the invite is sent to the user.

[myieye]

The default pattern our admins are accustomed to for usernames is firstName_lastName.
I don't think we can assume they're anonymous.

[megahirt]

This seems like a grey area to me. A username doesn't store structured firstname/lastname data, so even if there is a convention by some admins for firstname_lastname, that doesn't mean we are processing PII as such. Does it? Having a checkbox "I have obtained consent' seems easiest and legit, but I don't know if it's necessary. But I'm American and not thinking about GDPR legal stuff regularly. Chris

…

On Fri, May 24, 2024 at 10:21 PM Tim Haasdyk ***@***.***> wrote: The default pattern our admins are accustomed to for usernames is firstName_lastName. I don't think we can assume they're anonymous. — Reply to this email directly, view it on GitHub <#815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2I6KMJHKASMUCMO2LE2IDZD5LGTAVCNFSM6AAAAABICZOG5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRZHAYDGMZUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rmunn]

The Wikipedia GDPR article quoted https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-information-a-guide/, so I went there and found the following:

Personal data is information that relates to an identified or identifiable individual.
[...]
If it is possible to identify an individual directly from the information you are processing, then that information may be personal data.

So usernames of the first_last type would definitely count, but usernames likes workshop0001 would not.

I think a checkbox with wording like "If this/these username(s) include someone's name, I have their consent to create an account for them" (though the wording would need to be worked out so as to be clear and not too complicated) would be good.

[megahirt]

That could very well be true, however I still have questions about what is required under GDPR. For example, if I have a field called "user ID #" and I ask the person to create their user ID number using any number their want (as long as it's unique in our system), I would assume that this is not PII because the intention is that it's an ID number but not PII. If they chose to put in PII into the ID number field because that's what they choose e.g. phone number or SSN or any other PII number, that's on them, not on us right? I feel like user name (what if we change the label to "user ID"?) is similar - the intention of the field is that it's NOT PII, otherwise we would have "first name" and "last name" fields and we would store that and assign them a username based on those fields. I think as a process we could just encourage admins to not put PII into the username field. It's unclear to me if we as the service provider are on the hook for users who choose to input PII into fields that are not intended to be PII. Chris

…

On Mon, May 27, 2024 at 12:50 PM, Robin Munn ***@***.***> wrote: The Wikipedia GDPR article quoted https://ico.org.uk/for-organisations/ uk-gdpr-guidance-and-resources/personal-information-what-is-it/ what-is-personal-information-a-guide/, so I went there and found the following: Personal data is information that relates to an identified or identifiable individual. [...] If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. So usernames of the first_last type would definitely count, but usernames likes workshop0001 would not. I think a checkbox with wording like "If this/these username(s) include someone's name, I have their consent to create an account for them" (though the wording would need to be worked out so as to be clear and not too complicated) would be good. — Reply to this email directly, view it on GitHub <#815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2I6KI7HTKC434OQDFYNQ3ZELCS5AVCNFSM6AAAAABICZOG5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGY4TAMBUG4> . You are receiving this because you commented.Message ID: ***@***.***>

[myieye]

It feels like we're all a bit out of our depth on this one 😆.

But, I think our options are essentially:

Option 1

• We add a checkbox to each create user form forcing the admin to confirm that they have consent to give us the user's PII and we store that with the user

OR

Option 2

• We implement 2 different workflows for every user that gets created (individually or with the batch tool) based on whether an email or username was provided (@rmunn as a PR for this)
• We make it clear in the UI that the behaviour is different based on the type of value they provide
• We tell admins not to enter PII for usernames (which I expect they'll find awkward, because it means they have to be creative every time they make a user)
• We hope that admins listen and don't enter PII

Option 1 just seems like the clear winner to me:

• We don't lose a feature
• It keeps our code simpler
• It keeps our UI simpler
• We get consent

It's one weakenss IMO is that the consent is not bulletproof; it's second hand.
But option 2 is by no means bulletproof. We cannot guaruntee that we're not collecting PII.
And GPT4 is very convinced that it doesn't matter if we explicitly require PII or not, it's our responsibility to handle it properly and have consent if we happen to store it:

Conclusion

Even if you did not explicitly require PII, you are still responsible for ensuring that the data you collect and store does not inadvertently include it. Implementing validation mechanisms, providing clear guidelines, and regular audits are essential steps to mitigate this risk and ensure GDPR compliance.

[hahn-kev]

Alright I talked about this with Tim today. I like option 1 from a PO standpoint and I'd like that to be what we shoot for. We will track the user who reported that they obtained consent as that seems important (right now the CreatedBy column).

@megahirt can you find out if there's any official advice on the SIL side? Consider this my due diligence for finding out if a consent checkbox for our admins is enough, or if there's someone I can reach out to then let me know, thanks!

[megahirt]

@megahirt can you find out if there's any official advice on the SIL side?

I've written T.R. about it - will let you know when he follows up or points me to someone in SIL that can answer our GDPR questions.

I'm good with option 1 as well - GPT4 has persuaded me that we are responsible for handling PII properly with consent even if we didn't know it was or didn't intend it to be.