Peter Wendorff schrieb: > Unabsichtlichen Missbrauch verhindert es jedoch schon, denn einige > Entwickler kommen ja erst durch die Blockade auf die Idee, dass da > Server dahinterstecken, die nicht unlimitiert sind, und dass ein > Missbrauch in gewissem Ausmaß zu vermeiden ist.
Gut, der „ehrliche Entwickler“ wird seiner App sicher einen eindeutigen String geben können. Fraglich ist halt, in wie weit vermeintliche Browser-Zugriffe nun durch Apps steigen, bei denen der Entwickler einfach den String irgendeines weit verbreiteten Browsers angibt. … fraglich ist auch, wie ein Entwickler reagiert, wenn die OSM-Admins an in herantreten, weil seine App, identifiziert durch den User Agent, zu viel Traffic verursacht. Die Einfachste Variante wird da wohl sein, einfach einen Fantasie-UA, oder eben einen von einem Browser zu verwenden, anstatt aufwändig Caching, etc. zu implementieren. > Variante 1) gar nicht blockieren: halten die Server nicht aus. In wie weit Zugriffe ohne UA-String die Swrver mehr belasten als Zugriffe mit UA-String müsstest du mir noch mal erklären (würde der QLandkarteGT-Entwickler einfach einen User-Agent-String eintragen würde das die Zugriffe durch das Tool ja in keiner weise verringern) :) Wie der String nun tatsächlich lautet, scheint ja laut der Diskussion hier mehr oder weniger irrelevant zu sein, und sollte nur die Anwendung enthalten. Wobei eben das Problem bleibt, dass der String in seiner Gänze absolut rein gar nicht als irgendeine verlässliche Information ansehbar ist. Es könnte sogar derart verlaufen, dass – Achtung, konstruiert, aber nicht abwegig – ein Entwickler bewusst den UA-String einer Konkurrenzanwendung verwendet, und seine eigene Anwendung damit verbreitet, und auch Missbrauch betreibt. Die OSM-Admins sehen nur übermäßig viele Zugriffe einer Anwendung, und sperren die. Sobald das geschehen ist, wechselt der „Betrüger“ einfach seinen UA-String, und kann weiterhin damit werben, dass seine Anwendung die einzige ist, die XYZ kann, da die andere Anwendung gesperrt wurde. Wenn er das ganze mit Werbung oder kostenpflichtig vertreibt, eine nette Einnahmequelle – powered by OSM-Administration. > Den Admins einen Vorwurf zu machen halte ich an der Stelle aber für > falsch - zumindest, wenn kein gangbarer Alternativweg aufgezeigt wird, > und den sehe ich bei euch nicht. Eine Methode wäre, dass Anwendungen, die OSM-Daten nutzen wollen, registriert werden, und bei jedem API-Aufruf oder Start einen Token mitsenden müssen, der die App eindeutig als eben diese App ausweist. Oder dass der Zugriff nur mit einem OSM-Konto möglich ist, dass der User in der Anwendung eintragen muss. Idealer weise mit einfacherer Registrierung eines Kontos innerhalb der Anwendung, falls der Nutzer noch keinen OSM-Account hat. Gut, ein Token verhindert zwar auch den Missbrauch nicht, da bei OpenSource-Software jemand anderes einfach den Token kopieren und für seine eigene App nutzen kann, aber zuverlässiger als ein schon per Definition unsicherer String ist es allemal – Wobei ich die Account-Variante immer noch am sinnvollsten finde, da so nicht der Anwendungszugriff geloggt wird, sondern, wie viele Daten der einzelne User anfordert, den man dann gegebenenfalls gezielt sperren kann, anstatt die gesamte Anwendung zu blockieren. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2014-02-15T18:53:46+0100
signature.asc
Description: PGP signature
_______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
