Discouraging URLs in wiki:symbol?


a group of Outdoors contributors is preparing proposed additions to Waymarkedtrails so as to support symbols defined through the wiki:symbol tag. We are hitting security issues and would like to propose to restrain the use of this tag, and at least to leave URLs out.

The wiki:symbol tag is aimed at indicating that the symbol used for a given route must be fetched in SVG format from the OSM wiki. That is very useful for symbols that can’t be approximated with the mini-language offered by osmc:symbol. Other uses of wiki:symbol have been made, including references to PNG files from the OSM wiki, and full fledged URLs to, e.g. Wikipedia.

Loading and rendering arbitrary SVG files from arbitrary URLs can be a security weakness if the rendering app does not deactivate the execution of scripts found in SVG files.

What do you guys say to making this simple and discouraging URLs from appearing in this tag, and apps from supporting them?

1 Like

For a bit of context:

Read more:


Are SVG-files uploaded to the OSM Wiki safe, or can they be used to exploiting scripting injection as well?


I can’t see that they are safer by construction, but we can check them.

If so, then I don’t see how officially discouraging URLs is helping with this attack vector :thinking:

OSM Wiki and Wikipedia/Commons (especially Commons) are less likely to be affected by this problem as these files are at least sort-of-monitored.

Also, less likely to be legally problematic (but it is less likely to be problem with wiki:symbol)

OSM Wiki and Wikipedia/Commons are more likely to have machine-readable license info (some files may require attribution, though again wiki:symbol are far less affected by this)

If we want to allow two sources for ‘reviewed’ SVG files without having full URLs then we may need two tags, e.g wiki:symbol and wikimedia:symbol?

Please no.

If a file is not on the OSM Wiki, it “automagically” redirected to Wikimedia Commons.
So for me, wiki:symbol tag is enough


Incidentally, the most common wiki:symbol value (39%; the next most common value at just 7%) refers to File:Symbol SWV Örtlicher Weg.svg - OpenStreetMap Wiki, which exists on the OSM Wiki as a duplicate of File:Symbol SWV Örtlicher Weg.svg - Wikimedia Commons on Wikimedia Commons. I wonder if it was uploaded before the wiki was set up to automatically fall back to Commons.

By default, MediaWiki rejects SVG files that contain JavaScript, HTML, or internal links. Neither the OSM Wiki nor Wikimedia Commons have overridden this default, so there is a measure of safety. However, it remains possible to craft an SVG file that exploits a security vulnerability in an SVG renderer. The wiki communities are less likely to detect this issue because we primarily rely on MediaWiki’s server-side rasterization. If this concerns you, you can mitigate the issue by asking the MediaWiki API for URLs to a PNG thumbnail at the desired width and/or height.

Note that semantic information such as network and cycle_network is in some respects more important than wiki:symbol. These image URLs are very literally tagging for the renderer, in that a different renderer might need a slightly different image, for example with a slightly different color scheme or simplified shapes that are more legible at certain sizes. At best, it’s a last resort when semantically tagging an obscure symbol is very unlikely to yield renderer support.

1 Like

Good idea, thx. We’ll look into it.

I guess it is up to the renderer to decide which information is more important between text tags and image tags. The “pure text” tag symbol is more or less useless for any purpose I know, for instance.


Agreed. In fact, many occurrences of symbol on route relations are actually outdated Wikimedia Commons image URLs. The U.S. community had tried to standardize around that practice many years ago, but we abandoned the idea by 2012, after we set out to build a shield renderer and realized what a logistical and security nightmare it would be. Instead, we focused on a complex hierarchy of network values.

cycle_network exists because we needed something like network on road routes, with more expressiveness than osmc:symbol and more predictability than wiki:symbol but without clashing with values like network=rcn. Naming it cycle_network turned out to be a short-sighted decision, since it does nothing for hiking routes. There may be a benefit in promoting a semantic tagging scheme that can cover any kind of route.

Slowly drifting off-topic here, but this is the first time I hear about cycle_network, after 2-3 years of active contributing on (mostly) hiking routes and (marginally) other types of outdoors route! I know a fair bit about node networks and their cycling instances, especially in Belgium and the Netherlands. Could it be a case of independent invention of a similar concept?

If yes, I’d be more than happy to discuss in another thread how the two systems could converge. In all honesty, I relate more to the idea that network points to objects rather than to the idea that it has an encoded value that tells if this is a small or a long route, more or less.

1 Like

An example from a croatian thread.
They remove osmc:symbol=red:white:red_circle and add symbol=Knafelčeva markacija but even with a good translator, I can’t understand the value :cry:

Capture d’écran 2023-08-24 à 11.45.11

I think this is an interesting point that should discuss in a separate thread.
Here in France we want to display the “real” symbol so everybody could see it on the field and on the map.
I understand that some (at least in the USA) use the symbol for it’s semantic aspect (i.e. this a “regional” cycling route that form a loop).
Here in France use semantic tags link network and network:type=node_network.

Is there a security benefit in hosting all symbols on the OSM wiki instead of Wikimedia commons?

Given that files on OSM Wiki are patrolled and reviewed at lower rate and effectiveness than Commons, opposite if true if any such difference exists.

Can we, however, consider that is the wikis’ responsibility to scan svg for scripts rather than that of clients?

At least osmc:symbol allows renderers and routers to vary the pixels according to their specific needs. But wiki:symbol affords no such flexibility: you either use the image verbatim, whatever it is, or ignore the tag and leave the route unmarked. It could be a grainy JPEG with an unsightly white background or an SVG that confusingly blends in with the color for waterways, but the renderer has no control over it.

What’s more, even if the developer cares enough to design a better icon for that route in the context of their map, all they can do is add a special case that overrides a particular image name on the wiki, rather than anything intrinsic to the route. If a mapper uploads a different image they like better, for example converting the JPEG to a PNG but with the same color issues, this override stops working.

That’s effectively what’s happening now because both wikis reject SVGs containing scripts. However, both wikis also accept other file types that, when viewed raw, could cause problems. For example, MediaWiki is unable to guarantee that a PDF is free of security issues. (Yes, PDF is also a vector image format. In fact, it’s the main vector image format on Apple platforms.) But even a specially crafted PNG or JPEG can exploit security issues in some viewers, which is why it’s prudent to rely on MediaWiki’s server-side thumbnails.

1 Like

Problem in Croatia was that users were changing the osmc:symbol=* tag into some strange constructs which would help in showing just the ref=* in the Waymarked Trails renderer. The osmc:symbol=* tag isn’t very useful in Croatia because 95% or more trails are marked with the same red:white:red_circle blaze (which is called Knafelčeva markacija, or Knafelc blaze in English). But on Waymarked trails, if there is a osmc:symbol=* tag on a relation, then the ref=* isn’t shown. So we decided to delete the osmc:symbol=* tag, and add just symbol=Knafelčeva markacija.

After that we agreed to replace symbol=Knafelčeva markacija to symbol=red circle with white dot in the middle because that’s the standard value i found on taginfo. We will also add wiki:symbol=Markacija.svg

If the issue on Waymarked Trails is solved, we will come back to osmc:symbol=red:white:red_circle, and will probably delete the wiki:symbol=* tag. Is there a place where the Waymarked Trails development is discussed?

We have set up an experimental instance of Waymarkedtrails, in cooperation with Sarah. Maybe we could test options together?

Currently, as stated above, I am working on wiki:symbol. But we can explore other topics.