Genau so sehe ich das.
Hier jetzt zu versuchen, mit irgendwelchen Nutzungsbedingungen die Auswertung einzuschränken oder die Informationen gar nicht mehr zu veröffentlichen und somit der OSMF mehr Macht (Monopol) über einen Teil der Daten zu geben, halte ich für falsch.
Einen klaren Hinweise auf die Möglichkeit bestimmte (richtige, aber auch falsche) Rückschlüsse aus den beigetragenen Daten ziehen zu könne, halte ich für ausreichend.
D.h. klar zu machen, dass alle Bearbeitungen (wie z.B. Mappen, Änderungssatzkommentare, Diskussionen über Änderungssätze, Notes, GPX-Tracks, Profil-Bild) inkl. deren Zeitpunkt und den verwendete Editor öffentlich sind und mit dem Benutzernamen (ebenfalls öffentlich) verknüpft sind und diese Informationen natürlich richtige oder falsche Rückschlüsse z.B. auf die Identität, Wohnort, Arbeitsort, Urlaubsort, besuchte Orte, Ortskenntnisse, bestimmte Gewohnheiten ermöglichen können.
Noch etwas Witziges am Rande:
Letzten Sommer kam mir einer im Wald entgegen und fragte mich “Auch für OSM unterwegs?”.
Als Insider erkennt man sich gelegentlich gegenseitig.
Also anonym ist man nicht wirklich…
Mein undurchdachter Senf dazu.
Wie auch whb schrieb: Man muss deutlich machen was man an Informationen aus den Bearbeiterdaten herausziehen kann.
Also z.B. ‘Pascal Neis’ Dienste natürlich lassen wie sie sind. Es gibt dem IT-Laien einen Eindruck davon was man aus den Daten eruieren kann. Man könnte auch eine Liste weiterer Dienste und Analysen erstellen, wo der interessierte oder Neuling vor dem Mappen ersehen kann wie transparent er ist.
Und eine Konkrete Beschreibung was geht:
Hier die Aktivität von User123, der hat das ganze Dorf ABC gemappt, er scheint da der einzige OSMler zu sein und es sind seine ersten Edits. Da er aber im Dorf bekannt ist als der der da so komisch durch’s Dorf spaziert weiss man das User123 eigentlich Hein Mück ist. Dazu das keine Information sicher ist: Wenn irgendwo auf Facebook ein Kumpel die Zuordnung postet kriegt man sie nicht mehr aus der Welt.
In kurz: wir sollten kein ‘Securuy by obscurity’ einführen.
Wer wirklich an die Nutzeraktivitäten will kommt daran. Das die 3-Buchstaben-Organisationen eh’ dran kommen ist anzunehmen.
Falls wir das besser machen können wäre das natürlich zu diskutieren. Aber bitte keine halbgaren Verschleierungsaktionen. Das hält allenfalls einen IT-doofen Sachbearbeiter ab (Finanzamt, Jobcenter, …) aber deren IT-ler finden sicherlich heraus wie man jemanden identifizieren kann (Hier könnte Datenschutzrecht greifen, aber wenn man da bekannt ist gibt es auch Druckmittel unter der Hand).
Die Genauigkeit/Schärfe im Laufe der Zeit zu verringern finde ich gut… Wie ein Gedächtnis, mit der Zeit… erinnert man sich nicht mehr an alles… die Genaue Reihenfolge den genauen Namen. Wer kann sich schon noch an die Edits vor ein paar Jahren so genau Erinnern? Mit der Zeit verschwindet alles
Warum muss man die Usernamen von einem Note der vor 5 Jahren geändert wurde noch vorhalten… der Mapper kann sich vielleicht gar nicht mehr daran Erinnern dass er das einmal bearbeitet hat…
Warum alle Versionen eines Objektes aufheben? Warum alle Änderungssätze sich noch Anzeigen können die schon Uralt sind… usw. Vielleicht sollte eine Datenbank auch einmal ein bisschen wie ein Mensch sein: Vergesslich… , sich ändern… neu erfinden
PS: Username nur gegen Sicherheitsabfrage einzeln oder so… mit CAPTCHA abtippen
Wenn man eine Bearbeitung als vielleicht… als Dienstleistung oder keine Ahnung Handwerklich Leistung sieht… Dann hätte man 2 Jahr Gewährleistung… Mängelhaftung… Dann ist es vorbei… Dann könnte man die Unterlagen wegschmeißen… Außer man braucht diese noch für was anderes…
Es geht ja nicht um Haftung, es geht darum, Dinge klären zu können. Wenn ich über ein Detail irnkwo in der Welt stolpere, das vor 5 Jahren gemappt wurde und gar nicht zum Bing-Luftbild passen will, dann ist es unschätzbar wertvoll, den Kollegen direkt kontaktieren zu können, um zu fragen, ob die Straße tatsächlich umgebaut wurde oder was auch immer (das Bing-Bild kann ja ohne weiteres noch älter sein). Dann kann mir der Mapper entweder sagen: „Hab ich nicht genau gezogen, kannst du gern verfeinern, wurde seit 20 Jahren nicht umgebaut“ oder: „Ja, die Straße wurde verlegt, hab ich mit GPS vermessen, lass es bitte so, Bing ist veraltet“. Diese Möglichkeit sollte OSM-intern bestehen bleiben, sonst fehlt da was ganz Wichtiges.
Es gibt auch gewisse Konfliktregionen in der Welt, z.B. Bergkarabach, Südossetien, Abchasien, etc, wo man unter Umständen sogar ernsthafte Probleme bekommen könnte, wenn man dort Grenzen einträgt, die eine der jeweiligen Konfliktparteien für illegal hält und man dann in das jeweilige Land reist. Habe zwar noch nichts derartiges gehört, aber Aserbaidschan verhaftet ja schon Leute die Bergkarabach bloß kurz betreten haben. Ich kann mir durchaus vorstellen, dass jemand der z.b. Grenzen der armenischen Separatisten dort eingetragen hat, ein echtes Problem hätte, wenn er zufällig mal in Baku ist und seine Tätigkeit auf OSM dort bekannt würde.
Im Allgemeinen muss man aber damit leben, dass man die eigenen OSM-Aktivitäten nachverfolgen kann. Wer auf Wikipedia schreibt, nimmt auch in Kauf dass sein Name in Versionsgeschichten auftaucht. Da gibt man letztlich auch extrem viel über die eigenen Ansichten preis. Im Zweifelsfall kann man ja ein neues Benutzerkonto anlegen.
vielleicht könnte man als einen ersten Schritt in diese Richtung alle userbezogenen Daten auf openstreetmap.org nur noch für eingeloggte Besucher sichtbar machen? Es muss ja nicht unbedingt jeder dahergelaufene Bot meine komplette Edit-History sehen.
+1
Hinzu kommt bei der Variante, dass die ganzen Daten für Ottonormal eh komplett uninteressant bis verwirrend sind. Wer hat welches CS erstellt, kommentiert usw.
Weg damit.
Passt nicht ganz zum Thema aber kratzt etwas: im gleichen Atemzug könnte man für Ottonormal die Tags “übersetzen” bzw schönen und lesbar machen. Willkürliches Beispiel: http://www.openstreetmap.org/node/86001798 hier muss man sich aus “verwirrenden” Tags eine handelsübliche Adresse und andere Infos raussuchen.
zu spät und des wird nimmer helfen. das netz vergisst nix. ist schon doof wenn einem erst jetzt auffällt was man aus seinen daten und beiträgen alles rausfinden kann. tjaa erst denken und dann handeln. ist übrigens auch der grund warum ich keine gps-tracks hochlade und lieber unter unterschiedlichen accounts was mache. das ist natürlich nix für die “guggt mal alle wieviel ich schon gemacht habe, wie fleissig und wie toll ich bin” poweruser fraktion. phishing for compliments mit personal key performance indicator meets data security. entscheiden muss das jeder selber
Das ist als Sichtweise eines einzelnen zulässig (wenn auch reichlich arrogant). Aber sollten wir uns als Projekt nicht fragen, ob wir all die vielen einzelnen, die in der Zukunft zu uns stossen, besser schützen können (anstatt ihnen dann ein paar Jahre später ein hämisches “hättet ihr Euch früher überlegen müssen” entgegen zu rufen)?
Was mich an diesem Thread überrascht, oder vielleicht auch nicht, ist der häufige Gebrauch von “man”, in der Bedeutung “ich bin zu faul die Arbeit um die Ideen zu implementieren selber zu machen, aber vielleicht findet sich ein Doofer, der es macht wenn ich lange genug motze”. Das geht so weit, dass sich bis jetzt nur 4 Leute aus DACH sich auf https://github.com/openstreetmap/openstreetmap-website/pull/1431 gemeldet haben, wo es -konkret- um den Datenschutz geht und wo der Druck es so wie im PR implementiert in die Produktion zu übernehmen klar steigt.
Aus meiner Sicht geht es hier um einen größeren Umbau von “wir blasen alles was wir haben in die Welt hinaus” zu einer strikten Trennung von allgemeinen und nutzerbezogenen Daten. Also Privacy by Design. Ich denke diese Aufgabe ist zu groß für einen einzelnen und ich glaube auch nicht, dass es mit ein paar kleineren Patches getan ist. Mag sein dass ich einfach nur faul bin. Es könnte aber auch sein, dass wir nicht die Strukturen haben, um solche größeren Aufgaben anzugehen.
Wenn ich Fredericks Beiträge lese gings hier bisher um eine Diskussion und weniger um die konkrete Umsetzung.
Die deutsche Diskussion ist hier bestimmt gut aufgehoben, die Umsetzung bestimmt gut auf github.
Nicht jeder Mapper wird allerdings einen github Account haben. Von daher kann man schon von “man” reden.
Die zur Diskussion gestellten Anregungen und Vorschläge fand ich bisher übrigens sehr brauchbar.
Ich finde nicht, dass es einen so konkreten Zusammenhang zu diesem PR gibt. Da geht es ja immerhin um ein Opt-In. Und ob ich einer App nun so meine Email geben muss oder sie die aus meinen OSM Daten zieht, sehe ich jetzt keinen großen Unterschied. Der einzige aber sehr wichtige Knackpunkt ist, dass wenn ich EINER app zugang dazu geben muss dann gleich ALLE sie abfragen können. Das ist einfach Unfug und führt halt dazu dass ich das im Zweifelsfall anschalten muss für alle weil ich nur eine bestimmte App der ich vertraue nutzen will.
Das ist dann natürlich schon ein Datenschutzaspekt, weil ich quasi dann dazu genötigt werde ein opt in global zu aktivieren auch wenn es nicht nötig sein sollte gegenüber anderen Apps.
Wie kommst du denn darauf? Ich halte das für eine Fehlinterpretation des PR. Die Berechtigung hängt an jedem einzelnen OAuth-Client. Und was ich der einen App erlaubt habe, gilt noch lange nicht für eine andere App.
Da ist was leicht durcheinander: grundsätzlich kreiert der PR eine neue Permission, die es erlaubt, dass eine App auf die e-mail Adresse zugreift. Wenn in der Konfiguration für die App die Permission verlangt wird (das macht der App-Entwickler völlig selbstständig und da gibt es im Augenblick auch keine weitere Kontrolle oder Überprüfung durch Dritte), dann ist sie vor-ausgewählt, also wenn schon wäre es ein Opt-out, nicht ein Opt-in.
Aber in Wirklichkeit muss man die einzelnen Permissions gar nicht anzeigen, wird übrigens ausgerechnet von JOSM so praktiziert. Und wenn mal eingeführt, kann die App auch einfach die Arbeit verweigern solange die e-mal Permission nicht erteilt wird.
Genau. Und damit die Apps nicht die echte Email-Adresse in Erfahrung bringen, gibt es den Vorschlag, einfach pro App eine eigene Dummy-Adresse zurückzuliefern, die auf @xyz.openstreetmap.org hört. Mails an diese Dummy-Adresse landen einfach in eurem osm.org Postfach und werden automatisch weitergeleitet an eure echte Email-Adresse. Eure echte Adresse wird dabei nicht an Dritte übertragen.
Wenn man dann irgendwann keine Lust mehr auf die App hat, kann man die Berechtigung einfach selbst entziehen und braucht dafür nicht mal einen Admin zu belämmern. Ab dann ist Ruhe.
BTW: Für die App-Entwickler: Ist m.E. auch einfacher zu implementieren, als sich erst mit einer (noch zu entwickelnden) neuen API zu beschäftigen. EMail ist praktisch überall verfügbar und einfacher in bestehende Anwendungen einzubinden.
interessante Sache… 