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?
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)
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.
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.
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
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.
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.
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?
