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.
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?
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
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
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?
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.
Note that semantic information such as
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.
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
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.
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
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?
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
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
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.