[Talk-de] Schutz vor Manipulation/Vandalismus in OSM

[Guenther Meyer]

Am Montag 31 März 2008 schrieb Frederik Ramm:
> Hallo,
>
> > >  ich weiss nicht, ob das schon mal angesprochen wurde, zumindest auf
> > > einem der muenchner treffen war das mal thema:
> >
> > Wurde es, nicht nur hier sondern auch auf der Dev Liste.
> > Ferderik hat auch im Wiki was darüber geschrieben.
>
gut.

> Und den Link hatte ich hier neulich auch schon geposted, aber im
> Moment ist das ja eh nicht zielfuhrend, das das Wiki nicht geht ;-)
>
> > >  vorteile:
> > >  - man muss sich registrieren, um committen zu koennen
> >
> > ob das wirklich ein Vorteil ist mag ich bezweifeln.
>
> Man muss sich doch jetzt auch schon registrieren, um etwas aendern zu
> koennen?
>
ist das jetzt schon durch fuer alle moeglichkeiten des editierens?
sehr gut.
registrieren mag zwar fuer denjenigen erstmla aergerlich sein, aber dafuer hat 
man dann wenigstens die moeglichkeit, im zweifelsfall jemanden zu 
kontaktieren.

> > >  - man committet seine aenderungen als set, und nicht jedes geaenderte
> > > element einzeln
> > >
> > >  - man kann zu jedem commit einen kommentar hinzufuegen, was man denn
> > >  eigentlich gemacht hat
>
> Das hatte ich auch so geplant.
>
gut.

> > >  - jeder der daran interesssiert ist, kann sich automatisch eine mail
> > > bei jedem commit zuschicken lassen.
>
> Naja, Mails wollte ich in der Menge nicht verschicken, lieber so eine
> Seite, auf die man draufgehen kann und seine "Watchlist" durchschauen.
> Es besteht sonst die Gefahr, dass sehr viel Rechenzeit/Bandbreite auf
> die Erstellung letztlich unerwuenschter Information verwendet wird;
> wenn man den Kram erst dann berechnet, wenn er abgerufen wird, ist das
> evtl. sparsamer.
>
hmm, die gaengigen versionsverwaltungssysteme machen das selber. und es laesst 
sich normalerweise auch  so einstellen, das das nur an die leute, die sich 
dafuer explizit subscriben rausgeht, nicht an alle user.
drum sollte das nicht so wild sein. ich finde es ausserdem wesentlich besser, 
benachrichtigt zu werden, als staendig selbst nachschauen zu muessen...

> > >  - wenn jemand anderes, waehrend man selbst in josm editiert, im selben
> > > bereich was geaendert hat, bekommt man das spaetestens beim commit mit,
> > > und wird auf entstandene konflikte hingewiesen.
>
> So weit reicht mein Konzept im Moment nicht. Deine Idee ist von den
> Aenderungs-Sets eigentlich recht unabhaengig, sowas koennte man auch
> heute schon machen, dazu muesste bei jedem Abruf die Versionsnummer
> des Objekts mitgegen werden und beim Hochladen muesste ein Vergleich
> erfolgen, ob es immer noch die aktuelle Version ist. Das ist aber aus
> verschiedenen Gruenden sehr Datenbank-Zugriffs-aufwendig und wird
> daher vermutlich nicht viele Freunde finden.
>
naja, so wie ich mir das vorstelle, hat die versionsnummer nur der commit. und 
im log steht drin, welche elemente veraendert wurden.

um bei meinem beispiel zu bleiben:
ich lade mir daten in josm, um die zu bearbeiten. der satz hat den stand 
rev1234.
wenn ich fertig bin, will ich wieder hochladen. die api weiss aber, dass der 
aktuelle stand jetzt rev1236 ist, also zwischendurch zwei aenderungen erfolgt 
sind.
nun kann ein vergleich der logs erfolgen. wenn sich die bearbeiteten bereiche 
bzw. objekte mit meinen ueberschneiden, gibts einen konflikt, der mir 
(inklusive eventuellem kommentar) angezeigt wird und aufgeloest werden muss. 
wenn es keine ueberschneidung gibt, werden meine daten einfach eingefuegt und 
die aktuelle version auf rev1237 hochgezaehlt.

sollte eigentlich nicht allzu aufwendig und performance intensiv sein...

> > >  - wenn jemand unsinn macht, kann er kontaktiert werden, oder es
> > > koennen dessen aenderungen relativ einfach erkannt und entfernt werden.
>
> Mein Konzept sieht vor, dass man alle Aenderungen einer solchen
> "Changeset" komplett revertieren kann. Unklar ist leider, was
> geschehen soll, wenn einzelne dieser Aenderungen schon wieder von
> anderen weiter-veraendert wurden und daher nicht mehr "sauber"
> revertierbar sind.
>
letzteres wird wohl immer ein problem bleiben. da weiss ich leider auch keine 
gute loesung...



-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080401/37db1fae/attachment.sig>