ES:Vandalismo

From OpenStreetMap Wiki
Jump to navigation Jump to search
Vandalismo en forma de mapeo de una ciudad inexistente.

Se considera vandalismo el ignorar intencionadamente las normas consensuadas por la comunidad de OpenStreetMap sobre edición de datos. Las simples equivocaciones o errores de edición no son vandalismo, pero puede ser necesario revertirlos usando algunas de las mismas herramientas que se utilizan para el vandalismo.

Véase Abuso para el debate de algunos otros tipos de violación de las normas de consenso de la comunidad.

Vandalismo y otros tipos de malas ediciones

Grafitis en trazas GPS (3 nombres de puntos de referencia).

Vandalismo estrictamente hablando sería actos de grafiti en el mapa, llevados a cabo por la mera diversión pueril o como intento intencional de dañar OpenStreetMap. Es relativamente raro ver ocurrencias de puro vandalismo. OpenStreetMap tiene por objetivo una buena causa, carece de fines lucrativos y los datos del mapa son propiedad de la comunidad. En general, la gente tiende a respetar eso.

Existen varios otros tipos de malas ediciones que son muy similares al vandalismo, llevadas a cabo por varias motivaciones más allá de la mera diversión pueril, pero que requieren de remedios similares para corregirlas. Estas incluyen:

  • Infracciones de derechos de copia (Copyright)
  • Disputas en la base de datos de OpenStreetMap (guerras de edición)
  • Disputas en el wiki
  • Uso inapropiado de Bots
  • Comportamiento disruptivo persistente
  • Correo no deseado (Spamming)
  • Eliminación o degradación intencional de los datos que se sabe que son correctos
  • Adición deliberada de datos incorrectos.
  • Importaciones no discutidas previamente

Las simples equivocaciones o errores de edición no son vandalismo, aunque algunos pueden necesitar ser revertidos.

Respuesta al vandalismo

Información para principiantes

Si ves un error o algún daño en el mapa (malicioso o no), puedes estar confundido o inseguro de qué y cómo actuar. En tal caso, como es habitual, ponte en contacto con otros mapeadores y pide ayuda. Pero tal vez la información de esta página te ayude.

Directrices generales

Lo visto en una discusión mantenida en septiembre de 2009 fue:

  • Sería deseable que todos los contribuidores intentasen en todo momento hacer cambios buenos, precisos y bien documentados.
  • Tenemos que asegurarnos de que cada contribuidor hace al conjunto de datos mejor, no peor. Si la contribución ofrece dudas, debemos solicitar a otros contribuidores que la investiguen y verifiquen.
  • Debemos ser conscientes de que las personas cometemos errores, necesitamos tiempo para aprender y que los principiantes a menudo requerirán y responderán positivamente a nuestra colaboración.
  • Podemos solicitar, pero no exigir, que los contribuidores añadan comentarios a sus conjuntos de cambios y que creen una página personal útil con algunos detalles sobre sus intereses y conocimientos. Hacer esto hace la reversión menos probable y más probable que la persona sea auxiliada si fuese necesario.
  • En el caso de que alguien parezca estar haciendo ediciones extrañas, debemos asumir inicialmente que se hacen de «buena fe», pero observando cuidadosamente y discutiendo con otros su idoneidad.
  • Si se puede demostrar definitivamente que un número significativo de ediciones son maliciosas, obscenas, difamatorias o se consideran que pueden desvirtuar el proyecto, los conjuntos de cambios relacionados pueden revertirse inmediatamente sin discusión y sin un 100% de comprobación del resto de conjuntos de cambios.
  • Si las ediciones son dudosas pero no se puede demostrar que son incorrectas, entonces debemos contactar con la persona y pedirle información adicional. Si no recibimos una respuesta razonable (o no obtenemos respuestas) y las ediciones dudosas continúan y no hay un número significativo de contribuciones positivas, entonces debemos probar al menos una mala edición y luego tomar la decisión en discusión con otros sobre la idoneidad de revertir el conjunto de cambios en cuestión, y potencialmente todos los conjuntos de cambios realizados por esa persona.
  • Una vez que alguien ha sido identificado como un colaborador problemático, solo se necesita realizar un breve examen de las ediciones siguientes antes de la reversión de sus futuros conjuntos de cambios.
  • Si el problema continúa, le ponemos en «bloqueo virtual», por lo que sus ediciones se revertirán sin inspección del valor de los cambios, a menos que la persona se ponga en contacto con un administrador del sistema y diga que ha aprendido del error y quiere otra oportunidad.
  • Quien realiza malas ediciones en cualquier parte del mundo puede esperar una respuesta global, ya que parece muy improbable que alguien que la liara en Irlanda hiciese un buen trabajo en Islandia, por ejemplo.
  • Las personas que revierten el trabajo de otras personas deben tratar de justificar equilibrada y razonablemente los motivos de la reversión.
  • A veces las ediciones «nulas»  — aquellas que no tienen otro propósito que no sea «tocar» el elemento — se hacen por error, por el editor o porque son útiles para actualizar un área. No obstante, un gran número de ediciones «nulas» serán consideradas comportamiento disruptivo.

Reversión normal

Si el alcance del vandalismo es local, el impacto para la comunidad limitado y es probable que la edición no fuese maliciosa, haz un contacto humano directo y cortés a través de la mensajería de OSM o del sistema de conversación y comentarios de los conjuntos de cambios, asumiendo la buena intención del usuario y esperando entre 24-48 horas para obtener una respuesta. Si no se recibe una respuesta adecuada puede resultar apropiado discutir la cuestión en la lista de correo que corresponda (normalmente la lista local, nacional o regional) o con personas de confianza. Si se puede demostrar que algunas ediciones son contraproducentes y que las ediciones útiles no resultan obvias, entonces los conjuntos de cambios en cuestión deben revertirse.

Reversión rápida

Si se puede demostrar definitivamente que un número significativo de ediciones son maliciosas, obscenas, calumniosas o se considera que podrían desacreditar el proyecto, entonces es importante responder inmediatamente y revertir primero y hacer preguntas al colaborador en paralelo. También puede ser apropiado contactar con el Grupo de Trabajo de Datos al mismo tiempo. Los objetos que se hayan tocado desde la edición inicialmente mala pueden requerir el uso de un método de reversión complejo, así que si no estás familiarizado con estas herramientas, busca ayuda de la comunidad o del Grupo de Trabajo de Datos.

Bloqueo temporal

Si después de establecer contacto con el mapeador a través del sistema de conversaciones de conjuntos de cambios o a través de mensajería, el mapeador se niega a responder y no altera su comportamiento, el Grupo de Trabajo de Datos puede colocar un bloqueo temporal sobre el usuario en cuestión. Esto no es ni una presunción de culpabilidad ni un destierro del proyecto. Más bien, es una medida para llamar la atención del mapeador, ya que debe iniciar sesión en el sitio OSM y leer el mensaje de bloqueo antes de que pueda continuar cargando ediciones a través de la API.

Los bloqueos temporales varían en su duración, normalmente un plazo entre 0 a 96 horas. También tienen la capacidad de requerir de un usuario que inicie sesión y tenga que leer el mensaje de bloqueo antes de que se elimine el bloqueo, independientemente del tiempo de caducidad.

Los miembros del Grupo de Trabajo de Datos colocarán a menudo bloqueos de 0 horas en una cuenta con la única condición de tener que leer el mensaje de bloqueo, como medida inicial con aquellos mapeadores conflictivos que no respondan.

Un historial de bloqueos está disponible aquí.

Bloqueo de larga duración y bloqueo permanente

Consulta la política de bloqueo de la Fundación para obtener más información.

Gobernanza

Siempre que sea posible, la comunidad local de OpenStreetMap debe resolver el vandalismo a través de los procedimientos anteriores.

Grupo de Trabajo de Datos

Artículo principal: Grupo de Trabajo de Datos

El Grupo de Trabajo de Datos está autorizado por la Fundación para tratar con los actos de vandalismo más graves e informar a la junta en las reuniones mensuales de la junta directiva. Si es necesario el bloqueo de una cuenta, el asunto deberá ser notificado al Grupo de Trabajo de Datos (data@osmfoundation.org).

También se debe contactar con el Grupo de Trabajo de Datos si el problema requiere ocultar algunas partes del historial de los objetos editados.

Desarrollo

Existen un posible número de herramientas y técnicas que podrían utilizarse para gestionar casos de vandalismo. Las herramientas posibles incluyen:

  • Listas blancas
  • Reversión de datos — Permiten que la comunidad ejecute esta tarea mediante herramientas que han sido probadas.
  • Eliminación de datos — Permiten que la comunidad ejecute esta tarea mediante herramientas que han sido probadas.
  • Reversión de cambios
  • Eliminación del historial — Requiere privilegios de alto nivel.
  • Reversiones
  • Datos con historial anterior

Detección

Artículo principal: Detección del vandalismo

Existen herramientas disponibles para revertir ediciones para conjuntos de datos particulares, siempre y cuando no se hayan realizado más ediciones en ninguna de las características relevantes. Estas herramientas son difíciles de usar en la actualidad y requieren un buen conocimiento técnico para operar sin causar daños adicionales.

Detectar el vandalismo dentro de OSM es una tarea complicada, ya que los tipos de vandalismo mencionados anteriormente son variados en cuanto al tipo, extensión y efecto. OSMCha es una de las herramientas que puede usarse para esto.

Existen múltiples estrategias para la detección automatizada del vandalismo que generalmente se incluyen en dos categorías: estrategias centradas en conjuntos de cambios y estrategias centradas en el usuario. Pero, como en el caso de cualquier sistema de detección, a veces la estrategia empleada da como resultado falsos positivos o no detecta algunos vandalismos sutiles.

Centrada en conjuntos de cambios

La detección centrada en conjuntos de cambios se basa en escanear conjuntos de cambios para detectar ediciones dañinas a través del análisis de los metadatos del conjunto de cambios y quizás también los objetos reales o la naturaleza de las etiquetas empleadas. Un método común consiste en establecer límites basados en la cantidad de objetos editados, añadidos o eliminados. Un ejemplo de programa en pseudocódigo:

para conjuntos de cambios en archivo diff:
    si más de 1000 objetos fueron añadidos:
        marcar como potencial importación
    si más de 1000 objetos fueron modificados:
        marcar como potencial edición mecánica
    si más de 1000 objetos fueron eliminados:
        marcar como potencial vandalismo

Este tipo de escaneado se basa en la idea de que los usuarios generalmente no editan una gran cantidad de objetos en sus mapeos cotidianos. A pesar de que, en el ejemplo anterior, todos los eventos son marcados como «potenciales», a menudo hay explicaciones muy razonables para realizar tal número de acciones (p. ej., importaciones autorizadas, reversiones de malas ediciones, etc.). Tampoco detectaría ningún vandalismo a pequeña escala y ningún vandalismo dividido en múltiples conjuntos de cambios.

En la estrategia centrada en conjuntos de cambios, las etiquetas también pueden revelar un comportamiento potencialmente negativo. Indicar una fuente de datos protegida contra copia normalmente hace encender las alarmas, si bien algunos usuarios que no están familiarizados con el origen de las imágenes predeterminadas, como las imágenes de Bing, pueden indicar una  marca de uso común (p. ej. Google, Garmin) provocando un falso positivo. El uso de editores muy anticuados o poco comunes, añadir valores largos en las etiquetas, incluir muchas etiquetas extrañas de conjuntos de cambios u otros comportamientos similares son ejemplos de potenciales positivos en la detección de malas ediciones.

Otro componente de la estrategia centrada en conjuntos de cambios es el examen de las características espaciales de los objetos en el conjunto de cambios. Los objetos añadidos o editados pueden compararse con muestras de caras sonrientes, palabras dibujadas, características anatómicas y garabatos para comprobar cómo de similares son estos elementos a un potencial grafiti.

Centrada en el usuario

La detección centrada en el usuario examina el perfil de edición del individuo. ¿Hizo un usuario 300 ediciones a los 10 minutos de registrarse en OSM? ¿Son todas las ediciones de un nuevo usuario borrado de datos? Esta detección pretende captar el comportamiento del individuo en lugar de las características de los objetos.

Situación legal

Muchos países tienen leyes contra los crímenes cibernéticos relacionados con «la modificación de datos en un sistema informático y, por tanto, causarle daños» o crímenes similares. No se sabe si alguien ha sido conducido ante los tribunales o incluso condenado por vandalismo a OSM, pero en teoría estas leyes podrían aplicarse incluso a aquellos que persistentemente agregan grafitis a OSM, particularmente aquellos que evitan los bloqueos permanentes o a largo plazo.

Véase también

Enlaces externos