Il y a quelques semaines, j'ai eu la chance d'assister à plein de conférences intéressantes lors du festival Pas Sage En Seine dont les archives sont disponibles en ligne.
Parmis les conférences, celle de Aeris qui expliquait « comment powned une application bancaire en 30 minutes » m'a incité à regarder quelles étaient les données envoyées par l'application android Izly, à des fins d'interoperabilité.
Pour rappel, Izly, c'est un système bancaire parallèle imposé par les CROUS aux étudiants, « plus rapide, plus simple, plus sécurisé » qui permet de payer son repas au restaurant universitaire. Je dis bien « imposé » aux étudiants, car il est bien souvent impossible de payer en monnaie sonnante et trébuchante (ou seulement certains jours de la semaine). Il devient quasi impossible de se passer de Izly, ce qui est problématique pour des raisons de vie privée. Je parle dans la suite de cet article de l'application android Izly: il reste bien sûr possible de recharger en ligne (moyennant le fait de filer ses coordonnées bancaires au service), sans utiliser de smartphones.
Bref, grâce à mitmproxy, on peut étudier la manière dont l'application communique avec l'extérieur.
Example de requêtes envoyées par l'application Izly. Notons le peu de requêtes servant effectivement au service.
L'application commence par communiquer avec le domaine api.beaconforstore.com. Cette communication s'effectue en deux étapes:
-
Premièrement, une requête POST vers
https://api.beaconstore.com/api/v1/sdk/appInfosqui contient le nom du téléphone, son modèle, sa version d'Android, ainsi que d'autres champs aux noms évocateurs:"AdvertisingTrackingEnabled": 1,ou encore"sAdvertisingIdentifier": a5dd…. -
Une seconde requête POST vers
https://api.beaconforstore.com/api/v1/sdk/registerCustomercontient quant à elle des variables comme la position GPS du téléphone (avec la latitude et la longitude, mais pas l'altitude), ou encore l'identifiant unique du téléphone.
Le site web http://beaconforstore.com redirige actuellement vers le site web http://www.neer.by/ (qui ne supporte d'ailleurs pas les connections sécurisées), qui décrit le but du service: du « Real life retargeting platform ». En pratique, et le site illustre tout à fait ça, il s'agit de pister et d'espionner les mouvements physiques des utilisateurs. Ceci explique sûrement l'envoi de la position GPS du téléphone.
Screenshot de MITMProxy montrant la latitude et la longitude envoyées à beaconforstore
Dans un second temps, l'application communique avec l'API de Izly (bah oui, il faut bien que l'application serve à autre chose qu'à espionner les utilisateurs) pour l'établissement du service. Ça me semble assez classique, mais ça dépasse ici mon domaine de compétence.
L'application communique aussi avec le domaine api.ad4push.com, et envoie des données similaires aux données déjà envoyées, l'altitude et les données d'accélération en plus. J'ai donc le plaisir de vous annoncer que j'écris actuellement cet article à 413m au dessus du niveau de la mer. Est aussi envoyé le code postal de mon restaurant universitaire principal, mon CROUS de rattachement, et la date de validation des CGUs de Izly.
Enfin, l'application communique aussi avec izly.maximiles.com (code postal et crous de rattachement) (d'après Wikipedia, « Maximiles est une société de fidélisation de client par un système de point sur internet »).
Voilà donc avec qui l'application android izly communique.
Légalement, le CROUS s'assure avec des conditions d'utilisation leur permettant à peu près n'importe quoi. Ils précisent en effet que: « Les données personnelles de l’Utilisateur sont principalement utilisées par S-MONEY pour les finalités suivantes : la conclusion et l’exécution du présent Contrat, en particulier les opérations de rechargement du compte de Monnaie électronique de l’Utilisateur, la prospection et l’animation commerciale, les études statistiques […]. Elles sont destinées, de même que celles qui seront recueillies ultérieurement, à S-MONEY, au Groupe BPCE, ainsi qu’à ses filiales directes et indirectes ou à ses partenaires commerciaux. ». Pas certain que cette collecte soit par contre en accord avec le nouveau règlement européen pour la protection des données, le RGPD (règlement général sur la protection des données). En effet, le règlement précise que les données personnelles doivent être « collectées pour des finalités déterminées, explicites et légitimes », et « la prospection et l'animation commerciale » ou « les études statistiques » sont tout sauf des finalités précises.
Pour finir, une image tirée du site de neerby qui illustre le but suivi par cette entreprise. Sympa, pour une application de paiement!
Ah, et aussi, cette magnifique interview du cofondateur d'EzeeWorld, à qui les données sont envoyées: http://www.ecranmobile.fr/Patrick-Chatanay-EzeeWorld-Neerby-est-une-plate-forme-de-retargeting-physique_a64003.html:
« nous permet de connaître sa fréquentation (temps de présence, récurrence, …) et ses lieux de vie (lieu d'habitation, de travail, loisirs...) issus de milliers de points d'intérêt. »
« Concrètement, cela peut permettre à une marque d'envoyer un code promo à un client si elle le soupçonne de se rendre dans la boutique d'un concurrent »
« cibler des consommateurs correspondant à leurs cibles marketing et ainsi de concevoir de véritables stratégies cross device »