Since the recent (estimated: two days ago) update to version 1.7.1 (“Add basic browser and platform info to changeset tags (#2559, #2449)”) of our editor iD it publicly, permanently and silently logs operating system, browser and language details (+ more) for every user, for every edit by adding those tags to a changeset (example values follow; or see /history and pick a random one until you get one by iD):

browser = Chrome 37.0
locale = it-IT
platform = Linux

• I could imagine good uses for this big pile of data … e.g. * it may help in debugging the editor * one could potentially make nice statistics of our user base in total from this data (from a dump), or * use it for quality assurance heuristics (e.g. it may be more suspicious if a foreign language user edits at a specific place),
• But I also could imagine bad uses for this big pile of data: * it also enables everybody to create detailed statistics about a single user’s browser update habits and browser name * or operating system switching over time. Which all is not why people contribute to OSM. * Language, Browser name, exact version and operating system name may make a contributor identifiable among a big group of persons, especially if some of those details are not very usual (think of someone speaking Lithuanian using Epiphany under Linux and editing in an Argentinian city – the expectation of only contributing under a pseudonym user name is quickly broken. * Furthermore, the users are not even asked (and also not even notified) if they agree to permanently, publicly publish this private data. The iD editor just asks for the changeset comment. All other tags are added automatically and silently. This breaks the Privacy Policy (“All edits made to the map are recorded in the database with the user ID of the user making the change, and a timestamp at the time of change upload.”) if we assume that the users do not intentionally choose this editor and are aware that it does whatever things. Assuming that every contributor finds the small entry in the iD release notes at github is totally unreasonable. I only noticed the problem because I was viewing other contributors’ changesets. * The users have practically no chance to ever remove this information about them.

In the linked issues (found via the release comments) 2559 and 2449 I see no rationale at all why all this data needs to be saved 1. publicly, 2 permanently and 3. silently. Just reasons why the data could be useful are mentioned (similar to my ideas above) but not why the privacy and trust of our contributors needs to be hurt in this extent. Note: I have messaged the three involved developers/issue reporters via OSM mail about this post.

I think this recent change is really over the top and is doing harm, because to outsiders our project may seem as if it does not care about our contributors’ privacy and fools new users by silently publishing information about them. I would hate it if, in the future, I would need to pass along a big warning about privacy when I try to attract new contributors.

Of course a simple workaround is to use another editor, e.g. JOSM, which I suggest doing for other reasons anyway.

Please, let’s quickly remove this personal data canon before even more data is collected. By the way, I am intentionally not writing in a hidden bug tracker to make everybody aware of the problem and hopefully sensitise the developers a bit.

Update: on 16th May (15 days after writing this diary entry) iD’s main code was modified and browser (browser name), version (browser version), platform (operating system) were removed again. Still, the locale (user’s language setting) and host (the website at which iD is running at) are silently saved into the changeset tags. See https://github.com/openstreetmap/iD/pull/2643

Likely it will take some days until this new, partly fixed iD version appears on osm.org.

Constanze Kurz schreibt im FAZ.net-Feuilleton über historische Entwicklung, aktuellen Stand und Zukunft der digitalen Kartendienste: Wenn jeder Weg ein Weg zum Profit ist (21.12.2012).

OpenStreetMap wird in den letzten beiden Absätzen als unabhängige, beeindruckend präzise Alternative zu den voraussichtlich mit (als solchen nicht immer erkennbaren) Werbeeinträgen angereicherten, kommerziellen Kartendiensten vorgestellt. OpenStreetMap beziehungsweise seinen Beitragenden wird Engagement und Sorgfalt zugutegehalten, der Detailreichtum als die kommerziellen Angebote manchmal sogar übertreffend beschrieben und die verschiedenen Charakteristika der auf OpenStreetMap aufbauenden Angebote kurz genannt.

Um immer automatisiert die neuesten Vorgänge/Änderungen in meinem bevorzugt beobachteten Bereich (beispielsweise mein Heimatlandkreis) zu sehen, verfolge ich einige RSS-Feeds. Seit ein paar Wochen kam ein neues nützliches Werkzeug hinzu: “Who did it?”. Ich habe eine kurze Beschreibung in meinen Artikel Nützliche Werkzeuge (Überprüfung, Fehler, neueste Änderungen) integriert. Kommentare sind dort auch gern gesehen.

English: Title: Useful tools (quality review, errors, latest changes). A translation of the text is not yet available, if positive feedback is received I will publish a translation. You can use the likely awful automatic translation by big G to roughly get the meaning/content.

Deutsch: folgend.

Es existieren einige nette Werkzeuge, die ich mir für die OSM-Arbeit zusammengesucht habe und sehr praktisch finde. Praktisch sowohl für das Nachbessern, als auch Planen von Bearbeitungen (wo ist etwas zu tun?) und Begehungen (survey) vor Ort. Ich möchte hier gern möglichst einfach darstellen, was es so Nützliches gibt, da sicher einige Leser jene noch nicht kennen.

Automatische Überprüfungswerkzeuge

Diese Systeme prüfen die OSM-Daten auf Unstimmigkeiten sowie potenzielle Probleme und geben auch fixme-Markierungen (“hier ist etwas zu tun”) aus. Unter anderem gibt es hier: unverbundene Wege, Tippfehler, Tags vergessen, … Im Wiki steht viel zu Qualitätssicherungswerkzeugen, vieles ist aber veraltet oder für mich nicht sehr nützlich.

OSMi

OSMi bietet verschiedene Ebenen (links oben auswählbar) die verschiedene Kategorien potenzieller Probleme darstellen.

Keep Right

Keep Right (Karte, Beschreibung, Wiki) funktioniert recht ähnlich zu OSMi, man kann aber alle Kategorien gleichzeitig darstellen und vor allem sind es andere Kategorien. Beide Werkzeuge ergänzen sich gut.

• Eine ausführliche Anleitung im Wiki wurde erstellt.
• Wenn man einen Fehler behoben hat, jenen bitte als “vorübergehend ignorieren” markieren, damit der Fehler ausgeblendet wird, bis das nächste Keepright-Datenbankupdate gemacht wird. Man kann auch zusätzlich kurz einen Kommentar hinterlassen, was/wie man behoben hat.
• Beim Benutzen der Kommentarfunktion (Textfeld) am besten dem eigenen Kommentar Benutzername und Datum anfügen, sonst weiß keiner, wer was geschrieben hat und andere Benutzer können nicht kontaktieren, falls nötig.
• Eine gpx-Datei eines Bereiches (der aktuelle Kartenausschnitt; Anzahlbeschränkung beachten!) zum Import der Fehler als POIs auf ein GPS-Gerät ist nützlich zum effizienten Begehen vor Ort. So kann man unterwegs alle naheliegenden Problemstellen “in einem Aufwasch” besichtigen. Der Link zur gpx-Datei ist links unten auf der Keepright-Seite. Die gpx-Datei rnthält die aktuell in Keepright ausgewählten Fehlerkategorien. Auch kann man so einfach in der OSM-Datenbank für sich und andere markieren, wo etwas zu tun ist (mit fixme) und sich die Liste dann vor einer Begehung (oder einem Ausflug) auf das GPS-Gerät oder Smartphone laden, um vor Ort bei allen Fehlern nachzusehen, die man am heimischen PC nicht lösen konnte (zum Beispiel fehlende tracktypes bei Waldwegen oder sonstige Fehler, wo eine Besichtigung vor Ort nötig ist). Sinnvoll ist es vor dem Herunterladen der gpx-Datei (darauf achten die Checkboxen der bereits ignorierten Fehler zu deaktivieren!) die Fehler darauf zu überprüfen, ob etwas direkt am PC gelöst werden kann. Ich verwende die gpx-Funktion oft, wenn ich zum Beispiel in Bing sehe, dass irgendwo ein Weg sein könnte: Dann markiere ich den einem existierenden Weg nahen potenziellen Abzweigpunkt beispielsweise mit einem Tag “fixme=Survey bitte: Hier geht in Richtung Südwest ein Weg ab”. Zu beachten ist, dass die Keepright-Datenbank nur alle paar Tage (ca. vier) aktualisiert wird (Datum steht unten rechts auf der Kartenwebseite von Keepright).

Fehlermeldesysteme

• Notes bietet eine einfache Möglichkeit für jedermann Fehler zu melden, auch wenn man nicht bei OSM registriert ist (und sich nicht einarbeiten möchte). Notes ist das eigene Fehlermeldesystem von OpenStreetMap.
• Mapdust funktioniert relativ ähnlich. Bei Mapdust laufen auch Fehlermeldungen von Benutzern der skobbler/ForeverMap/scout-Naviapp (benutzt OSM-Kartendaten) auf. Oft sind sie leider nicht sehr nützlich für uns, aber doch gelegentlich schon! Hier kann man auch Fehler kommentieren und, sobald geschehen, als erledigt markieren. So können wir relativ einfach Außenstehenden unsere Schnelligkeit demonstrieren – was vielleicht dann auch die Fehlermelder anspornt, sich vielleicht selbst bei OSM direkt zu beteiligen. Hoffen wir mal, dass die Naviapps ihre Karten oft genug updaten…
• Siehe zu Notes und Mapdust auch die RSS-Feeds unten.

Auf dem Laufenden bleiben

RSS-Feeds

Um immer automatisiert die neuesten Vorgänge/Änderungen in meinem bevorzugt beobachteten Bereich (beispielsweise mein Heimatlandkreis) zu sehen, verfolge ich einige RSS-Feeds. Siehe zum Thema RSS Wikipedia und konkret OSM-Wiki: “RSS”. RSS-Feeds kann man mit einer Vielzahl von Programmen betrachten; ich verwende Mozilla Thunderbird, der eine Darstellung der RSS-Feed-Einträge wie E-Mails bietet. Anmerkung: Man sollte verantwortungsvoll die Server belasten, also nicht die RSS-Feeds alle 10 Minuten automatisch abrufen lassen, alle sechs Stunden reicht.

User tyr hat einen RSS-URL-Generator osm-qa-feeds gebaut, der ermöglicht, dass man nur einmal und bequem einen Bereich auswählen muss.

• Änderungen in einem Bereich (OSM.org): Der RSS-Link ist u.a. ganz unten auf der OSM-Chronikseite (Links am Ende dieses Absatzes). Leider verwenden einige Benutzer (allen voran ‘der Bot wheelmap_visitor von wheelmap.org) riesige Bereiche (bounding box) für ihre Änderungssätze, sodass sie jegliche Chronikansicht vollspammen, obwohl sie gar nichts in dem Bereich änderten. Als Filter verwende ich daher positron96’s RSS History Filter, der jene Weltänderungen herausfiltert. Als Latitude-Longitude-Limit-Parameter (alles mit größeren Ausmaßen fliegt raus) verwende ich 1.8 und 3.5 (das ist kleiner als Bundeslandebene). Beispiellinks: Chronik, Chronik als RSS, gefilterte Chronik als RSS
• Änderungen in einem Bereich (Who did it?): Who did it? (WDI) ermöglicht (zusätzlich zur Webansicht), dass man einen Bereich definiert, der beobachtet werden soll. Im Unterschied zur vorhergehenden OSM.org-Funktion basiert WDI nur auf Knotenpositionen. Wenn also ein Knoten im beobachteten Bereich geändert wurde, dann benachrichtigt mich dieser Dienst. Riesige Bereiche (bounding box) mancher Änderungssätze führen also nicht zu falschen Benachrichtigungen. Allerdings ist es (aktuell zumindest) etwas schwierig die konkret geänderten Objekte herauszufinden, falls die Änderungssätze umfangreich sind. Mit dem “Get RSS link”-Knopf bekommt man nach Zeichnen eines zu beobachteten Bereichs einen RSS-Link für die jüngsten Änderungen in diesem Bereich. Beispiel-RSS-Link, Beispiel für Show it on WhoDidIt.
• Where are the new OSM Contributors?: Zeigt einem neue Mitarbeiter, die in einer bestimmten Gegend bearbeitet haben. Link.
• Keepright: Hier lassen sich neue potenzielle Fehler/Inkonsistenzen sehen. “Neu” heißt, dass sie vorher nicht da waren – sie wurden also wahrscheinlich durch kürzliche Bearbeitungen ausgelöst/erzeugt (oder Keepright hat eine neue Fehlerkategorie). Nicht selten bekommt man so die eigenen Missgeschicke beim Bearbeiten wenige Tage später zu sehen und kann nachbessern. Der RSS-Link ist links unten auf der keepright-Seite zu finden.
• Notes, Mapdust: Hier lassen sich neue Fehlermeldungen im Mappingbereich sehen, um evtl. direkt reagieren zu können. RSS-Link wiederum jeweils links unten auf jenen Seiten bzw auf der verlinkten Wikiseite.

OWL

OpenStreetMap Watch List ist/war ein Dienst, um kürzliche Änderungen zu sehen. OWL würde gegenüber dem Chronik-RSS-Feed eine Verbesserung, nämlich weniger Falschmeldungen, bringen. Der Dienst ist aktuell (seit vielen Monaten) inaktiv, er soll aber bald reaktiviert werden. Schon aktiv ist der verbesserte History-Tab.

Schlusswort

Danke für die Aufmerksamkeit, ich hoffe es ist hilfreich. Ich freue mich über Kommentare und Tipps (bitte “Kommentar zu diesem Eintrag” benutzen). Bei entsprechender Rückmeldung werde ich auch gern nach Englisch übersetzen, damit es breiter zugänglich ist.

Der Text ist von mir, dem Autor, in die Gemeinfreiheit übergeben (siehe meine Benutzerseite).

Update 2012-11-11

Abschnitt Änderungen in einem Bereich (Who did it?) hinzugefügt und im übrigen Text einige Kleinigkeiten korrigiert.

Update 2013-09-11

Notes und RSS-Hilfstool osm-qa-feeds hinzu. OWL aktualisiert.

Update 2014-08-23

Kleinkram, OSB gelöscht, weil nicht mehr funktional.

Update 2016-06-02

Links repariert, hinzugefügt: “Where are the new OSM Contributors?”

Update 2017-09-01

Abschnitt bei OSMi zum Lizenzwechsel und Redaction Bot gelöscht, da seit circa drei Jahren irrelevant. Kleinigkeit zur Nützlichkeit von mapdust ergänzt. Keepright kann https.