User account self-deletion allows bad actors to delete and recreate the same account name to "lose" changeset discussion and block history

[SomeoneElseOSM]

URL

https://github.com/openstreetmap/openstreetmap-website/pull/3398

How to reproduce the issue?

There have been a number of recent examples of the following sort of activity, but lets give a specific example:

A user account was created with a name "francisdouglas88614" to "force through" some changes that they local community decided were not correct. The UID was 19014237, and due to it being a problematic returning vandal they were reverted and blocked until they contacted the DWG with https://www.openstreetmap.org/user_blocks/7071 (see previous messages in that chain of blocks for the history).

They then delete that account, and create another one - francisdouglas88614 / 19021744, and try and force through their changes again. They were reverted and blocked with https://www.openstreetmap.org/user_blocks/7074.

They then delete that account, and create another one - francisdouglas88614 / 19031302, and try and force through their changes again. They were reverted and blocked with https://www.openstreetmap.org/user_blocks/7077.

This is just 1 username here; there are at least 9 or 10 others. I don't believe that it is unfair to "name and shame" this account as this user has been widely discussed elsewhere.

Basically, this is pretty much as predicted by https://github.com/openstreetmap/openstreetmap-website/issues/1853#issuecomment-387682751 .

In additions to previous problems noted such as https://github.com/openstreetmap/openstreetmap-website/issues/3585 .

To be clear, the idea behind https://github.com/openstreetmap/openstreetmap-website/pull/3398 absolutely makes sense; but we should prevent it from being used by bad actors as it currently is. There may of course be reasons why a long-term-blocked user should be able to delete their account, and they can always ask the admins to do that. What I'm suggesting is that a user shouldn't be able to engage on vandalism, get caught, delete their account and repeat the process ad infinitum.

Screenshot(s) or anything else?

n/a

[fitojb]

For starters, used usernames should not be permitted to be reused

[tomhughes]

I really don't think that's going to work - we remove the names because they often contain personal data so we don't really have any option.

Besides which it will just leads to loads of people asking why they can't have a name which appears to be unused and anything which gives me more support mails to answer is definitely not on.

[HolgerJeromin]

we remove the names because they often contain personal data so we don't really have any option.

We could save a hash instead. And perhaps block a new account for a few days/weeks/month.

[SomeoneElseOSM]

We could save a hash instead.

That's not really relevant to the main problem here. Let's not worry about any general issues around account name re-use for now and just concentrate on preventing blocked users from deleting their accounts themselves. They'll still be able to ask; they just won't be able to do it themselves.

[tomhughes]

I'm trying to reduce the number of people sending me account deletion requests, not increase it.

Maybe I should say I'll agree to this if we can get some action on https://github.com/openstreetmap/openstreetmap-website/pull/3488 in return?

[SomeoneElseOSM]

I'm trying to reduce the number of people sending me account deletion requests, not increase it.

To be honest, most of these blocked users will have been shown a message such as https://www.openstreetmap.org/user_blocks/7071 which is actively trying to get them to reply to the DWG (and usually other mappers too). We (the DWG) would be more than happy to say "you can't do X until you've done (this other thing that you were explicitly asked to do)".

This won't affect "normal" mappers, only people trying to evade account blocks by deleting the old and creating a new account.

[SomeoneElseOSM]

Another example just this morning, see https://community.openstreetmap.org/t/odd-edits-in-italy/97706/55 . A well-known Italian troll created userid 19303717 (username "gapathys") and made some edits that they knew the community would not agree with. They then deleted the account and created a new userid 19471310 which they also called "gapathys" (now deleted) to revert those edits. They then did it again, userid 19478605. They then did it again, userid 19480213

Part of the solution for this problem is for users who are currently blocked not to be able to delete their own accounts.

[SomeoneElseOSM]

Somewhat related to this issue, the current state of the vandalism that "bad actor self-deletion" allows can be seen at https://community.openstreetmap.org/t/odd-edits-in-italy/97706/60 .

[tomhughes]

I really don't see how the proposed "solution" helps anything - trolls will still be able to create sockpuppet accounts they will just have to give them a different name.

Meanwhile I will get dragged into support complaints from people complaining that they can't delete their accounts.

[SomeoneElseOSM]

Meanwhile I will get dragged into support complaints from people complaining that they can't delete their accounts.

With this suggestion, you'll only get that from bad actors who have already been blocked . You're right that it doesn't stop "vandals will be vandals" (we'd need a much less fluid account sign-up process for that, which is a much wider issue), but it would stop a user from enforcing "their" edits with "their" account name, or being able to easily evade blocks by simply deleting their account and creating an "identical" one.

[simonpoole]

I think the important point here is that in creates an (admittedly minor) inconvenience for the vandal and makes things a bit more convenient for the community.

I don't quite see this being the source of additional support load on ops. Obviously when self-deleting the account fails it should display an appropriate message (for good measure I would throw in a note that creating accounts to avoid a block violates the OSMFs ToS).

[matkoniecz]

I really don't see how the proposed "solution" helps anything

It would allow people to easily look at other edits performed by vandal account.

[natrius]

I really don't think that's going to work - we remove the names because they often contain personal data so we don't really have any option.

Besides which it will just leads to loads of people asking why they can't have a name which appears to be unused and anything which gives me more support mails to answer is definitely not on.

I would love to see the following: If a user deletes his account, change the username to a random string like deleted_234234 and remove the profile-content. This way the profile itself remains clickable and the history and comments can be found and traced but the user-data is gone. Save the user-name in a database and block it for 6 months (arbitrary now) before it gets released again.

Additionally restrict name-changes to once a year, for example. The name-changes of one individual user drove me nuts and everybody as well because he tried to avoid getting found again. But this leave still the possiblity to switch up the name if you want it for some reason. (will search if there is an issue for this)

EDIT: we got one user that is creating accounts to edit a bit and now has discovered he can delete them as well. We counted about 40 accounts in the last days that were delete but the ones that were the account of this person is around 30 or 40. https://community.openstreetmap.org/t/user-mapped-hecken-im-grossen-stil/99983 This is the current thread in that matter

[hungerburg]

If a user deletes his account, change the username to a random string like deleted_234234 and remove the profile-content. This way the profile itself remains clickable and the history and comments can be found and traced but the user-data is gone.

That should be GDPR safe. There is warranted interest, even though the edit history may identify an individual, does it?

[SomeoneElseOSM]

For info, another example of this can be seen at https://www.openstreetmap.org/user_blocks/15138 . They had a previous user with the same name which was blocked a number of times (for essentially fantasy mapping) up to https://www.openstreetmap.org/user_blocks/5638 but then "deleted and recreated their account with the same name" and continued on regardless.

Two reasons for not closing this loophole were given above, for privacy and workload reasons. Both of these can be addressed:

With regard to the first, would it help if I discussed potential privacy issues with the LWG (with a DWG hat on if it helps) to understand whether there are any privacy blockers here? I'd be surprised if there were since we're not saying that users should not be able to have their accounts deleted, just that those who are currently blocked should not be able to do it via self-service?

With regard to the workload issue I'm sure that that could also be addressed - "requests for account self-deletion" could be reviewed by a wider pool of people, perhaps including from the DWG (who are likely the people who blocked them in the first place).

[mmd-osm]

How about we only allow self-deletion of a user account after a cool-down period of, say 28 days. Cool-down period in this case means: time since the last changeset has been uploaded by the user.

This is similar to the grace period approach I suggested back in https://github.com/openstreetmap/openstreetmap-website/issues/1853#issuecomment-387769478, but it would be much easier to implement.

Blocked users may not self-delete their accounts at all.

Rough idea:

  def eligible_for_deletion
    latest_changeset = Changeset.where(:user_id => current_user.id).reorder(:created_at => :desc).first
    latest_created_at = latest_changeset&.created_at || Time.zone.local(2000)

    days_since_last_upload = (Time.now.utc - latest_created_at) / 1.day
    days_since_last_upload >= 28 && # Settings.deletion_cool_down
      !current_user.blocks.active
  end

I'm using created_at because of proper db index support (changesets_user_id_created_at_idx).

[AntonKhorev]

How about we only allow self-deletion of a user account after a cool-down period

I asked about this yesterday on dwg channel, nobody complained.

[mmd-osm]

Another rough sketch how this could look like. UX experts in particular are invited to come up with better ideas ;)

We could include a list of all the checks we're performing, along with some more detailed explanation, in case a condition is not fulfilled. If the overall status is not ok, we disable the delete button.

[pnorman]

Are we allowed to refuse to delete an account if they've edited in the last month?

I expect delaying the delete is fine, but telling someone they have to come back to delete might not be.

[matkoniecz]

As I understand (see https://ico.org.uk/for-the-public/your-right-to-get-your-data-deleted/ https://gdpr.eu/right-to-be-forgotten/ https://www.dataprotection.ie/en/individuals/know-your-rights/right-erasure-articles-17-19-gdpr ) there is no universal method/rule.

We are - as far as I know, I am not a lawyer etc - not obligated to provide self-deletion button at all. We can also provide it allowing deletion at will (used primarily by vandals nowadays). We could also provide one that works only on odd-numbered days. Or only for people who have not edited for a long time.

Account-self deletion seems to exist to cut down on manually processed requests arriving via weird methods and exists for convenience ours and legitimate users.

Main risk of change proposed here is that we could start getting more paper/mail based account deletion requests, but this seems better and less taxing than rampant abuse by vandals.

Warning: I am not a lawyer, this is not official statement of anyone.

BTW, https://github.com/openstreetmap/openstreetmap-website/pull/3398#issuecomment-995018261 has

Did you by chance implement some grace period of 14 days, for people who regret their decision after a few days?

I'd forgotten about that idea of a grace period! It's something that I could add though.

[matkoniecz]

Another option is to reduce it from 28 days to say 7. Vandals would be likely blocked in meantime and their deletion requests can be (warning, I am not lawyer) rejected under

For example, an organisation may consider a request to be ‘manifestly unfounded or excessive’ if it is clear that it has been made with no real purpose except to cause the organisation harassment or disruption.

or

overriding legitimate interest for the organization to continue with the processing

or other legal regulations intended to cover this kind of abuse.

Warning: I am still not a lawyer, this is not official statement of OSMF.

[hungerburg]

Not a lawyer, not a UI scientist: The screenshot looks very fine. It mentions all the details of what well be deleted, what will be retained. This is how, as an ordinary citizen, I would like to get told what my action will entail. To the wording:

How about saying, will be retained "anonymized"? Can this be told and will that hold true? How about saying, will be hidden from view by the general public instead of hidden from view?

Four weeks seems an appropriate cool down duration and also give "gardeners" the necessary time to react in case of vandalism. Remember, two weeks are considered minimum in waiting time for reactions on changeset comments.

I understand, that the developers could initiate a timer that starts running from clicking the button and gets invalidated when new edits occur. Like this, it looks much more straightforward to implement. I have no idea how cumbersome such automatism will be to them. I'd say, if somebody truly wants to get off, they will return.

PS: A block actually should not prevent deletion. That seems to me running foul of GDPR. Last edit time should work in this case just as well - as the delay only prevents usage of same nick and does nothing against doing so under different nick.

PPS: One more reason to provide a "cool down period": People may have spent considerable effort into improving data but may throw this all away for arbitrary reasons or because they are confronted with more or less arbitrary criticism. I personally met people that did not go underground and became good contributors after the blocks expired.

[tomhughes]

How about saying, will be retained "anonymized"? Can this be told and will that hold true? How about saying, will be hidden from view by the general public instead of hidden from view?

The existing screen, which is quoted above, already explains the anonymisation process.

I understand, that the developers could initiate a timer that starts running from clicking the button and gets invalidated when new edits occur. Like this, it looks much more straightforward to implement. I have no idea how cumbersome such automatism will be to them. I'd say, if somebody truly wants to get off, they will return.

It's more complicated, but not impossibly. It's terrible UX though - you're basically setting a time bomb that might go off in three years time when you happen not to edit for four weeks.

PS: A block actually should not prevent deletion. That seems to me running foul of GDPR. Last edit time should work in this case just as well - as the delay only prevents usage of same nick and does nothing against doing so under different nick.

GDPR is not some magic spell. The right to deletion only applies where data is being processed by consent - if it is being processed for other reasons such as "legitimate interests" then it doesn't apply.

Now we certainly might want LWGs thoughts on the matter but there isn't an absolute right to always have things deleted.

[mnalis]

Now we certainly might want LWGs thoughts on the matter but there isn't an absolute right to always have things deleted.

I concur. And where there is a right, there is no requirement that there is self-service website do it. In fact, most common method I've encountered in the wild so far is still "Email the Data Protection Officer with your GDPR deletion request"

[natrius]

So, there is something to allow users self-delete and something else to delete all their data.

So it is possible to:

1. Allow self-deletion after 7 days of non-editing. If the user edited in the last 7 days, grey out the button with a information besides it, for example.
2. Allow coming back with a "Your Account will be available for you for another 90 days if you decide to come back."
3. While these stuff is happening no username-change is allowed
4. after the 90 days the username is changed to "deleted12345" with random number plus deletion of the profile-information (or just make it invisible?)
5. A possibility to allow deletion like mnalis said above "Email the Data Protection Officer with your GDPR deletion request". I don't think this will happen often at all.

This is all possible and i think would be good to restrict vandalism while allowing users to self-delete their account. Although i think some stuff might be harder to implement than others. But all in all i think it would be good for OSM.

[matkoniecz]

It's more complicated, but not impossibly. It's terrible UX though - you're basically setting a time bomb that might go off in three years time when you happen not to edit for four weeks.

Maybe it should be cancelled the first time user edits/makes note/changeset comment/etc?

[matkoniecz]

Now we certainly might want LWGs thoughts on the matter but there isn't an absolute right to always have things deleted.

Proposed text to send to LWG ( if you are maintainer of this repository - feel free to use it and send it to LWG in own name or tell me what needs to be changed or tell me that it is not useful to send as-is or tell me that it would be useful if I would send it, feedback is also appreciated from others ):

---

questions: Can we disable self-deletion functionality for people who edited within last month? Can we disable self-deletion of blocked accounts?

explanation: At osm.org we are providing "delete your account" feature. It can be used at will by users and make their edits much harder to connect with former account, this also removes their username, hides diary comments and so on.

Unfortunately, at this moment it is primarily used by vandals and malicious people that make harder to revert their vandalism and reuse account usernames. Typical vandal strategy is to register, commit vandalism and immediately delete account.

Would we comply with GDPR and UK privacy regulations (etc) if we would block self-deletion in cases like:

• user was active in last month
• user was active in last 7 days
• user is blocked

As I understand (I am not a lawyer!):

We are not obligated to provide self-deletion button at all. We can also provide it allowing deletion at will. We could also provide one that works only on odd-numbered days. Or only for people who have not edited for a long time.

Account-self deletion exist to cut down on manually processed requests arriving via weird methods and exists for convenience ours and legitimate users but is not legally required.

Main risk of restricting self-deletion is that we could start getting more paper/mail based account deletion requests. But it is entirely legal to restrict self-deletion.

triggered by: https://github.com/openstreetmap/openstreetmap-website/issues/4018

[tomhughes]

The question is not really about self deletion specifically though, it's about deletion in general because we don't people to do an end run around just by sending an email - that just creates more work for me without solving the problem.

[matkoniecz]

So it would be "Can we reject all deletion requests of blocked accounts?" or maybe "Can we reject all deletion requests of vandal-only accounts?"

I guess that rare case of user with 10 000 edits banned after editing dispute asking for their account to be deleted would be survivable, the main question is can we ignore vandal-only accounts.

And "can we tell people who edited recently to request account deletion in 28 days/7 days/24 hours". Or is it needed to refer such people to DWG for review rather than refuse deletion? (on assumption that it will lower overall DWG workload, DWG would need to be consulted about this).

Or is it OK to accept their deletion request, perform deletion with delay and cancel deletion request if they will edit or be blocked in meantime?

[matkoniecz]

it's about deletion in general because we don't people to do an end run around just by sending an email - that just creates more work for me without solving the problem.

would it solve this problem to give DWG power of deleting user accounts who requested account deletion? So burden of reviewing account deletions would be moved there

(if DWG would be happy about it - if that would be combined with eliminating self-deletion abuse it could reduce overall workload on DWG)

(yes I know that it requires extra code that will not write itself)

[tomhughes]

I'm sure DWG would be very happy with it yes but I have deliberately avoided giving that power to such a large group of people for the time being.

[matkoniecz]

Even if it would be only for accounts that requested deletion?

[tomhughes]

Now we're back to having to build a damned queuing system which we already rejected as over complicated!

[matkoniecz]

"user pushes button, DWG pushes button" seems simpler to me than "user pushes button, later something happens on its own" - but maybe it is still too complicated or I am simply wrong

[tomhughes]

No, it's harder.

In the first case we add a flag to the user and have a batch job that once a day looks for users with that flag set that haven't edited recently and deletes them.

In the second case we need table of queued deletion requests (well possibly we could just use a flag on the user if we had an index on it) and then we need to build UI to alert moderators to those requests and present them with a list of pending requests and a button they can press. That means several new server routes, several new views, etc, etc.

But really none of it needs to be this hard. We had an excellent UI suggested about three hundred comments ago, we just need to get LWG to agree to it.

[natrius]

Well, it has to get implemented and tested as well. I was about to suggest a ticketing-system. What about using an open source ticketing system for something like this? Like, someone presses "Delete" a e-mail get sent to the ticket-system, there is a group of people and the one with the lowest amount of open tickets will get it auto-assigned. And when the ticket is closed with a tag the user gets deleted or not.

It sounds easier in that matter that there is no ticket or queing system in need to be programmed, 'just' the connection or the link.

On the other hand, i can see the use for a osm-queing system for various uses, but i understand its quite something to program. There would be some usecases in my opinion.

[tomhughes]

I am unsubscribing from this ticket now to preserve my sanity.

[matkoniecz]

But really none of it needs to be this hard. We had an excellent UI suggested about three hundred comments ago, we just need to get LWG to agree to it.

New proposed version of text to be send to LWG, taking into account https://github.com/openstreetmap/openstreetmap-website/issues/4018#issuecomment-1776938957 and replaces https://github.com/openstreetmap/openstreetmap-website/issues/4018#issuecomment-1776930560

(I am assuming that preparing this text is useful, let me know if it is not)

---

Proposed text to send to LWG ( if you are maintainer of this repository - feel free to use it and send it to LWG in own name or tell me what needs to be changed or tell me that it is not useful to send as-is or tell me that it would be useful if I would send it, feedback is also appreciated from others ):

---

questions: Can we reject deletion requests for people who edited within last month? Can we reject deletion requests of blocked accounts?

explanation: At osm.org we are providing "delete your account" feature. It can be used at will by users and make their edits much harder to connect with former account, this also removes their username, hides diary comments and so on.

Unfortunately, at this moment it is primarily used by vandals and malicious people that make harder to revert their vandalism and reuse account usernames. Typical vandal strategy is to register, commit vandalism and immediately delete account.

Would we comply with GDPR and UK privacy regulations (etc) if we would block self-deletion and refuses deletion requests in cases like:

• user was active in last month
• user was active in last 7 days
• user is blocked

Are we allowed to tell people who requested self-deletion via email to stop editing and use self-deletion feature in X days?

Proposed new interface would look like this: https://github.com/openstreetmap/openstreetmap-website/issues/4018#issuecomment-1775915884

triggered by: https://github.com/openstreetmap/openstreetmap-website/issues/4018

[gravitystorm]

I think this discussion jumped too quickly from discussing incidents and went straight to proposals, without explicitly stating the specifics of the underlying problems. From this issue and the discussion at #4313 I would say these are some of the problems:

• Deleted accounts are hard to report, because they are not linked from changesets, ways etc.
• Immediately reusing display_names is confusing, since user urls are not stable (see #482). This hinders discussion of events since people can't link to a specific account.
• It's near impossible to navigate through the list of all changesets created by deleted users.
• Also third-party tools are struggling with deleted users, and fail to analyze such changesets: https://github.com/mapbox/osmcha-frontend/issues/669.
• Website users will also be unable to verify whether a deleted account has already been blocked and hence a report might be superfluous.

Things that a cool-down period won't help with:

• Vandals can just abandon their account, and vandalise using a fresh account. They will need a fresh email address (which they currently don't have any problems with).
• Perfectly normal people could get frustrated with a cooldown period, and this may lead to additional support requests.

If anyone has any more of the problems (I'm not looking for example incidents, I mean the problems that this behaviour is causing for the people trying to deal with it) then I'd be very grateful to hear them.

[matkoniecz]

It's near impossible to navigate through the list of all changesets created by deleted users.

And it is a problem because you cannot easily find other bad edits by this vandal (that would be otherwise easy to spot and initiate revert). Basically, quick self-deletion achieves the same effect as creating separate account for every single edit.

Or even worse, as "suspicious first edit" is a bit easier to spot.

[woodpeck]

(I had written something else before but that was not well thought out, here's a better version.)

Deleted accounts are hard to report, because they are not linked from changesets, ways etc.

Not only are deleted accounts hard to report - it is hard for an average website user to even find out if they are looking at a bad actor or just a bumbling newbie.

Vandals can just abandon their account, and vandalise using a fresh account. They will need a fresh email address (which they currently don't have any problems with).

True but at least being able to determine who the vandals are is already a big help.

I think this discussion jumped too quickly from discussing incidents and went straight to proposals,

Yes. The "cool-down" period idea is an easy and quick fix for the most pressing aspect of this issue, but it would still mean that after the cool-down is over, vandalism vanishes in some primordial soup.

It would be better to attack the problem at its root and ensure that even long after an account is deleted, the relevant information is still available for web site users to see - i.e. that certain edits were made at a certain time by the same individual as certain other edits, and that these edits attracted certain comments and that the user was or was not blocked. I fear, however, that a proper overhaul of the web site and API, possibly assisted by legal guidance, is a very big task that will take a long time to complete. The "cool-down" idea will take the pressure out of this as currently active vandals' self-deletion would be disincentivized, and the many eyeballs looking at current conflict regions could help combat vandalism more effectively.

[hungerburg]

A softer reason for delaying delete requests: The cool down period affects not just vandals. I'd say it can help people from throwing in the towel too easily thereby losing the investment into their persona. I guess, that is why it is called like that? Time to reconsider. The community should be better off with continuity in members.

In case somebody urgently wants to start from zero, they still can do that. Even with the same nick, if they rename the other one first. Brings up a question: Can users pending delete rename themselves?

we add a flag to the user and have a batch job that once a day looks for users with that flag set that haven't edited recently and deletes them.

If I understand correctly: The flag is a timestamp, delete request plus cool down period. The batch job selects where deletion due then checks whether flag minus time of last edit is greater than cool down period. If so there were no edits after delete request and deletion can happen, otherwise flag gets unset, i.e. request cancelled.

[AntonKhorev]

It's near impossible to navigate through the list of all changesets created by deleted users.

It's near impossible to navigate through the list of all changesets created by any users. For deleted users there's no list at all.

[mmd-osm]

Brings up a question: Can users pending delete rename themselves?

A few remarks based on the actual implementation that's under discussion in #4313:

There's no such thing as a "pending delete". We don't introduce any new flags, batch jobs or anything. Either your last edit was at least {cool_down_days} days ago, and you're eligible for deletion (=hitting the delete button is possible), or you need to wait for a few more days and then try again.

In a way, we're offloading the whole queuing part of the story to the users themselves.

Renaming the user has no impact on this process, since it doesn't change the last edit timestamp for this user id (which remains the same, even when changing your display name).

I'd say it can help people from throwing in the towel too easily thereby losing the investment into their persona.

Yes, that was also one of the scenarios I had in mind.

[gravitystorm]

@woodpeck I know you just deleted this, but this is another of the things I'm looking for:

Website users will also be unable to verify whether a deleted account has already been blocked and hence a report might be superfluous.

I've added it to my list above.

[Fizzie41]

I note Tom's concern that this would increase his workload with people asking to delete their accounts.

Do we have any figures on the number of normal mappers, NOT vandals, that currently self-delete their accounts?

Are we talking 10/day or 1/month?

[tomhughes]

There have been 348 accounts deleted so far this month, so about 13 per day. No idea how many are vandals though.

[AntonKhorev]

How many of them weren't blocked?

[mmd-osm]

I thought https://planet.openstreetmap.org/users_deleted/ could be good source, though I'm a bit surprised to find more than 40'000 deleted users for this month. I guess that's due to some unrelated spam user cleanup job?

[osmhomeblog]

The topic of deleting accounts concerns me. I would therefore like to take a closer look at possible motives. Anyone who has been involved in OpenStreetMap for a long time is confronted with the fact that this project is constantly evolving. What was normal in OpenStreetMap a few years ago is completely different today. But edits are static, they stay. So if you don't want to come into conflict with your own past way of working, a new name makes sense. There can be different levels of development in OpenStreetMap for each region. A way of working that suits one region can cause conflict in another region. Using different names makes sense.

A good way to let go of old things and protect an old way of working from comments that are irrelevant today is to delete old accounts.

We should ask ourselves what motivates hungerburg and natirus(Negreheb) in this thread to participate in this discussion. If you look at their history, both exert strong pressure on other mappers, both have a strong urge to act as gatekeepers in OpenStreetMap. Neither hungerburg nor Negreheb were appointed by a significant community for such a function; both are probably acting out of self-interest or in the interests of a small but influential group in OpenStreetMap. Which brings us back to the deletion discussion. To avoid pressure from gatekeepers, productive contributors to OpenStreetMap choose anonymity. Which of course doesn't please Hungerburg and Negreheb....

It may therefore be that deletions are a response to strong pressure. I think that putting pressure on ordinary contributors who map meadows or forests to improve building outlines is reprehensible, especially since there is still a lot of unfinished business in OpenStreetMap. We should distinguish whether vandalism is political in nature or whether it seeks to destroy. There should be protective mechanisms using AI for both today; gatekeepers who try to influence a broad group of participants with petty regional details are unnecessary. But I'm always impressed when Frederik defends OpenStreetMap against politically motivated renaming of the Persian/Arabian Gulf.