Permalinks break when user changes their display name

[gravitystorm]

This problem is well know, and not new, but still needs to be solved.

All of the user-related urls, like diaries and even user profiles, use the "display name" in the url, which can be changed by the user, e.g.

https://www.openstreetmap.org/user/Andy Allan

This makes it impossible to create stable links to users or their diaries etc, and users can hamper communication and anti-vandalism activities by repeatedly changing their display name.

The urls need to be stable. One way to achieve this would be to use the user-id instead of the display name

https://www.openstreetmap.org/user/4115

The user id is already exposed in the API and used by third-party services, precisely because the display name is unstable. We could do the same on osm.org.

[pnorman]

Something that some forums is a link like /user/Joe Smith-123

But yes, 👍 for link stability. Vandalism with changing user names would be hard to handle with some of our current tools.

[tomhughes]

I think /user/123-Joe Smith or /123/Joe Smith is more common and I could be tempted to do that, though there is a conflict with the sub pages unless you do the same thing there - ie does /user/Joe Smith/edits become /user/123/Joe Smith/edits? or just /user/123/edits?

Also, if we make the /name bit on the end optional, then the 1149 users that we have with all numeric names become unclear given the need to grandfather the old scheme...

[Zverik]

http://whosthat.osmz.ru/
Because the issue of not having user ids anywhere in the API was discussed numerous times, and always came down to "develop and code the whole infrastructure or shut up".
Also see this poll results.

[gravitystorm]

I've been thinking about this more (over the last 4 years, ahem) and so I'd like to propose the following:

• Usernames will no longer be allowed to start with numbers followed by a hyphen
• Any username (are there any?) that is currently in that format will need to be changed, e.g. contact users to let them choose, and then changing remaining hyphens to underscores.
• User links would be in the format /user/4115-Andy Allan/ i.e. numeric ID followed by a hyphen followed by username.
• Old-style user links would be supported with redirects, e.g. /user/Andy Allan would 301 redirect to /user/4115-Andy Allan/.
• Correct usernames in links will be enforced e.g. /user/4115-hahaha would 301 redirect to /user/4115-Andy Allan/.
• Everything above also applies to subpages e.g. /user/Andy Allan/edits would 301 redirect etc
• The numeric-only usernames would still be allowed and still work, e.g. /user/12345 would redirect to /user/1111-12345.

Any thoughts, or anything else that I should consider?

[tomhughes]

Sounds reasonable - for the record there are 276 users affected.

[tomhughes]

Only 74 of which have any edits.

[simonpoole]

I see a bit of a problem with the scheme that it potentially permanently leaks the uid - displayname relationship to the outside. One could argue that it is unlikely that the user page in its current form will remain public in any case, but I would suggest to avoid everything which makes things even more complicated till we've decided on the scope of the GDPR rejig.

[tomhughes]

I was literally about 30s away from having a go at implementing @gravitystorm's scheme, but I guess that's something else we can sacrifice on the altar of GDPR for now.

[simonpoole]

I hate being the person to but the brakes on this, but I'm not even sure if the current behaviour (permalinks break when the display name changes), isn't what we would actually want. At least we should think it through from a DP point of view.

[HolgerJeromin]

Do we want to mark issues like this one with a GDPR label in github?

[zerebubuth]

I see a bit of a problem with the scheme that it potentially permanently leaks the uid - displayname relationship to the outside.

This seems like it would pose problems for other sites with public profiles, such as Github or Twitter (sadly no public API, but the user ID is clearly visible in the data-user-id properties on various HTML element). What is the problem with linking the UID and display name?

[Zverik]

I am thinking of how many external services contain or generate links to our profiles, like HDYC. All these links will be broken by the change. Not to mention, the links won't look as nice.

As for linking uid and names, that is already done on many external services, starting with whosthat.

[simonpoole]

Likely scenarios for a GDPR regime are those in which we distribute far less meta data to the general public and make it substantially more involved to link edits to a specific individual and create profiles from both the meta data and the individuals edits. A minimal reduction for example could be removing display names from the publicly available data (I doubt that would be enough, but right now we are discussing "what ifs"). Linking to the user accounts in a form in which would easily make the display name . uid relationship visible to the general public, would naturally make such a removal of meta-data in the data pointless, potentially forcing our hand to remove it completely.

@Zverik the argument applies to whosthat in a similar fashion.

@zerebubuth you can be fairly sure that github et al have groups busily working on the consequences of the GDPR for them. Github naturally doesn't distribute versioned dumps of all repos publicly, so has less of an issue.

https://gdpr-info.eu is a good resource for the actual GDPR text, I would suggest looking at least at https://gdpr-info.eu/art-4-gdpr/

This is a bit the wrong issue for a general GDPR consequences discussion. I'll open a separate one asap.

[zerebubuth]

I am thinking of how many external services contain or generate links to our profiles, like HDYC. All these links will be broken by the change.

@gravitystorm's proposal was to continue to support existing "old-style" links with a redirect, which would mean existing external links would not be broken. (Or, to be more accurate; they'd break as the current ones do whenever someone changes their display name.)

Github naturally doesn't distribute versioned dumps of all repos publicly,

Of all repos, no. But it's possible to publicly clone any public repo, which contains the git metadata for all changes since the beginning of the repo, which contains the email address of every contributor.

For the record, I think it's good to be thinking about how we support the right to be forgotten and redaction of PII, but we should be trying to do so without curtailing the functionality of the site. Let's not throw the baby out with the bath-water on the back of an excessively cautious reading of GDPR.

[simonpoole]

excessively cautious reading of GDPR.

This is not true in any form, the excessively cautious reading version would essentially shut OSM down.

What we are trying to do is draw a line where changes would start affecting functionality and data used by the community and to limit any real impact to data distributed to consumers that don't need and care, about the personal data aspect (well matter of fact likely don't want to be anywhere near personal data when processing OSM geo-data to start with, because of all the consequences that entails).

In that context it doesn't make sense to start investing work now in changing things that might have to go in a different direction (lots of the stuff @gravitystorm has been working on is not relevant, to GDPR issues or will actually make changes easier, this just seems to be an exception).

[gravitystorm]

Oops. Pressed the wrong button there.

[gravitystorm]

Anyway, I fail to see how moving away from usernames and towards account ids will have any negative consequences for GDPR. Secondly, we need to have stable links to administer the site - right now, even internal admins can have problems viewing user pages since the URLs can be changed any second. Data protection rules always have exceptions for e.g. admins dealing with administrative things. And thirdly, there will be many people (myself included) who are quite happy to publish their profiles and OSM should prioritise community members doing community building, and not prevent stuff while making hand-wavey statements about data protection.

I'm unwilling to put this on pause unless a particular GDPR problem is identified. I've spent my entire adult life dealing with statements of "You can't do that because of the Data Protection Act" when in every single case it's been totally fine. Similarly, "Heath and Safety Act" gets thrown around in vague terms too, for all kinds of reasons. I'm not happy to see "GDPR" becoming a similar catch-all.

The proposed changes do not expose any personal data, since a) account ids are not personal information anyway and b) these are already published. The proposed change does not make it any easier or harder to implement future "right to erasure" proceedures. The proposed changes make significant improvements to the ability of our moderators to manage abusive users.

My intention is to make these changes, unless someone can explain explicitly how this change would contravene the GDPR, or comes up with some non-GDPR reason to avoid doing so. If the legal situation changes in the future and we want to go back to the current situation, that's entirely possible to do too.

[simonpoole]

@gravitystorm
a) nobody even remotely claimed that that accounts ids themselves are personal information, however they are the most convenient key that links meta data and geo-data together to a contributors profile that clearly is personal data, other not quite so convenient keys are display names, changeset ids, editor meta-data, time stamps and location.
b) nobody said the proposed change contravened the GDPR, as already said multiple times, it simply might have consequences elsewhere that should be thought through.

Final word nobody is going to bother with doing any further work on the topic if the response is going to be @zerebubuth and yours paraphrased "it's all nonsense".

[gravitystorm]

Oh damn this user interface where I try "cancelling" a half-written badly-thought-through comment and end up pressing "Close and comment" by mistake! I will step away from the keyboard and I apologise to everyone reading my draft (and cancelled for good reason) comments. Sorry!

[tomhughes]

@gravitystorm I understand you're annoyed by all this and you might have noticed I am as well but @simonpoole has already said he needs to open a proper ticket to discuss what needs to be done for GDPR compliance so how about we wait for that rather than trying to cover it here.

[gravitystorm]

That would definitely be useful.

[not-my-profile]

I do not think that the user profile URLs need to be stable. URLs certainly look nicer without any numeric ids in them.

However I think that we certainly need a way for external services to reliably link the profile of a given user. So I would suggest the introduction of a new /user-by-id/:id route that simply redirects to /user/:display_name.