Wikimedia once ran a free tile service but pulled out because it was too expensive. Now Wikimedia is an institution that has 250 million at the banks and an annual budget of about 150m if I remember correctly.
OSMF is run on a budget of less than a million a year and in 2024 could not meet the funding requirements by some of the working groups as it did not have the funds. The Fastly sponsoring is dwarfing the overall OSMF budget. If Fastly would pull out in sponsoring OSMF, no serious business continuity plans for the OSMF and tile.osm.org are available at the moment.
Just switching to vector tiles also does not help. If e.g. ourmap.us would rack up the traffic tile.osm.org has, the AWS egress costs (plus the than needed infrastructure to serve that egress computationally) would be six figures per month.
The OSM Carto layer has been used for much more than OSM map QA for its entire existence. It is, de facto, used by end users visiting osm.org for non-mapping related purposes and to a not insignificant extent in third party sites. I think that’s beneficial to OSM overall and I see no reason to change the current practice in response to the vandalism incident.
As pointed out by @julcnx, slower updates don’t solve the problem. Vandalism would be less likely to make it into a rarely updated map, but would stay visible for longer if it does – at least without some additional filtering mechanism or manual intervention.
Pushing the problem to third parties has very similar issues. Unless we can somehow prevent bad data from reaching data consumers (by stopping it before it even makes it into the OSM database or by having separate sanitized data releases/diff streams), this doesn’t seem like it would help with the vandalism problem at all.
I’m sorry but this sounds like “let’s close our eyes and everything is good”. But maybe I misunderstood you.
Currently there are several problems:
a) the osm standard layer as served by tile.osm.org is a big megaphone for anyone that wants to do harm. By that, it also has the ability to severely harm OSMs reputation.
b) Volunteers at working groups like the DWG are loosing patience in getting “service” tickets they should not get at all. How do we we handle that? How to tell people that OSM is not a service?
c) with the fiftyfold increase of traffic at tile.osm.org since the Fastly deal there is no plan b) if Fastly would pull out. All the old cdn servers got mostly decommissioned so even to serve just the ~ 5% of traffic that would be needed internally in the OSM ecosphere as a mapper feedback could not be provided so easily (maybe the tilerenderers would be able to handle this directly). Also the extra strain the traffic at tile.osm.org has on rendering servers also hindered a faster cleanup on tiles (now this is sth. where Tom is developing some brilliant analysis and mitigation, but it does only help post-incident, not pre-incident as the next vandalism act will be different). In general, even if Fastly never pulls out, more traffic at tile.osm.org, even if it is free through the Fastly sponsoring, also means more secondary costs in higher loads on tile rendering but also in higher loads on tickets created at several working groups (and I do think that some of those tickets are hilariously impertinent if I just go by an example at the OSM US Slack.). So a free service just essentially means that someone else is paying the price and in this case (besides the VC and investors at Fastly) it is literally also @SomeoneElse nerves (and those of many more that care deeply about OSM).
Where appropriate, I have been pointing people at that policy, especially in cases where third-party map suppliers and their customers have been contacting the DWG and “demanding that we fix the problem”.
I’ve also (of course) linked to some of the summary posts in the other thread that explains why they are seeing what they are seeing. Most people don’t understand how web browsers and web servers work, just that they do - and it’s sometimes difficult to communicate that the problem tiles likely only exist in their own web browser’s cache.
I’ve also referred people to other helpful resources explaining how they can use OSM data in different ways, in a similar way to my answers in the other thread and elsewhere.
The problem is that while I do think the tile usage policy is clear (ok, it better should state: “No service and support whatsoever. You are on your own in using this” instead of “No SLA” as a SLA is sth. hugely different) this is not the same that e.g. is communicated by other working groups. It is also not enforced in any way at the VSL level at Fastly (if they still use VSL). I rather have the feeling that while you still try to enforce this policy,
you do not get any support for enforcing this by other levels of the OSM ecosphere as people think: hey, Fastly handles the traffic, why should we care.
Plus: and this is another problem: telling endusers to use e.g. a browser reload (F5 etc.) of vandalised tiles will help at www.openstreetmap.org most of the times but not on third party websites and apps as those requests from third parties are treated differently on the cdn level (yes, this seems to be baked into the VSL as e.g. @ikonor showed in his analysis). This is also the reason (besides the overloading of rendering servers with 60GB filesize lists of dirty tiles to work through) that while the vandalism was only in the db for ~15min we still see complaints coming in today here at the community forums and elsewhere.
OpenStreetMap Carto is a style and is not designed primarily as “an important feedback mechanism for mappers”. This is one of four purposes, with no ranking of those purposes.
The standard tile layer, which is what the OSMF hosts, is around for a few reasons, but in my view the primary one is osm.org needs a map.
We have purchased one tile server in the last couple years, and it was to replace a server about 8-10 years old. I don’t have the asset register handy, but I recall it was about 4k EUR.
The biggest change in the last year is we changed how tile expiry was done in response to mapper complaints about not seeing updates for some classes of edits like relation-only edits.
This risk was noted in the OWG budget, so we are aware of it. If Fastly gave us notice that we would be leaving their Fast Forward program we would have to change our usage policy. We consider this a low risk.
I do not see anyone characterizing the number of support requests the OWG gets as heavy. They’re also some of the easy ones to deal with as the same response applies for all of them. I don’t know what the total time spent on them is, but I’ve certainly spent more time finding the correct figures above than I expect the OWG has replying to emails about this.
The tile usage policy is enforced at the CDN. The operational problems come from scrapers, not from websites or apps displaying tiles on-demand.
The idea would rather be, some kind of algorithm calculates a quality index or some other kind of flag of each diff. While applying diffs, I could halt my progress, when a different is below my standard and start applying all diff from then on when the next diff exists, which in beyond my standard.
For example above mentioned algorithm would detect diff_1 contains CS_1 which is detected as vandalism. I would stop applying diff-1 until diff_n-1. diff_n contains the reverted of CS_1. Now I can start applying diff_1 until diff_n.
I would absolutely describe “continuing to serve tiles containing known slurs against an individual many days after that has been removed from the OSM data” as “an operational problem”.
The various feeds are public, so you’re more than welcome to give that a go as some sort of “proof of concept”. An example diff is here (that just happened to be the latest one as I wrote this). You’re welcome to try and define a bunch of things that you can know from a diff and train even a simple Bayesian model on that as an input, and also look at “potentially negative community interactions” (blocks, unanswered comments, future reverts) as result data.
This is what a lot of downstream processors of osm data diffs do and that is why you don’t see the vandalism in third party produced maps or applications based on osm data by the processors that do this.
But you cannot do this for the Standard layer published via tile.openstreetmap.org as this one is build for mapper feedback - tile.osm.org is a tool for fast feedback for the osm mapping community and doing a tremendous job at this.
The problem is that the same layer is handed out massively as well to third parties to display maps at third party sites or apps. And for this it is the wrong tool and through this wrong use of the tool it is a massive amplifier for any vandalism actors.
And this is - besides the fact that we as a community should do anything we can to support community members that are targeted by those slurs - even bigger than one might think (esp. with plans of moving the OSMF into the EU but the legal setting is probably similar in the UK) as this would also imply legal obligations for a publisher of user generated content (and practically, OSM is exactly this) to immediately stop the publication of harmful content (hate speech = the vandalism slurs) as those may in it’s scope fall under criminal law in regard to defamation and false criminal accusations and as such must not be published anymore by an ugc publisher as soon as the publisher becomes aware of this. (For further reading: Digital Services Act - Wikipedia - OSM might be happy atm to not have received a vlops letter yet - as did Wikipedia - but with the growth at tile.osm.org usage this might happen in the future.)
Which also implies, as @SimonPoole rightly already stated elsewhere, that those kind of vandalism acts we have seen in April and May should not only be reverted but redacted as well.
It might also be worthwhile to think about stopping tile delivery via tile.osm.org to third parties for as long as those kind of slurs are in the cdn caches and e.g. only serve the tiles in these kinds of occasions to those working on reverting and redacting the data or only at www.osm.org or JOSM etc. with a warning attached. And then resume the delivery of tiles via tile.osm.org to third party website/apps etc. when the rendering backends are not overwhelmed anymore and all cdn caches are “clean” again (this would also be in line with the tile usage policy that practically says: “no guarantee on delivery” and “delivery may stop anytime”).
Isn’t OpenStreetMap primarily about the data? There are numerous styles available within the ecosystem. Why not showcase those instead and limit tile.osm.org to mapping editing software as “an important feedback mechanism”? While this won’t eliminate vandalism, it would free up substantial OSMF resources to address more critical issues.
Mappers also receive feedback by looking at the map outside of an editor. I can’t be the only one who habitually force-reloads the main map after saving my changeset, to get that instant gratification. On the other hand, I’ve rarely if ever needed to load the rendered tiles in an editor – that’s for aerial imagery and other external sources.
Openstreetmap may well be about the data as far as many here are concerned. However, has anyone asked those who ‘just’ use it as a map, or unknowingly as a route planner? I do wonder if for many users,
the Openstreetmap raster map IS Openstreetmap? Has there been much market research?
From the other topic, but I think it better belongs here.
I do not think that is another idea, in both cases I see a need for a curated/clean/release stream of diff’s and planet files etc. that third parties can use to draw tiles. Or does somebody thinks that is no responsibility for OSM and providing such curated/clean/release stream of diff’s and planet files should also be done by third parties.
I see also a need for a unfiltered “dev”/“qa” stream for mappers to see what they are doing and to detect vandalism that ideally is not in the curated/clean/release stream.
Fine to me if OSM does not provide tiles for that curated/clean/release stream but something will be needed so they do not use the unfiltered “dev”/“qa” stream instead as they are doing now.
Instead of two different streams, wouldn’t it be sufficient to have an API endpoint that says: diff 990 is known to (= has been reported by DWG to) contain a bad case of vandalism, this wasn’t reverted until diff 998, so don’t render tiles based on a database that hasn’t had diff 998 applied yet?
Of course this only helps data consumers that delay replication.
I think the standard tile layer is a huge part of what makes OSM succesful, it is ‘free’ advertising on a lot of sites.
I do think it is useful to have separate tile servers for mappers (any application where you can log in using OSM) and background map users.
For the seperate layer:
If there is a DWG edit on this tile between 30 and 60 minutes ago, use all changesets up to the most recent DWG edit on this tile (not necessarily in that window)
Otherwise all changesets up to an hour ago.
If the DWG fixes all vandalism within half an hour, it should not appear in the render-on-request tiles.
This is because the DWG edit will shift into the 30-60 minute window before the vandalism edit goes outside the 60 minute window. Therefore both the DWG and vandalism changeset are applied both or neither.
The 30 minute window is there to give DWG the option to revert with multiple changesets.
Otherwise we might get vandalism - partial revert = partial vandalism.
I don’t know how technically feasible this is, as some changesets need to be applied based on which tile is rendered.
How technically plausible this is** depends on the granularity you want. If you want monthly and don’t want OSM buildings, then Facebook has already got you covered (at least for now). Anyone with half an ear to the forums and the global block list could probably pick a time weekly, or even daily, and say “OSM data is mostly clear at this time”. What is much harder to do is to provide a feed without any vandalism in it.
** and I’m writing this without saying whether this is a good idea or not.
Please be careful as the planet.osm.pbf published by Daylight is not pure QA-controlled OSM data anymore. It once was but it got additions that will have the data differ in comparison to pure OSM data (and yes, I’m talking about the planet.osm.pbf and not the additions like ml-buildings, fb-roads, etc.). And depending on what you want you might have to do a QA again on the daylight planet.osm.pbf in regard to their additions.
A diary entry explaining what the actual differences are now would be really useful. I suspect a number that said “X% of Overture data is OSM” would also be informative.
When I last looked at in in detail (some months ago now) I was surprised at the lack of difference (beyond suppressing certain types of data altogether).