Datenschutz bei OSM

woodpeck wrote:

Wir haben dann über eine konkrete Idee etwas detailierter gesprochen, und zwar: Was wäre, wenn wir Benutzerdaten (also *wer* hat etwas editiert) grundsätzlich nur angemeldeten OSM-Benutzern zur Verfügung stellen würden?

Das würde ich sehr begrüssen.

Grüße
Peter

Hi Freederik,

vielen Dank für deine Bemerkungen.

woodpeck wrote:

• Man könnte die Genauigkeit/Schärfe von Metadaten im Lauf der Zeit verringern, d.h. zu Sachen, die 1 Jahr alt sind, geben wir vielleicht nur noch einen Timestamp mit Tag raus und keine Uhrzeit mehr oder so
  

Das bring nix, da ich die Daten ja schon habe. Die werden nur geändert, wenn ein neuer Diff-Changeset kommt - und das wollt ihr sicher nicht machen.

Wir haben dann über eine konkrete Idee etwas detailierter gesprochen, und zwar: Was wäre, wenn wir Benutzerdaten (also *wer* hat etwas editiert) grundsätzlich nur angemeldeten OSM-Benutzern zur Verfügung stellen würden? Ginge das überhaupt, was würde es nutzen, was für Nachteile hätte es, wie sähe das technisch aus?

• Das Planet-File (inkl. Diff-Updates) gäbe es in zwei Ausführungen - mit und ohne User; das mit User wäre nur für eingeloggte OSMer downloadbar.
  

Eine Umstellung des Diff-Prozesses auf Authentifizierung müsste dabei aber in Osmosis integriert werden, da der hier zentral beteiligt ist. Ein technisches Problem hätte ich damit nicht.

Nach dem "Großen Crash" im Januar '17 habe ich meine Datenbank daraufhin erweitert und begonnen, u.a. diese Userdaten in meine Anwendungen (u.A. Emergency Map) zu integrieren. Den Usernamen werde ich asap aus den Popups entfernen aber bei der Userid (Zahl) bin ich mir nicht sicher. Die Changset-Id möchte ich aber weiterhin ausgeben, allerdings können nur Profis was damit anfangen.

Wie du es schon gesagt hast: Wer es will, kommt an die Userdaten heran.

Gruss
walter

Danke dass ihr euch damit beschäftigt habt!

woodpeck wrote:

• Es wäre möglich, bei Verstecken von Usernamen trotzdem ein Reputationssystem zu haben, indem man das Reputations-Scoring der Webseite anvertraut: "Du siehst nicht, welcher User hier in Deiner Strasse editiert hat, aber er hat einen Reputations-Score von 4.8"
  

würde bedeuten, der Name dürfte in allen changesets nicht auftauchen da man es sihc daraus a selbst zusammenstricken könnte

woodpeck wrote:

• Bei der Wikipedia gibt es Statistiktools ähnlich wie Pascals Tools, die vom Benutzer ein opt-in erfordern, sonst erscheint er nicht auf der Liste. Aber jeder kann sich die Daten runterladen und auch ohne opt-in eine Statistik selber rechnen
  

Ich hab bei einem anderen Projekt das so als Datenpool fungieren würde auch eine solche Lösung angedacht und finde sie ersteinmal ganz gut. Ich hätte dafür allerdings ein Opt-out erwogen da die momentane Situation ja sowieso offen für alles ist. Zumindest aus Sicht des einzelnen Projekts fände ich das gerechtfertigt (opt-out) da die OSM Daten ja zur Verfügung stehen. Innerhalb meines OSM Accounts würd ich mir dann aber eigentlich einen deutlichen Hinweis wünschen

woodpeck wrote:

• Egal, was wir tun oder nicht tun, wir sollten eventuell dafür sorgen, dass neue Benutzer ganz genau wissen, was sie tun und was über sie später ermittelbar ist. Derzeit steht das in unserer Privacy Policy, aber wer liest die schon...
  

fände ich sehr gut

woodpeck wrote:

• OSMer müssten zustimmen, Userdaten grundsätzlich nur für interne OSM-Zwecke (Qualitätssicherung, Schutz gegen Vandalismus usw) zu nutzen. Eventuell würde man auch aggregierte Statistiken erlauben, aus denen keine Personendaten mehr hervorgehen.
  

• Das Planet-File-mit-Usernamen stünde nicht mehr vollständig unter der ODbL, sondern nur der Teil ohne Usernamen. Die Vereinbarkeit mit den Contributor Terms müsste geprüft werden, aber vermutlich ist das in Ordnung; die OSMF hat sich nicht verpflichtet, Usernamen unter ODbL rauszugeben. Darüber hinaus ist, zumindest im deutschen Recht, der Datenschutz stärker als das Urherber- oder Datenbankschutzrecht oder irgendwelche Lizenztexte.
  

Fände ich seht gut wenn das über der Lizenz machbar wäre. Dann könnte man der Auswertung und Verwertung der Daten zumindest so Herr werden. Wenn jemand z.B. eine soziologische Arbeit über die OSM Mapper machen wollte ginge das nur unter bestimmten datenschutzfreundlichen Beschränkungen bzw. nach Absprache/Abwägung.

woodpeck wrote:

• All diese Maßnahmen wären geeignet, einen Datenschützer davon zu überzeugen, dass wir Usernamen nicht mir-nichts, dir-nichts in der Gegend verteilen, sondern dass sie nur zu Zwecken der notwendigen Qualitätskontrolle und Zusammenarbeit im Projekt verwendet werden. Trotzdem wäre Missbrauch leicht - man muss sich ja nur einen Account anmelden.
  

en Missbrauch zu verhindern wäre wie es ja deutlich wird schwierig. Aber wenn man schonmal solche Maßnahmen ergreift würde es Aufmerksamkeit für das Thema schaffen und man würde vielleicht bessere Lösungen finden.

Um mal ein Beispiel zu bringen: Der Nutzer hfst hat im Juli 16 relativ lokale Edits in Südtirol gemacht. Bei genauerem Hinsehen findet man auch Links auf neue Bilder in Wikimedia Commons. Und ich denke, dass man auch einen Realnamen zu hfst ergoogeln kann.
Tja, und jetzt kann jeder rauskriegen, wo ich Urlaub mache.
Was auch nicht schlimm wäre. Schlimm wird es, wenn aus diesen Einzelinformationen statistische Schlüsse gezogen werden, die falsch sind.

Ich habe mir dazu auch schon Gedanken gemacht, die allerdings nicht so weitreichend waren. Danke für deine Zusammenstellung woodpeck. Natürlich kann man bei mir feststellen, wo ich schon mal im Urlaub war. Aber gleichzeitig auch ein paar false positives bekommen. Denn nicht überall auf der Welt, wo ich editiert habe, war ich auch tatsächlich.
Der Wohnort ist vermutlich bei >95% der Benutzer durch die Edits klar erkennbar.

Ich glaube aber, dass es nur dann ein Problem geben könnte, wenn man sich hier mit einem auch auf anderen Seiten verwendeten Benutzernamen angemeldet hat oder seinen Realnamen hinterlegt hat. Beides kann man problemlos vermeiden, wenn man es denn will.

Wer Angst vor einer entsprechenden Auswertung hat, dürfte über eine geteilte Lizenz auch nicht glücklich sein - es ist eine Sache von einer Minute, an das "interessante" planetfile zu kommen. Die Informationen, die daraus gezogen werden, werden dann eh so weiterverwendet, dass eine Lizenz in meinen Augen auch kein Hindernis darstellt.

Ob hdyc jetzt nur nach Login einsehbar ist oder nicht, ist mir letztlich egal. Ich kann solch eine Forderung verstehen und ich habe auch kein Problem damit, wenn ich mich einloggen muss.

Fakt ist: Wenn man sich im Internet bewegt, hinterlässt man eben Spuren, die nicht nur für Gutes gebraucht werden können und einem sehr viel über die eigene Person verraten können. Darüber muss man sich eben im Klaren sein, v.a. wenn es um Standortinformationen geht. Meine hochgeladenen GPS-Tracks starten somit auch nie direkt bei mir zu Hause.
Ich glaube, es gibt wenig, was wir verbessern können. Wenn jemand solche Auswertungen fahren möchte, dann kann er es - da bringt ein Login genausowenig, wie Benutzer-IDs nach einer gewissen Zeit nicht mehr zu übertragen.

Ich bin auch für mehr Datenschutz. Durch die Verknüpfung mit anderen Diensten wie z.B. Mapillary kann man schon als Laie recht gute Profile der Mapper erstellen. Gerade die aktiven Mapper sind schon sehr gläsern. Das war für mich Anlass auf verschiedenen Plattformen verschiedene Nutzernamen zu verwenden, aber wahrscheinlich nützt das auch nicht viel. Daher wäre mehr Datenschutz per Default sehr wünschenswert.

Ich bin da bisschen gespalten.
Einerseits ist der Datenschutz imho ein Disaster, andererseits sind nicht nur Tools wie bspw. von Pascal ein Segen, auch die Recherche in den CS direkt oder über Achavi etc. machen viel Arbeit einfacher.

Das wichtigste für mich wäre ein klares Statement für Neumapper direkt bei der Anmeldung. Ich bezweifle, dass das überhaupt jemandem so bewusst ist.

Sehr interessant finde ich übrigens den Ansatz Zweit-accs unsichtbar/anonym an den Hauptacc zu binden. Wäre ich wahrscheinlich sofort dabei. Hat wieder seine eigenen Nachteile, aber irgendwas ist immer.

MKnight wrote:

Sehr interessant finde ich übrigens den Ansatz Zweit-accs unsichtbar/anonym an den Hauptacc zu binden. Wäre ich wahrscheinlich sofort dabei. Hat wieder seine eigenen Nachteile, aber irgendwas ist immer.

Diesen Punkt fände ich auch sehr interessant.

Am liebsten hätte ich dann auch noch eine Erweiterung für JOSM, die mich am besten immer gleich beim JOSM-Start fragt, mit welchem meiner Accounts (die JOSM dann parallel speichern sollte) ich denn jetzt gerade editieren möchte. Diesen Dialog könnte man hübsch machen, inkl. Anzeige des jeweiligen Avatar-Bildchens von der OSM-User-Info-Seite neben den einzelnen Accounts. 😉 Nein, im Ernst, das wäre wichtig, ich würde sonst sicher immer wieder Edits mit dem „falschen“ Account machen …

MKnight wrote:

Das wichtigste für mich wäre ein klares Statement für Neumapper direkt bei der Anmeldung. Ich bezweifle, dass das überhaupt jemandem so bewusst ist.

Direkt unter dem e-mail Feld bei der Neuanmeldung hat es (schon -sehr- lange) ein Link auf http://wiki.osmfoundation.org/wiki/Privacy_Policy

Man muss sich einfach bewusst sein, dass wenn die Pläne umgesetzt werden, vielleicht umgesetzt werden müssen, es auf eine Zentralisierung der ganzen niederschwelligen QA Arbeit/Dienste herausläuft, also ganz andere Konsequenzen als nur mehr Datenschutz haben wird.

woodpeck wrote:

• Man könnte Benutzernamen komplett verschleiern (z.B. ersetzen durch zufällige Zahlen) - aber wie dann Reputation ermöglichen und Vandalismus unterbinden?
  

Ich will die Idee einer zusätzlichen Indirekion, nennen wir sie "Tagesrolle", nochmal konkret erläutern:

Die Tagesrolle braucht keine Zufallszahl zu sein, sondern kann fortlaufend sein. Jedem Benutzer wird automatisch bei seiner ersten Änderung an einem Kalendertag die nächste Nummer zugewiesen - seine Tagesrolle.

An den Objekten und den Changesets (und damit auch im Planetfile) stünden dann keine Kennungen mehr, sondern diese Tagesrollen.

Der Bezug zwischen Tagesrolle und Benutzer wäre Teil der Benutzerstammdaten - dort gäbe es pro Benutzer eine Liste all seiner Tagesrollen.

Mit Zugriff auf die Benutzerstammdaten ändert sich also vom Prozess her nichts - alles ist genauso rekonstruierbar wie bisher und man kann einen Changeset-Autor genauso kontaktieren wie bisher (auch bisher sieht man ja nicht seine email-Adresase).

Das Prinzip, was hier greift ist einfach, dass Benutzerstammdaten (ja auch jetzt schon) einen höheres Schutzniveau haben als die Geo-Daten.

Während hier über Datenschutz diskutiert wird, wird anderenorts darüber nachgedacht, die mit eurem OSM-Profil verknüpfte Email-Adresse auch externen Anwendungen auf Anfrage und mit eurer expliziten Genehmigung herauszurücken. Einige von euch hier haben ja bereits kritischen Anmerkungen dazu angebracht.

Ich habe immer noch nicht verstanden, wozu das überhaupt gut sein soll. Es gibt doch die Nachrichtenfunktion, Changesetkommentare, etc.. Zusätzlich Mails von zugelassenen Apps (z.B. Maps.ME) zu erhalten will ich ehrlich gesagt nicht. Also ein tiefrotes -1 von meiner Seite dazu.

Schon nervig genug, dass man für diese "Mailinglisten" eine Emailadresse angeben muss. 😎

Link: https://github.com/openstreetmap/openst … /pull/1431

Zu den anderen Punkten:

woodpeck wrote:

• Bei der Wikipedia gibt es Statistiktools ähnlich wie Pascals Tools, die vom Benutzer ein opt-in erfordern, sonst erscheint er nicht auf der Liste. Aber jeder kann sich die Daten runterladen und auch ohne opt-in eine Statistik selber rechnen
  

Opt-in wäre gar nicht so schlecht. Könnte man ja auf der Benutzerseite als Tag anbringen, so wie Pascal auch heute schon die Verknüpfung zu Help OSM, etc. für "How did you contribute" auswertet.

Siehe: https://www.openstreetmap.org/user/malenki/diary/38381

woodpeck wrote:

• Man könnte die Genauigkeit/Schärfe von Metadaten im Lauf der Zeit verringern, d.h. zu Sachen, die 1 Jahr alt sind, geben wir vielleicht nur noch einen Timestamp mit Tag raus und keine Uhrzeit mehr oder so
  

Wenn sich das auch auf Planet-Files oder alte Diffs bezieht: das würde zumindest die Attic-Funktion in Overpass potenziell gehörig aus dem Tritt bringen, wenn dann nicht mehr klar ist, welche Objekt(-version) zu einem bestimmten Zeitstempel (in Sekunden) gültig ist. Redactions sind heute schon ein Painpoint, mit unscharfen Metadaten wird das nicht besser.

woodpeck wrote:

• API-Requests, Overpass usw. würden Usernamen auch nur mitgeben, wenn man bei OSM eingeloggt ist, sonst bekommt man alles ohne Usernamen
  

Overpass als Beispiel schickt Metadaten, also insbesondere die Benutzer-Id und Name nur bei einem `out meta;`. Könnte man bestimmt irgendwie von einem angemeldeten Nutzer abhängig machen, d.h. zumindest nicht technisch unmöglich. Ob das Roland machen wollen würde, kann ich nicht beantworten.

Wahrscheinlich ist ein nicht gesetztes `out meta;` nicht ganz passend, da es auch Zeitstempel und Objekt-Version ausblendet. Da müsste etwas neues her, das explizit User-ID und Username ausblendet.

Edit: Ersten beiden Abschnitte überarbeitet wg. missverständlicher Formulierung

mmd wrote:

Während hier über Datenschutz diskutiert wird, wird anderenorts darüber nachgedacht, die mit eurem OSM-Profil verknüpfte Email-Adresse auch externen Anwendungen auf Anfrage herauszurücken. Einige von euch hier haben ja bereits kritischen Anmerkungen dazu angebracht.

Ich habe immer noch nicht verstanden, wozu das überhaupt gut sein soll. Es gibt doch die Nachrichtenfunktion, Changesetkommentare, etc.. Automatisiert von irgendwelchen Apps (Maps.ME) Mails zu erhalten will ich ehrlich gesagt nicht. Also ein tiefrotes -1 von meiner Seite dazu.

Ups, das ist mir entgangen. Wirklich? Sch***, das wäre für mich sogar ein Grund, aus OMS komplett auszusteigen. 🙁 Zumindest müsste ich mir dann für das OSM-Profil eine eigene anonyme E-Mail-Adresse zulegen, damit keine direkte Verknüpfung möglich ist …

Also auch von mir ein tiefrotes –1 dazu!

Chrysopras wrote:

Sch***, das wäre für mich sogar ein Grund, aus OMS komplett auszusteigen.

Sorry, mein Text war etwas missverständlich, ich wollte hier keine Panik schüren. Natürlich würde die Weitergebe nur erfolgen, wenn ihr dem ganzen explizit in einem Dialog zugestimmt habt. Ich möchte an der Stelle einfach an das Github-Issue das ich oben verlinkt habe verweisen.

mmd wrote:

Chrysopras wrote:

Sch***, das wäre für mich sogar ein Grund, aus OMS komplett auszusteigen.

Sorry, mein Text war etwas missverständlich, ich wollte hier keine Panik schüren. Natürlich würde die Weitergebe nur erfolgen, wenn ihr dem ganzen explizit in einem Dialog zugestimmt habt. Ich möchte an der Stelle einfach an das Github-Issue das ich oben verlinkt habe verweisen.

Danke für die (tlw.) Entwarnung! Trotzdem ist es gut, dass Du auf diese Pläne hingewiesen hast. Dann will ich hoffen, dass in diesem Dialog ausdrücklich darauf hingewiesen wird, dass nicht nur „irgendwelche Daten“, sondern auch die angegebene E-Mail weitergegeben wird. Denn die E-Mail-Adresse ist nun mal der direkteste Link zur Identität des Mitwirkenden …

Ich darf vielleicht anmerken, dass ich eigentlich nichts zu verbergen habe und mich auch nicht wichtig machen möchte. Aber ich möchte eben nicht, dass mein Engagement bei verschiedenen OpenSource/OpenData-Projekten von jedermann so leicht verknüpft werden kann, da durch eine solche Vernetzung ein unangenehm genaues „Bewegungsprofil“ entstünde. Deshalb verwende ich ja getrennte Nicknames. Die E-Mail-Adresse würde aber sofort eine Vernetzung ermöglichen …

Chrysopras wrote:

Deshalb verwende ich ja getrennte Nicknames. Die E-Mail-Adresse würde aber sofort eine Vernetzung ermöglichen …

Echt jetzt? Ernsthaft? So paranoid, getrennte Nicknames anzulegen, und dann DIESSELBE E-Mail-Adresse für ALLE Nicks zu verwenden??? 🙄

ADD: Sorry, aber so Leute verstehe ich einfach nicht, das ist einfach HALB und NIX GEKONNT, entweder Gescheit, d.h. pro Nick eine eigene Emailadresse und eigene Bankverbindung usw, oder gar nicht, dann kann man es auch sein lassen...

Harald Hartmann wrote:

Chrysopras wrote:

Deshalb verwende ich ja getrennte Nicknames. Die E-Mail-Adresse würde aber sofort eine Vernetzung ermöglichen …

Echt jetzt? Ernsthaft? So paranoid, getrennte Nicknames anzulegen, und dann DIESSELBE E-Mail-Adresse für ALLE Nicks zu verwenden??? 🙄

ADD: Sorry, aber so Leute verstehe ich einfach nicht, das ist einfach HALB und NIX GEKONNT, entweder Gescheit, d.h. pro Nick eine eigene Emailadresse und eigene Bankverbindung usw, oder gar nicht, dann kann man es auch sein lassen...

Danke für die freundlichen Worte. 😉 Allerdings … Bankverbindung? Komisch, habe ich bei der Registrierung für Wikimedia oder bei Open-Source-Projekten noch nie angeben müssen. Sprechen wir vielleicht von verschiedenen Dingen? Außerdem … warum paranoid? Dass ich vor Geheimdiensten oder einfach Internet-Providern so nichts verbergen kann, ist mir völlig klar, und daher versuche ich das auch gar nicht (deshalb dieselbe E-Mail-Adresse, solange diese nicht offen angezeigt wird). Alles, was ich meinte, ist, dass ich z.B. für Wikimedia-Projekte einen anderen Nickname verwende als für OSM, damit nicht jeder Depp sofort weiß, dass das ein und dieselbe Person ist, einfach weil das nicht jeden Depp was angeht. Man kann das auch anders sehen und absichtlich überall denselben Namen verwenden, auch das ist OK und nachvollziehbar.

Aber, mal im Ernst: Muss man sich hier für jede Dummheit verteidigen? Weißt Du, lieber Harald, es sind einfach nicht alle Leute so klug und erfahren wie Du. Tut mir leid. Ich kenne erstaunlicherweise sogar Leute, die haben nochmal weniger Ahnung als ich, trotzdem verspotte ich sie nicht öffentlich.

Und am besten beenden wir dieses Sub-Thema jetzt, denn (1) bin ich laut Harald sicher sowieso zu dumm, irgendetwas zu kapieren, (2) empfinde ich derartige herablassende Äußerungen wie die von Harald als persönliche Runtermachung, wie man deutlich sieht, und (3) gibt es ja noch andere wichtige Fragen in Sachen Datenschutz und OSM, über die Ihr Großen und Weisen in Ruhe diskutieren solltet, ich halte die Klappe und mich aus diesem Thread heraus.

Ich habe eine separate E-Mail-Adresse für OSM und bekomme da gelegentlich Spam 😐

Ich habe dir gar nicht unterstellen wollen, dass du keine Ahnung hättest oder Dumm wärst ... letztendlich ist es meine Meinung, dass die Datenschützer eher die Leute darüber aufklären sollten, dass sobald man sich elektronisch irgendwo beweget verfolgt/erfasst werden kann (unabhängig von den ganzen Schwachsinn mit anonymen Nicks und so Zeugs).

Wie du schon sagtest, es muss niemand bei irgendwelchen Projekten mitmachen, wenn man nicht möchte, dass man in irgendeinerweise nachverfolgbar sein möchte ... und bei einem Stimme ich dir sogar zu: diese Diskussion um Datenschutz und wie man die Latte (nur) ein bisschen höher legen könnte (damit nicht jeder einfach dran kommt, sondern sich anstrengen muss) braucht's in der Tat nicht.

PS: Und das mir der Datenschutz mal sowas von Sch...egal ist, sieht man an meinem Realname, damit kannst du auch meine reale Wohnadresse ausfindig machen: ach ich mache es dir noch einfacher: http://name.haraldhartmann.de/ ... ich würde dich (Chrysopras) ja sogar auf ein Bier einladen, wenn du mal vorbeikommst, aber das kann ich leider dann doch nicht machen, weil das erstens eine öffentliche Einladung wäre und zweitens ich ja dann gar nicht wüsste, ob der richtige anonyme Chrysopras vor mir steht.

Chrysopras wrote:

Alles, was ich meinte, ist, dass ich z.B. für Wikimedia-Projekte einen anderen Nickname verwende als für OSM, damit nicht jeder Depp sofort weiß, dass das ein und dieselbe Person ist, einfach weil das nicht jeden Depp was angeht.

Und um weiter sachlich zu bleiben und weiter zu argumentieren, frage ich dich: Wieso? Was hast du zu verbergen? Genau diese Argumentation führt meiner Meinung nach genau dazu, dass einige genau in diesem (vermeindlichen) Schatten der Anonymität eben Dinge unternehmen, die eventuell unerwünscht sind und in der Tat besser im Verborgenen bleiben sollten, was aber letztendlich dann dem (freiwilligen/opensource) Projekt negativ angelasstet wird.

Und abschließend von mir noch die klare Meinung/Forderung: ALLE Daten von OSM transparent für ALLE offenlegen, ohne Einschränkungen!

woodpeck wrote:

Jeder, der unser Planetfile runterlädt und verarbeitet, wird unwillkürlich zum Verarbeiter persönlicher Daten und könnte sich Probleme einhandeln (und sei es auch nur, weil er in einer Behörde ode großen Firma arbeitet, die strenge Richtlinien für den Umgang mit solchen Daten hat).

Ganz vergessen, auch darauf einzugehen: dann Sch.. auf die persönlichen "Reputation" und wir nehmen ALLE "persönlichen Daten" aus der Datenbank und erfassen ALLE absofort "anonym" (ganz ohne Konto/Anmeldung)! ... also ganz meinem Motto: Ganz oder gar nicht, immer nur so mitten drin versuchen einen Mittelweg zu finden ist pure Augenwischerei.

Harald Hartmann wrote:

wir nehmen ALLE "persönlichen Daten" aus der Datenbank und erfassen ALLE absofort "anonym"

Hatten wir schon. War auch nicht das Gelbe vom Ei.

Harald Hartmann wrote:

Ganz oder gar nicht, immer nur so mitten drin versuchen einen Mittelweg zu finden ist pure Augenwischerei.

Versteh ich nicht, warum soll man nicht nach nem Mittelweg suchen? Wenn's keinen machbaren gibt, dann eben weiter so oder gar nicht. Wenn's aber einen gibt, umso besser.

Weil die bisher vorgeschlagenen Mittelwege nur die Hürde anheben, aber das grundsätzliche Problem nicht beheben. Und ja, mir ist auch bewusst, dass wenn man das eine Problem behebt, andere entstehen, darauf hat thomas8122 denke ich mal angespielt, weil ich ja auch geschrieben habe, dass die voll Anonymität dem Projekt sicherlich nicht hilfreich ist. Und beim Mittelweg wird es definitiv auch weiterhin immer Einwände geben. Wenn man aber in die beiden von mir genannten Extremen tendiert, weiß jeder von vorne rein, woran er/man ist und braucht sich nachher nicht darüber beschweren. Vor Gericht kann ich auch nicht sagen das ich meiner Taten nicht bewusst war ... gut, könnte ich schon, aber dann wirste halt in die Klapse geschickt.

Harald Hartmann wrote:

Weil die bisher vorgeschlagenen Mittelwege

(Hervorhebung von mir)

Die kratzen teilweise nur am Problem, ja, aber vlt. gibt's ja ne Kombination diverser Dinge, die das halbwegs zufriedenstellend lösen. Wenn der Datenreichtum für Dich ok ist, ok. Für andere ist er das entweder nicht, oder wie in meinem Falle: ich sehe, dass es ein Problem gibt, was extrem schwer zu lösen ist, wo man aber drüber reden muss.
Wie bereits gesagt, ist das nicht jedem bewusst.

So, und da dies nicht jedem bewusst ist, hier noch ein konkreter Vorschlag von mir zur Lösung dieses Problems:

Bereits bei der Registrierung eines OSM Accounts neben den Lizenzbedingungen auch noch ein bisschen Text über die Verarbeitungsmöglichkeiten dieser (gesammelten) Daten. Am Ende dann aber nicht so eine einfache "Ja, habe ich gelesen"-Checkbox, sondern mehrere Fragen mit mehreren Antwortmöglichkeiten, damit es auch jedem wirklich bewusst wird und man dann auch davon ausgehen kann, dass der Text wirklich vollständig gelesen UND verstanden wurde.

Natürlich müsste man dies auch für alle bereits angemeldeten Mapper tun, wie damals bei der Lizenzumstellung (wo doch auch nur jeder auf "Ja, gelesen" geklickt hat und wir immer wieder das Problem von Lizenzverletzungen haben, weil es kaum einem bewusst ist, wie weitreichend die Lizenz ist). Und weil dann jedem bewusst ist, was man mit den Daten machen kann, ist es auch kein Datenschutzproblem mehr.

Klar tut sich dann ein neues Problem auf: die Hürde zum Einstieg wird größer, was machen wir mit Mapper, die nicht einverstanden sind und ihre Daten gelöscht haben wollen (was ja eigentlich auf grund der aktuellen Lizenz gar nicht so ohne weiteres möglich ist, weil man sich ja damit einverstanden erklärt hat, das die übertragenen Daten in eine höhere allgemeine Schicht abwandern)?

Harald Hartmann wrote:

Natürlich müsste man dies auch für alle bereits angemeldeten Mapper tun, wie damals bei der Lizenzumstellung (wo doch auch nur jeder auf "Ja, gelesen" geklickt hat und wir immer wieder das Problem von Lizenzverletzungen haben, weil es kaum einem bewusst ist, wie weitreichend die Lizenz ist). Und weil dann jedem bewusst ist, was man mit den Daten machen kann, ist es auch kein Datenschutzproblem mehr.

Es geht in erster Linie nicht um ein rechtliches Datenschutzproblem, sondern darum wie OSM Mapper geschützt werden könnten unanbhängig welche rechtliche Verpflichtung besteht. Zwar waren die Meinungen dazu auch unterschiedlich, aber wahrscheinlich gibt es nach der bestehenden Policy keine rechtlichen probleme bisher. Nur den Wunsch, OSM Mappers besse zu schützen vor Missbrauch der gesammelten Daten.

Wenn das für dich kein Problem darstellt ist das ja gut. Für andere Leute tut es das allerdings. Ich hantiere teilweise auch aus diesem Grund mit verschiedenen Accounts was sehr suboptimal ist bisher. Die Idee mit den Subaccounts fände ich bisher sehr gut, natürlich besteht dann intern immer noch die Verknüpfung, aber an der Stelle muss dann halt vertraut werden dass die nicht öffentlich werden.

Aber warum braucht es den Schutz von OSM Mapper? Doch nur, weil sie sich dessen nicht bewusst sind, wie mir scheint, zumindest konnte ich aus dieser Diskussion noch nichts anderes rauslesen.

Zum Beispiel: Wenn sie sich des Problems einmal bewusst sind, haben Sie vielleicht Hemmungen gewisse Daten an gewissen Orten aufzunehmen. Ist wie gesagt bei mir selbst so, weil ich kein Interesse daran hab dass alle Welt einfach nachschauen kann in welchen Gegenden ich mich so rumtreibe.

Hakuch wrote:

..haben Sie vielleicht Hemmungen gewisse Daten an gewissen Orten aufzunehmen.

Anscheinend dann zu Recht, es bestehen also Zweifel, gesunder Menschenverstand, aber unter dem Deckmantel der Anonymität kann man es ja dann machen, geile Logik.

Hakuch wrote:

Ist wie gesagt bei mir selbst so, weil ich kein Interesse daran hab dass alle Welt einfach nachschauen kann in welchen Gegenden ich mich so rumtreibe.

Mehrere Accounts zu haben und verschiedene Orte sauber zu trennen, finde ich überhaupt nicht abwegig, obwohl ich mich nicht wirklich als paranoid einschätzen würde.

Das gibt es sogar im echten Leben: wer etwas herumgereist ist, wird vielleicht schon mal davon gehört haben, dass man auch einen zweiten Reisepass beantragen kann. Ob das jetzt die Einreise in gewisse Länder vereinfacht, sei mal dahingestellt...

https://www.service-bw.de/leistung/-/sb … leistung-0
https://www.welt.de/reise/article137540 … eiden.html

Und ich habe auch kein Problem damit, wenn Nordkorea, China und Bonn dann halt weiße Flecken auf der OSM Landkarte sind.

Ich sehe das gelassen:
Ich würde keinen Liebesbrief auf Postkarte versenden, einen Urlaubsgruß aber schon, und ich sehe OSM-Einträge eher analog zu letzterem. Ich muss mir nur bewusst sein, dass die OSM-"Postkarte" von jedem weltweit gelesen werden kann.

Einen Trampelpfad durch ein streng geschütztes Gebiet würde ich aber nicht aufnehmen (schon deshalb, weil ich da auch nicht lang gehe).

seichter wrote:

Ich sehe das gelassen:
Ich würde keinen Liebesbrief auf Postkarte versenden, einen Urlaubsgruß aber schon, und ich sehe OSM-Einträge eher analog zu letzterem. Ich muss mir nur bewusst sein, dass die OSM-"Postkarte" von jedem weltweit gelesen werden kann.

Wenn du in 10 Jahren mit Deinem Nachbarn in Streit gerätst, hat der aber keinen Zugriff auf Deine Postkarten der letzten 10 Jahre 😉

woodpeck wrote:

seichter wrote:

Ich sehe das gelassen:
Ich würde keinen Liebesbrief auf Postkarte versenden, einen Urlaubsgruß aber schon, und ich sehe OSM-Einträge eher analog zu letzterem. Ich muss mir nur bewusst sein, dass die OSM-"Postkarte" von jedem weltweit gelesen werden kann.

Wenn du in 10 Jahren mit Deinem Nachbarn in Streit gerätst, hat der aber keinen Zugriff auf Deine Postkarten der letzten 10 Jahre 😉

Von den OSM-Daten hat er aber genau so wenig, wenn ich nicht seinen privaten Swimmingpool mappe. Gegen seine Hausnummer kann er sich nicht wehren 🙂.

Moin!

woodpeck wrote:

Der Ausgangspunkt war, dass ich gesagt habe: Es gibt Leute, die bei uns nicht mitmachen, weil sie das Gefühl haben, dass man dadurch zu viel von sich preisgibt

Ich finde diese Überlegungen sehr wichtig. Ich habe seit mehreren Jahren vor allem aus diesem Grund keine Tracks mehr hochgeladen und einige Dinge nicht in die Datenbank eingetragen.
Wer in einer weniger freien Gesellschaft als unserer lebt, wird deutlich größere Probleme mit dem Schutz persönlicher Daten haben.

• Im Grunde ist ein OSM-Account immer abstreitbar, selbst wenn der Account den eigenen Realnamen trägt, kann niemand beweisen, dass man das selber war.
  

So ein formaler Einwand nützt vielleicht vor einem deutschen Gericht, aber nicht, wenn man im nächsten Urlaub bei der Einreise zurückgewiesen wird wegen Spionage (Eintrag von militärischen Objekten), Propaganda für Terrororganisationen (name-Tag in der falschen Sprache) oder Gefährdung der nationalen Sicherheit (Editieren einer "inkorrekten" Grenze).

• Jemand, der eine Seite wie die von Pascal betreibt, würde also auch einen OSM-Login davorschalten - alles, was nur nach OSM-Login nutzbar ist, ist offensichtlich "interne OSM-Zwecke"
  

• API-Requests, Overpass usw. würden Usernamen auch nur mitgeben, wenn man bei OSM eingeloggt ist, sonst bekommt man alles ohne Usernamen
  

Damit kann man evtl. verhindern, dass ein neugieriger Ladenbesitzer einfach herausfindet, wer sein Geschäft bei OSM eingetragen hat.
Gegen kommerzielle Datensammler oder staatliche Stellen hilft es nichts.

• Mehrfach-Accounts sind nicht für jeden leicht zu verwalten, und ein kleiner Fehler Jahre später kann die Anonymität kaputtmachen.
  

Eine Alternative zu Mehrfach-Accounts wäre die Möglichkeit, Changesets anonym einzureichen.
Um Vandalismus zu verhindern müssten diese Changesets von einem anderen Mapper geprüft und erst dann in die OSM-Datenbank eingetragen werden. In der Datenbank würden sie unter dem Namen des Prüfers mit einem eindeutigen Kommentar stehen.
Damit hätte man ein hohes Maß an Datenschutz ohne größere Gefahr von Vandalismus.

Vielleicht könnte man damit sogar die Einstiegshürde bei OSM abgesenken.
Sicherlich befürchten manche, dass ihre erste Mitarbeit Schäden an der Karte verursacht oder negative Kommentare hervorruft.
Für diese wäre eine anonyme Teilnahme mit Kontrolle durch einen erfahrenen Mapper evtl. ein Einstieg.

Weil ich gerade auf der oester. Mailingliste darauf hingewiesen wurde, bei automatischen Edits wird im Wiki der Realname gefordert, in der Diskussionseite des Themas haben da zwei was dagegen:
https://wiki.openstreetmap.org/wiki/Aut … of_conduct

Sicher, automatisch editieren ist ein sehr heikles Thema, aber wie sieht es damit aus? Wurde daran bei der aktuellen Diskussion gedacht?

Es ist leider so, daß Anonymität bei diesem Projekt nicht tatsächlich gewährleistet werden kann. Selbst wenn ich mir einen weiteren Account zulegte, könnten findige Leute aus Merkmalen meiner neuen Beiträge und ihren Ähnlichkeiten mit früheren Beiträgen mich identifizieren - davon bin ich überzeugt. Es gibt genügend Merkmale: Orte der Aktivität, verwendete tags, Änderung oder Neuanlegung oder Löschung, Wochentag und Tageszeit der Tätigkeit, Größe des Changeset, verwendeter Editor, Abstände zwischen Nodes, ... Bei so wenigen aktiven Mappern genügt das sicherlich.

Damit könnte ich auch den gegenteiligen Vorschlag machen: gleich klipp und klar sagen, daß hier nichts anonym sein kann.

Gegenüber Leuten, die durch ihre Mappingtätigkeit wirklich gefährdet werden könnten, wäre das ehrlich. Damit hätten wir zwar jemanden vom Mapping abgehalten, aber das ist besser, als jemanden ins Gefängnis gebracht.

Bernhard Hiller wrote:

Es ist leider so, daß Anonymität bei diesem Projekt nicht tatsächlich gewährleistet werden kann. Selbst wenn ich mir einen weiteren Account zulegte, könnten findige Leute aus Merkmalen meiner neuen Beiträge und ihren Ähnlichkeiten mit früheren Beiträgen mich identifizieren - davon bin ich überzeugt.

Es steht bei der ganzen Diskussion ein bisschen die Frage im Raum: Wenn wir jetzt sozusagen "symbolisch" sagen, die Nutzerdaten sind nur für uns intern, und einige (durch Anmeldung eines Accounts leicht zu umgehende) Schutzmassnahmen ergreifen - hat das dann einen Nutzen, weil wir wenigstens klar machen, was wir wollen, anstatt zu sagen "ist uns egal, mit Nutzerdaten darf jeder machen, was er will"? Oder schadet es eher, weil es eine Sicherheit vorgaukelt, die keine ist?

Tatsache ist: Im Moment kann ich, ohne mich zu verstecken, ganz frech eine Webseite machen, auf der immer steht, was der Bernhard H. in der letzten Woche so am Rechner gemacht hat (in OSM zumindest). *Das* könnten wir schon unterbinden. Die Info kann ich dann immer noch rausfinden, aber ich kann sie nicht mehr frech ins Web blasen.

Bernhard Hiller wrote:

Damit könnte ich auch den gegenteiligen Vorschlag machen: gleich klipp und klar sagen, daß hier nichts anonym sein kann.

Ja, das ist m.E. das Mindeste, was wir tun müssen - ohne Panikmache, aber schon so, dass auch der unbedarfte Nutzer versteht, woran er ist. Und wir müssen überlegen, was wir tun, wenn jemand bei uns tatsächlich sein "Recht auf Vergessen" einfordert - denn wie Du oben geschildert hast, kann es in solchen Fällen eventuell gar nicht ausreichend sein, einfach den Usernamen auf 012345 zu setzen, wie wir das im Moment tun, wenn jemand sienen Account löscht.

Bye
Frederik

woodpeck wrote:

ist uns egal, mit Nutzerdaten darf jeder machen, was er will"? Oder schadet es eher, weil es eine Sicherheit vorgaukelt, die keine ist?

das ist imho nicht der Punkt. Der Punkt ist: wir müssen zusehen, wie wir einerseits die Edits anonymer machen (können) und andererseits, wie man das (nicht nur) Noobs vermittelt, dass sie (noch) nicht anonym sind. Die Policy zählt da für mich nicht als Argument. Gibt Hunderte Policies, die weder bindend noch nachvollziehbar sind (Ja, ich hab die Osm-Policie auch nicht gelesen)

Tatsache ist: Im Moment kann ich, ohne mich zu verstecken, ganz frech eine Webseite machen, auf der immer steht, was der Bernhard H. in der letzten Woche so am Rechner gemacht hat (in OSM zumindest). *Das* könnten wir schon unterbinden. Die Info kann ich dann immer noch rausfinden, aber ich kann sie nicht mehr frech ins Web blasen.

Rechtlich kann man (in einer Policy) das unterbinden, ja. Aber wie Du und andere selbst indirekt sagst, hat das keinen Wert. Jeder Interessent weltweit ist in der Lage CSe von User_XY zu analysieren.

Ein kleiner Punkt ... imho ... kann sein, dass Dumps nicht mehr full-dumps sein dürfen. Sondern reine Daten-dumps. Das macht Tools wie von Pascal oder overpass etc. kaputt, aber da kann man auch Wege finden. Man könnte bspw. via Opt-In die User-History an solche Dienste abgeben.

Hätte nicht nur Vorteile für den Datenschutz, sondern auch für die DL-Grösse und die Weiterverarbeitbarkeit.

woodpeck wrote:

Oder schadet es eher, weil es eine Sicherheit vorgaukelt, die keine ist?

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.

Bernhard Hiller wrote:

Damit könnte ich auch den gegenteiligen Vorschlag machen: gleich klipp und klar sagen, daß hier nichts anonym sein kann.

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

whb wrote:

Letzten Sommer kam mir einer im Wald entgegen und fragte mich "Auch für OSM unterwegs?". 🙂
Als Insider erkennt man sich gelegentlich gegenseitig.

Nicht immer: "Na, auch Pokemon?"

The times they are a-changin'

Gruss
walter

...ohne alles zu lesen.. 😉

woodpeck wrote:

• Man könnte Benutzernamen komplett verschleiern (z.B. ersetzen durch zufällige Zahlen) - aber wie dann Reputation ermöglichen und Vandalismus unterbinden?
  

• Es wäre möglich, bei Verstecken von Usernamen trotzdem ein Reputationssystem zu haben, indem man das Reputations-Scoring der Webseite anvertraut: "Du siehst nicht, welcher User hier in Deiner Strasse editiert hat, aber er hat einen Reputations-Score von 4.8"
  

• Bei der Wikipedia gibt es Statistiktools ähnlich wie Pascals Tools, die vom Benutzer ein opt-in erfordern, sonst erscheint er nicht auf der Liste. Aber jeder kann sich die Daten runterladen und auch ohne opt-in eine Statistik selber rechnen
  

• Man könnte eine Statistikseite wie die von Pascal hinter einen Login stellen als kleine Hürde
  

• Man könnte die Genauigkeit/Schärfe von Metadaten im Lauf der Zeit verringern, d.h. zu Sachen, die 1 Jahr alt sind, geben wir vielleicht nur noch einen Timestamp mit Tag raus und keine Uhrzeit mehr oder so
  

• Egal, was wir tun oder nicht tun, wir sollten eventuell dafür sorgen, dass neue Benutzer ganz genau wissen, was sie tun und was über sie später ermittelbar ist. Derzeit steht das in unserer Privacy Policy, aber wer liest die schon...
  

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 😎

In der Arbeit würden wir dazu... Aufbewahrungsfristen sagen... Wie lange muss was aufgehoben werden.. 1,3,5,10 Jahre oder dauerhaft.. 🤔 interessante Sache... 🙂

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

miche101 wrote:

Dann hätte man 2 Jahr Gewährleistung... Mängelhaftung... Dann ist es vorbei... Dann könnte man die Unterlagen wegschmeißen...

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.

--ks

PS: Gab’s Pünktchen im Sonderangebot?

kreuzschnabel wrote:

PS: Gab’s Pünktchen im Sonderangebot?

Ja gab es im Sonderangebot beim Aldi,........... Magst a a paar? .......... 😉

Hakuch wrote:

Zum Beispiel: Wenn sie sich des Problems einmal bewusst sind, haben Sie vielleicht Hemmungen gewisse Daten an gewissen Orten aufzunehmen. Ist wie gesagt bei mir selbst so, weil ich kein Interesse daran hab dass alle Welt einfach nachschauen kann in welchen Gegenden ich mich so rumtreibe.

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.

Hallo,

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.

Gruß

margin-auto wrote:

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.

margin-auto wrote:

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?
Gruß

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

geomehr wrote:

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

Bye
Frederik

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/openst … /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.

Simon

SimonPoole wrote:

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...".

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.

SimonPoole wrote:

...dass sich bis jetzt nur 4 Leute aus DACH sich auf https://github.com/openstreetmap/openst … /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...

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.

Hakuch wrote:

Der einzige aber sehr wichtige Knackpunkt ist, dass wenn ich EINER app zugang dazu geben muss dann gleich ALLE sie abfragen können.

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.

Hakuch wrote:

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

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.

Simon

SimonPoole wrote:

grundsätzlich kreiert der PR eine neue Permission, die es erlaubt, dass eine App auf die e-mail Adresse zugreift.

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.

mmd wrote:

SimonPoole wrote:

grundsätzlich kreiert der PR eine neue Permission, die es erlaubt, dass eine App auf die e-mail Adresse zugreift.

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.

Wir schon im PR Kommentar geschrieben, ich finde die Idee ja durchaus gut, nur implementiert der PR sie nicht .....

PR=?

wambacher wrote:

PR=?

"Pull Request". So heisst ein Änderungsvorschlag bei git (der besprochene z.B.).

"Vorschlag" nicht im Sinne von "ich will, dass es jemand macht" (das heisst dort "Issue"), sondern im Sinne von "ich habs gemacht, schaut Euch das an. Wollt Ihr den Code?".

wambacher wrote:

PR=?

Kommt auch noch bald auf dich zu: PullRequest 😉

wambacher wrote:

PR=?

pull request

maxbe wrote:

"Pull Request"

aso, konnte mich mental nicht von "Press Release" lösen 😉

SimonPoole wrote:

mmd wrote:

SimonPoole wrote:

grundsätzlich kreiert der PR eine neue Permission, die es erlaubt, dass eine App auf die e-mail Adresse zugreift.

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.

Wir schon im PR Kommentar geschrieben, ich finde die Idee ja durchaus gut, nur implementiert der PR sie nicht .....

Macht nichts, wir machen jetzt erstmal etwas Lobbyarbeit: https://www.openstreetmap.org/user/mike … iary/40882

Hi,

als erstes Sorry, dass ich mich erst jetzt hier zu Wort melde.
Ich bin ja so ein bisschen der Ursprung für das ganze Unheil 😉

Ehrlich gesagt hätte ich eine stärkere/größere Diskussion hier auf
der ML oder auch im Forum bzgl. des Datenschutzes erwartet. Zumindest
vor ein paar Jahren wollte doch der ein oder andere rechtlich gegen
mich vorgehen.

Grundsätzlich vertrete ich die Meinung, dass die Metadaten, die beim
Mappen entstehen, weiterhin verfügbar sein sollten, wenn nicht sogar
müssen. Andernfalls sehe ich keine Chance um z.B. gegen Vandalismus
vorgehen zu können. Als erster Schritt sollten wir also auf alle Fälle
versuchen, neue Mitglieder bei der Registrierung ordentlich darauf
hinzuweisen, dass beim Erfassen der Geodaten auch die Metadaten
gespeichert werden und verfügbar sind. So wie es bereits von Frederik
oder auch anderen beschrieben wurde.

Auf der anderen Seite, sollten wir aber auch versuchen die Mapper
nicht komplett "gläsern" und für alle abrufbar zu gestalten. Als ersten
Schritt habe ich daher zumindest HDYC[1] hinter den bekannten OAuth
Login[2] von OSM.org gebracht. Viele von euch hatten ja bereits
signalisiert, dass sie so etwas begrüßen würden.

Hoffe damit zumindest schon einen kleinen Teil beigetragen zu haben.

Viele Grüße
Pascal

PS: Dieser Text wurde auch auf der deutschen OSM ML [3] gepostet.

[1] https://hdyc.neis-one.org
[2] http://wiki.openstreetmap.org/wiki/OAuth
[3] https://lists.openstreetmap.org/piperma … 14033.html

PT-53 wrote:

woodpeck wrote:

Wir haben dann über eine konkrete Idee etwas detailierter gesprochen, und zwar: Was wäre, wenn wir Benutzerdaten (also *wer* hat etwas editiert) grundsätzlich nur angemeldeten OSM-Benutzern zur Verfügung stellen würden?

Das würde ich sehr begrüssen.

+1 Ich sende öfter Links zu Objekten an Nicht-OSMler, auch zur Illustration, dass OSM keine Karte sondern eine Datenbank ist. Die Benutzerdaten sind dabei erst mal ohne Belang.

Pascal hat das (seit heute?) bereits umgesetzt - http://hdyc.neis-one.org ist nur noch nach Login einsehbar.

edit: 4 Minuten zu spät 😉

pitscheplatsch wrote:

[...] Als ersten
Schritt habe ich daher zumindest HDYC[1] hinter den bekannten OAuth
Login[2] von OSM.org gebracht. Viele von euch hatten ja bereits
signalisiert, dass sie so etwas begrüßen würden.
[...]

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

Ich bin mir zwar dessen bewusst, dass ich durch mein Mappen "aufspuerbar" bin, tragikomischerweise trage ich aber gerade auch deshalb hier bei, weil ich der Meinung bin, dass man mit OSM "Schnueffel-" bzw. "Google-"freie Karten zur Verfuegung stellen kann.

Prima Sache. Da ich nach erfolgter OAuth-Anmeldung meine Benutzertokens auch unverschlüsselt durch die Gegend schicken kann (via [1]), könnte sie völlig hypothetisch gesprochen auch jemand abschnorcheln und damit in meinem Namen weitere Anfragen machen. Besser wäre, wenn die Seite nach der Anmeldung dann durchgängig nur noch HTTPS nutzen würde. Ansonsten +1.

[1] http://hdyc.neis-one.org/

Gppes wrote:

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

Keine Panik, das ist erst in Diskussion und heute noch nicht der Fall, siehe diesen Thread weiter oben.

Hi,

Gppes wrote:

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

eine ähnliche Frage kam auch gerade auf der ML.

Beim Zugriff auf die User Preferences sind nur Daten enthalten,
die auch so hier öffentlich[1] oder über die API hier[2] abrufbar sind
(soweit ich mir das angeschaut habe). Die EMail-Adresse ist nicht dabei.

Hoffe das hilft etwas weiter.

Viele Grüße
Pascal

[1] http://www.openstreetmap.org/user/pitscheplatsch
[2] osm.org/api/0.6/user/52626

pitscheplatsch wrote:

Als erster Schritt sollten wir also auf alle Fälle versuchen, neue Mitglieder bei der Registrierung ordentlich darauf hinzuweisen, dass beim Erfassen der Geodaten auch die Metadaten gespeichert werden und verfügbar sind.

+1, bin ich, wie in #27 zu lesen ist, ganz klar dafür 🙂

Hi,

mmd wrote:

Prima Sache. Da ich nach erfolgter OAuth-Anmeldung meine Benutzertokens auch unverschlüsselt durch die Gegend schicken kann (via [1]), könnte sie völlig hypothetisch gesprochen auch jemand abschnorcheln und damit in meinem Namen weitere Anfragen machen. Besser wäre, wenn die Seite nach der Anmeldung dann durchgängig nur noch HTTPS nutzen würde. Ansonsten +1.

[1] http://hdyc.neis-one.org/

in meinem Post hatte ich extra httpS://hdyc.neis-one.org geschrieben.

Viele Grüße
Pascal

pitscheplatsch wrote:

in meinem Post hatte ich extra httpS://hdyc.neis-one.org geschrieben.

Klar, das passt schon. Mir ging es nur um die Leute, die aus welchen Gründen auch immer per HTTP auf die Seite gelangen.

pitscheplatsch wrote:

Gppes wrote:

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

(...)

Beim Zugriff auf die User Preferences sind nur Daten enthalten,
die auch so hier öffentlich[1] oder über die API hier[2] abrufbar sind
(soweit ich mir das angeschaut habe). Die EMail-Adresse ist nicht dabei.

(...)

[1] http://www.openstreetmap.org/user/pitscheplatsch
[2] osm.org/api/0.6/user/52626

Etwas mehr ist es glaube ich schon.
Wenn es die selben Informationen wären, wie sowieso schon öffentlich zugänglich, bräuchte es kaum eine extra Berechtigung diese zu lesen.
Wenn ich mich richtig erinnere, erlaubt die Berechtigung den Zugriff auf (man muss seine eigenen Zugangsdaten eingeben, dann bekommt man die Info):
https://www.openstreetmap.org/api/0.6/user/details

Das ist dann das Ergebnis (habe ich hier mit "x" unkenntlich gemacht):

<osm␣version="0.6"␣generator="OpenStreetMap␣server">
<user␣id="x"␣display_name="x"␣account_created="x">
<description>x</description>
<contributor-terms␣agreed="x"␣pd="x"/>
<roles>x</roles>
<changesets␣count="x"/>
<traces␣count="x"/>
<blocks><received␣count="x"␣active="x"/></blocks>
<languages>x</languages>
<messages><received␣count="x"␣unread="x"/><sent␣count="x"/></messages>
</user>
</osm>

Die E-Mail-Adresse ist da sicher nicht dabei.
Diese ist bisher mit keiner Berechtigung zugänglich.
Deshalb läuft hier auch eine Diskussion, ob eine neue Berechtigung eingeführt werden soll, welche den Zugriff auf diese dann erlauben würde, falls der Benutzer diese Berechtigung erteilt:
https://github.com/openstreetmap/openst … /pull/1431

Viele Grüße,
whb

whb wrote:

Etwas mehr ist es glaube ich schon.

Das ist dann das Ergebnis (habe ich hier mit "x" unkenntlich gemacht):

<osm␣version="0.6"␣generator="OpenStreetMap␣server">
<user␣id="x"␣display_name="x"␣account_created="x">
<description>x</description>
<contributor-terms␣agreed="x"␣pd="x"/>
<roles>x</roles>
<changesets␣count="x"/>
<traces␣count="x"/>
<blocks><received␣count="x"␣active="x"/></blocks>
<languages>x</languages>
<messages><received␣count="x"␣unread="x"/><sent␣count="x"/></messages>
</user>
</osm>

ja, danke, du hast Recht.

Ohne die Anforderung von irgendeiner Berechtigung habe ich den OSM OAuth von hier[1] aber nicht funktionsfaehig bekommen.

Viele Grüße
Pascal

[1] https://github.com/osmlab/osm-auth

hdyc...

mmd wrote:

Leute, die aus welchen Gründen auch immer per HTTP auf die Seite gelangen.

... z.B. über's wiki, die Stats-Seite oder mal im wiki nach 'hdyc' suchen. So einfach kommt man als Otto-Normal-User auf http-hdyc-Seiten 😉

Gppes wrote:

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

Die "user preferences" sind ein (sehr) wenig genutztes Feature um ein Key-Value Datastore für jeden Nutzer zu haben, siehe auch http://wiki.openstreetmap.org/wiki/API_ … ed-in_user

Eine mögliche Nutzung wäre zum Beispiel irgendwelche Einstellungen einer App zu speichern.

Hat also nichts mit e-mail oder so zu tun. Falls mal irgendwann die Option die e-mail Adresse freizugeben kommt, gehe ich schon davon aus, dass die OSMF das bekanntgeben würde und dann natürlich auch die Privacy Policy angepasst würde.

Simon

RoterEmil wrote:

hdyc...

mmd wrote:

Leute, die aus welchen Gründen auch immer per HTTP auf die Seite gelangen.

... z.B. über's wiki, die Stats-Seite oder mal im wiki nach 'hdyc' suchen. So einfach kommt man als Otto-Normal-User auf http-hdyc-Seiten 😉

Ich war mal so frei und habe HTTPS daraus gemacht. Die URL befindet sich aber auch an zig anderen Stellen im Wiki.

Die Änderung bzgl. OAuth empfinde ich als einen sinnvollen Schritt. Gleichzeitig sind Metadaten sehr wichtig für OSM denke ich. Nicht nur um Vandalismus effektiv bekämpfen zu können, auch um überhaupt lokale Communities aufbauen und halten zu können.

SimonPoole wrote:

Gppes wrote:

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

Die "user preferences" sind ein (sehr) wenig genutztes Feature um ein Key-Value Datastore für jeden Nutzer zu haben, siehe auch http://wiki.openstreetmap.org/wiki/API_ … ed-in_user

Eine mögliche Nutzung wäre zum Beispiel irgendwelche Einstellungen einer App zu speichern.

Die Berechtigung erlaubt aber nicht nur den Lesezugriff auf
https://www.openstreetmap.org/api/0.6/user/preferences
sondern auch auf
https://www.openstreetmap.org/api/0.6/user/details
Wenn ich mich da jetzt nicht komplett täusche?

Viele Grüße,
whb

pitscheplatsch wrote:

Ohne die Anforderung von irgendeiner Berechtigung habe ich den OSM OAuth von hier[1] aber nicht funktionsfaehig bekommen.

Jupp, dem ist so, und laut API ist "read user preferences" das einzig "lesende" Recht (außer private GPS Traces lesen zu dürfen, was vermutlich aber noch schlimmer ist).
Es bräuchte also für diesen Zweck, wo man nur feststellen möchte, ob sich jemand erfolgreich gegen openstreetmap.org authentifiziert hat, eine neue Berechtigung "is_authenticated"

whb wrote:

Die Berechtigung erlaubt aber nicht nur den Lesezugriff auf
https://www.openstreetmap.org/api/0.6/user/preferences
sondern auch auf
https://www.openstreetmap.org/api/0.6/user/details
Wenn ich mich da jetzt nicht komplett täusche?

Nein, du täuschst dich nicht.

Und um nochmal die Unterschiede der Daten durch die unterschiedlichen Möglichkeiten des Abrufes darzustellen:

Durch die öffentliche API (ohne irgendeinen Login) erhält man in meinem Fall

<osm␣version="0.6"␣generator="OpenStreetMap␣server">
<user␣id="92644"␣display_name="Harald␣Hartmann"␣account_created="2009-01-19T07:09:19Z">
<description>
[OSM␣Wiki](https://wiki.openstreetmap.org/wiki/User:Haribo)␣[OSM␣Forum](http://forum.openstreetmap.org/profile.php?id=65376)␣[OSM␣Help](https://help.openstreetmap.org/users/10952/harald-hartmann)␣[mapillary](https://www.mapillary.com/profile/haribo)
</description>
<contributor-terms␣agreed="true"/>
<img␣href="http://api.openstreetmap.org/attachments/users/images/000/092/644/original/30bfe23411ce9e2e2a3b0cdda516e117.jpg"/>
<roles></roles>
<changesets␣count="510"/>
<traces␣count="0"/>
<blocks>
<received␣count="0"␣active="0"/>
</blocks>
</user>
</osm>

Die einzige Information darin, die ich nicht durch normales Grabben der öffentlichen Benutzerseite (ohne irgendeinen Login) erhalte ist die Anzahl der "blocks"

Meine Details (nach erfolgreichem Login/OAuth)

<osm␣version="0.6"␣generator="OpenStreetMap␣server">
<user␣id="92644"␣display_name="Harald␣Hartmann"␣account_created="2009-01-19T07:09:19Z">
<description>
[OSM␣Wiki](https://wiki.openstreetmap.org/wiki/User:Haribo)␣[OSM␣Forum](http://forum.openstreetmap.org/profile.php?id=65376)␣[OSM␣Help](https://help.openstreetmap.org/users/10952/harald-hartmann)␣[mapillary](https://www.mapillary.com/profile/haribo)
</description>
<contributor-terms␣agreed="true"␣pd="true"/>
<img␣href="http://api.openstreetmap.org/attachments/users/images/000/092/644/original/30bfe23411ce9e2e2a3b0cdda516e117.jpg"/>
<roles></roles>
<changesets␣count="510"/>
<traces␣count="0"/>
<blocks>
<received␣count="0"␣active="0"/>
</blocks>
<home␣lat="50.5175"␣lon="10.8698"␣zoom="3"/>
<languages>
<lang>de-DE</lang>
<lang>de</lang>
<lang>en-US</lang>
<lang>en</lang>
</languages>
<messages>
<received␣count="121"␣unread="0"/>
<sent␣count="144"/>
</messages>
</user>
</osm>

erlauben dann noch den Zugriff auf die Informationen "home", "languages" und "messages"

Interessant wäre ein vom Nutzer selbst konfigurierbarer Opt-Out bzgl. Teilnahme an personenbezogener Statistiken. Heißt, der Nutzer setzt in seinen Einstellungen einen Haken à la "[x] Teilnahme an personenbezogenen Statistiken nicht erwünscht", was keinen Einfluss auf die gespeicherten oder beziehbaren Metadaten haben soll, von Tools wie hdyc jedoch berücksichtigt werden sollte. Bei hdyc könnte dann einfach die Nutzerseite leer bleiben.

Ich sehe dabei aber auch direkt wieder Nachteile. Einmal könnte diese Funktion gegenteilig verwendet werden in dem gezielt nach Nutzern gesucht wird, die diesen Haken gesetzt haben. Beispielsweise um sich danach anzuschauen was und wo diese Nutzer editieren, und wo sie ggf. wohnen könnten. Andererseits muss man vermutlich auch diese Opt-Out-Beschreibung juristisch geschickt wählen um darauf hinzuweisen, dass die ganze Sache ausschließlich Tool-seitig berücksichtigt werden muss und dennoch genauso viele Daten wie vorher gespeichert und abrufbar sind.

Einerseits gibt man dem Nutzer dann ein die Möglichkeit, im gewissen Maße der Nutzung seiner Metadaten zu widersprechen. Andererseits wiegen sich dann viele im falschen Glauben. Vielleicht schon Grund genug, sowas doch nicht zu machen?

Meinungen dazu? 🙂

whb wrote:

SimonPoole wrote:

Gppes wrote:

Sorry, bin echt schon verunsichert, was bedeutet bei der OAuth Abfrage noch mal:

Allow the client application to:
[x] read your user preferences.

Z.B. moechte ich meine Email unter keinen Umstaenden und zu keinem Zeitpunkt an dritte ausgehaendigt wissen.

Die "user preferences" sind ein (sehr) wenig genutztes Feature um ein Key-Value Datastore für jeden Nutzer zu haben, siehe auch http://wiki.openstreetmap.org/wiki/API_ … ed-in_user

Eine mögliche Nutzung wäre zum Beispiel irgendwelche Einstellungen einer App zu speichern.

Die Berechtigung erlaubt aber nicht nur den Lesezugriff auf
https://www.openstreetmap.org/api/0.6/user/preferences
sondern auch auf
https://www.openstreetmap.org/api/0.6/user/details
Wenn ich mich da jetzt nicht komplett täusche?

Viele Grüße,
whb

Siehe https://github.com/openstreetmap/openst … ssues/1530

mmd wrote:

pitscheplatsch wrote:

in meinem Post hatte ich extra httpS://hdyc.neis-one.org geschrieben.

Klar, das passt schon. Mir ging es nur um die Leute, die aus welchen Gründen auch immer per HTTP auf die Seite gelangen.

Ist es nicht möglich, HTTP-Aufrufe automatisch auf HTTPS umzuleiten? Ich meine mich zu erinnern, dass es Websites gibt, die einen, wenn man sie mit http://www.beispiel.com aufruft, automatisch auf https://www.beispiel.com landen lassen, sodass man sie nicht einmal versehentlich über HTTP abfragen kann. Das wäre vielleicht in diesem Fall ganz praktisch. Oder irre ich mich, oder hat das andere Nachteile?

Chrysopras wrote:

Ist es nicht möglich, HTTP-Aufrufe automatisch auf HTTPS umzuleiten?

Ja, klar. Ich persönlich ärgere mich aber oft über solche Websiten, weil ich als Nutzer gern entscheiden möchte, wie ich die Seite aufrufe. Erst neulich war ich wieder in einem Hochschul-Netz unterwegs, aus dem ich bestimmte HTTPS-Seiten nicht aufrufen konnte, weil irgendwie der Zwangsproxy damit ein Problem hatte, und wenn einen die Seite dann noch auf HTTPS zwingt, geht gar nichts mehr. Da sagen die HTTPS-Fundamentalisten dann "tja Pech gehabt, wenn alle sich an die Standards halten würden, gäbe es das Problem nicht", aber davon kann ich mir nichts kaufen...

Bye
Frederik

woodpeck wrote:

Da sagen die HTTPS-Fundamentalisten dann "tja Pech gehabt, wenn alle sich an die Standards halten würden, gäbe es das Problem nicht", aber davon kann ich mir nichts kaufen...

Nunja, Pascals Seite wird in diesem Fall wohl eh nicht funktionieren, weil die Anmeldung über openstreetmap.org sehr wohl HTTPS nutzt. Momentan könnte man das nur so umschiffen, indem man sich zu Hause anmeldet, dann darauf hofft, dass das Cookie das Jahr lang unbeschadet überlebt und keine weitere Anmeldung mehr notwendig ist.

Generell macht es halt nicht soviel Sinn, wenn ich zunächst die Anmeldung über HTTPS mache und später die Tokens einfach so herumschicke. Mag im konkreten Fall nicht so schlimm sein, ist aber nicht gerade 'best practise'.

In dem Fall würde ich mich auch als https-hardliner bezeichnen und hab auf fast allen meinen Instanzen eine Zwangsweiterleitung eingerichtet (was übrigens sehr einfach ist). Ist halt leider der einzige Weg solche (Uni)Netzwerke dazu zu zwingen, mit Umweg die Endnutzer-innen zu "quälen" damit die sich bei der Netzwerkverwaltung beschweren.

Wär schön wenn man entsprechende Fehlermeldungen platzieren könnte statt einfach nur "keine Verbindung" zu bekommen.

Aber zum Thema: ich fände eine feinere Definition der permissions fürs oauth, also ein "is_authenticated" statt "read_preferences" auch für sehr sinnvoll. Ich bin auch immer sehr irritiert über diesen Text weil ich dann ersteinmal denke "was will die app denn von meinen Einstellungen wissen?" Was dann wieder dazu führt, dass Leute trainiert werden so etwas zuzulassen wo es vielleicht echt nicht notwendig wäre.

Hakuch wrote:

Aber zum Thema: ich fände eine feinere Definition der permissions fürs oauth, also ein "is_authenticated" statt "read_preferences" auch für sehr sinnvoll. Ich bin auch immer sehr irritiert über diesen Text weil ich dann ersteinmal denke "was will die app denn von meinen Einstellungen wissen?"

Genauso geht es mir auch. Daher +1 für ein "is_authenticated" o.Ä.

Chrysopras wrote:

Hakuch wrote:

Aber zum Thema: ich fände eine feinere Definition der permissions fürs oauth, also ein "is_authenticated" statt "read_preferences" auch für sehr sinnvoll. Ich bin auch immer sehr irritiert über diesen Text weil ich dann ersteinmal denke "was will die app denn von meinen Einstellungen wissen?"

Genauso geht es mir auch. Daher +1 für ein "is_authenticated" o.Ä.

auch ein +1 von mir.

Wie bereits erwähnt, ich wollte ohne irgendwelche Permissions die Authentifizierung in HDYC integrieren, was mir aber leider nicht gelungen ist. Laut OAuth Spec (2.0?) sollte es aber auch vom Standard irgendeine Funktion dafür geben. Ich weiß es aber gerade leider nicht mehr ganz genau. Vom OSM Server wird sowas nicht angeboten.

Bis jetzt bin ich aber ehrlich gesagt ziemlich positiv überrascht. Die "Beschwerden" über den jetzt vorhanden Login auf HDYC kann ich an einer Hand abzählen. Was ich oder auch ihr allerdings häufiger machen muss, ist zu erklären, warum ich die "read_preferences" einfordere und was diese überhaupt sind. Hier herrscht anscheinend etwas Unklarheit, was ich jetzt aber nicht schlimm finde. Sollen die Leute lieber fragen, anstatt alles anzuhaken und zu klicken.

Viele Grüße
Pascal

PS: Aktuell mach ich mir ein paar Gedanken, wie HDYC Profile auf expliziten Wunsch public (ohne Login) einsehbar sein können. Derzeit tendiere ich zu einem Opt-In Parameter à la "Ja, bitte mein HDYC-Profil öffentlich & ohne Login anzeigen" auf der OSM User Profile Seite, ähnlich wie die "Related OSM Accounts". Dann kann das Jeder aktivieren wie er möchte.

pitscheplatsch wrote:

..Laut OAuth Spec (2.0?) sollte es aber auch vom Standard irgendeine Funktion dafür geben. ..

openstreetmap.org unterstützt OAuth 1.0a, OAuth 2.0 ist was wesentlich anderes.

Simon

Mir ist gerade folgender Feature Request von Nakaner aufgefallen, wo es darum geht, Geofabrik-Extrakte ohne (oder nur mit eingeschränkten) Metadaten anzubieten, zumindest für öffentlich frei verfügbare Downloads.

https://github.com/osmcode/libosmium/issues/241 wrote:

Geofabrik currently evaluates its download service in regard with privacy regulation which seems to force us to remove some metadata from our public downloads: user names, user IDs and changeset IDs. (These information would still be available to authenticated users)

Gibt's zu dem Thema inzwischen irgendwelche finalen Empfehlungen, OSMF-Entscheidungen oder was auch immer, die auch für andere Projekte ggfs. relevant wären?

mmd wrote:

Mir ist gerade folgender Feature Request von Nakaner aufgefallen, wo es darum geht, Geofabrik-Extrakte ohne (oder nur mit eingeschränkten Metadaten) anzubieten, zumindest für öffentlich frei verfügbare Downloads.

https://github.com/osmcode/libosmium/issues/241 wrote:

Geofabrik currently evaluates its download service in regard with privacy regulation which seems to force us to remove some metadata from our public downloads: user names, user IDs and changeset IDs. (These information would still be available to authenticated users)

Da kommt vsl. nächste Woche noch ein Schwung Testergebnisse, wie diverse Programme mit metadatenarmen und metadatenfreien OSM-Daten zurechtkommen.

mmd wrote:

Gibt's zu dem Thema inzwischen irgendwelche finalen Empfehlungen, OSMF-Entscheidungen oder was auch immer, die auch für andere Proekte ggfs. relevant wären?

Siehe dazu die Protokolle der LWG vom September und November 2017 (waren in der Wochennotiz verlinkt).

Hi,

pitscheplatsch wrote:

PS: Aktuell mach ich mir ein paar Gedanken, wie HDYC Profile auf expliziten Wunsch public (ohne Login) einsehbar sein können. Derzeit tendiere ich zu einem Opt-In Parameter à la "Ja, bitte mein HDYC-Profil öffentlich & ohne Login anzeigen" auf der OSM User Profile Seite, ähnlich wie die "Related OSM Accounts". Dann kann das Jeder aktivieren wie er möchte.

bin gerade an meinen Vorbereitungen für den FOSSGIS-Talk.
Habe dafür den Thread hier noch einmal durchgearbeitet und
dabei den Beitrag von mir gefunden.

Seit einiger Zeit könnt ihr euer HDYC Profile auch ohne Login verfügbar machen.
Das wurde doch von einiges Leuten bei mir angefragt.

Wenn ihr möchtet, dass eurer Profil ohne Login abgerufen werden kann,
müsst ihr, ähnlich zu den Related OSM Accounts, lediglich einen Link zu eurem
HDYC bei euch im OSM Profil hinzufügen. Spätestens nach 24h sollte es dann
public sein (eine OSM-Editierung vorausgesetzt in der Zeit).

Viele Grüße
Pascal

Hi,

Nakaner wrote:

mmd wrote:

Gibt's zu dem Thema inzwischen irgendwelche finalen Empfehlungen, OSMF-Entscheidungen oder was auch immer, die auch für andere Proekte ggfs. relevant wären?

Siehe dazu die Protokolle der LWG vom September und November 2017 (waren in der Wochennotiz verlinkt).

danke für das Posten.

Also in dem Bereich OSM-User/Meta-Informationen werden sich wegen der GDPR dann ein paar Sachen ändern.

Viele Grüße
Pascal

pitscheplatsch wrote:

Wenn ihr möchtet, dass eurer Profil ohne Login abgerufen werden kann, müsst ihr, ähnlich zu den Related OSM Accounts, lediglich einen Link zu eurem HDYC bei euch im OSM Profil hinzufügen.

Wieviele haben das denn, neben mir, bereits gemacht? Hast du da bereits eine Zahl?

Hi,

Harald Hartmann wrote:

pitscheplatsch wrote:

Wenn ihr möchtet, dass eurer Profil ohne Login abgerufen werden kann, müsst ihr, ähnlich zu den Related OSM Accounts, lediglich einen Link zu eurem HDYC bei euch im OSM Profil hinzufügen.

Wieviele haben das denn, neben mir, bereits gemacht? Hast du da bereits eine Zahl?

habe gerade in meiner DB nachgeschaut:
Aktuell haben etwas mehr als 300 User einen Link zu HDYC in ihrem OSM Profil.

Weil es gerade in den Kontext passt:
Ca. 220 User haben mind. oder mehr als 3 Related OSM Accounts angegeben.

Viele Grüße
Pascal

Bin mir nicht sicher, ob das hier her gehört bzw. schon betrachtet wird...

Im Mai tritt in Österreich die DatenSchutzGrundVerOrdnung (lt. EU) in Kraft. Im Wesentlichen bedeutet das (und ich bin kein Jurist), dass bereits Name/Adresse/Kontaktdaten als personenbezogene Daten gelten (d.h. bereits die Speicherung einer Telefonnummer zu nicht privaten Zwecken ist betroffen!) und alle diesbezüglichen Bestimmungen (Einwilligung/Beauskunftung/Richtigstellung/Löschung/Datenübertragbarkeit, Verarbeitungsverzeichnis etc.) zu befolgen sind. Gilt auch für Vereine. Das betrifft m.E. nicht nur osm-User, sondern auch alle in osm abgelegten derartigen Daten (und macht mittelbar alle Nutzer dieser Daten zu potentiellen Verarbeitern).

Siehe auch:

DSGVO
DSGVO bei der Wirtschaftskammer

Grüße
wolfbert

wolfbert wrote:

Bin mir nicht sicher, ob das hier her gehört bzw. schon betrachtet wird...

Im Mai tritt in Österreich die DatenSchutzGrundVerOrdnung (lt. EU) in Kraft. Im Wesentlichen bedeutet das (und ich bin kein Jurist), dass bereits Name/Adresse/Kontaktdaten als personenbezogene Daten gelten (d.h. bereits die Speicherung einer Telefonnummer zu nicht privaten Zwecken ist betroffen!) und alle diesbezüglichen Bestimmungen (Einwilligung/Beauskunftung/Richtigstellung/Löschung/Datenübertragbarkeit, Verarbeitungsverzeichnis etc.) zu befolgen sind. Gilt auch für Vereine. Das betrifft m.E. nicht nur osm-User, sondern auch alle in osm abgelegten derartigen Daten (und macht mittelbar alle Nutzer dieser Daten zu potentiellen Verarbeitern).

Das ist seit Monaten immer mal wieder in der Wochennotiz erwähnt worden. Man sollte sie halt bis zum Ende lesen und nicht nach Ende des Abschnitts "Community" aufhören. Danach kommen nämlich die wirklich wichtigen Dinge.

Es gibt neue Minutes von der LWG - Zitat aus der Wochennotiz Nr. 399

"Das Protokoll der Sitzung der Licensing Working Group vom 8. März ist online. Themen waren u. a. die Datenschutz-Grundverordnung und der Jugendschutz."

--> https://docs.google.com/document/d/1O_L … C2dmU/edit

Um das weitere Vorgehen hier auch etwas zu dokumentieren:
"Die Datenschutzgrundverordnung (engl. GDPR) der EU, die Ende Mai in Kraft tritt,
erfordert zahlreiche Änderungen am OSM-Projekt und wird die seit dem Lizenzwechsel
im Jahr 2012 größte Veränderung am OpenStreetMap-Projekt sein. Die LWG hat ihre
Empfehlungen in einem längeren Dokument (PDF) zusammengefasst..." (Quelle)

Vorgestellt wurde es auf der OSM-Talk und OSMF-Talk Mailing Liste von Simon.
Dort können auch weitere Fragen zu dem Thema nachgelesen werden.