[arch-dev-public] Fwd: AUR ToS (aka making AUR user names public)

Lukas Fleischer lfleischer at archlinux.org
Tue Mar 7 07:35:17 UTC 2017


Hello,

the following email is from the former Arch developer Phil Thiselton. He
can no longer post to arch-dev-public, so I am forwarding this on his
behalf. He revisits the arguments from my original email on why I think
that user names cannot be called "private data".

Forwarded message from Phil Thiselton (2017-03-06 12:06:22):
> Hi Lukas
> 
> You don't know me but I used be an Arch Linux dev. I read you email to the
> arch-dev-public mailing list with real interest and just wanted to add some
> commentary. I, obviously, can't reply to the list.
> 
> IANAL but I do have a lot of data protection and information governance
> experience.
> 
> Firstly, in the UK, your username for a service is not protected by any
> laws. It's not considered to be personal information. I seriously doubt any
> country considers it to be.
> 
> Secondly, I don't think there is any reason not to disclose information
> that is already publicly available. You could advise AUR users that "you"
> intend to share this information. Users cannot effectively opt out of this
> because their username is already public. A realistic opt-out would be to
> delete their account. You can offer them that option.
> 
> Thirdly, a lack of a ToS or EULA, in this case, is pretty remiss. A ToS or
> EULA should definitely be implemented.  I would build this into the
> backend, so agreement to the ToS is stored in the dbase. This way you can
> ask existing users to log into the account and accept the new terms. You
> can say that acceptance is a requirement of continued use. Set a deadline
> and delete the accounts that don't accept.
> 
> I strongly suspect "you" are storing out dated information for many users
> in the AUR and many of these should be deleted anyway.
> 
> Finally, I would start with a ToS/EULA simply as a statement of what
> signing up CURRENTLY means. Completely avoid extending the scope of ToS
> beyond what should be obvious to current users.
> 
> Do not seek permission to share information with 3rd parties but do make it
> clear that limited information is already accessible to third parties.
> 
> Once this is established you can then make later amendments. For example,
> that you will provide publicly available data on request.
> 
> Personally, if anyone even talks about "privacy" with regard to their
> username, I would laugh. They should have no expectation that their
> username is private. Users number one concern would be about their real
> name being linked to their username. I can't see there is a legitimate
> service reason for adding your real name to the AUR account details, so I'd
> consider deleting that from the interface entirely. I'd consider checking
> the dbase to see who has actually completed that field as well.
> 
> I'd have a slight security concern about links between the username and
> email address but that's up to the users.
> 
> Hope that helps.
> 
> Best,
> 
> Phil

When I asked him whether I should forward the email to the mailing list,
I got the following reply with some more details:

Forwarded message from Phil Thiselton (2017-03-06 17:01:35):
> Hi Lukas
> 
> Happy for you to forward it on but I would like to expand on the privacy of
> usernames comment and why the idea is laughable.
> 
> In the AUR, your username is also your display name, as it is for many
> other services (Twitter,Github). Usernames are one way in which real names
> can be obfuscated i.e they act as pseudonym. Unless the argument is one of
> security (username is part of authentication) the idea that your username
> should be private would require a further abstraction of "identity", which,
> at some point, becomes absurd.
> 
> The security argument is weak too - I assume the AUR protects password
> brute forcing?
> 
> The real solution, if someone were concerned about "privacy", would be
> never to reuse the same username for more than one service. Again, that's
> in user hands.
> 
> Best,
> 
> Phil

Best regards,
Lukas


More information about the arch-dev-public mailing list