¿Alguna pregunta?   971.31.13.31   info@faseconsulting.es

Aspectos técnicos de la aplicación para móvil de la Liga de Fútbol

Ayer hicimos público un post en nuestro blog sobre la aplicación de móvil de la Liga de Fútbol Profesional, y el uso que hace del micrófono para grabaciones y lucha contra el fraude. Ahora que se ha dispuesto de más tiempo para analizar el código de la aplicación en sí, creo que es oportuno un nuevo post dedicado a esta parte.

Sobre la parte técnica en general, podéis acudir al post “analizando la app de la Liga para Android“, pero quiero aprovechar para destacar un par de temas que creo que son importantes sobre el funcionamiento técnico de la App.

¿Cómo sabe el momento para grabar?

Si recordamos la nota de prensa de la Liga de Fútbol Profesional, se nos indicaba que las grabaciones se limitarían a determinados momentos, es decir, no se trataría de un uso continuado del dispositivo de grabación o de los datos de geolocalización del terminal

LaLiga sólo activará el micrófono y geoposicionamiento del dispositivo móvil durante las franjas horarias de partidos en los que compitan equipos de LaLiga.

La pregunta es cómo discrimina la aplicación que nos encontramos ante una de estas franjas horarias. Podemos observar como en diversas instancias se hace referencia a getMatchLive

if (DataManager.INSTANCE.getMatchLive()) {
DataManager.INSTANCE.sendUserLocation(this.fluzoId, this.longitude, this.latitude, TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis()));
}

Esta función, localizada en DataManager, devuelve un valor booleano que permitirá a la aplicación saber si se encuentra en una franja horaria de partidos o no

    public boolean getMatchLive() {
        boolean z = false;
        try {
            String source = getBufferReaderJson("https://laliga.fluzo.com/settings");
            if (source != null) {
                z = ((Settings) getCustomGsonInstance().fromJson(source, Settings.class)).isLocation_enabled();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return z;
    }

En este caso, la información se proporciona desde los propios servidores de fluzo, con un subdominio dedicado para el servicio que prestan a la LFP, ejecutando un GET en el endpoint ‘settings’. Basta usar un navegador para ver qué tipo de información es la que se nos devuelve

En este caso podemos observar que se nos devuelve lógicamente un objeto JSON con un único campo, location_enabled. Si accedemos a este directorio fuera de las franjas de horarios de partidos, se nos devuelve como valor lógico falso, lo cual impediría que se realizara una grabación o que se enviara la geolocalización.

Por lo tanto

  • El sistema no se encuentra permanentemente grabando
  • Se realizan comprobaciones periódicas del estado de este campo en el servidor, que le indicará si se encuentra en una franja horaria correspondiente a un partido. Esto supone que la Liga de Fútbol Profesional deberá subir previamente un archivo con la información de franjas horarias para que la API pueda devolver el valor adecuado
  • El señalamiento de que es una franja horaria de partido o no a los efectos de grabaciones no lo hace la LFP, sino Fluzo a través de su servicio. Por lo tanto, las garantías de no grabar fuera de dichas franjas dependen al final de la confianza en esta empresa.

Dejando de lado la efectividad de su tecnología, lo cierto es que la empresa es poco transparente, lo que no me produce personalmente demasiada confianza. Su web aparece totalmente en blanco, y la entrada a paneles solo informa de su copyright y poco más (uno de los vicios recurrentes en muchos servicios online)

Sin más aviso legal ni información, de momento no puedo más que desconfiar.

¿Cómo funciona Fluzo?

Como mencioné en el otro artículo sobre la aplicación de La Liga, mi opinión es que el mecanismo más sencillo pasaría por utilizar señales de audio inaudibles dentro de la propia emisión, que serían las que posteriormente buscaría el sistema para comprobar si se está viendo un partido. Este mecanismo requeriría, como he indicado, la incorporación de dicha señal en la emisión de los partidos.

Este mecanismo es el utilizado por servicios como el de Silverpush. La FTC en su momento mandó notificaciones a desarrolladores de aplicaciones que incorporaron el código de esta empresa en sus apps

We recently discovered that your mobile application “_______________” includes a software development kit created by the company Silverpush. Silverpush makes available for application developers a “Unique Audio Beacon” technology that enables mobile applications to listen for unique codes embedded into television audio signals in order to determine what television shows or advertisements are playing on a nearby television. This functionality is designed to run silently in the background, even while the user is not actively using the application. Using this technology, Silverpush could generate a detailed log of the television content viewed while a user’s mobile phone was turned on.

Dicho esto, la poca información que se ha podido encontrar sobre la integración con fluzo parece dar a entender que funciona de forma distinta. Así, en un artículo sobre el servicio podemos encontrar lo siguiente:

El proceso de integración en los clientes para empezar a recoger datos es muy sencillo: FLUZO integra su tecnología en las apps de sus clientes (anunciantes, cadenas de radio y TV, medios, etc.). Estos suben su contenido (spots, cuñas de radio, series…) a la plataforma FLUZO, que se encarga de procesarlo todo y de guardar la huella digital (fingerprint) del contenido en una base de datos.

Por lo tanto, y siempre que demos por ciertas las afirmaciones que realizan, el servicio requeriría

  1. Creación de la huella digital de los contenidos de manera previa a su comprobación
  2. Posteriormente un proceso deberá enviar las huellas capturadas al servidor de la empresa para comprobar si existen coincidencias

En el caso de contenido emitido en directo, como sucede con los partidos de fútbol, el orden de estas acciones se invertirá, dado que no contamos con una huella digital previa del contenido que podamos comprobar, a menos que utilicemos para generar la misma algún tipo de contenido que conozcamos de antemano (como pueden ser spots publicitarios, el que se emita tras la vuelta de la publicidad antes de mostrar de nuevo la emisión en directo, etc), aunque esto podría dificultar la comparación al contar con menos información. Por estas mismas razones, y su sencillez, es por lo que inicialmente pensé que se trataba de algún tipo de señal inaudible.

Una solución posible pasaría por almacenar las diversas huellas digitales que los usuarios hayan enviado, para que posteriormente el usuario suba el contenido correspondiente y se realizara la comparación, aunque en este caso las métricas se obtendrían a posteriori (aunque para la lucha contra el fraude no debería afectar). La otra solución es, como he indicado, subir los spots y cuñas que vayan a emitirse, u otras señales auditivas que puedan incorporarse durante la emisión, y entender que los falsos negativos que puedan llegar a darse son tolerables.

¿Tiene sentido que se manden grabaciones a Fluzo?

Desde el punto de vista práctico, la verdad es que no tendría mucho sentido que se mandaran grabaciones de audio de manera periódica a Fluzo. Esto podría llegar a suponer una carga importante en la red en determinadas zonas, además de un consumo de ancho de banda del usuario importante. Es por ello que servicios como Shazam acuden al mecanismo de generar una huella digital del contenido, que es lo que se envía a la API, tal y como podemos ver en el artículo “how shazam works

1. Beforehand, Shazam fingerprints a comprehensive catalog of music, and stores the fingerprints in a database.
2. A user “tags” a song they hear, which fingerprints a 10 second sample of audio.
3. The Shazam app uploads the fingerprint to Shazam’s service, which runs a search for a matching fingerprint in their database.
4. If a match is found, the song info is returned to the user, otherwise an error is returned.

De forma similar lo explica uno de los desarrolladores en su paper “an Industrial-Strength Audio Search Algorithm”

To perform a search, the above fingerprinting step is performed on a captured sample sound file to generate a set of hash:time offset records. Each hash from the sample is used to search in the database for matching hashes. For each matching hash found in the database, the corresponding offset times from the beginning of the sample and database files are associated into time pairs. The time pairs are distributed into bins according to the track ID associated with the matching database hash.

Este paper también nos indica que este tipo de algoritmos, correctamente implementados, puede ser viable incluso en entornos con ruido ambiental como pueden ser los bares durante un partido

The algorithm performs well with significant levels of noise and even non-linear distortion. It can correctly identify music in the presence of voices, traffic noise, dropout, and even other music.

Volviendo al tema de envío de archivos de audio, si revisamos el código, encontramos referencias a pruebas en que se manda al endpoint “match” un archivo wav denominado test.wav que previamente tenemos en la variable inputStream2

C0851a a = C0851a.m828b(new StringBuilder(String.valueOf(this.f674a.f728k)).append("/match").toString()).m846a((int) Indexable.MAX_BYTE_SIZE).m851b((int) Indexable.MAX_BYTE_SIZE).m847a("FLUZO-SDK-Name", Fluzo.NAME).m847a("FLUZO-SDK-Tier", Fluzo.TIER).m847a("FLUZO-SDK-Version", Fluzo.VERSION).m852b(this.f674a.f729l, "").m848a("test", "test.wav", "audio/wav", inputStream2);

Ahora bien, si continuamos revisando el código y las referencias a este endpoint, encontramos que en el resto de los casos se contempla el envío de un hashMap

c0851a = C0851a.m828b(new StringBuilder(String.valueOf(this.f674a.f728k)).append("/match").toString()).m846a((int) Indexable.MAX_BYTE_SIZE).m851b((int) Indexable.MAX_BYTE_SIZE).m847a("FLUZO-SDK-Name", Fluzo.NAME).m847a("FLUZO-SDK-Tier", Fluzo.TIER).m847a("FLUZO-SDK-Version", Fluzo.VERSION).m852b(this.f674a.f729l, "").m850a(hashMap, "UTF-8");

A mi parecer, y salvo error (posible a causa de cómo se encuentra el código relativo al SDK de Fluzo), este sistema se basa en una generación de huella digital similar a la que realiza Shazam, que será la información que se pasará al sistema dentro de este hashMap. Este mecanismo podría utilizarse tanto en el caso de señales inaudibles como de contenidos ordinarios, al final con lo que contamos es con una huella digital generada a partir de un algoritmo adecuado.

El perfilado de usuarios

Aunque trabajemos con huellas digitales y no con grabaciones en sí de conversaciones, debemos seguir teniendo en cuenta que la información acaba asociada a un usuario. Debemos recordar que la casilla que se nos mostraba hablaba de la lucha contra  la piratería

Se nos habla del uso de nuestros datos personales para la detección de fraudes, no para otras finalidades. No obstante lo anterior, lo cierto es que la empresa se publicita especialmente para la obtención de métricas

El valor diferencial de Fluzo reside en que no sólo desarrollan una tecnología ACR al nivel (contrastable) de nuestros competidores, sino que ofrecen a sus clientes mucho más que ACR. La startup pone a su disposición una plataforma analítica de Content Intelligence que, por primera vez, ofrece métricas digitales en tiempo real sobre quiénes son los espectadores y cómo consumen el contenido de sus clientes. Fluzo no es sólo tecnología; es tecnología más datos al servicio del negocio de nuestros clientes.

Resulta sencillo darse cuenta de que, más allá de la detección de posibles fraudes, la obtención de información de cómo se consumen los partidos, dónde, así como otra información adicional puede resultar atractiva para un ente como la Liga de Fútbol Profesional

Creamos Content Intelligence al extraer datos que hasta ahora no se podían conseguir sobre cómo interactúan los usuarios con los anuncios y otros contenidos creados por marcas o canales en medios tradicionales. FLUZO se convierte así en una especie de combinación de Shazam y Google Analytics de los medios audiovisuales.

El problema surgiría aquí porque se trata de una finalidad de creación de perfiles de usuarios de la que no se ha informado al usuario. Es posible que Fluzo pueda ofrecer un servicio que no incluya Content Intelligence, pero una vez se cuenta con información de los usuarios de la app existen perfiles potentes bajo el control de esta empresa, sean comunicados a La Liga o no.

Sergio Carrasco Mayans
Síguenos

Sergio Carrasco Mayans

Consultor at Fase Consulting
Sergio Carrasco Mayans es Ingeniero de Telecomunicaciones, Informático, politólogo y Licenciado en Derecho por la Universitat Oberta de Catalunya, especializado en Derecho de la Sociedad de la Información, Derecho Civil y Derecho Público.
Sergio Carrasco Mayans
Síguenos

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Últimas publicaciones

En los medios

Dada nuestra especialización, participamos regularmente en artículos en medios de comunicación.
Voz Pópuli
El Español
Hipertextual
Crea Cultura
Xataka
Eldiario

Contáctanos

Calle des Cubells 33, Esc 3, 3A
Teléfono: 971.31.13.31
Móvil: 625.93.81.24
Website: https://www.faseconsulting.es
Email: info@faseconsulting.es