[OSM-talk-fr] Continued aggression against French contributors (cadastre integration)

[Philippe Verdy]

Le 18 octobre 2012 21:53, Pierre Béland <infosbelas-gps at yahoo.fr> a écrit :
> surtout pas que tous viennent de façon désordonnée et passionnée exprimer
> leur point de vue. Ça ne fera pas avancer le débat.

Tout le monde ne vas pas s'adresser front baissé directement au DWG.
Malgré tout, les listes publiques de discussion sont là pour connaitre
le sentiment d'une communauté plus large, afin que les quelques uns
qui vont négocier habilement avec le DWG rapportent le sentiment
général (tout en permettant d'avoir derrière lui une trace de ce
sentiment général partagé par un plus grand nombre, pour conforter
certains arguments).

Mais c'est vrai que les propos échangés ici sont trop agressifs et ne
peuvent pas tous servir directement pour la négociation.

Encore une fois, on (la communauté et le DWG) a besoin d'ambassadeurs
comme intermédiaires de confiance, acceptés par les deux parties, sans
pour cela demander à tout le monde de s'adresser directement au DWG
qui, rapidement, se retrouve submergé et ne peut plus rien faire
d'autre que le statu quo de sa position puisqu'il ne sait plus comment
s'adresser autrement à chacun étant donné les trop nombreux avis
contradictoires qu'il reçoit : pour se simplifier sa tâche il choisit
évidemment alors de ne plus s'adresser à tout le monde, mais prends
les problèmes isolément avec quelques utilisateurs qui sont pour lui
un problème (même s'ils ont le soutien large de leur communauté,
celle-ci ayant le gros défaut d'être inaudible et incompréhensible et
ne souhaitant pas non plus négocier pour aplanir les angles).

Je reste malgré tout convaincu que la "solution" du double compte ne
sert strictement à rien et en tout cas pas du tout à la veille de la
qualité. Techniquement elle ne tient pas la route et OSM a évolué
depuis longtemps depuis l'introduction des changesets qui permettent
la séparation et l'identification des imports tout en ne nécessitant
aucun changement de compte utilisateur.

Je note même que la politique imposée par le DWG n'oblige **même pas**
à identifier les seconds comptes pour les associer sans équivoque avec
le compte principal (il ne fait qu'une "recommandation", ce qui rend
cette obligation du double compte encore plus inutile et inapplicable
en pratique).

Si le problème est la taille des changesets pour faciliter les reverts
(sans trop de conflits d'édition à résoudre) c'est qu'une solution
technique reste à développer dans les éditeurs (particulièrement dans
JOSM, puisque dans Potlatch les changesets sont limités en durée,
comme en volume par la capacité des navigateurs à repondre
efficacement, et parce que Potlatch ne permet pas réellement
d'importer des données externes mais sert surtout à travailler sur des
zones déjà tracées sur un fond d'imagerie où forcément tout s'intègre
immédiatement).

Le problème de qualité pourtant est aigu avec Potlatch, puisque
n'importe qui ne fait que des modifications locales sans tenir compte
de ce qui s'y connecte, et efface ou modifie trop facilement des
données qui n'avaient pas besoin d'être modifiées (ce sont des erreurs
humaines essentiellement dont la gravité reste cependant localisée,
car Potlatch en revanche ne permet pas de modifications en masse par
des moyens automatisés).

L'autre sérieux problème de qualité vient de l'API de modification
directe de la base de données. Cela concerne un peu JOSM, mais surtout
ce qu'on peut faire avec des bots si ceux-ci sont opérés par des
vandales. Une bonne solution contre ça serait de développer une
interface nécessitant une identification sécurisée des utilisateurs et
du logiciel qu'ils utilisent. Les bots sont à autoriser spécifiquement
et de façon plus fine que les utilisateurs régulier de JOSM.

JOSM n'est pas un outil automatique, il y a encore un opérateur humain
qui voit et contrôle l'essentiel des modifs faites avant leur envoi,
même s'il est facile de programmer un bot pour générer un fichier .osm
qu'un opérateur humain chargera dans JOSM pour l'envoyer tel quel au
serveur. Mais un vrai bot opéré par un vandale n'a pas besoin de JOSM.
Il ira nettement plus vite et plus facilement en programmant son bot
pour laisser encore moins de traces, en utilisant l'API directement.

Le bot vandale aussi pourra envoyer des changesets en grand nombre,
avec autant de comptes utilisateur qu'il voudra, et passera les radars
basés sur les tailles de changeset (quelques parades existent mais ne
peuvent pas se baser sur l'identifiant utilsiateur, ni la taille de
changeset, mais sur la détection des adressses IP source permettant de
savoir que les divers comptes utilisateurs sont liés et que les divers
changesets malveillants peuvent être alors retrouvés).

Le bot ne répondra pas non plus aux messages envoyés aux comptes
utilisateurs qu'il utilise, ou bien les comptes utilisés (spammeurs)
seront déjà identifiés sur d'autres sites comme malveillants (pour ça
on a des blacklists publiques d'adresses mail ou de domaines ou de
blocs d'adresses IP correspodnant à des proxies anonymiserrs, regardez
ce qui est fait sur Wikipédia par exemple pour les détecter). Cela
pourra aussi constituer des lignes défensives de nature technique (qui
ne dispenseront pas non plus une supervision humaine collective).