Peter Wendorff schrieb: > Also bietest Du als Alternative für ein nur sehr eingeschränkt > funktionierendes System ein System, was genauso eingeschränkt > funktioniert
Nein, ein eingeschränkter Missbrauchsschutz (da der Missbrauch auch auf Seite des Missbrauchenden aufwändiger wird) als Ersatz für ein technisch wirkungsloses System. > >> - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal > >> was committen, einen eigenen entwicklerspezifischen API-Key haben > >> müssen? > > > > Bereits nötiger User-Account. > > Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht > die mit JOSM osm-Daten hochladen. Ahso :) Ja, die müssten sich dann natürlich einen API-Key holen (oder eben, siehe andere Mail – diskutieren in zwei Thread-Zweigen ist irgendwie anstrengend – ihren User-Account nutzen). > Also nicht für jeden Entwickler einen Key, sondern sogar für jeden > User. Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden > einzelnen User tracken können (denn nichts anderes tust du damit). Ja, wie mit dem Useraccountzwang beim Commiten von Geodaten an OSM. Das ist 1:1 übertragbar. Zudem würde eine einmalige Authentifizierung innerhalb der Anwendung völlig ausreichend sein. Alternative: Die Anwendung bekommt durch Anmeldung mit den OSM-Userdanten innerhalb eben dieser Anwendung einen usergebundenen Token, mit dem sie sich an der API anmelden kann, und erhält dadurch einen nicht mehr usergebundenen Token, der diese Installation der Anwendung legitimiert, die API zu nutzen. Somit ist nicht nachvollziehbar, welcher User über die Anwendung auf die API zugreift, sondern nur, DASS ein Zugriff stattfindet. Im Falle des Missbrauchs kann der jeweilige Token (automatisiert) gesperrt werden. User, die mehrmals für die selbe Anwendung einen Token durch Anmeldung mit den OSM-Daten anfordern, können dies nur in einem Abstand von N Zeiteinheiten pro Account, müssten also erst Abwarten, oder einen neuen Account anlegen, um Token zu „sammeln“. Natürlich ist dies mit Programmieraufwand und zusätzlichen Ressourcen verbunden, aber ich wiederhole mich da: Sicherheit und Bequemlichkeit schließen sich aus. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2014-02-16T21:50:31+0100
signature.asc
Description: PGP signature
_______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
