Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo Frederik, _Präambel_ D a verstehe ich Dich gut und bin ganz Deiner Meinung: Machtkonzentration fuehrt fast immer zu einem oder mehreren der folgenden negativen Effekte: [..] all das bindet Zeit und Arbeitskraft Und macht oft viel Unmut und Ärger. Es ist mir ein wesentliches Anliegen, das zu verhindern. Und ich freue mich, dass Du so konsequent darauf achtest! Aber Macht ist nicht per se korrumpierend. Macht kommt von machen - ganz i.S.v. Opensource. Wer viel macht hat Macht. Sie kann auch konstruktiv eingesetzt werden. Beispielsweise zur Erzeugung von Qualität. (die Macher bei OSM sind lebendige Beispiele dafür) _Ziel_ Mir geht es um Folgendes: Stell Dir eine Benutzergruppe vor, für die zuverlässige Daten existentiell sind. Und die aber aus ideologischen oder ökonomischen Gründen kein proprietäres oder kommerzielles Material nutzen möchte. Ich würde mir wünschen, dass OSM mittelfristig solche Anforderungen erfüllen kann. 2011 ist durchaus ein realistisches Ziel: Ich könnte mir gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten automatisierte Prüfungen macht. Dazu hat Tobias in einem anderen Thrad vorgeschlagen, mit besonders geneuen amtlichen Referenzpunkten einen Pilotversuch zu machen und Erfahrungen zu sammeln. Ich würde mich freuen, wenn Du das aufgreifst. _Qualität_ Bei OSM gibt es keine zentrale, allen gemeinsame Definition von Qualitaet was der eine wegwirft, ist fuer den andren wertvoll Abgesehen von individuellen Vorlieben gibt es: - Verlässlichkeit - Genauigkeit - Vollständigkeit - Aktualität - Schnelligkeit - Übersichtlichkeit um nur die wichtigsten zu nennen. Unabhängig von einzelnen Zielen, macht es Sinn, insgesamt besser zu werden. Dafür braucht es eine Definition von besser. Und ein Mass, dieses zu messen. Und Verfahren, um den Zielen näher zu kommen. _Wege_ Ich bin für alle Wege offen. Und wir brauchen ja auch nichts übers Knie brechen. Deine Vorschläge gefallen mir gut und ich freue mich, wenn sie erfolgreich sind. Ich möchte aber auch, dass andere Ideen diskutierbar sind und geprüft werden können (und nicht aus ideologischer Sicht verworfen werden). Gut fände ich, wenn wir Ideen anhand von operationalisierten Zielen prüfen. sorgfältige Eingangsprüfung Das wuerde eine Warteschlange von noch nicht genehmigten Aenderungen erfordern, zusammen mit einem Interface und einer privilegierten Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach denen sich diese privilegierte Personengruppe konstituiert. Das haben wir jetzt auch schon. Nur halt eben am Ende. Da gibt es eine privilegierte Personengruppe, die entscheidet, welche Daten wann und in welcher Form angezeigt werden. Theoretisch sind die Daten zwar von jedermann nutzbar, aber in der Praxis bestimmen die Anwendungsprogrammierer, wie das auszusehen hat. Und die Datensammler richten sich (meist) danach. Besser fände ich, wenn die Regeln offen diskutiert und kommuniziert würden. Ich bin als Datensammler sehr aufgeschlossen dafür, die Daten genau in dieser Form zu liefern, mit der ich optimale Karten und Routen erhalte. Wenn nun eine Benutzergruppe für ihre Anwendung besondere Anforderungen an die Daten hat, dann versuche ich diese Qualitätsmerkmale zu erfüllen. Dazu muss ich sie aber - kennen - verstehen - umsetzen können. Sowas sehen wir fruehestens 2011 Manchmal ist Opensource schneller als gedacht... und auch dann nur gegen meinen Widerstand ;-) Wie gesagt: Du hast meine volle Unterstützung gegen Machtmissbrauch! Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. sowas waere recht leicht ueber ein modifiziertes OSMXAPI machbar (es uebernimmt einfach nur gestempelte). Das klingt interessant! vielleicht ist gefilterter mirror ja dasselbe wie read-only In die Richtung koennte es gehen. Der Vorteil ist das basisdemokratische Element - jeder oder jede Gruppe entscheidet selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte Daten, steht diese Option nicht mehr offen. Ich schlage vor, wir fangen einfach mal an und sammeln Erfahrungen. Beispielsweise mit Referenzpunkten? Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo Frederik, danke für Deine wertvollen und detaillierten Vorschläge zur Qualitätssicherung! Ich denke, das sind zukunftsträchtige Ideen, die sich möglicherweise schon in den nächsten OSMXapi-Versionen wiederfinden könnten. - Aktuell besteht ja noch keine Notwendigkeit, denn entsprechend sicherheitsbedürftige Daten liegen noch nicht grossflächig vor (aber das kann sich bei der schnellen Entwicklung von OSM ja bald ändern). _sicherheitsrelevante Objekte_ Mein Wunsch ist es, für sicherheitsrelevante Objekte, beispielsweise ein Leuchtturm für die Schifffahrt, verlässliche Daten zu haben. Meine Idee war, dies über eine besonders sorgfältige - *Qualitätsprüfung bei der Dateneingabe*, und über eine - *red-only*-Funktion der geprüften Daten bei der Datenausgabe zu erreichen. Änderungen an den Daten würden dann genauso wie bei der Dateneingabe die Qualitätsprüfung durchlaufen. Damit wäre gewährleistet, dass Anwendungsprogramme bei sicherheitsrelevanten Objekten nur qualitätsgeprüfte Daten erhalten. Nach aussen würde sich nichts ändern: Der Benutzer sieht im Editor die vorhandenen Daten, ändert sie oder fügt neue hinzu, diese werden geprüft und anschliessend neu angezeigt. Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Checksummen-Algorithmus Das ist ein wertvolles Instrument für die Eingangsprüfung, beispielsweise zum Vergleich mit amtlichen Daten (zur sicheren Prüfung von Abweichungen), oder mit bestehenden Daten (zur Verhinderung von Tippfehlern, versehentliches Verschieben, etc.). Programme, die Daten auslesen, könnten die Checksumme prüfen und wenn sie nicht zu den Koordinaten passt, den Node ignorieren (oder den Benutzer irgendwie warnen). Eine Ausgabeprüfung würde - Daten einzelner Objekte nicht ausliefern (bei Fehlern) - den Download verlangsamen (durch die Prüfung) sich gegen *absichtliche* Datenänderungen schützen, trust-Weg: Man hat eine Liste von Benutzern, denen man vertraut, und bei bestimmten Objekten verlässt man sich ausschliesslich auf diese Leute Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Qualität bedingt definierte Ziele und Parameter. Sie entsteht durch Menschen, die diese verstanden haben und denen man vertraut diese umzusetzten, verfeinert durch ein Vier-Augen-Prinzip. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Der Nachteil dabei ist, dass die Eingangsprüfung Zeit braucht, eine Änderung in der DB also nicht in Echtzeit erfolgt. Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Wir würden zugleich ein Tool a la OSM-Inspector oder OSM Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von unseren Objekten ändert, um diese Änderung dann auch prüfen und abstempeln zu können. In der Eingangskontrolle wären solche Instrumente sehr effizient. Krypto-Tokens, basierend auf public key-Kryptographie. Die Anwendung habe ich noch nicht ganz verstanden. Aber ich erinnere mich, dass ECDIS zur Verifizierung ihrer Daten solche Methoden anwendet (aber eher aus ökonomischen Gründen). Die OSMXapi hat übrigens ein interessantes Feature, das in diese Richtung geht (siehe http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre Watchlist setzen können, und selbst wenn andere Benutzer dieses Tag entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, trotzdem einen gefilterten Mirror zu betreiben, der Änderungen nur dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln zulässig sind. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten Gruss, Markus PS: ich verstehe nicht so viel von DB-Design - aber so rein gefühlsmässig erscheint mir eine
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo, Markus wrote: Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Weil dies eine Macht bei jenen konzentrieren wuerde, die entscheiden, was gesperrt wird und was nicht und wer etwas bearbeiten darf. Solche Machtkonzentration fuehrt fast immer zu einem oder mehreren der folgenden negativen Effekte: * einige Leute fuehlen sich besonders wichtig, es bilden sich Machtstrukturen, Entscheidergremien, Abstimmungen, Anfechtungen von Abstimmungen, Rauswuerfe von Gremienmitgliedern, Anfechtugen von Rauswuerfen und all das * einige Leute sind Flaschenhaelse, an denen immer alles haengenbleibt, und wenn sie mal in Urlaub oder im Real Life ueberarbeitet sind, geht nix mehr * es entstehen komplizierte Authentifikations-/Legitimationsverfahren und ein Ruf nach Sicherheit (wenn Du mit Deinem Account ploetzlich spezielle Bearbeitungsrechte hast, wird Dein Account auch ploetzlich besonders schuetzenswert - man darf dann nur noch Authentifizierung ueber HTTPS machen und solche Scherze); all das bindet Zeit und Arbeitskraft Wenn man hingegen am Ausgang kontrolliert, dann kann jeder Empfaenger selbst definieren, welche Art von Qualitaet er will, wem er trauen will und wem nicht und so weiter; an den zentralen Bottlenecks der Datenbank faellt dadurch keine zusaetzliche Last an, es muessen keine Listen privilegierter Benutzer gefuehrt werden, Editoren muessen nicht angepasst werden... Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Diese Lektionen lassen sich m.E. auf OSM keinesfalls uebertragen, zumindest nicht pauschal. Bei OSM gibt es keine zentrale, allen gemeinsame Definition von Qualitaet; was der eine wegwirft, ist fuer den andren wertvoll (bsp. ein 1000m daneben liegender Leuchtturm - wenn ich nur analysieren will, wie die Leuchtturmdichte pro Quadratkilometer in verschiedenen Kuestengebieten ist, dann ist mir das wurscht). Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Eine Eingangspruefung wird es auf absehbare Zeit nicht geben. Dazu fehlen sowohl die technischen Mechanismen als auch der Wille. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Das wuerde eine Warteschlange von noch nicht genehmigten Aenderungen erfordern, zusammen mit einem Interface und einer privilegierten Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach denen sich diese privilegierte Personengruppe konstituiert. Sowas sehen wir fruehestens 2011 und auch dann nur gegen meinen Widerstand ;-) Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Sag das nicht, sowas waere recht leicht ueber ein modifiziertes OSMXAPI machbar (es uebernimmt einfach nur gestempelte). In der Eingangskontrolle wären solche Instrumente sehr effizient. Es wird keine Eingangskontrolle geben. Das widerspricht den Grundprinzipien von OSM. - Eine Eingangskontrolle gibt es bei Google Map Maker, soviel ich weiss. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten In die Richtung koennte es gehen. Der Vorteil ist das basisdemokratische Element - jeder oder jede Gruppe entscheidet selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte Daten, steht diese Option nicht mehr offen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Detlef Reichl schrieb: Am Mittwoch, den 21.01.2009, 00:13 +0100 schrieb Frederik Ramm: [sehr ausführlich] Hallo Frederik, ich schließe mich dir an, das keine Nutzergruppen mit besonderen Rechten implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Auf der anderen Seite fände ich ein Werkzeug zur Überwachung von Bereichen oder Objekten sehr hilfreich. Auch ich habe ein paar Objekt, die mir mit der Erstellung recht viel Zeit gekostet haben und die ich nicht gern verunstaltet sähe. Da hat sich im letzten Jahr extrem viel getan, wir haben jetzt den schönen OSM Mapper von ito womit sowas schon relativ komfortabel geht. Um Verunstaltungen rückgängig machen zu können sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand für eine Objekt oder einen Bereich zurückgehen kann. Dieses Werkzeug sollten für den normalen Benutzer auf eine bestimmte Anzahl von Versionsständen begrenzt sein. In diesen Bereich hätte ich kein Problem damit, wenn es Benutzer gäbe, die - aufgrund dessen was sie zum Projekt beigetragen haben - erweiterte Rechte hätten, um z.B. auch auf ältere Versionen zurückspielen zu können. Im Prinzip haben wir das, mit Potlach kann man einfache Änderungen wieder rückgängig machen, für schlimmere Sachen muss man schon mit Diffs oder ähnlichem arbeiten. Aber es gäbe schon noch Verbesserungspotenzial. Das schützen von Objekten sehe ich zwiespältig, bei soetwas wie Grenzen könnte es vorteile haben, aber man muss aufpassen, dass man keine Arbeit behindert oder Motivation vernichtet. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Am Mittwoch, den 21.01.2009, 00:13 +0100 schrieb Frederik Ramm: [sehr ausführlich] Hallo Frederik, ich schließe mich dir an, das keine Nutzergruppen mit besonderen Rechten implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Auf der anderen Seite fände ich ein Werkzeug zur Überwachung von Bereichen oder Objekten sehr hilfreich. Auch ich habe ein paar Objekt, die mir mit der Erstellung recht viel Zeit gekostet haben und die ich nicht gern verunstaltet sähe. Um Verunstaltungen rückgängig machen zu können sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand für eine Objekt oder einen Bereich zurückgehen kann. Dieses Werkzeug sollten für den normalen Benutzer auf eine bestimmte Anzahl von Versionsständen begrenzt sein. In diesen Bereich hätte ich kein Problem damit, wenn es Benutzer gäbe, die - aufgrund dessen was sie zum Projekt beigetragen haben - erweiterte Rechte hätten, um z.B. auch auf ältere Versionen zurückspielen zu können. Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Am 21. Januar 2009 00:13 schrieb Frederik Ramm frede...@remote.org: Hallo, es gibt immer mal wieder die Anforderung, dass Objekte gegen Änderungen geschützt werden sollen. ich sehe das im Großen und Ganzen kritisch: wer sollte z.B. unentgeltlich alle Seezeichen überprüfen, vor allem, da sich diese ständig ändern (in den Daten und vermutlich auch in Echt), und dann evtl. sogar noch dafür haften? Auch sehe ich unsere Daten noch nicht vollständig genug. Dennoch habe ich mich in letzter Zeit über bestimmte member geärgert, die offensichtlich bereits bestehende vereinzelte Straßen löschen, um dann auf einer weissen Fläche vermeintlich schneller alles nochmal eingeben zu können (zumindest war das meine Interpretation, weil ich bei Straßen, die ich eingegeben hatte, nicht mehr in der history auftauchte). Auch bestimmte Tools halte ich für schädlich (simplify way). M.E. sollte man da einen Schutz einbauen, dass man damit nur *ways* bearbeiten kann, deren *nodes* man *selbst* hochgeladen hat, bzw. vor dem Hochladen (bzw. bei gemischten ways sollten von dem Tool nur die Nodes berücksichtigt werden, die man selbst eingegeben hat). Die anderen vorgeschlagenen Verfahren zur Qualitätssicherung halte ich dagegen eher für kontraproduktiv, auch wenn es im ersten Moment verlockend scheint. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hi, Am 21. Januar 2009 00:54 schrieb Detlef Reichl detlef.rei...@gmx.org: implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Bitte nur so etwas schreiben, wenn du dir auch sicher bist, danke. (Hint: Es ist nicht der Fall und die gesichteten Versionen, die du möglicherweise ansprichst, funktionieren anders). Um Verunstaltungen rückgängig machen zu können sollte es simple Werkzeuge geben, mit denen man auf eine beliebigen Versionsstand für eine Objekt oder einen Bereich zurückgehen kann. Der Vorteil von Wikis liegt zum Teil darin, dass das Rückgängigmachen von Vandalismus in der Regel einfacher ist, als die Durchführung desselben. Dies ist derzeit bei OSM leider nicht der Fall. Um genau zu sein wundert es mich immer wieder, dass sich für OSM noch niemand ähnliche fiese Vandalismus-Techniken hat einfallen lassen, wie sie in der WP zur Anwendung kommen. Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Um genau zu sein wundert es mich immer wieder, dass sich für OSM noch niemand ähnliche fiese Vandalismus-Techniken hat einfallen lassen, wie sie in der WP zur Anwendung kommen. wie kommst Du denn da drauf? Die haben wir nur noch nicht entdeckt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Tim 'avatar' Bartel: Am 21. Januar 2009 00:54 schrieb Detlef Reichl detlef.rei...@gmx.org: implementiert werden sollten. Was dabei raus kommt sieht man bei WikiPedia. Dort muß derweil auch die kleinste Änderung an den meisten (alle?) Artikeln von den Admins abgenickt werden. Das tötet die Motivation vieler Leute. Bitte nur so etwas schreiben, wenn du dir auch sicher bist, danke. (Hint: Es ist nicht der Fall und die gesichteten Versionen, die du möglicherweise ansprichst, funktionieren anders). Diese gesichteten Versionen haben dazu geführt, dass ich seither keine Wikipedia-Änderungen mehr mache. Ich wollte eine aktuelle Entwicklung in meinem Heimatort in Wikipedia eintragen und nach einem Tag Wartezeit wurde meine Änderung von jemandem der sich scheinbar nicht mit dem Ort auskennt umformuliet so dass die gesichtete Version danach wesentlich falscher war als vorher. Wie sehr sich Detlef mit der Wikipedia auskennt weiß ich nicht, ich kenne mich nicht besonders damit aus, aber seine Aussage dass das die Motivation tötet ist absolut treffend. Gruß, Bernd -- Spontaneität muß wohlüberlegt sein. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
