Of course. The more difficult social issue is the burden on people to perform the moderation and potential to slow down edits and whether we feel either is acceptable/desirable.
1 Like
Problems that come to mind:
-
approval before putting stuff in the database wonāt work because then
various conflicting edits could wait for approval -
approval after putting stuff in the database, but before stuff is
released for public distribution, would avoid that particular problem
but funny conflicts would still be possible if, for example, someone
deletes and re-draws something and for some reason one of the two edits
is released and the other still waiting -
what if something is not approved but other stuff has been done on top
of that in the mean time? -
new mappers would have to wait longer for their contributions to
appear which could be a bad user experience for them
I have wondered about the same sort of concept, & thought about the theory of designating the moderators of the various Communities here as āapproversā of new edits by new mappers in each of their regions?
If the new mappers are not mapping big sweeping changes that are visible across the entire globe, I donāt see it as necessary to wait for their changes to be approved.
Sure we may get a few vandalised names here and there but that obviously isnāt of as much concern as painting over the entire map.
4 Likes
Suppose that all experienced users can opt to help with approval and given the current situation of prolonged attack, would you switch such a system on? It doesnāt need to be on at all times.
The idea is that mappers can still map and see their edits in mapper tools, but propagation for real world user applications is done only with approved objects.
Wouldnāt mappers understand the need for approval, once they have seen the damage caused by this kind of intentional vandalism?
The idea is to delegate approval to the mapper community as a whole. So not as a specific function, but just another mapperās task. E.g. mappers with a certain amount of edits and/or say two years experience, are asked to opt in as approvers. Maybe only during an attack, and just to say I think this is not vandalism.
How the approval workflow would work is an issue, but Iām sure clever OSM people can solve that.
1 Like
Wikipedia has been experimenting with various āapprovalā mechanisms, and for the most part they were a failure (see Pending changes), mostly for reasons pointed out by Fredrick. Experienced editors feel reviewing of changes as a burden, and as result pending changes sit in a queue for extended periods of time, at which point they are more prone to cause edit conflicts and complicate workflow for those wishing to tackle them (who then give up).
What was a success at Wikipedia was the Cluebot (who used relatively simple rule set to revert obvious childish vandalism), and after that various measures to limit editing capabilities of new users (banning creation of new articles for unregistered users; blocking non-500/30 editors from many controversial pages, and similar).
Plus, there was always an efficient revert mechanism readily available for all registered users, who could revert vandalism on spot.
Obviously, our environments differ quite a lot, but we have some lessons to learn.
12 Likes
Now it is worldwide fake ways with abusive names, and we cannot stop it, because all preventive measures can be easily bypassed. Detection of this particular issue is pretty fast but still the damage is not entirely repaired, and the next attack will do the same damage.
Once the word gets around how to do this, and how easy it is to hit the sitting duck, risk is that it becomes a sport.
4 Likes
If the ease of creating new sock-puppet accounts with which to continue vandalism is part of the ātime/cost imbalanceā between vandalism and cleanup, then maybe the addition of a tutorial/sandbox restriction could help add time/cost to account signup in a way that is useful and maybe even helpful for new non-vandal users.
This could serve as a combination of CAPTCHA and training space and would hopefully take about the same time to complete as vandalism takes to revert (~30 minutes? ~1 hour?).
Hereās one way such a thing might work:
- New account is registered, starts blocked from the main API and only able to communicate with a sandbox API.
- The new user is presented with some number of standard mapping tasks that they must perform against the sandbox.
- Automated checking would examine their change-sets to confirm that they completed successfully and that these changes match heuristics of a person (e.g. not completed too fast or to precisely the same coordinates as a previous submission).
- The submission doesnāt pass. The user is presented with a button to request manual review and appeal.
- The submission passes. The account is now authorized to edit the main database.
As with other mechanisms proposed, this one would also involve significant development work, particularly in the choosing and analyzing of the results. One advantage it has is that it could be inserted into the signup workflow rather than changing the editing API. It would also give benevolent new users the opportunity to practice mapping and learn some techniques before they make their first edit to the main database.
All this said, if the number of sock-puppets is actually small, then maybe this increased friction wouldnāt be worth the development effort. 
1 Like
Wow, the fact that we now need to discuss restrictions that would result in enormous additional work gives these vandals immense power. If these idiotic waves of vandalism cause OpenStreetMap to be less free and open than it has been, then these jerks have already won. OSM will forever bear their mark, which is exactly the stage they shouldnāt get.
Such proposals that large-scale edits need to be moderated in some form inevitably lead to further problems. For example, the fact that data is no longer updated live can immediately lead to conflicts between individual edits. The larger the area, the more likely this is. And with additional entry barriers, we are likely to lose significantly more good new contributors than it would actually deter those intending to vandalize.
Letās show our respect to the volunteers (!) of the DWG for the fact that it only took a few minutes each time until the reverts were done. This shows that the team is doing everything right.
Of course, itās very annoying that traces of this vandalism are still visible days later, but I think if we want to discuss measures, we should focus on how we can quickly and unobtrusively remove the traces of vandalism. This way, we donāt give these people a stage anymore, and hopefully, they will eventually give up.
2 Likes
We already know that we donāt have anywhere near the manpower (neither volunteered nor paid) to moderate newbie edits, I donāt think flogging very dead horses is going to help a lot with the issue.
PS: naturally there is the whole social aspect of having some mappers being more equal than others, but we donāt need to venture there as it is a non-starter in any case.
5 Likes
We donāt know for certain the motivation of each of these high-profile vandals, but thereās a good chance that none of them woke up this morning thinking, āI want OSM to be less free and open.ā It would be useful to game out what typical vandalsā motivations might be as a starting point for brainstorming common-sense countermeasures.
5 Likes
My (sonās) idea works from live updated data! The edits do not wait for approval, the distribution does. If I used OSM data for a serious end user application, given the choice, I would always opt for extra security if the delay only omits changes to very recently edited objects. Assuming I would receive the latest approved version, of course.
PS Iām still trying to grasp if this leads to extra conflicts between edits. Have to make a diagram, Iām afraid.
Eg if the approval mechanism is turned off, and mapper A edits and uploads an object while mapper B edits the same object, you have a conflict when B uploads the edit; there is no locking mechanism on that level. Now turn on the approval mechanism, then Aās edit is uploaded and applied to the object, but it is not made available for end user apps or data user services apart from mapper tools. Bās edit gets the same conflict as without the approval.
Other case: A edits and uploads the object; B downloads this object and, using a mapperās tool, gets the unapproved version, which she can edit and upload. You could argue that Aās version no longer needs approval, because Bās work serves as a correction.You could also say there are two unapproved versions of the object, so end user distribution will be two version behind.
Deletions probably are more complicated, but Iām sure this could be worked out for all cases, once the basic mechanism is in place. Still brainstorming, of course. Important: the OSM database still holds all the edits without any extra delay; the approval does not prevent edits.
Note that my (sonās) idea gives all mappers the same opportunities, not requiring nomination nor assigning a position, just a basic qualification.
Note that my (sonās) idea does not work with pending changes, but with delayed distribution.
For OSM a max approval time could be set, after which the changed object version is automatically approved for publication. In normal times that would be zero: automatic approval or: no approval needed.
In times of massive attacks, maybe 15 minutes would already be enough to give mappers enough time to perform reverts, before the errors are distributed.
If countermeasures cannot be taken within 15 minutes, set de delay higher.
Or the other way around, start with max 24 h, then cut it back as soon as countermeasures are quick enough in detecting and preventing further attacks.
This way, you never have un unlimited queue, no matter how the approval workflow is.
Iām sure a tool could be made, available for all qualified users, to perform approvals on changes in times of need.
This would give vandals the power to block OSM-Editing for everybody as long as they want.
I think itās important to note that this wave of vandalism attacks mostly disrupted the OSMF provided standard layer tiles, not the database itself. The vandalism was reverted at the database level quite quickly and thus the risk to downstream data consumers was low. However, the vandalism pattern revealed a vulnerability in the OSMF tile rendering pipeline. Essentially it is quick and easy to make large geographic objects which result in a huge number of expired tiles clogging up the render queue. This could be seen as a kind of denial of service attack on the render servers which allows vandalism to persist in the tiles long after it has been removed from the database.
Given all this, the most sensible change to make in response is a hardening of the rendering process to make it less vulnerable to this type of thing. @TomH has a good idea here which could prevent the render queue from getting overwhelmed with expired tiles triggered by extremely long lines.
This seems similar to the idea I floated earlier to reject changesets with extremely large objects, but handling it instead at the tile rendering level which makes a lot of sense given how events unfolded.
14 Likes
It is rather difficult to separate out edits after the fact*, then I would like my suggestion from 2 dozen or so postings back (naturally haha) substantially better, simply pause diff distribution if something wrong is detected. This requires a bit of a delay between diff generation and making them available to work, I suspect 5 minutes would be enough, and then resume once the vandalism has been fixed. As diffs undoing malicious changes within a not too long time frame should essentially null out, this would essentially deny vandals the fruit of their labour.
* Facebooks QA pipeline for the now defunct daylight distribution essentially does this on an per object base, however given that they want to keep it closed source, likely to give the OMF a competitive edge, it isnāt available to us.
4 Likes
If by āthisā you mean what I suggested: that doesnāt block OSM editing at all. Itās a distributing delay at the object level, to prevent drastic delays at the tile service level.
But I guess it would take more and more persistent and devious attacks to get support for something like this. Now it suddenly seems like the incredible shrinking problem!