Si me logras leer en este preciso momento es porque estás conectado a un ISP, de Internet Service Provider –en español: Proveedor de servicios en Internet o PSI– es lo primordial para poder acceder a la gran red. En el caso de Colombia tenemos proveedores de servicios conocidos como lo es Tigo, Claro, Movistar, Edatel y otros por hay, cada uno de ellos se diferencian por las prestaciones y términos con condiciones hacia sus usuarios finales, quienes contratan sus servicios, unas más laxas que otras o en su defecto restrictivas frente a la leyes vigentes que rigen Internet en nuestro país, en su mayoría enfocada a bloquear la piratería, pornografía y un largo etc.
Todo parece normal y aceptable, pero más allá de los términos y condiciones que aceptas al contratar el servicio queda algo en lo profundo y es, su activa colaboración con la autoridades estatales, cuestión que sirve de mucho para casos que en verdad lo ameriten, pero por el contrario en su mayoría sólo sirve como un caballo de troya para “identificarnos” tal cual por medio de una “razón” legal. Agrego: No todos los proveedores de servicios colaboran activamente, unos más que otros, incluso unos que sólo se limitan a aceptar las solicitudes legales en última instancia, pero eso va para otro artículo… en caso de querer proteger nuestra privacidad y en cierto modo parcial anonimato ¿qué hacer? No hay ninguna solución impenetrable, pero si sirve demasiado seguir un conjunto de buenos hábitos, cómo lo son: sólo acceder a paginas certificadas de confianza bajo el protocolo https, siempre hacer conexión por medio de VPN de confianza, mantener lejos las cookies, hacer limpieza de credenciales y logs o en su última instancia para los más paranoicos ALEJARSE DE INTERNET jaja (es broma).
Hoy les traigo un proyecto bastante interesante por el cual podremos disuadir a nuestros ISP con la recolección activa de datos y si, no podemos bloquear dicha recolección ¿Qué hacer? En este caso contaminarla.
ISP Data Pollution
El voto de los partidos del Congreso permitirá a los ISP explotar los datos privados de su familia sin su consentimiento. Ver “El Senado pone los beneficios de los ISP por encima de tu privacidad“.
Este script está diseñado para evitar esta violación generando grandes cantidades de navegación web realista y aleatoria para contaminar los datos del ISP y hacerlos efectivamente inútiles al ofuscar los datos reales de navegación.
Pago a mi ISP mucho por el uso de datos cada mes. Normalmente no utilizo todo el ancho de banda que pago. Si mi ISP va a vender hábitos de navegación privados, entonces voy a contaminar la navegación con ruido y usar todo el ancho de banda que pago. Este método lo consigue.
Si todo el mundo utiliza todos los datos por los que ha pagado para contaminar su historial de navegación, entonces quizás los ISP reconsideren el modelo de negocio de vender el historial de navegación privado de los clientes.
La alternativa de usar una VPN o Tor simplemente empuja el problema a la elección del proveedor de VPN, complica la red, y añade el problema real de navegar por los captchas cuando aparece como nodo de salida de Tor. Además, el tráfico meramente encriptado tiene demasiada información de canal lateral explotable, y todavía podría ser utilizado para determinar cuándo los miembros específicos de la familia están en casa, y las actividades en las que están involucrados.
Este rastreador utiliza chromedriver con la biblioteca selenium de Python, utiliza listas negras para sitios web indeseables (ver el código para más detalles), no descarga imágenes, y respeta robots.txt, todo lo cual proporciona una buena seguridad.
Línea de comandos
python3 isp_data_pollution.py
python3 isp_data_pollution.py –help
python3 isp_data_pollution.py -bw 1024 # 1 TB per month
python3 isp_data_pollution.py -g # print debugging statements
Motivación para la eficacia
El enfoque utilizado en este script es susceptible tanto de ataques estadísticos como de anomalías de tráfico. El artículo de Jon Brodkin sobre la privacidad a través de la inyección de ruido cubre varias críticas válidas: el enfoque no garantiza la ofuscación de información privada sensible, e incluso si funciona inicialmente, puede no escalar.
Sin embargo, hay buenas razones teóricas de la información y probabilísticas para sugerir que un enfoque como éste podría funcionar en muchas situaciones prácticas. La privacidad mediante la ofuscación se ha utilizado en muchos contextos. En las ciencias de la información, Rubin propuso un método estadísticamente sólido para preservar la confidencialidad de los sujetos enmascarando los datos privados con datos sintéticos (“Statistical Disclosure Limitation“, JOS 9(2):461-468, 1993). En un buen artículo relacionado con este repositorio, describen un modelo de privacidad del lado del cliente que utiliza la inyección de ruido (“Noise Injection for Search Privacy Protection“, Proc. 2009 Intl. Conf. CSE).
A continuación se exponen dos argumentos de carácter práctico sobre la eficacia de este enfoque en el caso de la intrusión en la privacidad de los ISP. No se trata de pruebas, sino de modelos sencillos que sugieren un cierto optimismo. La eficacia real debe determinarse probando estos modelos en el mundo real.
Argumento teórico de la información
El enfoque de Ye et al. intenta minimizar la información mutua entre los datos del usuario y los datos del usuario con ruido inyectado presentados a un servidor. La información mutua es el solapamiento entre la entropía de los datos del usuario y la entropía de los datos del usuario con ruido inyectado (área púrpura de abajo). La cantidad y distribución del ruido inyectado se selecciona para que esta información mutua sea lo más pequeña posible, dificultando así la explotación de los datos del usuario en el lado del servidor.
Información mutua
El ejemplo del artículo de Ye et al. son las consultas de búsqueda específicas. La analogía en este artículo son los dominios específicos. La información del dominio es el principal dato que se filtra a los ISP si se utiliza HTTPS cifrado, y por tanto es relevante. El caso del tráfico no cifrado con términos de consulta y contenido explícitos se analiza en la siguiente sección sobre máxima probabilidad.
Ye et al. muestran que la información mutua desaparece si:
Número de llamadas con ruido ≥ (Número de llamadas de usuario – 1) × Número de llamadas posibles.
Para esta aplicación, el número de llamadas posibles es el número de dominios que un usuario podría visitar (por día), y el número de llamadas es el número de visitas realizadas. Nielson informó en 2010 que la persona media visita 89 dominios al mes. Para ser extremadamente conservadores en la (sobre)estimación del número de llamadas de ruido necesarias para oscurecer estos datos de navegación, supongamos que el usuario medio visita O(100) dominios al día, con O(200) peticiones de usuario al día, o aproximadamente una cada cinco minutos durante un largo día.
La ecuación anterior afirma que se necesitan (200-1)×100 o unas veinte mil (20.000) llamadas de ruido para lograr una información mutua nula entre los datos del usuario y los datos del usuario más el ruido.
Esto equivale a una llamada de ruido cada cinco segundos aproximadamente, lo que es muy fácil de conseguir en la práctica, y entra fácilmente dentro de un límite de ancho de banda nominal de 50 GB al mes.
Si el modelo teórico de la información del lado del cliente de Ye et al. es válido en la práctica, es razonable esperar que los parámetros elegidos en este guión puedan reducir o eliminar en gran medida la información mutua entre los datos reales del dominio del usuario y los datos del dominio presentados al ISP.
Además, se pueden utilizar menos llamadas de ruido si se introduce un modelo de dependencia entre las distribuciones de usuario y de ruido.
Argumento de máxima probabilidad
Las llamadas HTTP no codificadas filtran datos muy específicos del usuario al ISP. Los métodos de publicidad dirigida utilizan estos datos capturados para clasificar al usuario y ofrecerle publicidad a medida basada en su categoría. Desde el punto de vista probabilístico, este enfoque depende intrínsecamente de la búsqueda de “picos” específicos en la distribución de consultas de un usuario, y de la utilización de estos picos para encontrar las categorías de consumidores más probables para el usuario. La inyección de un gran número de llamadas no correlacionadas (o mejor, anticorrelacionadas) puede dificultar el enfoque de máxima probabilidad utilizado para clasificar al usuario porque añade muchos más picos en toda la distribución medida de intereses del usuario.
Además, el ancho de banda de transmisión del anunciante está muy limitado: sólo caben unos cuantos anuncios en una página web. La adición de llamadas de ruido no correlacionadas complica el problema de la selección del anuncio adecuado.
Críticas a la contaminación de datos
Los excelentes artículos de Kaveh Waddell y Jon Brodkin sobre la privacidad de los ISP en The Atlantic y Ars Technica abordan importantes críticas a este enfoque. Las resumimos aquí junto con una respuesta, tanto para que los usuarios sean conscientes de estos problemas como para que se hagan sugerencias para resolverlos.
- “Enmascarar el historial de navegación de una persona mediante la superposición de copias de los patrones de navegación de otras personas podría ser más útil. … ‘Sería un sistema similar a Tor en el que el anonimato se consigue mediante el uso compartido'”. [Bruce Schneier] Comentario 1: Es posible enmascarar la privacidad con métodos estadísticos (Rubin, op. cit.; Ye et al., op. Cit.) Comentario 2: Un sistema de enrutamiento tipo Tor o I2P sería preferible si se encuentra una buena solución al problema de los nodos de salida de Tor. Un ejemplo de rastreo ilustra que crear contaminación autogenerada es mucho, mucho más seguro que ejecutar un nodo de salida Tor (o similar a Tor) que permite a cualquiera enviar peticiones abiertas desde una dirección IP personal.
- “[No subestime] la capacidad de los proveedores de Internet … para ver a través de las tácticas de ofuscación de datos”. [Bruce Schneier] Comentario: Los parámetros de ancho de banda en este repositorio se eligen teniendo en cuenta un modelo teórico de información específico que, si es correcto, elimina la información mutua entre los datos del dominio del usuario y los datos contaminados que se presentan al ISP. Si no hay información mutua, no hay oportunidad de explotar los big data. Se trata de un área en la que se requiere más investigación, ya que los fallos/imperfecciones en el método de ofuscación filtrarán información. Una cantidad suficiente de ruido correctamente elegido hace que los enfoques de big data sean significativamente más difíciles. Esta es una hipótesis que queda por comprobar en este contexto.
- “Las búsquedas aleatorias en Google podrían enviar el programa a una oscura madriguera, sin que el usuario lo sepa”. [Kenn White]
Comentario 1: Esta es una posibilidad. Se mitiga con (1) el uso de búsquedas seguras en Google; (2) una lista negra en memoria; (3) sin descargas de imágenes. Basándose en esta crítica, se añade el parámetro explícito safe=active a las consultas de búsqueda. –
Comentario 2: El tráfico de los nodos de salida de Tor casi seguro que contiene este tipo de tráfico, que es un problema importante para los operadores de los nodos de salida. En cambio, el ruido autogenerado es probablemente -y en la práctica parece ser- mucho más seguro.
Comentario 3: Todavía no se ha observado ni comunicado este posible problema. Los informes de tales problemas o las sugerencias para mitigarlos son bienvenidos en los Temas de la repo.
- “Alguna información es sensible aunque esté rodeada de ruido. … Imagina que los hackers atacan a tu ISP, tu historial de navegación se filtra y muestra que has visitado sitios web controvertidos. … Incluso si eso estuviera rodeado de ruido, sería muy difícil conseguir el tipo de ruido que te daría una negación plausible”. [Jeremy Gillula]
Comentario 1: Esto es correcto. La ofuscación es un enfoque estadístico que no puede ocultar datos muy específicos, personales y sensibles, y no ofrecería una negación plausible.
Comentario 2: Esto también es un problema potencial para los usuarios de VPN.
Limitaciones conocidas de la contaminación de datos
El análisis de otros enfoques de ofuscación de datos muestra la susceptibilidad a los ataques de clasificador de aprendizaje automático: Pedinti y Saxena demostraron una clasificación significativa de los usuarios con el complemento del navegador TrackMeNot, destinado a derrotar a un motor de búsqueda adversario (“On the Privacy of Web Search Based on Query Obfuscation: A Case Study of TrackMeNot“, en Proc. PETS2010, 2010). El modelo adversarial y los métodos de entrenamiento utilizados en este análisis no son directamente aplicables al caso de los intermediarios ISP. Las características principales del ataque de Pedinti y Saxena son:
- “Nos propusimos investigar si sigue siendo posible (y en qué medida) que un motor de búsqueda adversario -equipado con los historiales de búsqueda de los usuarios- filtre las consultas de la RGT utilizando clasificadores de aprendizaje automático de uso corriente y, por tanto, socave las garantías de privacidad que ofrece la RGT.”
- “El problema considerado en este trabajo es diferente del problema de identificar las consultas de un registro de búsqueda anónimo. En primer lugar, un adversario en nuestra aplicación es el propio motor de búsqueda y no un tercero que intenta desanonimizar un registro de búsqueda. En segundo lugar, a diferencia de un tercero, el motor de búsqueda ya está en posesión del historial de búsqueda de los usuarios, con el que puede entrenar eficazmente un clasificador.”
- “En nuestro modelo adversario, asumimos que el motor de búsqueda es adversario y su objetivo es distinguir entre la RGT y las consultas de los usuarios con fines de perfilado y agregación. También asumimos que el motor tendría acceso a los historiales de búsqueda del usuario durante un tiempo determinado hasta el momento en que el usuario comienza a utilizar el software de la RGT.”
- “Algoritmos de clasificación. Dado que la agrupación con los parámetros por defecto no funcionó bien, decidimos trabajar con algoritmos de supervisión/clasificación que se entrenan con datos etiquetados previos.” Cantidad de datos de ruido comparable a la cantidad de datos de usuario debido a los límites de la API del motor de búsqueda.
Ninguna de estas características de ataque es necesariamente aplicable a un modelo de adversario de un ISP. Es posible que un ISP pueda utilizar datos históricos de usuarios no contaminados para entrenar un clasificador, sin embargo, esto supone que los intereses, números e identidades de los usuarios en una dirección IP de cuenta no cambian de mes a mes, un hecho poco probable para la mayoría de los usuarios y hogares. Sin datos de usuarios no corrompidos con los que entrenar, este trabajo ilustra las dificultades de la desanonimización por parte de terceros, incluso con cantidades limitadas de ruido. Sería útil cuantificar el rendimiento de la clasificación con y sin la posibilidad de entrenar con datos de usuario no alterados. Conocer la respuesta para ambos casos indicaría posibles mejoras en el enfoque de ofuscación.
Privatización del filtro proxy con acceso VPN
La contaminación de datos es un componente de la privatización de sus datos personales. Instala HTTPS Everywhere y Privacy Badger de la EFF en todos los navegadores. También vea los repositorios osxfortress y osx-openvpn-server para bloquear la publicidad, los rastreadores y el malware en todos los dispositivos.
El uso de un proxy privatizador para unir su propio tráfico personal con el tráfico de contaminación de datos añade otra capa de ofuscación con el control del tráfico de cabecera. Las cabeceras HTTP del tráfico contaminado aparecen como
GET /productos/trajes-de-mujeres.jsp HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Usuario-Agente: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) como Gecko
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
Host: www.bananarepublic.com
Conexión: keep-alive
Ejemplo
Así se vería un sitio con la contaminación activada, nótese que no descarga imágenes.
Instalación
Dependiendo de tu instalación de Python (v. 3), las dependencias del módulo son numpy, requests, selenium y fake_useragent, así como chromedriver. La forma de instalarlos depende de tu sistema operativo.
Esto implica elegir un gestor de paquetes de Python (v. 3), normalmente pip o Anaconda.
A mí me gusta pip, así que en mis máquinas diría
sudo pip-3.7 install numpy requests selenium fake_useragent OpenSS
ChromeDriver
Se recomienda instalar el binario de chromedriver directamente desde chromedriver.chromium.org Asegúrese de verificar el Etag de la instalación descargada.
Si estás detrás de una distribución GNU/Linux basada en Ubuntu, tu instalación debe ser de tal forma:
sudo apt-get install git
git clone https://github.com/essandess/isp-data-pollution.git
cd isp-data-pollution/
sudo apt install python3-pip
pip3 install –upgrade pip
pip3 install numpy
pip3 install psutil
sudo -H pip3 install psutil –upgrade
sudo -H pip3 install –upgrade pip
sudo -H pip3 install selenium
sudo -H pip3 install fake_useragent
sudo -H pip3 install pyopenssl
sudo apt-get install fontconfig
sudo apt-get install libfontconfig
sudo apt-get install build-essential chrpath libssl-dev libxft-dev
sudo apt-get install libfreetype6 libfreetype6-dev
sudo apt-get install libfontconfig1 libfontconfig1-dev
#! Please update these commands for chromedriver
# export PHANTOM_JS=”phantomjs-2.1.1-linux-x86_64″
# sudo mv $PHANTOM_JS /usr/local/share
ls /usr/local/share
# sudo ln -sf /usr/local/share/$PHANTOM_JS/bin/phantomjs /usr/local/bin
# phantomjs –version
python3 isp_data_pollution.py
Si está detrás de un cortafuegos, utilice sudo -EH para heredar la configuración del entorno http_proxy.
Finalizando este artículo he de decir de que todas las fuentes de referencias han sido ancladas al texto por medio de hipervínculo reservando sus derechos intelectuales detrás de sus ideas. Además he de hacer referencia al sitio oficial del que partí este artículo y es el repositorio essandess creado y mantenido por Steve Smith a quién se agradece todas son ideas y mecanismos para escapar de la vigilancia y captación de datos en la gran red.
La finalidad de este artículo es dar a conocer un método más para intentar disuadir la recolección de datos a los que somos expuestos día a día en la gran red, eso si, hay que tener en cuenta que este proyecto no sé actualiza hace 5 años aunque aun está operativo y llega a funcionar, teniendo en cuenta sus limitaciones y contra indicaciones de las que podríamos ser objeto si caemos en el bajo porcentaje de falla en la probabilidad resaltada en líneas mucho más arriba, vale la pena experimentar y mejorar. Se les agradece el aporte a este artículo, corrección o más.
