[Talk-de] Mapnik Administration blockt QLandkarteGT

Peter Wendorff wendorff at uni-paderborn.de
So Feb 16 14:52:03 UTC 2014


Am 16.02.2014 15:13, schrieb Dirk Sohler:
> Peter Wendorff schrieb:
>> Also kannst Du Anwendung und Browser voneinander unterscheiden?
> 
> Mittels anwendungsspezifischem Token, der aufgrund der API nur durch
> entsprechende Header übermittelt werden kann eher, als über einen
> simplen String, in den jeder reinschreiben kann, was er will.
Wenn jemand fälschen will, dann ist das auch da kein Problem, den Token
zieh ich mir eben von osm.org direkt.
Dazu gehört dann außerdem noch die Authentifizierung über alle
Tilecache-Instanzen etc pp - nicht grade wenig Aufwand für minimal mehr
Hilfe.
> 
> 
>> Abgesehen davon: Was ist ein Browser, was eine Anwendung?
> 
> Stelle dich doch bitte nicht bitte dümmer, als du bist.
> 
> Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten
> aufrufen kannst, und eben auch die OSM-Seite;
also:
Firefox, Thunderbird, Thunderbird-Adressbuch mit OSM-Karten-Erweiterung
(gibt's die? wär praktisch...),
Internet-Explorer, jede Anwendung, die die entsprechende
IE-ActiveX-Komponente benutzt, um Webseiten darzustellen,
wget (cool, kann www-Seiten aufrufen...),
...
 und Anwendung: Spezielles
> Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet
> wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen
> zu können.
Okay, also wenn meine App Twitternachrichten und OSM-Kacheln darstellt,
ist es demnach ein Browser?

> 
>> Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt?
> 
> In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein
> Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt,
> nein. 
Und wo ist der Unterschied zwischen WWW-Seite und API?
Du bist ja derjenige, der mit Umgehungsmöglichkeiten argumentiert.
Wenn ich also www.osm.org mit entsprechendem permalink aufrufe und alle
damit verbundenen Kacheln mit runterlade, ist das wieder ok? wenn ich
das hundertmal tue, auch?

Aber da du nur provozieren willst, brauche ich dir das sicher
> nicht zu erklären, da du es bereits weißt.

Ich will nicht provozieren.
Du kritisierst eine seit langem angewandte Praxis, die weitgehend
funktioniert; und hängst die auch noch an einem Fall auf, der
offensichtlich ja eben sogar gefunden wurde.
Du äußerst aber Kritik, ohne einen funktionierenden und mit vertretbarem
Aufwand umsetzbaren Gegenvorschlag anzubringen.

>> Inwiefern würde eine solche Lösung das Verfahren einfacher,
>> fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter
>> machen?
> 
> Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token
> geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht
> einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen
> Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert
> werden kann.
CLosed-Source - cool, also auch noch alle OpenSource-Software im
OSM-Ökosystem rausschmeißen, weil damit das System nicht funktioniert.
Ich glaube, du hast das Grundprinzip immer noch nicht verstanden, und
das heißt Fairness und Offenheit.

Das Tool von Github kann keiner mal eben forken, weil das Token nicht
drin ist (und nicht drin sein kann, denn sonst wär das ja nicht mehr
verschlüsselt), dafür muss man sich zusätzlich bei OSM anmelden -
wunderbar... - aber irgendwie eben nicht Offen.

> Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition
> weiter oben) ist, dass man eindeutig einen Useraccount identifizieren
> kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender
> sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch
> seiner Anwendung den Firefox-UA-String verpassen.
> 
> Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung
> eines simplen Strings fälschungssicher? Was hindert einen Entwickler,
> der alle Tiles runterladen will eher daran, das technisch umzusetzen?
> Ein beliebig änderbarer String, eine App-Registrierung um einen Token
> zu bekommen, oder die Notwendigkeit eines Useraccounts?
Abgesehen vom Aufwand auf dem Server, um die Token-Lösung einzusetzen -
wie würdest du das für, sagen wir, JOSM umsetzen wollen? Steht der Token
im Code und damit im SVN? Steht der Token nur im Build und auch da
Verschlüsselt? Wie passt das dann mit OpenSource zusammen? Soll sich
jeder Entwickler, der mal einen Patch einreicht, extra registrieren?

Und wenn ja, dann haben wir entsprechend hunderte Registrierungen, was
hindert dich als denjenigen, der sich hier als der Böse aufspielt, der
alles aushebeln kann, daran, deine Anwendung hundertmal zu registrieren
und und den Token immer wieder zu wechseln?

Sorry, irgendwie überzeugt mich das noch nicht.

Gruß
Peter




Mehr Informationen über die Mailingliste Talk-de