Closed Dimitar5555 closed 4 months ago
Do you know http://whosthat.osmz.ru/ ?
~Unfortunately, that site doesn't seem to update anymore. Late update date in Sep 2021 looks like a Let's encrypt issue. @Zverik : do you know more about the current status?~ -> Resolved now!!
This is literally impossible to do because we don't keep any history of usernames.
Obviously we could start recording changes going forward but there is no way we can show previous names before now.
All the old minutely/hourly/daily diffs still have the old user name available, which is how "whosthat" created their stats in the first place. (No, I'm not suggesting to replicate that feature...)
Yes I mean it's not available in the API database, and we're not going to have the web site grovelling around in thirty party services to try and divine it.
It is true that a bad actor can use the name change facility to make their activities more difficult to track. People also do silly things like changing their username to something like "your mother" and then befriending others which results in them getting an email "your mother added you as a friend". If change their name back quickly, the recipient has no chance of finding out who it was. (Obviously "your mother" is a harmless variant of this game, the message could also be a threatening or demeaning one.)
Third-party services relying on .osc files will only detect user name changes when an edit has been made with a certain name; shenanigans like the above will not be detectable from .osc files.
A proper recording of user name changes would help reduce the confusion such trolls can create, but they could then do other things like creating a new account and deleting it immediately. Also, users might legitimately want to change their name for privacy reasons (having e.g. used their real name initially and later wanting to switch to a pseudonym). An easily accessible list of historic user names would remove that possibility.
I think only recording changes going forward would be fine for this feature.
... If change their name back quickly, the recipient has no chance of finding out who it was. (Obviously "your mother" is a harmless variant of this game, the message could also be a threatening or demeaning one.)
That's why I also suggested having at least 30 days "cooldown" after a name change. In that period the user shouldn't be able to change it.
Having more control on when / how frequent user name changes is possible is also being discussed in #1720, although more from a DWG/moderation point of view.
Somewhat at a tangent from this issue, but useful to address some of the issues that woodpeck mentions above - it'd be great if userids were more visible throughout the site. This is something that's touched on by other issues such as https://github.com/openstreetmap/openstreetmap-website/issues/482 .
I suspect that any change (including a list of previous usernames, however obtained) would need some extra admin effort to deal with questions about, e.g. admins being asked to delete historical references to a user's real name, if that was changed by accident. This does happen - within the last year I can think of at least one user who deleted their account immediately after a name change from a pseudonym to a regular human "first name, second name", I suspect by accident.
Users have also been known to rename and then delete their accounts so that their previous block and changeset comment history is no longer associated with their chosen account name.
The OSMF privacy policy specifically points out that changing the display name is a privacy feature of the website. Definitely tracking previous names is a violation of both the GDPR and the OSMF ToSs outside of internal use by the DWG.
PS: naturally internal use would have to be documented in a policy update.
how can changing the display name be a privacy feature if the connected and public user id always remains the same?
how can changing the display name be a privacy feature if the connected and public user id always remains the same?
Because it allows users to change away from display names that leak PI or are associated with other activities (social media and so on) and yes this requires removing them from dumps and diffs too. But there is no point in restarting discussion of what was vetted by numerous experts in the field, I was just piping up to, probably in vain, stop the OSMF from digging itself an even deeper hole than what it is already in.
Definitely tracking previous names is a violation of both the GDPR and the OSMF ToSs outside of internal use by the DWG.
(the usual caveat - I am not a lawyer; this is just my interpretation of the ICO's** advice here)
I suspect you'd need to make a specific case for both of those. For the avoidance of doubt the OSMF policy says, in a subsection entitled "How can you control the processing of your data and reduce privacy related issues", "you can select a non identifying login name and change it at any time you want".
Do the OSMF ToSs even link to that policy at user signup? I certainly don't remember seeing it the last time I created a test user, and I do look out for this stuff.
With regard to the GDPR, I'm sure a case for "making more use of userids across the site" could be made under several of the 6 lawful bases for processing. Obviously the GDPR has no concept of what the DWG is, and I suspect that the OSMF could argue that other logged in OSM users are part of the "you" used in the GPDR "lawful bases for processing" wording, and that they are a vital part of some of the functions mentioned (for example, by noticing data copied from third-party sources with incompatible licences and reporting it. At a stretch you could also make a case that "showing a list of previous usernames of a user" to logged-in OSM users is supported by the GDPR because they're part of the "you" mentioned there.
I don't think that you could make a case for "showing a list of previous usernames of a user to non-logged in users" was covered by one of the 6 legal bases for process.
For the avoidance of doubt "could make a case for" does not mean "must do immediately" - it just means that it might not be a violation of the GDPR (subject to interpretation - see above) and discussion of whether it's actually a good idea or not should continue.
** the data authority in the jurisdiction in which the OSMF currently resides.
Edited: typo: for/are
Definitely tracking previous names is a violation of both the GDPR and the OSMF ToSs outside of internal use by the DWG.
(the usual caveat - I am not a lawyer; this is just my interpretation of the ICO's** advice here)
All the policies and texts were created by or at least in conjunction with lawyers with expert knowledge in the field.
I suspect you'd need to make a specific case for both of those. For the avoidance of doubt the OSMF policy says, in a subsection entitled "How can you control the processing of your data and reduce privacy related issues", "you can select a non identifying login name and change it at any time you want".
Do the OSMF ToSs even link to that policy at user signup? I certainly don't remember seeing it the last time I created a test user, and I do look out for this stuff.
The privacy policy has been linked to in the initial registration screen for a very long time and additionally from the ToS (that you you need to accept for account creation) for a good 4 years (aka since the ToU were adopted).
I believe it's obvious from the description provided by @simonpoole above, that adding this feature would be in violation of the OSMF privacy policy. I'm closing here.
Description
Currently changing one's username is trivial and it can be easily abused. For example user Black11 (uid: 9545352) (who has a long history of name changes) changes his name very frequently. That makes it hard to identify his changeset when he does. My suggestion is to create a link on one's profile page that shows the previous usernames along with the dates from and to to they were used. Another useful feature would be to have some sort of "cooldown" period of at least 30 days after a name change in which you are not allowed to change it again.
Screenshots
No response