Portada
mis comunidades
otras secciones
#9:
#1 Pues me lo he leído enterito y engancha bastante, #7 justo, ni shazam ni ostias, guarda el archivo de audio y lo envía a un servidor, en postprocesado en servidor ahí puedes hacer lo que te de la gana.
Me ha asustado más que la función que devuelve si hay partido siempre devuelva true, lo que significa que cada 30 minutos se pone a grabar, con dos cojones, es para que la AEPD les cruja a base de bien.
Me ha asustado más que la función que devuelve si hay partido siempre devuelva true, lo que significa que cada 30 minutos se pone a grabar, con dos cojones, es para que la AEPD les cruja a base de bien.
#14:
#9 Amplío mi comentario, vamos que a todos los que la tuvieran les han grabado cagando y a los no meneantes follando en algún momento. A políticos en conversaciones, consejos de empresa... ni la maquinita esa que decía la Espe que tenía el gobierno, además está gestionado por una empresa de un tercero, una delicia de datos vamos, y encima ligado a los usuarios.
#7:
"Sobre la Startup Fluzo [...] imagino que si lo esta usando La Liga [...] es que la cosa funciona, si ese es el caso mis diez para los creadores de Fluzo por que como ya dije al principio me parece algo muy complejo lo que hace su servicio, mucho más que shazam o similares y que tanta repercusión tienen en la sociedad y a los que compañias como Apple echaron el ojo rápidamente."
Dejando a un lado el análisis de dudosa calidad que hace de la aplicación, esta persona de tecnología no tiene mucha idea. Este caso es exactamente igual que Shazam, con 2 salvedades:
1. El análisis no es necesario que sea en tiempo real, puede ser en diferido. Se graban los audios, se procesan aunque tarden semanas, y se obtiene un listado de bares sospechosos de estar pirateando la emisión de los partidos. Y la denuncia se puede presentar meses tras la emisión, no pasa nada. No hay un usuario esperando una respuesta exacta en ese preciso instante. Es decir, es mucho más fácil que Shazam.
2. El análisis no se hace contra una base de datos de cientos de millones de canciones, si no únicamente contra un único flujo de audio: el que corresponde al partido de Liga que se está emitiendo en ese momento. Es decir, otra vez es mucho más fácil que Shazam.
Dejando a un lado el análisis de dudosa calidad que hace de la aplicación, esta persona de tecnología no tiene mucha idea. Este caso es exactamente igual que Shazam, con 2 salvedades:
1. El análisis no es necesario que sea en tiempo real, puede ser en diferido. Se graban los audios, se procesan aunque tarden semanas, y se obtiene un listado de bares sospechosos de estar pirateando la emisión de los partidos. Y la denuncia se puede presentar meses tras la emisión, no pasa nada. No hay un usuario esperando una respuesta exacta en ese preciso instante. Es decir, es mucho más fácil que Shazam.
2. El análisis no se hace contra una base de datos de cientos de millones de canciones, si no únicamente contra un único flujo de audio: el que corresponde al partido de Liga que se está emitiendo en ese momento. Es decir, otra vez es mucho más fácil que Shazam.
#5:
"Quiero decir, el hecho de grabar audio y geolocalizar para detectar emisiones fraudulentas me parece una idea bastante buena, pero ahorraría muchos mal entendidos explicar claramente a los usuarios que se graba, para que y a quien se le dan los datos para que los procese y con que finalidad asi como facilitar el acceso [...]"
También ahorraría muchos malentendidos escribir sin faltas de ortografía.
También ahorraría muchos malentendidos escribir sin faltas de ortografía.
#27:
#7 No hace falta criticar al original diciendo que tiene poca idea, a pesar que comete un error de bulto. Justo el mismo error que tú. Al menos él ha decompilado el código y se ha currado un artículo.
¿De verdad pensáis que necesitan postprocesar el audio del partido? ¡Ellos son los que generan el audio!
Les basta con incorporar un pequeño patrón (periódico) en las frecuencias no audibles por las personas pero que sí emiten altavoces y recogen micros. Podríamos decir que es un código de barras. Código único por emisión.
Se puede procesar y buscar este código en el teléfono. Sería sin duda muchos menos intrusivo que enviar trozos de audio a un servidor, pues puedes borrar el audio sin código instantáneamente. Si encuentras un audio con código, es entonces cuando lo comunicas al servicio (el código y las localización, no el audio completo).
Eso es lo que intenta vender el comunicado que el autor no entiende (y habla de viajan al futuro).
Por cierto, esto de los códigos de barras, ya es un método habitual. Los tenéis en anuncios, programas de tv, etc. y los recogen muchos juegos y aplicaciones.
¿De verdad pensáis que necesitan postprocesar el audio del partido? ¡Ellos son los que generan el audio!
Les basta con incorporar un pequeño patrón (periódico) en las frecuencias no audibles por las personas pero que sí emiten altavoces y recogen micros. Podríamos decir que es un código de barras. Código único por emisión.
Se puede procesar y buscar este código en el teléfono. Sería sin duda muchos menos intrusivo que enviar trozos de audio a un servidor, pues puedes borrar el audio sin código instantáneamente. Si encuentras un audio con código, es entonces cuando lo comunicas al servicio (el código y las localización, no el audio completo).
Eso es lo que intenta vender el comunicado que el autor no entiende (y habla de viajan al futuro).
Por cierto, esto de los códigos de barras, ya es un método habitual. Los tenéis en anuncios, programas de tv, etc. y los recogen muchos juegos y aplicaciones.
#16:
#9 A ver, que Shazam hace precisamente eso, graba una muestra y la envía al server que es quien analiza y determina que canción es... y hay mas servicios que hacen lo mismo, pero según el comunicado de LaLiga es que ellos hacen eso de forma local en el móvil.
Es viejuno pero no desfasado: http://coding-geek.com/how-shazam-works/
Por cierto según la GDPR deberían informar que el audio se comparte con terceros como son Fluzo. Vamos desde mi punto de vista... deberían meterles un puro por protección de datos / GDPR.
Es viejuno pero no desfasado: http://coding-geek.com/how-shazam-works/
Por cierto según la GDPR deberían informar que el audio se comparte con terceros como son Fluzo. Vamos desde mi punto de vista... deberían meterles un puro por protección de datos / GDPR.
Comentarios
"Sobre la Startup Fluzo [...] imagino que si lo esta usando La Liga [...] es que la cosa funciona, si ese es el caso mis diez para los creadores de Fluzo por que como ya dije al principio me parece algo muy complejo lo que hace su servicio, mucho más que shazam o similares y que tanta repercusión tienen en la sociedad y a los que compañias como Apple echaron el ojo rápidamente."
Dejando a un lado el análisis de dudosa calidad que hace de la aplicación, esta persona de tecnología no tiene mucha idea. Este caso es exactamente igual que Shazam, con 2 salvedades:
1. El análisis no es necesario que sea en tiempo real, puede ser en diferido. Se graban los audios, se procesan aunque tarden semanas, y se obtiene un listado de bares sospechosos de estar pirateando la emisión de los partidos. Y la denuncia se puede presentar meses tras la emisión, no pasa nada. No hay un usuario esperando una respuesta exacta en ese preciso instante. Es decir, es mucho más fácil que Shazam.
2. El análisis no se hace contra una base de datos de cientos de millones de canciones, si no únicamente contra un único flujo de audio: el que corresponde al partido de Liga que se está emitiendo en ese momento. Es decir, otra vez es mucho más fácil que Shazam.
#1 Pues me lo he leído enterito y engancha bastante, #7 justo, ni shazam ni ostias, guarda el archivo de audio y lo envía a un servidor, en postprocesado en servidor ahí puedes hacer lo que te de la gana.
Me ha asustado más que la función que devuelve si hay partido siempre devuelva true, lo que significa que cada 30 minutos se pone a grabar, con dos cojones, es para que la AEPD les cruja a base de bien.
#9 Lo terrible es que no les va a pasar nada. Ni AEPD ni GRPD ni ostias. No les va a pasar nada.
#13 la GPRD está por encima de cualquier corporación, y laliga no es nada especial. Se les podría acabar el chollo y sacarles hasta el tuétano de los huesos si los usuarios afectados se unieran y demandarán todos juntos. Pero no pasarà nada porque los usuarios de la app tienen bastante con poder respirar por ellos mismos. Porque si la supervivencia dependiera del coeficiente intelectual, ya estarían muertos
#9 Amplío mi comentario, vamos que a todos los que la tuvieran les han grabado cagando y a los no meneantes follando en algún momento. A políticos en conversaciones, consejos de empresa... ni la maquinita esa que decía la Espe que tenía el gobierno, además está gestionado por una empresa de un tercero, una delicia de datos vamos, y encima ligado a los usuarios.
#14 "...y a los no meneantes follando en algún momento..."
#9 A ver, que Shazam hace precisamente eso, graba una muestra y la envía al server que es quien analiza y determina que canción es... y hay mas servicios que hacen lo mismo, pero según el comunicado de LaLiga es que ellos hacen eso de forma local en el móvil.
Es viejuno pero no desfasado: http://coding-geek.com/how-shazam-works/
Por cierto según la GDPR deberían informar que el audio se comparte con terceros como son Fluzo. Vamos desde mi punto de vista... deberían meterles un puro por protección de datos / GDPR.
#16 con lo cual encima te va zampando la tarifa de datos, porque enviar ficheritos cada media hora al cabo del mes, pueden ser unos cuantos megas
#25 Me inquieta más que haya una empresa que tenga grabaciones tuyas las 24 horas del día vinculadas a tu id de dispositivo y de redes sociales, ni Facebook tuvo huevos a eso
#28 una o varias, pueden revenderle los datos a quien les parezca...
#9 si pero tú lo entiendes
la parte técnica es insondable para mí
#9 Esa parte no me ha quedado nada claro que realmente devuelva true siempre. O al del blog se le ha pasado describir un trozo, o se ha colado. No veo que describa ningún sitio donde location_enabled se inicialice a o se haga el set a true.
#41 En realidad no devuelve siempre true, sino lo que diga location_enabled en https://laliga.fluzo.com/settings.
Se ve que inicializa un objeto Settings usando el JSON de esa web, usando Gson (https://sites.google.com/site/gson/gson-user-guide)
#52 Tu si que sabes!
#41 lo saca de un properties
#9 el problema es que el usuario acepta eso al instalar la app.
Buenas, soy el autor del artículo y del blog en general, me gustaría responder a algunas cuestiones que se han planteado en los comentarios.
De modo genérico decir que el tema de los 30 minutos ya lo he corregido, efectivamente lo había interpretado mal, no envía datos cada 30 minutos pero si que recopila la ubicación del usuario cada 30 minutos, igualmente creo que lo importante no es cada cuanto tiempo lo manda si no que la decisión sobre cuándo manda los datos la aplicación no lo decide La Liga, si fuera así lo controlarían desde su servidor, igual que es ahí donde almacenan la nota legal que muestran al usuario, y no en el de una empresa que vive de analizar datos y que por ende cuantos más datos más beneficio. No acuso a nadie de nada, simplemente me parece algo curioso.
#8 Totalmente de acuerdo
#9 Sobre lo de la AEPD, realmente esto lo hacen con la autorización del usuario... en la versión 6.4.7 así que no tengo ni idea de si tiene algún tipo de pega a nivel legal. Remarco lo de esta versión porque mirando anteriores versiones, en la 6.4.5 ya se enviaban datos a Fluzo y en este caso no existía esa nota legal, por tanto han recopilado datos de los usuarios sin su consentimiento.
#66 Varias cosas:
Lo de la API mmmmm, depende, yo si fuera desarrollador en este caso no la 'hardcodearia', es un servicio privado que está manejando datos sensibles, piensa que si alguien conoce el endpoint adecuado y existe la posibilidad podría bajarse todos los audios de los usuarios, o las estadísticas que genere fluzo en base a estos, perfiles de usuarios, datos etc; evidentemente la documentación de la API de fluzo no es pública y es imposible saber que impacto tiene dejarla expuesta, pero que los propios devs de Fluzo no la pongan a pelo en el código de su SDK me hace sospechar.
Lo de la funcion decrypt() no es una suposición, los desarrolladores de fluzo han cifrado una serie de Strings por el motivo que sea y es asi como las descifran, lo cual no quita que no sea algo trivial de revertir y que para eso mejor no hacer nada, pero meh, peor para ellos.
#53 Primera linea un insulto y un fail. Si tuvieras un mínimo de comprensión lectora verías que no he usado dex2jar, genio.
Sobre lo de las opiniones, a mi La Liga no me ha pagado por analizar su aplicación, no es un informe que tenga que entregar a un cliente, a lo mejor estoy equivocado pero en mi blog podré hacer las apreciaciones subjetivas que me parezcan oportunas. Igualmente todas las conclusiones estan fundamentadas en el análisis del código de la aplicación, si tienes alguna evidencia objetiva que demuestre que mi análisis este equivocado en algún punto exponlo.
#57 El tema es que La Liga de a entender que el procesado se hace de forma local, cuando en realidad lo hace una empresa externa. Esto no sería un problema si informasen correctamente a los usuarios, al final el usuario es completamente libre de usar o no una aplicación.
#85 Te animo a que respaldes tu argumento con líneas del código, porque yo no he visto ninguna evidencia de lo que comentas, más bien todo lo contrario. Te pongo exactamente el código con el que suben el audio al servidor de fluzo:
Test de conexion: https://i.gyazo.com/cd9925b936481535be08627f0b0a1185.png
Peticion real: https://i.gyazo.com/49de6b22b31d0b1216ac8d2ac3ce3e46.png
#10 Pues buena pregunta, han violado claramente las politicas para desarrolladores de Google Play ya que en el changelog de la v6.4.7 dicen que la ubicación se usará para decir a los usuarios como llegar al estadio, función que ya estaba disponible en versiones anteriores pero con la que intentan justificar y enmascarar su verdadero fin, un fraude de libro que evidentemente no entra dentro de lo que Google Play considera "legal" https://play.google.com/intl/es_ALL/about/privacy-security-deception/user-data/ habrá que ver si Google dice algo al respecto o se pone de perfil, me imagino que si no reciben un número lo suficientemente elevado de reclamaciones se mantendrán al margen.
#101 No lo he mirado, pero según el comunicado de La Liga es algo que sólo pasa en Android, aunque visto lo visto a saber.
#104 Efectivamente, lo de detectar el fraude es lo que menos debería importar a los usuarios, lo realmente preocupante debria ser que hacen con los datos que recopilan por que tienen informacion de sobra para construir perfiles sobre los usuarios como bien indicas. En estos casos sólo queda confiar en la buena fe de la empresa de análisis, que analicen para detectar fraude y no hagan nada más, desafortunadamente este tipo de empresas viven del comercio de datos, así que cada uno que saque sus propias conclusiones.
Peticion real: https://i.gyazo.com/49de6b22b31d0b1216ac8d2ac3ce3e46.png
#10 Pues buena pregunta, han violado claramente las politicas para desarrolladores de Google Play ya que en el changelog de la v6.4.7 dicen que la ubicación se usará para decir a los usuarios como llegar al estadio, función que ya estaba disponible en versiones anteriores pero con la que intentan justificar y enmascarar su verdadero fin, un fraude de libro que evidentemente no entra dentro de lo que Google Play considera "legal" https://play.google.com/intl/es_ALL/about/privacy-security-deception/user-data/
#7 los partidos ya muestran en pantalla um codigo alfanumérico a veces, en una esquina, que es diferente en función de si es una subscripción de bar, de casa, etc... Un amigo mio trabajo yendo por los bares chequeando eso hace años.
No seria de extrañar que la señal de los partidos emitiera un patrón de somidos cada x tiempo que identifique el equipo que recibió la señal.
#20 Si estás pirateando la señal de bar, tendrá el mismo código que cualquier otra señal de bar.
#31 No tiene por qué, ahora mismo la señal de TV lleva una "orden" al decodificador oficial para que emita su numero por pantalla.
la señal de bar, no trae ningún "código" trae "la orden" que hace que el decodificador OFICIAL emita su numero de abonado
#35 ¿Y dónde está el problema? Tu decoder pirata puede emitir el código que tú quieras. El del bar de enfrente, por ejemplo.
#63 Eso mismo, si tu decoder pirata emite el mismo que el bar de enfrente y tropecientos sitios más, ya pillan que donde estás hay señal pirata y además qué decoder ha publicado dicha señal.
#63 que no emitiría NINGUNA señal
#31 no se los detalles de aquel código. Se que a dia de hoy sigue saliendo pero no se si es único por aparato o por señal. Pero hacer que cada aparato emita un sonido cada x tiempo, imperceptible (o no, simplemente disimulado) y que se procese el audio buscando ese patrón tiene sentido.
Ya lo dijeron los Simpson, la liga de
béisbolfútbol nos espía#20 yo creo que el código ese, está para evitar que la gente emita por streaming simplemente enfocando el móvil a la pantalla en un directo de Facebook y cosas así...
#7 No hace falta criticar al original diciendo que tiene poca idea, a pesar que comete un error de bulto. Justo el mismo error que tú. Al menos él ha decompilado el código y se ha currado un artículo.
¿De verdad pensáis que necesitan postprocesar el audio del partido? ¡Ellos son los que generan el audio!
Les basta con incorporar un pequeño patrón (periódico) en las frecuencias no audibles por las personas pero que sí emiten altavoces y recogen micros. Podríamos decir que es un código de barras. Código único por emisión.
Se puede procesar y buscar este código en el teléfono. Sería sin duda muchos menos intrusivo que enviar trozos de audio a un servidor, pues puedes borrar el audio sin código instantáneamente. Si encuentras un audio con código, es entonces cuando lo comunicas al servicio (el código y las localización, no el audio completo).
Eso es lo que intenta vender el comunicado que el autor no entiende (y habla de viajan al futuro).
Por cierto, esto de los códigos de barras, ya es un método habitual. Los tenéis en anuncios, programas de tv, etc. y los recogen muchos juegos y aplicaciones.
#27 La paja mental que te has montado es espléndida, pero fallas de base, en tu "¿De verdad pensáis que necesitan postprocesar el audio del partido?". Pues claro que necesitan procesarlo, por la sencilla razón de que en un bar hay ruido. Y hacer matching de dos sonidos cuando uno de ellos tiene muchísimo ruido de fondo (gritos, conversaciones, ruidos de cubiertos) no es fácil, y mucho menos trivial. Y un móvil tiene poca capacidad de cómputo, por eso se hacen estas cosas siempre en la nube.
#29 ¡Que no matchean sonidos! Que se puede hacer con un simple código binario en determinadas frecuencias.
#44 Yo sinceramente no sé si entiendes cómo funciona el sonido y los teléfonos móviles. El "código binario en determinadas frecuencias" es sonido. Y el teléfono móvil, después de capturarlo en el micrófono, lo convierte (mediante el ADC) a binario. Y ahí, lo primero que tiene que hacer (antes del matching o identificación o lo que quieras) es quitar ruido ambiente. Ésa es la parte difícil de todo el problema.
#61 Como te he dicho esto, esto que he llamado coloquialmente "los códigos de barras" para la audiencia general de meneame, hace tiempo que se está haciendo, se denominan balizas (ultrasonic beacons).
Te dejo lectura anda: Privacy Threats through Ultrasonic Side Channels on Mobile Devices
"we spot 234 Android applications
that are constantly listening for ultrasonic beacons in the
background without the user’s knowledge." (Y de esto hace año y medio....)
https://www.sec.cs.tu-bs.de/pubs/2017a-eurosp.pdf
#29 Emitir una señal pulsada a 10KHz de bajo volumen es trivial, nadie lo oye, pero un microprocesador de mierda de 50 céntimos es capaz de extraer es señal del ruido del bar e identificarla.
#69 Pues hay gente que piensa que un smartphone (esos que superan hoy día la potencia de portátiles y tienen más RAM) no pueden, y además se permiten llamarse entendidos.
Gracias por tu aportación.
#7 Este articulo es bastante malo, cierto.
#30 El articulo esta escrito por un prepotente que se cree que sabe un huevo porque alguien le ha pasado el dex2jar y no pone tres frases seguidas sin meter un error garrafal. Al del articulo, si me lees, la capacidad crítica y objetiva de un tipo que se las da de lo que tu son claves para hacer un buen trabajo. Un auditor no pone conclusiones propias sino hechos objetivos y aporta pruebas concluyentes. No es tu caso. Tienes de antemano las conclusiones y las intentas medio-justificar; y lo haces mal.
He leido hasta:
"Realidad -> devuelve siempre verdadero." cuando en el código no solo no pone eso sino que de ser como dice, faltarían más trazas.
y a partir de ahi, me hago una idea, dejo de leer.
#53 Hazlo tu mejor, si sabes. Listo.
Yo que no tengo ni pajorela, agradezco el trabajo de este señor.
Qué facil es quejarse del (mal) trabajo de otros...
#76 Pues como no tienes ni idea, puede que te la esten colando, asi que no agradeceria algo sobre lo que no puedo evaluar su calidad. Y yo he visto dos errores garrafales en su analisis, pero dejo que el personal los disfrute.
#76 Vas de sobrado chaval y pecas de ello. Lo dejo bien claro en mi comentario, no puedes afirmar categóricamente cosas y con tanta rotundidad cuando 1) te equivocas repetidas veces y 2) no eres objetivo. Por otro lado no tengo tiempo ni me interesa un carajo andar mirando una app que tampoco me interesa. Agradezco el esfuerzo de la gente como tu pero tu no eres divulgativo, eres egocéntrico.
Sin acritud, yo tambien he pasado por esa etapa.
#22 #32 He usado "binarizar" por mantener su terminología. <
#7 En cualquier caso, calcular un hash o cualquier otra cosa de mi voz, que se encuentra en el entorno de grabación supone el tratamiento de un dato biométrico.
Es el mismo concepto por el que está prohibido instalar cámaras de videovigilancia que graben audio.
Así lo estableció el Tribunal Constitucional en su Sentencia 98/2000
En resumen, la implantación del sistema de audición y grabación no ha sido en este caso conforme con los principios de proporcionalidad e intervención mínima que rigen la modulación de los derechos fundamentales por los requerimientos propios del interés de la organización empresarial, pues la finalidad que se persigue (dar un plus de seguridad, especialmente ante eventuales reclamaciones de los clientes) resulta desproporcionada para el sacrificio que implica del derecho a la intimidad de los trabajadores (e incluso de los clientes del casino). Este sistema permite captar comentarios privados, tanto de los clientes como de los trabajadores del casino, comentarios ajenos por completo al interés empresarial y por tanto irrelevantes desde la perspectiva de control de las obligaciones laborales, pudiendo, sin embargo, tener consecuencias negativas para los trabajadores que, en todo caso, se van a sentir constreñidos de realizar cualquier tipo de comentario personal ante el convencimiento de que van a ser escuchados y grabados por la empresa. Se trata, en suma, de una intromisión ilegítima en el derecho a la intimidad consagrado en el art. 18.1 CE, pues no existe argumento definitivo que autorice a la empresa a escuchar y grabar las conversaciones privadas que los trabajadores del casino mantengan entre sí o con los clientes. Lo cual conduce al otorgamiento del amparo con el restablecimiento al demandante en la integridad de su derecho, tal como le fue reconocido en instancia por el Juzgado de lo Social núm. 3 de Pontevedra.
#40 Si a mi tambien me ha hecho gracia lo de su comunicado y el codigo "binario".
Pffffffff, y sacarte una foto y subirla a Facebook tambien es tratar un dato biometrico, no se, ahi veo un poco forzado tu razonamiento.
#49 Es muy difuso, lo se, pero hay una diferencia fundamental.
En el caso de Facebook la utilidad primera y para el usuario es precisamente eso. Subir la foto entre otras utilidades que se ofrecen al usuario.
En el caso de la liga no. El tratamiento de audio no es para el usuario ni como uso lateral o secundario sino para uso exclusivo de la liga.
#51 Totalmente de acuerdo contigo, la finalidad no es la misma. Pero es que tampoco tengo muy claro porque se ha montado todo este pifostio ahora y no lleva montandose desde hace la hueva. ( Y el procesado parece hacerse en local, asi que no se sube la grabacion fuera... )
Por ejemplo la app movil de eldiario.es te pide acceso a la agenda. Tu crees que es necesario que eldiario.es acceda a mi agenda de contactos para prestarme el servicio ?
No se, es que veo demasiado postureo con estas cosas ... sera que me hago viejo y me vuelvo pragmatico.
#40 Falso. Si calculas un hash de un archivo de audio estás transformado dicho archivo en otra cosa, y deja de ser dato identificativo. Si se hiciese, y se hiciese bien (que parece que no), es decir, calculando el hash en el móvil antes de enviarlo al servidor, las leyes de protección de datos no aplicarían.
#62 Y es asi como se hace por lo que he visto. Se descarga una serie de fingerprints acusticos (que no hashes), y los compara con fingerprints que genera en tiempo real capturando x segundos cada vez. Si existe un match, hace cosas, entre otras notificarlo ...
No, no suben el audio a ningun lado. Pero que la realidad no nos joda una deliciosa teoria conspiranoica. Aunque el para que y como lo usen, si es para cagarse en ellos.
#62 Falso más.
La mera obtención del audio para calcular el hash supone tratamiento.
Palabrita de AEPD.
De ahí en adelante lo que quieras.
Pero ya has hecho un tratamiento.
No puedes calcular el hash si no tienes el dato en si mismo. El hash ya es un dato procesado y tratado. Punto.
Pero insisto, para la AEPD no necesitas no grabar nada para tener que cumplir.
La disociación, término definido en la propia ley, es ya una acción posterior a la obtención y posterior tratamiento.
Por otro lado un hash permite identificar unívocamente, salvo colisión. Así que no es disociación per se.
#86 Vamos por partes.
1. Calcular un hash supone tratamiento. Pero se hace bajo el control del usuario (su terminal). Es similar a cifrar un dato antes de enviarlo al proveedor del servicio, o de decirle "mi DNI empieza por 4". El dato personal deja de serlo. No identifica.
2. Un hash no identifica unívocamente. De hecho como sabes hay infinitas entradas que provocan un mismo hash. Me remito al ejemplo anterior.
No me sé la LOPD ni la GDPR de memoria, pero yo diría que no tienen nada que hacer aquí.
#93
1. Captura de voz de particulares por parte de una empresa= LOPD. Da igual lo que hagas con ella. Fin.
2. Mal hash si hace eso. Colisiones. Etc. Acabas de tirar a la basura el 80% de los sistemas de almacenamiento de la contraseña de casi todo internet.
#89 Las conversaciones entre particulares están fuera de la aplicación de la LOPD. Son actividades privadas. La ley es interpretable en su aplicación pero no debe romper el espiritu de la misma
#97 Sí, pero es la empresa de telefonía quien transmite esos datos. Pero ni "hurga" en ellos ni los analiza, sólo los transmite.
Por otro lado, si yo activo un micrófono pero de esos datos hago un filtrado tal que no queda absolutamente nada excepto esa señal que busco, no puedo estar saltándome la LOPD.
#98 Lo que puede resultar lógico acaba no siéndolo a efectos de LOPD.
¿Que dirías que ocurre con los sistemas de cámaras que permiten vigilar un comercio pero que no graban nada ni conservan nada y que solo permiten que el vigilante pueda ver varias zonas del comercio en tiempo real?
Insisto en un concepto: No se graba absolutamente nada por que ni siquiera hay sistema de grabación instalado. Solo cámara y monitor....
¿Le afecta o no?
#97 Lo ves todo muy simplificado.
1. La captura se hace bajo el control del particular. Se hace en un móvil de su propiedad. Lo que dices es similar a denunciar a los fabricantes de cuadernos porque en ellos se apunte un DNI. El fabricante desarrolla una herramienta que el usuario utiliza, pero en ningún momento tiene posesión de esos datos personales. No es que lo procese y lo borre, es que nunca lo tiene. Para que lo entiendas, modifica un poco el escenario: imagina que es una empresa que ha desarrollado un programa para Android para grabación de sonidos. ¿Ves que es estúpido que se le aplique la LOPD?
2. TODOS los hashes tienen colisiones. Es la definición de función hash: una función no inyectiva de un espacio infinito a otro finito. Y por supuesto, muchos de los sistemas de comprobación (que no de almacenamiento, un hash no almacena información, la destruye) son vulnerables.
"Quiero decir, el hecho de grabar audio y geolocalizar para detectar emisiones fraudulentas me parece una idea bastante buena, pero ahorraría muchos mal entendidos explicar claramente a los usuarios que se graba, para que y a quien se le dan los datos para que los procese y con que finalidad asi como facilitar el acceso [...]"
También ahorraría muchos malentendidos escribir sin faltas de ortografía.
#5 Gracias por no aportar nada salvo un poco de chulería
¿No podeis mandar un privado para cosas que no aporten nada a la noticia?
#5 malentendidos entre 'que' y 'qué' y 'asi' y 'así'. Guerras han empezado por menos. #enfin
Cojonudo el analisis
#3 muy documentando y además despeja casi cualquier duda de que han mentido torticeramente.
Seria cómico que un facha como Tebas terminara delante de un juez por esto y no por todas las borradas que ha soltado por esa boca.
Personalmente descarga la aplicación hace tiempo ( para saber el horario de los partidos ) y en una de las actualizaciones ( muy frecuentes por cierto ) empezó a pedir permisos ( agenda,cámara etc..) inmediatamente la borre
#2: Y luego decían que el Teletexto es demasiado antiguo... puede ser, pero al menos no te espía y también te da los resultados en tiempo real.
#8 El teletexto es una invención del copón, meter toda esa información en 10 líneas de vídeo y diseñar cómo pasar de una página a otra con una simulada interactividad...
¿¿Por qué no quita esta aplicación Google de la Play Store??
#10 una app que apesta. prefiero mil veces sofaScore
#17 poder tener los resultados en tiempo real de la liga de Somalia no hay quien lo pague!
Me lo estoy leyendo y ya he visto una cosa que no es cierta, dice:
Mirando la funcion mas en profundidad, envía la información si la función DataManager.INSTANCE.getMatchLive() devuelve un True, osea deducciendo un poco, por el nombre, si hay partido activo, devuelve verdadero, sino, devuelve falso.
Realidad -> devuelve siempre verdadero.
Y no es cierto, va a preguntar a la pagina de settings de fluzo.com y al menos en este momento dice: location_enabled:false
Cómo leer arameo
#1 El arameo esta mejor escrito y es mas inteligible que ese articulo y la app de la liga.
#1 Unas anotaciones en cristiano, por si sirve mejor que leer código:
1) En el artículo se horrorizan de que la clave del API está visible.
-¿Y qué? Es perfectamente seguro. Probad a usar integración con Maps o Firebase (servicios de Google) y me contáis dónde metéis la clave de API. O mejor aún, intentad alguna trastada con ella. Nada, ¿no?
2) El código para comprobar el permiso es un horror. ¿Guardar el permiso en SharedPreferences? ¿Con qué fin? ¿Y un return en medio de un if? Pues vale.
3) ¿ACCESS_FINE_LOCATION? ¿Qué pasa, me vais a venir a recoger o algo? ¿Para qué cogéis mi posición con la máxima precisión posible? No entiendo.
4) Lo de que la función getMatchLive() devuelve siempre verdadero es más falso que Judas. A no ser que la clase Settings que han puesto en el artículo forme parte del backend (que no me lo creo, que me digan quién les ha dado ese código... para mí que se lo han inventado ellos). Aún así, si tuviera que adivinar, diría que getMatchLive() devuelve verdadero siempre que la app pueda localizar la posición GPS del móvil, lo que sería raro de cojones igualmente.
5) Es verdad que la app intenta enviar localización GPS cada cierto tiempo al servidor. Esto es raro y no se me ocurre ningún fin justificable.
6) Más abajo los del artículo ya están viendo ovnis otra vez... Plantan una función que se llama decrypt(), que ellos suponen que sirve para cifrar claves de API (que de nuevo, no hay ninguna necesidad de hacer esto), cuando lo único que hace es transformar datos a Base64. Es decir, circulen...
7) Es gracioso que el programa (después de solicitar permiso al usuario, eso sí) intenta usar el micro para grabar siempre que puede. Digo que es gracioso porque claro, como potencialmente el usuario ya les ha dado el permiso, pues les pueden estar grabando mientras cagan, duermen, etc. Me apuesto dinero ahora mismo a que la app intenta comenzar a grabar nada más arrancar la app. Estoy por descargármela, arrancarla y grabarles porno gay ahora mismo...
#72 #66 aclara mucho
#66 La clave api en ALGUNAS implementaciones es todo lo que necesitas, no te hace falta usuario y password. Dependiendo de los permisos asociados a esa clave puede ser un fallo MUY gordo de seguridad, si por ejemplo te permite obtener datos a cascoporro. En Google maps te da igual porque todos los datos son públicos igualmente.
#78 Una clave API nunca es un secreto. Jamás. No sé a qué implementación te estás refiriendo cuando dices "algunas". Una clave API es sólo un identificador de usuario. Si te estás refiriendo a enviar la clave API y la firma de forma que el servidor compruebe la firma en base a la clave API, esto muy probablemente no es lo que está haciendo la Liga ni falta que les hace...
#88 Nop, te equivocas.
https://en.m.wikipedia.org/wiki/Application_programming_interface_key
The API key often acts as both a unique identifier and a secret token for authentication, and will generally have a set of access rights on the API associated with it.
Y no sólo porque lo diga la wikipedia sino porque curro con varias aplicaciones en la nube y una de ellas usa el key como user+pwd y no solo como identificador del cliente.
Me da que tu estas acostumbrado a las apis usadas desde apps móviles. Pero hay más mundo ahí fuera.
#90 Sin embargo, si entro en el link de la wiki que me has dado y hago click en la fuente que da la propia wiki, (este otro link)...
https://www.ibm.com/support/knowledgecenter/SSYJJF_1.0.0/ApplicationSecurityonCloud/appseccloud_generate_api_key_cm.html
Aquí ya empiezan a diferenciar entre Id y Secreto.
#91 Y dale. Ese es un producto de ibm. Hay otras implementaciones. En apis publicas tipo Google maps es como tú dices porque todos los datos son públicos. En apis que deben controlar autorización más autenticacion las hay que usan el api-key como sustituto de usario+pwd. Por ejemplo sistemas en la nube de RRHH, finanzas, gestión de proveedores, etc. En el caso que nos ocupa depende de los permisos asociados a esa key. Si lo han hecho bien da igual que sea pública. Si lo han hecho mal y esa key te permite llamar servicios que te den datos que no son públicos...
Ejemplo:
https://success.coupa.com/Integrate/Technical_Documentation/API/Get_Started
Requests are authenticated by a unique API key, generated in Coupa.
#92 Me informaré de qué otras implementaciones hay en las que te sirvan usuario y password en la propia request. No digas "y dale" cuando te contestan con la info que hay en el propio link que tú mismo ofreces...
#94 Otro ejemplo de producto comercial que usa el mismo esquema:
https://sentworks.com/blog/how-to-get-and-configure-an-everbridge-api-key/
De hecho estos usan como api-key el base64 del mismo user+password que utilizas para logarte via web. Obviamente para hacer esto tienes que ir siempre por https porque sino estarías mandando la password en claro.
#88 normalmente es parte de la autenticación , pero no es todo lo necesario. Normalmente n los servicios o tienen una "whitelisting" o varios mecanismos para que solo con la API key no valga por si mismo... Pero no es bueno ir dando pistas al enemigo....
#1 Ya te digo, más allá de la cuestión técnica está escrito como el culo.
1.Rootear el sistema.
2.Instalar Xposed.
3.Instalar Xprivacy
4.Ejecutar Xprivacy.
5.Denegar permisos de acceso al microfono.
#75 Desde hace un par de versiones de android ya no hace falta eso. Puedes tunear los permisos de cada app. No a un nivel muy fino, pero puedes.
#75 rootear el sistema... Empezamos bien
Muy interesante el artículo, aunque tiene un fallo. Dice que la funcion getMactchLive devuelve siempre verdadero, pero por lo que se ve en el código, parsean las settings que estan en https://laliga.fluzo.com/settings y que ahora mismo está a falso.
Gracias, articulista. Ahora ya lo podemos decir, con conocimiento de causa.
Venga, todos a una: ¡malditos hijosdeputa!
#6 Se dice hijueputas, ya lo decía Don Pablo Escobar Gaviria.
Los receptores i-Plus emiten el código de abonado en frecuencias inaudibles para el ser humano pero que su app si detecta,luego coteja el número de abonado y la geolocalización GPS con una base de datos de todos los bares que pagan por el partido
PD: Yo sabia que nos la metía doblada y no tengo ni puta idea de ingeniería inversa
Da gusto leer artículos tan detallados y documentados. Gracias.
#32 No es igual, si quisieran decir hash lo habrían hecho porque ese comunicado les compromete, además que dime tu como sacas un hash con el ruido de fondo de un bar que valga para algo
Me aburre mucho el tema ya, pero en resumen, el artículo no da una al derechas. No hace falta grabar, y no hace falta enviar audio. Y si la aplicación pide permiso de micrófono y posicionamiento y sólo usa eso no infringe nada.
Ahora, el que quiera dejarse el gorrito de albal, que se lo deje. Yo ya paso.
#68 No se trata de que estén espiando a los usuarios, si no que usa al usuario como espía o caballo de troya.
Dos caminos no excluyente s:
LOPD/RGpd por cuanto se obtiene información de audio de terceros que no han consentido explícitamente. Os recuerdo que poner cámaras que no graben implica necesariamente aplicación de la LOPD y hay sanciones de la agencia en ese sentido. Incluso sanciones por cámaras simuladas.
Ley de consumo por cuanto se suministra una aplicación a un usuario con una funcionalidad encubierta y oculta que no sirve al usuario y que lo convierte en medio de explotación empresarial para los exclusivos fines de La Liga, aunque se le advierta, y se usa para beneficio de un tercero. Ya, esto pasa casi con cualquier app que explote datos de los usuarios que consienten pero no las de los que no consienten.
Y no me vale que no grabe o que "binarize"el audio. Cualquier tratamiento que se haga de mi voz, que no tengo la app, en el bar donde hay otros parroquianos que si la tienen, exige de mi consentimiento.
Si se "binariza" el audio ya hay un tratamiento de mis datos biométricos. Se grabe o no.
#11 Binarizar en el contexto de software es absurdo, todo se binariza, las canciones que escuchas en el móvil están binarizadas, y que si interpretas luego esos binarios, pues sale tu voz, la canción, una película... es una respuesta que trata de subnormales a la gente
#22 Vamos, que querian decir hashea no binariza, pero creo que se entiende, no hay que ser tan tikismikis, el problema es otro (El micro abierto y la geolocalizacion a saco, o vaya, lo mismo que hace Google), no que use el termino "binarizar".
#11 Entonces jamás podrías hablar por teléfono en un bar, porque inevitablemente estarás cogiendo el sonido de fondo también y con él las palabras de otras personas que no te han autorizado a ello.
Ojalá que consideren infracción muy grave (que lo es) y le metan a LaLIga 20 millones de euros con las nuevas sanciones del GDPR.
Salu2
#64 no se si has leido bien mi comentario
¿Y cómo ha conseguido el código fuente? Pregunto desde la ignorancia... No me muerdan
#12 lo "desempaquetas" del apk instalable.
#12 tecnología inversa. Es algo accesible. Pasas la apk por un programa.
#12 lo explica en el artículo:
Para esto se puede tirar de apktool para ver el smali o lo que sea, nos vale un dex to jar y tirando, total lo que interesa es ver el código de una manera estática sin necesidad de editar el comportamiento.
#12 El java compilado se puede descompilar muy muy facilmente.
#24 Como te pasen la clase por un ofuscador, lo "descompilas" tan facilmente que despues te da un derrame cerebral.
#12 existen herramientas que te permiten exportar un apk instalado en un terminal para obtener el fichero apk.
Con el apk en tu pc, existen herramientas (el winrar te vale) que permiten extraer el binario (generalmente un fichero .dex) dentro de ese paquete.
Con ese código "dex" puedes usar herramientas para pasarlo a .jar y también hay herramientas para "decompilar" el codigo jar a lenguaje java. Como bien dice #34, no lo lograrás siempre. Puedes obtener resultados parciales, totales o nulos.
Dificultad? muy baja. Estas tools estan para cualquier SO y son muy intuitivas y gratuitas. Usa google.
#58 Como la clase la pasen por un ofuscador, el resultado del ultimo pasito que comentas, lo interpretas por los cojones.
Por poner un ejemplo:
JavaGuard is a general purpose bytecode obfuscator, designed to fit effortlessly into your regular build and testing process, providing peace of mind that your valuable Java code is more secure against decompilation and other forms of reverse engineering.
Entrevista a la gente de Fluzo, que se ve que es una empresa española: http://www.elreferente.es/tecnologicos/fluzo-google-analytics-tele-30102
#82 Cuatro entepeneurs como los de twenty: pijos copiando una idea ya mascada. Marca España.
Habría estado bien una captura de red, pero muy interesante.
#45 No es algo nuevo. Se usa hace años.
Es mucho más sencillo. La emisión incorpora un ultrasonido y la app lo identifica y con el GPS da la posición. Si en la base de datos no aparece el local ya tienen pillado al pirata.
#36 Estas suponiendo que los altavoces de las teles son capaces de emitir esa frecuencia, y me parece mucho suponer. Pero bueno, podrían hacerlo emitiendo un anuncio en particular a una hora en particular, eso si.
El comunicado de la liga es perfecto para que no se nos ocurra volver a instalar esa mierda de aplicación. Cualquier aplicación de resultados es mejor que la suya.
Que gran artículo
Supongo que aplicación enviara los fragmentos de audio a un servidor con el fin de transcripción.
Transcribir audio a texto no es difícil, hace unas semanas sin ir más lejos yo mismo implemente un sistema que envía audio a Amazon Transcribe para posteriormente analizar el sentimiento del texto (Sentiment Analysis).
#39 ¿Has probado a grabar las muestras en un bar hablando lejos del móvil?