Yes but your thread was (initially) more of the same and got (rightfully IMO) merged with this topic before it derailed at some point, talking about how to reduce vandalism and at that point, I’d have started a new one or (better yet) posted to How about limit new accounts.
5 Likes
To anyone concerned: this forum software (discourse) has the function of muting or ignoring a user.
E.g. if you are tired of those 1000 variations of the “don’t show a vandalized tile (or only show it for mapping feedback)” song that I may have been performing here or elsewhere (yes, I’m tired of that song as well), you might want to visit my forum profile where you’ll find the option to mute or ignore my replies.
In some situations this function really helps regaining your sanity.
This screenshot shows what it would look like:
3 Likes
The following is easy to misunderstand. I do not want to critize you or anyone else. Just invite you to look at the other side, by drawing a comparison:
If I go to a concert (does not matter whether paid or free of charge) and the solo pianist plays a wrong note (to take a drastic fully made-up example) and I write a critical review someplace, I am dead sure that the one answer I would not get is “can you play the piano? No? Then your critique is unqualified, please learn to play first”. Either you want outside views or you don’t.
To anyone concerned: this forum software (discourse) has the function of muting or ignoring a user.
I would note, however, that the “Forever” option in fact merely mutes the user for 1000 years, which will probably suffice in this topic but probably isn’t enough for the abandoned railways one.
23 Likes
I checked this morning, and the tile has been updated. Thank you.
Maybe rate limit changeset size? · Issue #4805 · openstreetmap/openstreetmap-website · GitHub - you can help in testing new countervandal tool (that bounding box one), it is now deployed for testing on the test server
3 Likes
Yes, but some forms of vandalism are much more problematic than others. Continental stuff is likely to be noticed by many. Renaming a POI in an obscure village is not. There is a whole scale between.
The point is that OSM needs to be able to prevent the stuff which is noticeable.
The situation with OSM is a little like HTML when it started. HTML1 was very loose - and that freedom was necessary, as use of RDF or other complex systems (equivalent to your point about ‘regulations’ in OSM) would have hampered growth. New ecosystems (HTML, OSM) upon their creation often need to adopt a liberal approach.
Fast forward a couple of decades, and that looseness starts to become problematic. In the case of the web browser technologies, specifications are increasingly stricter and require avoiding errors, but then tools have improved such that errors can be more easily prevented in the first place. Similarly, OSM is arguably well past the point where an anything-goes culture is acceptable in quite a number of situations, e.g. cross-continent moves, being able to rename countries, etc.
I’d be interested in further examples. Moving a floating dock seems to me a pretty obscure case that OSM ought not to rest entire policy on. As the current incident shows, there are far bigger problems to prevent actively than a dock having to be copy-pasted to a different area (where arguably it becomes a ‘new’ thing anyway - for instance its number in the new dock might be different).
1 Like
The question really is a question of core policy.
The current policy approach of the API appears to be to allow a reasonably anything-goes culture, even if the submitted data has logical impossibilities. The API allows a scenario of a road reaching most of the way across the world. We rely on every editor to implement ‘sensibleness’.
An alternative policy approach would be for the API increasingly to adopt a more conservative standpoint of disallowing things that are known to be logically impossible in the real world?
For instance, is there really a good reason why the database should accept data like:
-
Moving ways more than a few km; as discussed previously, real world objects do not move such distances, therefore the API ought to reflect that.
-
Allowing a highway to span excessive distances; no highway goes the distance that the recent incident implemented, therefore the API ought to reflect that.
-
A highway crossing a body of water without being marked as tunnel or bridge (or however you call those cases of it being just below the water, with fencing either side); no highway can do this in reality, therefore the API ought to reflect that.
-
Two highways crossing each other without either being marked as a tunnel or bridge, and without a connecting node; this is a physical impossibility, therefore the API ought to reflect that.
Over time, rules like these could be formalised, tuned, and implemented. I don’t accept these could not be defined clearly after discussion. There may be exceptions to the examples I’ve given but they are likely to be specific combinations of tags. One could envisage a repo full of policy JSON files for instance, with discussions and pull requests, that the API then pulls in over time.
A good start would be to look at the list of cases that KeepRight flags up and see whether any of those can be turned into formalised rules including exception scenarios but without any edge cases.
1 Like
This is not problematic though. ‘Any tags you like’ doesn’t get rendered, therefore vandalism of irregular tags becomes moot since no-one will see it anyway.
What matters is ‘pre-approved’ tags that everyone uses, e.g. highway. Even if not a formal spec, these are de-facto formal as of well over a decade ago.
This sounds to me expensive to compute. It also reminds me of a term “edge computing” – let the peripheral devices do the hard work.
Not a problem, as long as there is only a limited number of trusted editors pushing data updates.
Zero Trust is expensive.
I appreciate your confidence in your proposed solution, but I don’t think you’re fully considering the possibility that a persistent vandal may be paying attention to their target. Even if OSM had a more generic AbuseFilter-like system with more flexibility than your proposal, I still wouldn’t recommend holding public consultations about the specific rules to put in. You’d just shorten the effective lifespan of those heuristics. In fact, there is no public consultation, but you’re still brainstorming on their behalf – or on behalf of a less sophisticated copycat. Let’s just hope Discourse doesn’t decide to include yet another one of these posts in its tl;dr of this very long thread. If you have concrete ideas for countering an active vandal, reach out to the OWG or DWG.
2 Likes
So is:
- loss of reputation
- wasted effort
- participating in 500-message-long forum threads
12 Likes
This is exactly what we should be doing, and it’s called red teaming. Any organization with good cyber defense does this. You have to think like the bad guy, and come up with their possible exploits and prevent them before the attacks happen.
…which is exactly why:
If you want to stay ahead of the attackers, you have to identify the exploits behind closed doors. Otherwise you’re essentially granting a roadmap for attacks before you can patch the hole.
8 Likes
While I agree the first two points (because they’re most likely to be caused by vandals)…
That should be handled client-wise (they are) as these (alongside road-building crossings) are fairly small errors and happen not by malice but rather by error and could hurt more than it’s actually worth. For example, there are brook-road crossings where I believe the wrong tag have been chosen (i.e. the latter is falsely mapped as a bridge instead of the former as a tunnel) but it also requires some local knowledge to see which one is what to the point where some falsely use layer=-1 all to fix an error.
As far as I understand main blocker here is
- lack of specific design (where and how exactly in code this filtering would happen)
- lack of actually existing code
(this is not an official statement of any organisation, note “as far as I understand”)
1 Like
Implementing a multi layer protection strategy would also be useful. Adding filters, security or quality controls to the API, or imposing some limits could be one part of the solution against vandalism. The other part should deal with attacks that were successful against those first protections.
Could it be a solution to keep offering a standard layer service, just not like it is today, but instead a curated map in this standard layer, and also offer a new tile layer service, which should be used only for feedback and by mapping tools (only allowing whitelisted editors or QA tools)?
This curated layer should mitigate the vandalism OSM is receiving, as vandalism would not succeed in their goals (assuming the goal is to disrupt the standard tile), and seeing that they should just stop doing it.
Is it technically and economically viable to implement?
1 Like
Discussions like these are indeed red-teaming (firewalls, sandboxes, border router software sophistication, predictive vandalism specific defenses…) and indeed belong behind closed doors (not this forum).
I’m OK if this is a ?WG (something-or-other-that-hasn’t-been-named-yet Working Group). It’s effectively OSM’s Department of Defense. These people know who they are. These people may not (yet) know or do the next right things, or perhaps there are minor squabbles about what’s next before we lurch to another crisis). But they are talking amongst themselves. Some here and now, too, though I think they’d agree these conversations best take place behind closed doors. Think of it as a “cone of silence” (like in the Get Smart 1960s TV series), but one that actually works.
While I am not one to quench free speech, I also know that “loose lips sink ships.” And if we could get to 500 in this topic and everybody just zips it shut, I’d be overjoyed. We’ll soon see if I get my wish.
1 Like
I think it is a good idea, there is already a separate topic for it: