Yes indeed I was zoomed in 110%, it was causing the blur and the white tiles border.
Though I still have the Russian street names on certain zoom level and certain tiles.
2 Likes
The white grid lines (not talking about streets) show up in Safari based browsers on iOS, it is probably an upstream Leaflet issue. Maybe sth. triggers an autoscaling in iOS Safari on www.openstreetmap.org, haven’t checked this yet.
About blurry and lines: we already found out that the user was using a 110% scale in his browser, so that was solved already.
1 Like
So far, I haven’t seen any public news items about the attacks in OpenStreetMap.
I am not in a place to give further details, but this is now being done.
17 Likes
rhaag wrote:
https://tile.openstreetmap.org/19/274778/177218.png
Tile is clean. Last rendered at Mon Jun 17 14:34:36 2024.
https://culebre.openstreetmap.org/19/274778/177218.png/status
A tile with vandalism from this afternoon, that was not expired by the revert.
Can you run through the list here to make sure that the data has actually been fixed?
To be clear - the processes to “revert the problems in the data” and “recreate tiles” are completely separate - doing the first will only trigger the second in the same way that any map edit will.
You’re right, I was assuming that is has been fixed, because I know there was a revert.
I just double-checked and it’s indeed fixed in the data.
1 Like
I know, but it has been a recurring problem that the revert doesn’t trigger a rerendering for some tiles.
It was a worldwide problem, and there’s a summary about it here. Problems have been fixed in the data itself, but the tiles that you see in your web browser might take a little while to catch up.
OWG is expiring tiles again (see “low” queue), now “due to be rendered”:
Tile is due to be rendered. Last rendered at Mon Jun 17 14:34:36 2024.
https://culebre.openstreetmap.org/19/274778/177218.png/status
Update:
And fixed:
Tile is clean. Last rendered at Mon Jun 17 20:10:16 2024.
I don’t want to jinx things and say “nice save,” everyone (too early), but nice save.
Eternal vigilance is what it takes to keep doing this. Please, take a bow, everybody. Adults learn at age 20, we’re fine. Smarter, wiser, fine.
1 Like
this threat actor severely affects at least two pillars of infosec, integrity and availability. the short term impact, at least, is a lot of people wasting their time trying to mitigate or nullify their malicious effects, instead of using their time to add new data or other type of valuable contributions. at mid term or long term, it will or could affect how people or at least new contributors collaborate with OSM, which is one of the intrinsic values of the project.
it affects the project as a whole, mining one of the key features that is was that any user could start adding data from the beginning and without limitations, because to protect the data from the threat, the project is forced to impose limitations to legitimate users. Some kind of user classification could be done, so each user is assigned to a level, and he can level up proving that he deserves it for the contributions he has made. but I think of me, getting started in a project like this, and it would be completely different from the OSM when i started +10 years ago.
4 Likes
Not only should this be considered a restriction for new users, it should be considered a restriction full stop.
The API ought to implement a hard reject for each of the following scenarios. Even legitimate mappers would not be doing them. It is surely unacceptable that our increasingly mature map allows continental-level changes to anything whatsoever.
-
Moving of any Node or Way beyond a relatively short distance. I cannot think of any scenario when an object should legitimately be movable more than a few km. Real world objects (perhaps except shipping routes) simply do not change like that; the API should therefore reflect that reality.
-
Drawing of any object (other than boundaries and shipping routes) over a very long distance. Nothing else legitimately spans these distances, surely.
-
Changesets whose bbox is larger than a continent (and certainly worldwide). Individual changes should never span continents, and the wiki already makes clear bboxes should be small, as otherwise changes are poorly-scrutinisable. Correctly-implemented mass-edits similarly are not supposed to be creating bboxes of large size for the same reason; scripting should be parcelling sensibly by area.
-
Any changes to boundaries (which are one of the few long-distance objects) by users with a low number of changesets. Even if legitimate, this is a skilled operation, with high risk of breakage, that no inexperienced member should be permitted to do.
Would any of these actually be difficult to implement in coding terms? Are there really any scenarios when they would interrupt legitimate mapping?
I would propose the numerical limits for the above could be set reasonably high (e.g. prevent continent-level stuff) to start with, and then gradually reduced as experience determines cases like genuinely long roads through rural / desert areas.
12 Likes
Changes to the map aren’t showing up for me except at the nearest zoom level, even with a force refresh. Is something going on?
If you’ve got an exception then we’ve got to have a pre-approved list of tags. Pre-approved tags in general goes against “any tags you like”. I think we also have long subsea cables, time zones etc. etc.
This prohibits any edit to the France relation, the main USA relation, the aforementioned timezones, anything that spans the anti-meridian and probably other tings.
I think the current rendering process marks tiles dirty when an edit affects them and puts them in a rendering queue. My gut instinct at the moment is that it would be good if a changeset bounding box over a certain size didn’t trigger tile re-rendering. That way the criss-crossing would only appear when another, more local, edit occurs and fewer overall problematic tiles are rendered overall. Of course this might just lead to spurious “local” edits too to boost visibility.
3 Likes
There will be unfortunate tradeoffs to almost any strict limit we impose on not-yet-trusted users. Done well, user limits can be a minor nuisance, akin to this forum’s restriction on posting more than three links in a post. (New users often chafe against that restriction, but it’s for a good cause.) The key is to design limits that well-meaning newbies can intuit and sympathize with, and offer recourse to those who feel unfairly hamstrung by these limits due to their unique circumstances.
In various recent threads about vandalism, I’ve been careful to advocate only for technical measures that operators can configure on the fly in response to current threats. Although general tools are more difficult to picture and probably more difficult to implement, I think it does more good than to brainstorm specific heuristics and their false positives and negatives on this forum. These vandals are likely sophisticated enough to know how to find this thread, not to mention any copycats who come along in the future.
6 Likes
I’m afraid the word is out, how to damage OSM. Maybe even toolkits. People will be doing this, even without “messages”, just for “fun”. They get the same gratification as mappers get: immediate results on OSM-based maps.
So far, I have not seen suggestions that can effectively stop this kind of vandalism. Probably the current crude MO of these “Long roads” attacks can be made harder or even impossible, but can those measures prevent other types of damage? As attackers get more knowledgeable, they will find other ways AND spread the word how to circumvent the measures.
Yes, I’m preaching doom, and I hope I’m proven wrong. Anyway, an essential part of fighting this will be to stop the instant gratification and its comet’s tail of lingering debris.
Any API restriction that is based on the current tagging of an object is trivial to circumvent.
A general API bounding box size check is likely to happen, there are a couple of minor difficulties and some disagreement exactly on how this should be done, but I expect there will be something in place rsn (at which point in time the vandal will simply change how his attacks works, but at least such a restriction is useful outside of the current issue).
7 Likes