The vandal created one more account.
I don’t think so - it makes sense to restrict privileged accounts to the minimum set that actually need them. In the case of SomeoneElse_Revert they can follow a link back to SomeoneElse and back again that shows the link was “approved by both sides”.
As has also been pointed out elsewhere, many if not most of the day-to-day data tidying activities and reverts are carried out by non-DWG people, and that’s great.
3 Likes
Though I did point out that this is a common problem, this also means that other platforms have come up with mitigations that our software could potentially adopt.
For example, I am unable to register “Woodрeck” (with the Cyrillic “р”) on the OSM Wiki, because the AntiSpoof extension would recognize it as too similar to Woodpeck. It would also likely detect an l/I spoof. AntiSpoof is based on the Equivset library, which in turn is based on the Unicode standard’s list of “confusables”. There’s also a seldom-used blacklist of regular expressions that applies to user names, which administrators can easily tighten or loosen as needed.
This mechanism isn’t perfect by any means. Sometimes it snags playful but harmless user names. In these cases, the user can temporarily choose something different, then ask an administrator to rename their account. Since the data behind these mitigations is open-source and easily discoverable, it only protects against casual troublemakers, but not someone who is sufficiently committed to impugning a community member.
Given the tradeoffs, I understand why the software developers view spoof detection as a low priority. However, it would be much more effective to apply such mitigations at the software level than to expect users to protect themselves by registering doppelgänger accounts. This idea is worth revisiting in the future if attacks become more common.
5 Likes
In the absence of any software changes, there are some convenient methods for detecting a spoofed user name on your own:
- Enter the user name into an online Unicode character lookup tool or browser extension.
- Copy the entire URL and paste it into a text field or text editor. Chrome and Firefox percent-escape non-ASCII characters when you copy the entire URL (but not when you copy only part of the path). Additionally, some browsers like SeaMonkey percent-escape the URL in the status bar when you hover over the links on the profile page. (Unfortunately, Safari never applies percent escapes.)
- Bookmark the user profiles you trust beforehand, then notice that your browser doesn’t consider this page to be bookmarked.
Then again, now that you’re aware of homograph attacks, you can suspect one when you see an unexpectedly recent account creation date or far fewer edits than expected, even without checking the characters in the user name.
6 Likes
The English Wikipedia solution was to disallow mixed-alphabet names. All-Latin name? Fine. All-Cyrillic name? Fine. Mixed Latin and Cyrillic? No.
10 Likes
A technical solution targeting Cyrillic letters here would be uncomfortably similar to what the account did here (removing Russian-language names). The impersonation merely aggravated the bigger issues of mass deletions to the point of vandalism and inflammatory changeset comments.
That solution makes perfect sense.
I think the impersonation of woodpeck_repair is just the normal, run-of-the-mill vandalism that happens on a regular basis and thus isn’t terribly interesting.
What I think this ought to highlight is the vulnerability we have against a determined user that wishes to damage the database. This could be for whatever reason - a disgruntled user, a state actor with a political axe to grind, or a corporate competitor that desires to damage OSM’s data or reputation.
Let me ask this - if such a motivated actor were to create a bot that had the ability to rapidly damage OSM’s database, how much damage would be done before the DWG could get a block established? What if that bot could automatically spin up new user names or was operating from a pool of pre-established accounts for this purpose? It’s not clear to me that we have any meaningful protection against an actor that wanted to serious cause harm.
If such a cyber-attack were to happen, I think the OWG/DWG would be forced to take OSM offline for editing while they figure out how to defend the database against such activities. I think this is a strategic threat that project’s leadership isn’t thinking that seriously about.
13 Likes
Not to mention the biggest issue, large changeset bboxes. 
This vandal clearly intended to make a point loudly, but this is not always the motivation. A more sophisticated vandal could have mass-erased data much more subtly, such as using a series of smaller changesets by a sockpuppet farm as @ZeLonewolf describes, or by burying the changes in other changes that look more innocuous, without announcing them to the world.
4 Likes
This is a highly hypothetical question. In worst case the database would be stopped and some backup restored or something like that.
A “pool of pre-established accounts” is not unusual for this sort of activity in OSM, and seems to have been a factor here too - although I think we need to reserve judgement on a couple of the potential accounts (assume good faith and all that).
The other thing that I don’t think has been mentioned so far is password-stuffing of existing accounts. Lots of large password leaks have occurred on lots of other sites, and people (especially 10 years ago) often shared passwords between sites.
The idea of a maximum number of edits per account and day - that could
be increased on a case-by-case basis in the case of properly discussed
imports - has been floated and could, together with even stricter limits
for newer accounts, help reduce this threat.
12 Likes
One clear response today is to find the changesets removing names in Russian and revert all of them to remind people that this sort of action doesn’t pay. Taginfo still has 400,000 down.
@DWG are you going to revert the Changesets by ixpoDre or should the community do this.
The idea of a maximum number of edits per account and day - that could
be increased on a case-by-case basis in the case of properly discussed
imports - has been floated and could, together with even stricter limits
for newer accounts, help reduce this threat.
I’m not sure that this really scares off bad actors.
Here
someone used over 15’000 different IP addresses from quite a number of
IP different address blocks from various countries and specifically used
crafted Overpass requests to make the system unavailable for everyone else.
I’m confident that this has been the third or forth round of attacks
after two or three earlier rounds have been contained by Overpass’ quota
system.
There are definitely both aggressive and sophisticated actors out there
that might be able to command a huge number of user accounts. However,
trying to predict attack patterns is Movie Plot
Security,
not actual security.
Don’t forget that there might be attacks to disrupt more the community
than the data.
I’d rather focus on tools that give insight into the state of our own
data and the community. Such tools help to reassert ourselves that our
data and community is still in good shape. There is a lot of things that
can be improved there.
Nonetheless, it always makes sense to prepare lines of defense than can
be turned on when other options are dire. Restricting edit activity per
day and account clearly falls into that category.
4 Likes
If there is ever need for that, we could require asking for mobile number verifications, just as some big tech does. Or alternatively via U2F keys (their ID is unique) for privacy conscious people.
2 Likes
Here’s where it was floated:
Bruce Schneier’s point about movie plots is that a society should counter broad threats by thinking about the bigger picture, rather than playing whack-a-mole, going out of our way to address very specific scenarios, some of them imaginary.
This is good food for thought, but it shouldn’t dissuade us from increasing the cost of evading blocks, hiding vandalism inside slash-and-burn changesets, harassing users anonymously through sockpuppets, and other techniques that are so easy that even more casual troublemakers may be tempted to try them. API-level restrictions, improved analysis tools, and stricter enforcement of existing policies can all contribute to addressing these challenges.
As for the bigger picture, realistically, this project isn’t going to solve the war in Ukraine. But that doesn’t mean we must be an attractive target for vandalism masquerading as solidarity.
5 Likes
I made a CLI tool, uniwhat which shows the unicode characters which could be useful too. Homoglymps were an issue for taginfo too. Those feeling evil can generate homoglyphs from homoglyphs.eu.
2 Likes
