While reverts are in progress, do not edit affected names
To redraw the map in the browser after rollbacks, reload the page without cache: Ctrl+F5 or Cmd+Shift+R.
If you notice new cases: go to user profile → Report this User
Also at the link you can also see that we reported the current status of reverts and explained how it works, why vandalism may not disappear from the map for a long time.
HDYC and OSMCha (if I remember correctly because Overpass was unavailable) became victims of such diffs in the past times. Live-update users in OsmAnd also faced huge updates.
Also, edits with 10k modified objects are very difficult to view quickly and without lags in the change viewer. OSMCha, Achavi, JOSM.
And imagine vandalising not just one person, but several hundred organised on some 4chan or on a video blogger’s stream
By the way, code is already deployed for testing here: https://tomh.apis.dev.openstreetmap.org/
You need to sign up there (your main osm.org account won’t work there), and then try uploading some, or even lots of data.
you can test whether reasonable edits are going through and mass scale vandalism is limited (and error handling in editors and API and so on)
We’'ll have a look. Blocked for now, we’ll amend that message with more detail once more detail is know.
At first glance it looks like a case of password-stuffing; and if so it wouldn’t be the first example in OSM. The general advice to avoid this sort of thing is for people to ensure that they don’t share passwords between accounts for different things on the internet (so that if passwords for site A get published, they aren’t useful for site B).
large-scale vandal activity should be now reduced, as large edit volume will be blocked, especially from fresh accounts
note that large scale edits from new accounts may be also affected, but should not affect vast majority of genuine new users
brand new bot/import accounts may need to operate in way dealing with rate limits if editing at huge volume, also old ones may be affected if volume is exceptionally large
Thanks for everyone who contributed!
Note that further changes may be needed to make life harder for vandals. For example abusive use of delete account feature likely should be stopped/reduced.
… and now reverted (by several people, including me in this changeset).
Because there have been several people reverting things at the same time, it’d be really helpful if people could see if there are any examples of problem data still existing?
With the latest vandalism in mind:
Wouldn’t it be a good idea to also limit the changesets of new accounts in size (area)?
This would make it slightly more difficult to make global vandalism resulting in this massive tile updates we saw the last week.
This . Preventing new accounts from creating large geographical changesets is hopefully the simplest and most effective way to prevent large-scale visible vandalism. It would be even better if the editor restricted changes to the new user’s current location, similar to how StreetComplete operates.
As much as I enjoy introducing OSM to my neighbors, hoping they’ll join me in improving coverage of Silicon Valley, I also respect that many of them choose to contribute in parts of the world that are comparatively underrepresented, such as through HOT.
StreetComplete asks for your location using Android’s location services. iD can similarly obtain your location from the browser if you click the button to jump to your location. However, it doesn’t ask for this information upfront, because this project has historically determined that sharing your current location should not be a prerequisite to editing the map.
It would be quite ironic if the first-run experience were to consist of, on the one hand, an option to opt out of loading brand logos from Facebook’s CDN to avoid divulging the fact that you can see a McDonald’s in street-level imagery, but on the other hand, a requirement to share your location before proceeding. At the moment, one cannot forever associate a mapper with their whereabouts based on where they made their first edits. It should probably remain that way.
What about the idea of “Preventing new accounts from creating large geographical changesets” regardless of location? Sorry if this topic has already been covered, but I am finding it challenging to keep track of all these related discussions.
Where to focus from the Editor to the API to the Tile Server ? When such intensive vandalism actions, I suggested before that it would be possible to focus at the API level. I dont know how the API is managed but I supposed that a Detection function could be located before the API adds new data to the database to detect vandalism content and simply ignore such changesets. This function could be triggered when intensive vandalism and adapted to particular situations. New accounts or any other criteria like abusive language or moving nodes km away could be considered.
This might slow the API processing and force OSM contributors to try to resend their changeset if data not uploaded to the database. But there would be less problems to later correct both in the database and the Tile server.
. Preventing new accounts from creating large geographical changesets is hopefully the simplest and most effective way to prevent large-scale visible vandalism. It would be even better if the editor restricted changes to the new user’s current location, similar to how StreetComplete operates.