How about limit new accounts?

I don’t actually disagree with anything you say here, but the biggest stumbling block, as Tordanik touched on, is going to be who does the checking & approving of new user’s edits?

Just some of the details that would need to be worked out - a newbie has created their account & made 10 edits, which now need to be checked. What happens tomorrow? Can they make another 10 edits, or is their account blocked until those first 10 are checked & approved? “I’ve” only had time to check 5 out of those 10 - can they make another 10, or only 5?

Another option may be to only allow 1 user account per IP address, which would definitely disadvantage some power-users, or possibly prevent accounts from being set up via a VPN?

Please don’t get me wrong, it’s not a bad idea, just a lot of details to be worked out first!

1 Like

Let’s get this knocked on the head straight away - no-one’s suggesting limited new users to 10 edits. A previous wave of vandalism of which this was a related block** had a few hundred changes per “first new edit” of each sockpuppet, and was relatively straightforward to deal with - we could set “new account limits” in that sort of area and we really wouldn’t inconvenience any genuine new users.

** that sockpuppet made 4 changesets with 123, 24, 2 and 633 changes in them.

1 Like

In light of these numbers it seems to me that a fully automated system could have some benefit without requiring any volunteer time to review edits. For example, brand new accounts could be limited to 100 changes per changeset and 1000 changes per day. These limits could increase by 100 and 1000 respectively for each day of editing so by the 10th day they’d be at 1000 changes per changeset and 10,000 changes per day. After a certain number of days the limits could be removed. Tweak these numbers as appropriate to make sockpuppets frustrating to use, while not bothering genuine new users.


I’d suggest starting at something like 25 & 250 first day, 50 / 500 2nd, then 100 / 1000 3rd day?

Not too many new mappers are going to hit those limits right away, & as you say, it would slow the baddies down & give time for the rest of the community to spot & stop them.


I would prefer if we focus on mapping days since they are a bit harder to fake and earn…
Few examples:
0-20 editing days:

  • Can’t modify wiki or names on elements that have wiki(this are usually important elements/places) that people target for vandalism
  • Can’t edit admin_level 0-7

20-50 editing days:

  • Can’t edit admin_level=0-2
  • Can’t delete names

And if it becomes problem that people harvest such accounts to be used later, maybe once a day program can be ran on all accounts with 19 days of editing to detect if any of them is bot doing dummy changes just to get account to 20 days… It is not fun task but that feels like most reasonable way in my opinion.

We could also have “vouching system” where someone with 100+ editing days introducing OSM to friend could lift this limits on day 0 for friend…

To understand my perspective… I work at Microsoft and see too often admin borders changed by accounts with 0 days of expirience mostly accidently or fear New York name changing to something else…


To conquer malicious edits as discussed here there are two options:

Option 1: Restrict what or new users can edit, or how often they can edit. Like, allow them to add new information but disallow editing existing information. This will even work quite well with apps like StreetComplete, where mostly new information are added (there are exceptions, of course).
Option 2: Just restrict editing certain tags, like in this example restrict editing/removing of name:ru. This has very few side-effects but will be very effective against the current vandalism.

Of course there can be other vandalism where both options won’t have much effect, like fake drawings.

I like the completely open approach of OSM and I want OSM to stay an inclusive project. However, with enough ill intent it is possible to harm this project significantly. I guess the DWG is currently well busy with identifying and removing these malicious edits. Resulting in less time being available for other work.

Maybe we can agree on applying the limits for new users discussed here only for a certain duration until things have calmed down. Afterwards, they can be lifted to return back to the current no-limit status. If things get heated again (for whatever reason), then we have something at hand that we can apply immediately.


It would block anyone trying to map forest/lake/road/multiple buildings as their initial edits, what seems undesirable to me

Adding 6 square buildings is already: 6 * 4 = 24 nodes, 6 new ways - for 30 map changes in total. And it is a reasonable edit in the first day of mapping.

I would go with limit like 1000 changes per day for new accounts, later upgraded up to 50000 per day with bot-flagged accounts having no limit. Which should already put some limits on vandal scripts without harming true users.

But even 1000 changes per day would likely cause problems for say people attending workshops about OSM mapping.

Maybe even higher limits like 5000 changes/day for new accounts would be a better start? Something that basically never will hit even unusual newbies? And will put some pressure on vandal accounts starting from vandalising 9000 objects as the first edit?

I’m not quite convinced here. Are 1000 or 5000 bad changes / objects significantly better than 9000? I.e. is it really worth the effort? If the limit is 1000 or 5000 objects, then using multiple accounts will still allow to make 9000 bad edits very easily.

Unless there is also a limit regarding account creation. Creating multiple OSM accounts is not forbidden but maybe we can limit the account creation to 1 per day per email address.

1 Like

this limit exists already

you already can create a single account for given email address, ever (though it is easy to get piles of disposable mails anyway)

Still 9 times more effort to setup accounts. Not a big barrier but always something.

And there were also annoying to revert broken imports adding broken stuff on even larger scale (original motivation for Limit number of edits per user and day · Issue #2342 · openstreetmap/openstreetmap-website · GitHub ).

1 Like

There seems to be nothing left by that account, so thanks everyone for reverting!

1 Like

A couple more that there are still objects last modified by, though, are SdfN5h5163 and dfn5h54563. Those accounts’ edits might need checking because in a couple of cases they seem to have edited the same object sequentially.

1 Like

Love the discussion, thank to all the great replies.

I think the intent I had seems to be mirrored nicely; normal beginning editors will be able to do mapping without noticing the limits. Growing in permissions as their work progresses. Only the rare addicted-to-this person should hit ceilings.

What is important to me is the social part. The current group of mappers, and everyone commenting here, are self selected as people that are Ok figuring stuff out on their own. Finding that wiki, possibly even joining this forum or some chat. All without the UI giving any indication that this is possible or even useful.

This means we have ignored a large chunk of the population that is not so brave with their mapping efforts. We have a ‘I would like to get someone to review my edit’ checkbox which has no real-life effect of someone actually coming to review it in most cases.

The social part is underdeveloped and we self-selected our community to be filled with people that are Ok with that. The Dutch community is quite busy and has various social channels, which is awesome and I wish I found out about the earlier than I did. For instance.

So the numbers should be picked based much less on how much damage they can do, but much more about how much the edit should be team-approved. I see someone talking about editing a forest. Or mapping houses. These are great examples of things that people would appreciate help with. A quick review, a simple pointer to examples. ANY human interaction, really.
So, sure, you can increase the limits to allow the brave to add loads of stuff, and that may work in various cases. But it may also dramatically backfire with the work needing loads of love afterwards and some mappers will just leave instead of doing that.

The point is that the bigger the changes (area, points etc), the greater the risk of the person going in a different direction as the rest of the community is going.
And that is the reason for limiting their rights, not because of them being destructive but because it works better if we share the knowledge with new people. Propagate the culture, as it were.
The good part is, the vandalism is solved with the same approach without us explicitly aiming for that.

Someone mentioned StreetComplete, which has a great way of rewarding people by giving them some tokens of appreciation based on the work they did. It has no value or effect, but the social concept is known to the streetcomplete people.
I’m sure that the guys behind that project would be willing to join the conversation on combining their stuff into some ‘levels’ design we can make for the OSM database.

In that light, the limits should not be too high, its not about vandalism per-sé, it is about triggering a social and inclusive direction for the OSM teams.
And that means that this would not be a change in isolation. It would trigger more ways that make the mapping experience less about doing something in total isolation, which frankly is what it is today.
This limits on accounts would in my view be a trigger where the rest becomes something that fits and makes sense. Thus leading to a system of building community and onboarding to our culture.

1 Like

No it doesn’t. There’s no attempt to limit the number of OSM accounts per single email account. As an example, I’ve just signed up again here with exactly the same gmail address that I use for normal OSM access but with a “+” modifier on it. I can do that again, and again, and again, and the process would be pretty simple to automate (in fact I’d be surprised if the very large numbers of accounts created by this nefarious user weren’t created automatically).

The idea that any one person could sit on 10s, 100s or even 1000s of dormant, valid, OSM accounts is frankly ridiculous. This shouldn’t be a discussion about “how many edits can new accounts make” before they have to stop, it should be “how do we stop one person accumulating 100s or 1000s of valid accounts” that they can then perform vandalism with.

There’s a board meeting tomorrow. I would very much expect this issue to pop up in “Any other business” or “Guest comments or questions”. You’re on the board - make something happen to prevent this sort of thing occurring again.

– Andy (writing in a personal capacity and without consulting any DWG colleagues).

1 Like

I think that thinking is perfectly in line with the idea that a fresh account is nearly useless for vandalism purposes, as this thread suggests.

Naturally, to limit new accounts being created on the same email does look like a sane thing to do too. But certainly orthogonal to the value proposition of limiting accounts.

1 Like

these email aliases are treated as separate email accounts, similarly someone with catchall redirect and own domain can register multitude of accounts using single real mail.

And fundamentally we cannot really restrict to single OSM account per single real mail account. At least not without allowing signups only from some limited pool of email providers and banning all unknown ones - which has own issues.

Maybe there should be a special custom logic to defang that Gmail + aliases, given Gmail popularity

is this feature being used by vandals? is there already open issue for that on OSM website repository?

Main problem here is that typical solutions (require verification using SMS code, require payment, pile annoying CAPTCHa, manual account activation, heavily restrict signup eligibility, require government issued id card, require Google/Microsoft/Steam/FB/etc account, require vouching by existing user, verification using credit card but without charging user etc) have own problems that are very likely even worse.

Though more general problem, “osm website development could be going better” to phrase it diplomatically is something that board is trying to solve/improve/help/not make worse. Sadly without big successes at least for now.

I will be trying to do something, but right now I have no obvious idea what can be done and is not already being attempted (at least for collecting unreasonable number of user accounts).

Limiting how much single user account can do can be more tractable, but still will not help much if someone can create thousands of user accounts.

(writing in a personal capacity and without consulting with anyone, that is not an official announcement).


That’s only possible because we let them. There is absolutely no technical reason that says that it has to be the case.

I’m not suggesting that. I am suggesting that someone should not be able to sign up for thousands of dormant accounts. As I said above, I’m sure that any restrictions can be brought in at a high enough level to not inconvenience any normal users.

Most of that list is simply FUD - we’re not talking about implementing a full KYC system here; just putting enough in place to ensure that one individual cannot create potentially thousands of dormant accounts to use later for nefarious purposes.


No. A public issue tracker doesn’t seem the ideal place to discuss how people might exploit OSM’s sign-up process.

If I was on OSMF’s board, I’d have two items at the top of my list following this incident:

  1. Talk to the admins to understand exactly what happened here, and understanding what needs to be done to prevent it from happening again. For example - over what period of time were the (now deleted) dormant accounts created? How might we recognise that happening in future?
  2. Saying a heartfelt “thank you” to everyone who helped tidy up the mess. Mostly these weren’t people on working groups or admins but ordinary OSM mappers who detected issues as they arose and made sure that the problem changes were reverted.

Did you also try the part with the


No. :innocent:
Didn’t receive an email. Guess my provider doesn’t allow it.

Exactly, all these discussions in the open of how to fix/prevent will wise these guys up too, in fact I think a recent thread could have been a fishing expedition to find out how to by a ‘concerned citizen’.

1 Like

Absolutely wonderful discussion here, everybody. I still don’t know how I feel about all this (limiting initial user contributions, with a “ramp up” to “full” over time seems on the “more wise” side), as we are talking about making fundamental changes to the “openness” of OSM. A major cultural shift, in other words.

And in the spirit of “constructive criticism,” I’ll offer a minor correction / clarification to the initial post: all users do not (quite) have the ability of “every account can do anything and everything.” Not quite, as the DWG’s (most powerful) tools of blocking and banning (effectively shutting down an account) are not available to everyone (and that’s a good thing). The difficulty is in managing the vandalism, even knowing there is a fair amount of “user-level users” (without DWG privileges) who are doing some, maybe even much (I don’t think quite “most”) of the cleanup of “bad edits.” Some of these are vandalism, some are more simply, more innocently “ignorance” or “laziness” (like not reading wiki when needed). Still, “it takes a village” (to be stewards of good map data) and this is a gigantic effort: our “garden of global data” has weeds and even pests, but we pluck out the nasty and sometimes give a lethal zap to those who are so pesky they deserve to be shown the exit door.

As I hear (loud and clear) DWG members (like @SomeoneElse) asking for “any takers?” in his requests for additional assistance to “keep the garden weeded,” is there something we could do to better formalize these sorts of tasks? A kind of “Deputy DWG” role (without block or ban powers, but who merely are offered a basket of potential cleanup tasks)? The vetting of volunteers / contributors who would become members of this “squadron” should likely reside with DWG itself, but then there is the cost of organizing the “baskets.” That could be a “win-win,” that could be a “break even,” I’m not sure.

1 Like