[Talk-de] Objekte gegen Änderungen schützen

Markus liste12A45q7 at gmx.de
Sa Jan 24 12:25:31 UTC 2009


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 einzige weltweite OSM-DB einfacher, 
sicherer und schneller, als mehrere verteilte kleine DBs.




Mehr Informationen über die Mailingliste Talk-de