6 Previa a Conclusiones

Previa a Conclusiones

Considero de tal vital importancia para la investigación y su veracidad los siguientes comentarios que he decidido incluirlos en un capítulo aparte previa al finale.

¿Qué esperamos encontrar?

Podemos presentar una dicotomía entre desenlaces de este trabajo, en base a lo encontrado en las estadísticas tomadas. El punto clave estará en analizar gráficas (una por vuelo investigado) de la siguiente forma:

• En el eje X tendremos el tiempo: una timestamp de cuándo se realizó la búsqueda.
• En el eje Y figura el precio del billete de avión más barato para el vuelo que estemos estudiando.
• Habrá tres gráficas en una:una línea de precios resultantes en búsquedas con cookies, otra en búsquedas sin cookies con IP tracking, y una última de búsquedas con Tor.

Con ello, dicha dicotomía se arbitra así en función de las gráficas:

• NO hay discriminación de precios de primer grado según el uso de privacidad en búsquedas de vuelos por Internet: Las tres líneas de cada método de búsqueda coinciden, o bien varían en mínimas fluctuaciones que incluso a veces desfavorezcan métodos óptimos según lo expuesto.
• SÍ hay discriminación de precios de primer grado según el uso de privacidad en búsquedas de vuelos por Internet: Las tres líneas de cada método no son coincidentes. O bien los métodos óptimos se van situando por debajo (más barato buscar, p.ej., con Tor que con cookies), o bien van coincidiendo hasta que el precio del vuelo más barato sube, momento en el que los métodos mejores permanecen "por debajo" un cierto margen de tiempo antes de subir para acompañar métodos en teoría peores.

Este último hecho tiene una limitación: En caso de estar pasando esto, dependemos de la velocidad en la toma de medidas de forma proporcional a cuánto margen existe. He realizado entre tres y diez lotes de búsquedas por día (en la conclusión mostraré cuántas búsquedas se realizaron). Quizás con un ordenador más potente (tener acceso a un cluster, p.ej.) o con mejor conexión a Internet habría sido posible mejorar la precisión en las medidas.

¿Discriminación de Precio?

Independientemente de los resultados finales, quería comentar este factor que puede ser importante para cualquiera que se identificó bastante con la puesta en contexto de la Introducción.

Los buscadores de vuelos no disponen del precio real siempre. Estos suelen actualizar todos sus precios entre dos y cuatro veces diarias. Disponer del precio actualizado cada segundo probablemente tenga la consecuencia de un gran gasto innecesarios de recursos.

Con ello, es posible que se tenga un vuelo fijado y que tengamos la mala suerte de entrar a comprar en ese intervalo de seis o doce horas en el cual subió el precio del billete. El hecho de que esta subida tenga lugar para todo el mundo a la vez es una de las materias que veremos en conclusiones, pero en la sección anterior se habló de la limitación existente a poder ver esto.

Por último, comentar que sí se ha demostrado que comprar varios billetes de forma seguida (pero no a la vez) supone aumentar el precio a dicha persona (para por ejemplo evitar la reventa de dichos billetes). La forma de comprobar que es "una misma persona" suele ser su IP, y esta es una razón crucial para aquellos que se identificaron en la Introducción cuando, por ejemplo, realizaron una compra de billetes entre varios amigos pero cada uno el suyo (puesto que probablemente estuvieran en la misma subred y, a ojos de los hosts web, fuera la misma IP pública).

El Vuelo Más Barato

Probablemente esta decisión de implementación afecte a la completitud en las medidas de este trabajo: Siempre se guarda el vuelo más barato de los encontrados. A continuación listo razones de la toma de esta decisión:

• Fluctuación de Precios: Son los vuelos más baratos los que más cambian de precio. Aquellos en hora punta o de clase bussiness apenas varían de precio. En mi opinión, esto ayudará además en conclusiones a obtener ideas de cuándo comprar un vuelo para obtenerlo más barato.
• Complejidad: Extraer todo vuelo de la página de resultados supone bastante dificultad en las funciones de obtención de precios (para un detalle que quizás en semanas pueda fallar, como explicará la sección siguiente). Aparte y más importante, considero que guardar todo vuelo podía complicar la extracción de conclusiones al estar realizando observaciones en tantos valores a variar a la vez.

Mantenimiento de flight_search

Incluyo esta sección aquí en caso de utilizarse flight_search más allá de mediados de 2019 (por si quiero usarlo para buscarme viajes de forma automática). Hay tres aspectos que dificultan la longevidad de nuestro programa, que suelen ocurrir en una coordinación de modularización unilateral (esto es, cuando mi programa depende de otro que desconoce mi existencia):

• Comprobación de conexión a Internet: Introduje un booleano en flight_search.py llamado internet_on(). Simplemente comprueba que hay respuesta en una request que se hace a cierta IP (en este caso de Google). Destacar que se le pide a la IP y no al dominio por el hecho de que podríamos "quedarnos parados" en la resolución DNS en caso de no haber conexión, y esto es justo lo que estamos comprobando. A la mínima que deje de utilizarse la IP de Google, flight_search diagnosticará siempre que no hay conexión.
• URLs: Para acceder a cada compañía, es necesario requerir de su URL primero. A veces, usamos otras URLs cuando hay un "atajo" en la búsqueda, como es el caso de lo ya explicado en "Ejemplo: GET Ryanair" del capítulo 4. En el momento de cambiar una URL (más probable en el caso de los "atajos"), flight_search fallará por parsear en un Not Found.
• HTML de cada página: Este es el peor y más probable parámetro que dificulta el mantenimiento de flight_search. La gran desventaja de Selenium es que, si los desarrolladores Web del host sobre el que trabaja nuestra spider cambian id,class,aria, etc. de un elemento HTML, aquél parámetro mediante el cual buscábamos ha de adaptarse a las nuevas características del elemento. Lo más probable es que en algún momento cambie el diseño completo de páginas como Iberia o Ryanair, y ello conlleva rediseñar las funciones de completar formularios y obtención de precios y horas.

Legalidades de una Araña Web

Pese a que se tratara bastante qué podemos hacer investigando el funcionamiento de un sistema informático, faltaba un detalle importante a mencionar tras la implementación de flight_search. Las arañas web tienen ciertos recursos del servidor web prohibidos. Acceder a dichos recursos no tiene repercusiones penales (por lo general), tan solo supone un probable bloqueo de nuestra IP.

Los recursos a los que podemos acceder y a los que no figuran en robots.txt. Por ejemplo, para Iberia es https://www.iberia.com/robots.txt. En dicho archivo se encuentra una tabla de pares verbo-recurso donde el verbo es allow o disallow y el recurso una ruta (a veces aparece *, lo cual se interpreta como "todo archivo en").

Y aquí empieza una "batalla" entre spiders y hosts web, puesto que los hosts no suelen dar la bienvenida a ninguna araña salvo una: la del algoritmo Page Rank de Google. La cuestión es hasta dónde permitir acceso a dicha araña sin "ponernos en peligro" por las demás.

Clicks y Esperas Aleatorias

Allá donde una araña puede no tener acceso según robots.txt, puede tener acceso un cliente normal y corriente. La siguiente parte de la "batalla" está en intentar simular ser humano. Esto se consigue por lo general mediante clicks en lugares aleatorios y en dormir (sleep(segs)) en momentos aleatorios. Cierto es que existen otras formas de descubrirnos como robots y no humano, como pueden ser las honeytraps: recursos HTML no visibles para un usuario pero que figuran en el .html, que al momento de interactuar con ellos "caemos en la trampa" y, por supuesto, es claro que el cliente es un spider.

Entonces entra la búsqueda del equilibrio entre aparentar ser humano para poder automatizar las tareas que deseamos y en la eficiencia de nuestra araña web (¿qué sleeps se salen de los necesarios y ralentizan el programa?). En nuestro caso veremos que tenemos ciertos matices de ello, pero en algunas compañías no es necesario porque surgirán problemas mayores.

El Problema con Iberia

La "guerra" entre hosts de servicios web y de clientes que se salen de lo habitual (como puede ser una araña web) da lugar a que, pese a dificultades y soluciones mencionadas en apartados anteriores, webs como Iberia tienen una medida fatídica contra fligth_search, tanto que me hizo decidir apartar a Iberia del marco de investigación.

Dicha solución es un Captcha. No creo que sea necesaria una introducción de lo que es. Si bien un Captcha tiene gran aplicación y sentido en contextos como ataques a contraseñas por fuerza bruta online, posteo de mensajes en un foro, etc., me pregunto los motivos por los que Iberia colocaría un Captcha entre la búsqueda de vuelos y obtención de resultados. Si alguien quiere poner a prueba (atacar) el servidor de Iberia, ¿no existen muchos otros métodos más eficientes que no requieren de rellenar formularios de forma automatizada?

Quizás la respuesta a la pregunta anterior tenga que ver con poder sabotear sus estudios de mercado (por ejemplo, con los recursos suficientes, simular que millones de clientes están interesados en volar de Madrid a Egipto).

Con ello, no era posible automatizar un lote de búsquedas, puesto que en menos de veinte búsquedas aparecía este Captcha, que se mantenía durante veinticuatro horas (y de hecho todo usuario de mi subred tenía que introducirlo).

Acceso a Iberia con Tor

flight_search no funciona con Tor para Iberia. El motivo creo que se escapa de mis capacidades. Iberia, directamente, bloquea toda conexión que sea mediante Tor, o al menos la mayoría de nodos desde los que he podido acceder (ha sido muy rara, un 3%, las ocasiones de prueba en las que conseguí conectarme desde Tor).

Este motivo, juntado con el de la sección anterior, fueron bastante importantes como para llevarme a cercar el marco de investigación únicamente en Ryanair.

Tor e IP Anónima

Contrario a lo que mucha gente pueda pensar al navegar con Tor mediante, no tenemos IP anónima. Distinto es el hecho de que dicha IP no sea nuestra, por lo ya explicado en Distinción de Contextos: Tor. Repetía este hecho por esta consideración en nuestra investigación: quizás se poluta nuestra medida que afirma no tener IP tracking por el hecho de que se aplique esta técnica a algunos nodos finales mediante los cuales hemos buscado.

Por supuesto, la probabilidad de esto es mucho menor, además porque apenas flight_search -t va repetir nodos. Considerado este detalle, ya es parte del lector opinar si la medida "Sin cookies e IP anónima" es verídica o no.

Tor y Determinismo en Fallos de Ejecución

flight_search no siempre funciona con Tor. Sin embargo, considero este un factor que se escapa de mi código. Por lo general, flight_search -t dependerá del último nodo que conecta con el host web. Dichos nodos, en ocasiones, han sido utilizados "de forma maligna" (entre comillas al ser por lo general intentos fallidos de ataques), y ello conlleva un bloqueo (temporal o permanente) por parte de los hosts.

La única solución posible a este problema es el hecho de reintentar establecer conexión, reseteando el Tor bridge hasta un número máximo de veces que está establecido en la configuración de flight_search y refrescando el enlace.

Desafortunadamente, esta solución no consigue paliar del todo el problema y, en comparación con las búsquedas con y sin cookies, flight_search -t con Ryanair tiene una tasa de acierto de, aproximadamente, un 60%.

Se Pueden Conseguir Vuelos Más Baratos con Tor

Este aspecto es bastante importante para quien realmente quiera "ahorrar" comprando billetes de avión. Tor puede realmente conseguir vuelos más baratos. El truco está en el cambio de moneda. Hay varios artículos que demuestran que se puede ahorrar bastante por las fluctuaciones de diferencias monetarias en ciertas aerolíneas, y se debe a que estas en ocasiones adaptan el precio de un billete según ciertas monedas en lugar de realizar el cambio "automáticamente".

Para este trabajo este no es el objetivo: Deshabilité nodos finales de zonas que no fueran europeas. Además, para no poder errar en conclusiones por cambio de moneda, directamente decidí no implementar una get_prices que atendieran a algún precio que no fueran Euros.