The "OSM Standard tile layer" looks wrong (white lines, abusive comments etc.)

The vandalism has been repaired. There are still a few map tiles that have not yet been re-rendered and show the lines (streets).
Please clear your browser cache with Shift-F5 / Ctrl-F5 (use the key combinations several times), this will request new, updated map tiles.

Thanks - does that mean that if someone sees a problem now it’s definitely just in local cache?

We’re still getting DWG reports with screenshots coming in - we’d like to be able to say “just do a force refresh and the problem will go away” (but obviously don’t want to say that if that isn’t 100% true).

Hard to say that as regular mapper without access to servers, maybe CDN is still poisoned?

But refreshing browser cache often helps and typical person cannot do more.

Even after OSM CDN cache will be fixed it is possible that they may be using OSM map from somewhere else, not from OSMF hosted tileserver.

This seems to be the current go-to-thread for current abuses. Maybe make the title more understandable for non-technical people as well?

map on osm.org looks wrong (white lines, absuive comments, …) - OSM Standard tile layer hacked?

Or something like that?

1 Like

I’ve edited the title in line with that suggestion.

2 Likes

What I did was set the tile.openstreetmap.org CDN to not consider any tiles before Wed Apr 10 2024 05:00:00 GMT (time after revert) as valid and instead retrieve new tiles. Light version of a shift-F5 or similar.

The render backend will then normally supply a fresh tile rendered after Wed Apr 10 2024 05:00:00 GMT, but if the render backend is overloaded / slow it might supply an older tile back to the CDN.

Most of the tiles with vandalism were for tiles render before Wed Apr 10 2024 05:00:00 GMT. If a tile with vandalism was viewed then it may still be in local browser cache. The result is, if user sees vandalism then ctrl-F5 or shift-F5 is best route for them to try get a fresh non-cached tile without vandalism.

2 Likes

I found this (zoom +1) : Feissons sur salins | OpenStreetMap

Moderation: Map image with inappropriate and offensive street names removed

1 Like

As described above, the actual data has probably already been fixed, but it’d be great if you could run through the steps above just to make sure?

There’s a (fairly technical) description of what the process is between data being fixed and you looking at a map above here, and according to this post above the people in charge of the displayed maps are trying to fix the problem that you are seeing.

1 Like

Most of these are/were horrible, but I must admit the “Andy Townsend is butch” one makes me laugh. It’s nearly the etymology of Andy, and usually quite flattering besides.

2 Likes

Hey Andy, whether you’ve been called worse or not, I imagine it’s still a horrible thing to experience. So, just want to say thanks for what you do.

26 Likes

The day before got the weekly community activity summary. The “I’ve been called worse” reply was listed as a popular post. :no_mouth:

I made a visualization showing the majority (788) of the vandalized ways, derived from a revert changeset (149801026):

At z13:

A single way:

Existing ways got their node refs replaced by some random node ids from all over the world.

In total, there were three user accounts involved, with 46 changesets and 1737 changes.

The vandalism started on April 10 at 2am UTC. The revert by mavl started one hour later and was done in 25 minutes (except some broken relations).

22 Likes

That’s the important bit - the data was fixed very quickly (with the exception of a few problems related to well-meaning people who didn’t understand what was happening doing individual single-changeset reverts using online revert tools). Also, the limits on what “new” accounts can do worked well.

All of the discussion above was about people seeing things in local cache (mostly) or from the CDN (less often, but now fixed).

9 Likes

That’s amazing!
It’s like a Picasso from outa space, drawn by Jean-Luc Picard himself in this case.

2 Likes

It’s a shame that a lot of valuable time has to be spent to clean this scrap up, but it’s good to know that there are people behind OSM able to handle such cases fast and effectively. Thanks to everybody helping to clean up the mess!

9 Likes

Hi, just checking in to see if people still don’t think we have a cybersecurity problem :popcorn:

I note that a couple petty vandals in a few minutes with sock puppet accounts can waste a lot of time by many other people. As usual, this will not be a wake-up call for the project to understand that they need to think a lot harder about things like user trust and data integrity.

I am thankful for folks that clean this stuff up, but I resent that they are wasting their time on it rather than pursuing more fruitful pursuits.

8 Likes

I’ve no doubt people did the best they could with the tools available to them, but it seems a bit of a stretch to call the cleanup “fast and effective”. Some users were still seeing the vandalism around a week after it occurred (?).

I’m sure this sort of thing is already being considered, but perhaps we need a “cache busting” mechanism that can force clients to request fresh tiles in this kind of situation?

1 Like

In my opinion, cleaning the database from the effects of vandalism is not wasted time.

4 Likes

So - what parts of how OSM works would you change, in areas such as:

  • What people need to provide when creating a “new account”?
  • Assuming they’ve cleared that hurdle, how much editing (and where) they’re allowed to do and in what period of time?
1 Like

I’ve said on several occasions that what the project needs is a cybersecurity professional. Someone with expertise in protecting digital assets. While our use case is fairly unique in the scheme of things, it is no less important to consider cybersecurity protections and how we might protect what’s important to the project. It’s naive to think that those of us who casually dabble in security at the minimal level needed to write code and launch websites are equipped to correctly assess and identify the best controls that balance protection with access. I put myself in that category as someone who knows just enough about Internet security to operate a public-facing web site, but definitely not enough to secure a popular and complex global enterprise.

So with that caveat,

I think the way it is now, where users can essentially spin up accounts anonymously is fine, however, those new accounts should live in a highly restricted sandbox. In that sandbox, new users should be allowed to do the typical types of edits that new users might make. Namely, low volume and geographically compact.

I think we should let new accounts out of that sandbox when they do certain things. Link a cell phone or authenticate with two-factor authentication? Your trust goes up. Account ages and you make edits for awhile? Your trust goes up. More trust=looser restrictions. This is a general principle, not a recipe.

There is probably some need for a (presently non-existing) feature where users can crowd-source the trust factor in a neutral way. Getting lots of :+1: from highly trusted users? The shackles come off faster.

You’re asking good questions but I think it’s a trap to think that there’s a simple formula on how to do this. These days, people get college degrees in cyber security yet somehow we don’t seem to have anyone around on the project applying that expertise to our rampant vandalism problem.

I can do my taxes, but that doesn’t qualify me to audit a company’s financial statements. I can brew a cup of coffee in the morning, but that doesn’t qualify me to hire baristas and open a coffee shop. I can dig a hole in the ground but it doesn’t make me an archaeologist. Likewise, I can write code, but that doesn’t make me competent in designing a cyber security plan for a major global project. But I can certainly recognize that we have a problem.

I think our failing here is thinking that it’s easy and not asking for the right expertise.

13 Likes