La fragmentation d’Android : un obstacle pour les apps de contact tracing

Les fabricants de smartphones Android apportent parfois de légères modifications à l’OS de Google. L’une d’entre elles concerne une sécurité apportée par google en 2015 : depuis Android 6 il faut que la localisation soit active pour utiliser certaines fonctionnalités Bluetooth Low Energy (ci-après BLE ou Bluetooth). Cette restriction empêche qu’un utilisateur soit localisé à son insu mais elle est peu documentée et n’a pas été intégrée dans certains smartphones Android. Cette disparité n’avait pas d’effet majeur tant que l’utilisation du BLE pour détecter les appareils se trouvant à proximité était peu répandue, mais elle devient critique maintenant que des millions de smartphones utilisent le BLE pour mesurer des distances. Pour corser le problème, la solution la plus simple pour activer la localisation depuis une app (et donc s’assurer que le BLE fonctionne) implique de remonter des informations de localisation à Google.

Disclamer : Cet article s’appuie essentiellement sur la documentation d’Android et différents articles de blog que j’ai référencés autant que possible. Je n’ai pas pu tester les apps sur plusieurs modèles de smartphones Android, aussi n’hésitez pas à m’indiquer si vous observez des comportements différents sur votre smartphone et/ou à m’indiquer des corrections via twitter (dm open).

Pourquoi demander la localisation pour scanner le Bluetooth

Bien que l’utilisation première du Bluetooth soit de pouvoir connecter des appareils se trouvant à proximité du smartphone (casque, oreillette,…), il peut aussi, tout comme le wifi, être détourné par les apps pour géolocaliser l’utilisateur sans qu’il n’en soit averti[1]. Par exemple, des sociétés proposent de déployer des balises Bluetooth à des fins de géolocalisation dans les magasins[2]. Pour éviter que les utilisateurs soient géolocalisés à leur insu, Google a intégré des protections au niveau d’Android pour avertir les utilisateurs qu’ils pourraient être géolocalisés.

En 2015, Google a intégré à Android une protection pour éviter ce détournement de fonctionnalités : toute app souhaitant utiliser le BLE pour scanner les appareils à proximité est considérée comme une app localisant le smartphone[3]. Ainsi, à partir d’Android 6, pour pouvoir scanner en BLE, une app doit obtenir la permission de localiser un utilisateur. Donc, que ce soit pour le localiser ou non, le BLE ne peut pas être utilisé sans avoir préalablement obtenu la permission de l’utilisateur.

Une documentation vague et un OS fragmenté

  • Un excès de transparence…

A en croire la documentation Android, pour qu’une app puisse scanner les appareils Bluetooth à proximité, il lui suffit d’obtenir la permission de localiser. En pratique, cette permission n’est pas toujours suffisante.

Extrait de la documentation bluetooth

Src : https://developer.android.com/guide/topics/connectivity/bluetooth

En effet, Google a considéré jusqu’au bout qu’une app utilisant le BLE était une app souhaitant localiser l’utilisateur. Or pour qu’une app Android puisse localiser l’utilisateur, il faut non seulement qu’il lui en ait donné la permission, mais aussi que le service de localisation du smartphone soit actif. Google a donc imposé la même contrainte dans son OS : pour qu’une app puisse scanner en Bluetooth, il faut que la localisation du téléphone soit activée. Ainsi, non seulement l’app qui veut scanner le BLE pourra localiser l’utilisateur, mais ce sera aussi le cas pour toutes les applications et services ayant déjà obtenu la permission de localiser le téléphone.

Figure 1 L’app de scan BLE demande la permission de localiser  Figure 2 L’app demande à activer la localisation  

Cette seconde condition n’est pas mentionnée dans la documentation Android citée plus haut et n’est pas non plus complètement intuitive. C’est comme si, par crainte que des voyeurs utilisent des caméras infra-rouges pour épier votre domicile, votre propriétaire (ici Google) décidez d’enlever tous les rideaux aux fenêtres. Certes, vous avez plus conscience des risques de voyeurisme et vous adaptez votre comportement en conséquence, mais vous êtes également visibles par plus de monde. Ici le résultat est le même puisque tous les services et applications qui ont la permission de vous localiser pourront eux aussi accéder à votre localisation et pas seulement l’application utilisant le BLE.

Il aurait été souhaitable de débattre de ce choix technique qui n’est pas anodin et pas forcément compris des utilisateurs ni des développeurs. Cette contrainte technique n’ayant pas été documentée, aucun débat n’a pu avoir lieu sur sa pertinence ou sur les alternatives.

  • … pas toujours compris des fabricants de smartphones

Pour ajouter à la confusion, les fabricants[4] de smartphones Android n’ont pas tous implémenté cette deuxième protection. Sur certains smartphones, il faut que la localisation soit active pour qu’une app puisse détecter les appareils Bluetooth à proximité, mais sur d’autres cela fonctionnera même avec la localisation désactivée.

Etonné par ce comportement incohérent, un développeur a testé plusieurs smartphones et, selon lui, les smartphones Android avec une surcouche « légère » (c’est-à-dire avec une version d’Android très peu modifiée par le fabricant) vérifient bien que la localisation est activée mais les smartphones qui utilisent des versions plus « customisées » ignorent complétement cette contrainte[5]. On peut s’interroger aussi sur l’objectif des fabricants de smartphones qui n’ont pas inclus une protection quand ils ont « customisé » Android. Il n’est d’ailleurs pas certain que Google sache que certains fabricants ont modifié le code d’Android pour enlever cette protection.

Cette fragmentation est problématique pour les développeurs puisqu’elle ne leur permet pas d’avoir un comportement constant d’un smartphone Android à l’autre. Ainsi, les développeurs devraient tester leur apps sur de multiples smartphones pour considérer les différents cas de figure. Cerise sur le gâteau : un smartphone qui bloque le scan BLE ne remontera pas d’erreur mais indiquera seulement qu’il n’a détecté aucun appareil à proximité. L’application ne sera donc pas en mesure de savoir si c’est parce qu’effectivement aucun appareil n’est à proximité ou si c’est parce que l’OS a bloqué le scan.  

L’implication pour les apps de contact tracing

Jusqu’à présent, relativement peu d’applications utilisaient les scan BLE de façon intensive. Mais l’apparition des apps de contacts tracing changent la donne puisque celles-ci reposent principalement sur le bluetooth pour détecter les contacts. Par conséquent, ces apps ont besoin de scanner constamment le BLE à la recherche d’autres appareils à proximité. Or sur certains téléphones, elles ne pourront le faire que si le service de localisation est activé.

  • Quelle proportion d’utilisateurs affectée

Il n’est pas facile d’estimer sur quelle proportion d’appareils le scan BLE est bloqué en l’absence de localisation. D’une part, pour que cette protection soit bloquante, il faut que l’utilisateur n’ai pas la localisation constamment active sur son smartphone. Je n’ai pas trouvé d’estimation du nombre d’utilisateurs qui désactivent la loc sur leur téléphone. Un petit sondage twitter m’indique que près de 50% des personnes qui me suivent coupe la localisation[6], mais cette estimation est probablement biaisée. A ma connaissance, l’étude la plus proche est le baromètre de la CNIL selon lequel 43% des utilisateurs désactivent parfois la localisation[7]. On peut donc considérer qu’une part assez faible d’utilisateurs la désactive fréquemment.

D’autre part la proportion d’appareils qui vérifient que la localisation est activée avant de permettre le scan BLE est à ma connaissance inconnue. Jusqu’à ce qu’il soit demandé aux personnes de se balader constamment avec le Bluetooth allumé pour espérer sauver des vies, les scans BLE étaient rarement utilisés ce qui explique un faible intérêt pour ce problème.

Par curiosité, j’ai effectué un test sur mon smartphone (un Moto G5 Plus avec Lineage) et l’appareil scanne bien en BLE même avec la localisation désactivée. Difficile cependant de savoir si ce comportement relève de l’exception ou de la règle.

Des app de contact tracing avec des stratégies opposées

Pour être assuré de fonctionner parfaitement sur tous les smartphones Android, les applications de contact tracing devraient forcer l’activation de la localisation. En pratique, toutes ne le font pas, soit par omission (puisque ça semble fonctionner sur certains appareils), soit pour éviter que l’utilisateur pense qu’il va être localiser.

  • Les applications basées sur EN forcent à géolocaliser

Toutes les applications de contact tracing Android qui s’appuient sur l’API Exposure Notificaiton (proposée par Apple et Google) demandent à ce que l’utilisateur active la localisation pour pouvoir fonctionner[8] (sauf sur Android 11). Cet été, Google a d’ailleurs été critiqué car certains y voyaient une tentative pour récupérer plus de données de localisation[9]. En fait, Google ne pouvait pas contourner cette restriction sauf à modifier le code de son OS, et ce n’est que sur Android 11 que Google peut corriger le tir.

En forçant les utilisateurs à activer la localisation, Google s’assure que les applications de contact tracing fonctionneront parfaitement sur tous les terminaux. Mais le corollaire est que certains utilisateurs vont activer la localisation sans que cela n’ait été vraiment nécessaire remontant probablement des données à google (c.f. encadré).

  • StopCovid et TraceTogether ne forcent pas la localisation

StopCovid et TraceTogether ont une approche différente puisqu’elles peuvent être utilisées même avec la localisation désactivée. Sur mon téléphone, aucune des deux apps n’a vérifié que la localisation était active avant de lancer des scans [11]. Ne sachant pas s’il s’agit d’un bug ou d’une feature, j’ai signalé le problème aux développeurs[10].

Dans les cas où le scan bluetooth est bloqué, StopCovid ne devrait fonctionner qu’à moitié :

  • Puisque votre smartphone émet toujours en bluetooth, si vous êtes passé à côté d’une personne testée positive au Covid, vous devriez être notifieé.
  • Par contre, si vous êtes-vous même testé positif vous ne pourrez pas notifier les personnes que vous avez croisées quand votre scanner n’était pas actif.

TousAntiCovid (i.e. StopCovid v2) semble ne demander l’activation de la localisation que dans une situation précise : si le téléphone est sous Android 10 et qu’il ne supporte pas le batch de scan (je n’ai pas encore pu déterminer si cela réglait le problème).

Extrait du code de “TousAntiCovid”

Google Location Services

Quand une application souhaite localiser un utilisateur, elle peut soit utiliser l’API ouvert d’Android qui utilise le GPS, soit utiliser les Google Location Services (GLS) qui offrent une localisation plus rapide et plus précise. Les GLS font partie des Google Play Services, c’est-à-dire de l’ensemble d’APIs propriétaires qui sont disponibles sur une écrasante majorité de smartphones Android (en dehors de la Chines). Les GLS sont activés par défaut sur la plupart des terminaux Android, et les désactiver nécessite de fouiller dans les paramètres de localisation du smartphone.

Le principal inconvénient des GLS est qu’ils font régulièrement remonter à Google la localisation des utilisateurs. En effet, comme l’explique Google, « des données de localisation de votre appareil sont recueillies régulièrement et utilisées de façon anonyme pour améliorer la précision de la localisation »[12].

Il est important de noter ici une petite subtilité : les données de localisation qui sont envoyées à Google ne sont pas anonymes, seule l’utilisation qui en est faite l’est. Cette description des données remontées par les GLS et de l’usage qui en est fait diffère sensiblement de la description qui en était faite jusqu’en 2018. En effet, jusque-là, Google décrivait les données qui étaient remontées comme anonymes. Ainsi, on observe dans la plainte de NYOB que Google décrivait que « des données de localisation anonymes seront envoyées à Google lorsque l’appareil sera allumé ». 

Extrait de la plainte NYOB

Très peu de documentation explique quelles données sont envoyées par les GLS. Dans une réponse adressée à deux sénateurs américains en janvier 2018, Google précise que les GLS remontent des informations de localisation associées à des identifiants temporaires et tournants[13]. Il s’agit vraisemblablement de données pseudonymisées et selon la méthode et la fréquence avec lesquelles ces pseudonymes sont générés, il est plus ou moins facile pour Google de retrouver à qui ces données de localisation correspondent.

Popup de demande d’activation des GLS dans Google Maps. Les explications (écran de droite) n’apparaissent que si on clique sur la flèche

Les GLS sont souvent activés par les utilisateurs. S’il est vrai qu’ils permettent une localisation plus rapide et plus précise, leur fort taux d’utilisation s’explique aussi par la simplicité de leur activation : lorsqu’une app veut demander à l’utilisateur d’activer la localisation, il est beaucoup plus simple de le faire en utilisant l’API des GLS : un popup apparaît et l’utilisateur n’a qu’à cliquer sur OK. A ma connaissance, il n’existe pas d’API permettant de d’activer aussi simplement la localisation sans activer les GLS.  A contrario désactiver les Google Location Services nécessite de fouiller dans les paramètres du téléphone[14].

Exposure Notification bénéficie d’une API privilégiée

Les applications de contact tracing qui souhaitent pouvoir utiliser le scanner Bluetooth sur la globalité des terminaux Android n’ont, a priori, pas d’autre choix que de s’assurer que la localisation du téléphone est active. Lorsque la localisation n’est pas active, les apps ont deux options pour demander à l’utilisateur de l’activer :

  1. Lui demander de se rendre dans les paramètres du téléphone pour activer la localisation. Cela implique de faire sortir l’utilisateur de l’app pour le diriger vers les paramètres du téléphone puis de le faire revenir dans l’application. Ces opérations sont fastidieuses et nuisent significativement à l’expérience utilisateur.
  2. La seconde option consiste à lui permettre d’activer la localisation via une popup qui apparait dans l’app. Cette seconde option est préférable d’un point de vue expérience utilisateur puisque ce dernier reste dans l’app et n’a pas à naviguer dans les paramètres du téléphone. Plusieurs applications font d’ailleurs apparaitre un tel popup lorsque la localisation n’est pas active. La subtilité est que cette option n’est disponible qu’avec les Google Location Services, il n’est pas possible pour un développeur de faire en sorte que seul le GPS soit activé. En choisissant cette seconde option, le développeur active les GLS et la collecte par Google de données de localisation pseudonymisées.

Les deux options ont leurs inconvénients : la première nuit à l’expérience utilisateur alors que la seconde nuit à sa vie privée Mais pour les applications qui s’appuient sur EN, Google semble avoir apporté une troisième option : ces applications peuvent activer le service de localisation depuis l’app sans pour autant activer les GLS. Elles disposent ainsi des avantages des deux approches : une expérience utilisateur plus fluide qui n’active pas systématiquement de remontée d’informations.

Le fait que toutes les applications basées sur l’API Exposure Notification utilisent exactement le même texte pour décrire l’activation de la localisation indique que c’est au niveau de l’API Exposure Notification que l’opération est effectuée et non au niveau de l’app. Comme pour les GLS Google peut modifier un paramètre depuis une app car les Plays Services disposent des permissions requises pour le faire[15], mais les autres applications n’ont pas accès à ces fonctionnalités (à noter que les apps utilisant EN ne demandent pas non plus la permission de localiser).

Captures de 4 applications de contact tracing basé sur Exposure Notification

Même si la localisation est activée pour les besoins d’une application de contact tracing, les autres applications qui ont la permission d’accéder à la localisation et les services de Google précédemment activés (Location History ou GLS) pourront localiser l’utilisateur. Or une fois encore, on peut se demander qu’elle est la pertinence de permettre la collecte de données de localisation lorsque l’utilisateur souhaite simplement utiliser une app de contact tracing. Google aurait pu aller un cran plus loin et désactiver l’envoi d’informations à destination de ses propres services lorsque la localisation était activée depuis une app de contact tracing.

La voie à suivre ?

Une meilleure solution serait de n’activer la localisation que sur les terminaux Android sur lesquels cela est nécessaire. En effet, comme on l’a vu, du fait de la fragmentation, sur une partie du parc de terminaux Android la localisation n’a pas à être activée pour permettre aux app de contact tracing de fonctionner. Forcer l’activation de la localisation sur ces terminaux n’a donc pas de sens, mais encore faut-il pouvoir les identifier or l’API ne permet pas forcement de le faire.


[1] https://team.inria.fr/privatics/ftc-inmobi-settlement-our-2014-research-predicted-the-abuse-of-the-wifi-permission/

[2] https://www.nytimes.com/interactive/2019/06/14/opinion/bluetooth-wireless-tracking-privacy.html

[3] https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-hardware-id

[4] On entend par fabricant, les sociétés qui vendent des smartphones avec l’OS Android telles que Samsung, Xiaomi, Huawei, LG…

[5] https://www.polidea.com/blog/a-curious-relationship-android-ble-and-location/

[6] https://twitter.com/vtoubiana/status/1309022372142477313

[7] https://linc.cnil.fr/fr/barometre-linc-2019-les-pratiques-de-protection-des-donnees-progressent

[8] https://blog.google/inside-google/company-announcements/update-exposure-notifications

[9] https://www.nytimes.com/2020/07/20/technology/google-covid-tracker-app.html

[10] Si vous souhaitez voir si StopCovid fonctionne correctement sur votre smartphone quand la localisation est désactivée, vous pouvez installer cette version (https://github.com/ofa-/stopcovid-android) qui affiche une notification dès qu’un appareil avec StopCovid passe à proximité. Si après avoir désactiver la localisation, vous lancer l’application puis passez à proximité d’un autre smartphone avec StopCovid et que rien ne s’affiche, c’est probablement que votre smartphone bloque les scans quand la loc n’est pas activée. Si vous ne faites pas confiance au développeur de ce fork, une alternative consiste à télécharger le code puis à débugger l’application pour voir si le scan fonctionne bien.

[11] https://github.com/opentrace-community/opentrace-android/issues/61

[12] https://policies.google.com/technologies/location-data?hl=fr&fg=1#how-find

[13]  “The information Google collects from Android devices for use in GLS is linked to a temporary and rotating device identifier that is not used by or shared with other services.” https://www.accc.gov.au/system/files/Oracle-Submission-2-%28September-2018%29.pdf.

[14] https://support.google.com/accounts/answer/3467281?hl=fr

[15] https://developer.android.com/reference/android/Manifest.permission

Utiliser P2B pour avoir plus d’informations sur les APIs

Depuis le 12 juillet, le règlement Plateforme-To-Business est entré en application. Ce règlement ambitionne de rendre plus équitables et transparentes les relations entre les plateformes et les entreprises. P2B s’applique entre autres aux magasins d’applications qui permettent d’installer des applications sur smartphones. Dans cet article je m’intéresse plus particulièrement à son impact sur l’app store d’Apple.

Le règlement « promouvant l’équité et la transparence pour les entreprises utilisatrices de services d’intermédiation en ligne » (aka Platform-To-Business ou P2B)[1] a été adopté en juin 2019 et est entré en application il y a quelques jours. Comme son nom l’indique, ce règlement essaie d’établir un peu d’équilibre entre les plateformes (i.e. les services d’intermédiation en lignes et les moteurs de recherche) et les entreprises. Le scope visé par le règlement est relativement large puisque derrière le terme de service d’intermédiation en ligne, on retrouve les plateformes de site hôteliers (par exemple booking, hotels,…), les place de marché de biens (par exemple les marketplaces d’amazon, de la fnac,…) et les magasins d’applications. Le règlement couvre aussi les moteurs de recherches.

Comme le soulignait l’Arcep[2], ce règlement apporte une première pierre vers l’ouverture des terminaux. Néanmoins, il reste limité pour l’essentiel dans l’impact qu’il aura sur ces derniers puisque les APIs sont assez explicitement exclues du champ d’application du règlement… sauf dans le cas où elles sont directement liés à un service d’intermédiation en ligne :

« Les fonctionnalités et interfaces technologiques qui se limitent au raccordement du matériel et des applications ne devraient pas être régies par le présent règlement, étant donné qu’elles ne remplissent pas, en règle générale, les critères pour être considérées comme des services d’intermédiation en ligne. Toutefois, ces fonctionnalités et interfaces peuvent être raccordées directement à certains services d’intermédiation en ligne, ou leur être accessoires, et dans ce cas, les fournisseurs de services d’intermédiation en ligne concernés devraient être soumis aux exigences en matière de transparence liées au traitement différencié sur la base de ces fonctionnalités et interfaces. [mise en gras] »

Or dans le cas d’Apple, la possibilité pour une app d’utiliser certaines APIs se décide directement au niveau de l’App store.

L’App Store comme point de contrôle des APIs

Pour développer une application sur iOS, les développeurs sont restreints dans les APIs qu’ils peuvent utiliser : seules les APIs publiques sont documentées et ouvertes aux développeurs tiers. Il existe des APIs privées qui ne sont utilisables que par les applications d’Apple, celles-ci offrent des fonctionnalités plus avancées aux développeurs d’Apple.

Apple vérifie qu’aucune API privée n’est utilisée au moment où une app est soumise sur l’App Store. Par le passé, certaines apps ont réussi à contourner cette vérification mais ont par la suite été retirées de l’app store[4] pour violation des conditions d’utilisation de l’App Store[5].

La question de l’ouverture de ces APIs est importante puisque certaines peuvent donner un avantage compétitif aux apps d’Apple[3] mais si elles étaient ouvertes à tous, cela pourrait nuire à la sécurité d’iOS et à sa stabilité.

Certaines APIs (privées et publiques) requièrent une autorisation explicite d’Apple (un entitlement) au moment où l’application est soumise sur l’App Store. A défaut d’obtenir un entitlement, iOS ne laissera pas l’application utiliser l’API[6].

Ainsi, on peut considérer que ces APIs raccordées directement à l’App Store puisque c’est ce dernier qui fait office de point de contrôle.

On pourrait alors considérer que le règlement P2B s’applique à l’utilisation des APIs privées ou soumises à entitlements. En particulier, l’article 7 du règlement imposent aux plateformes de décrire les traitements différenciés qu’elles mettent en place :

1.   Les fournisseurs de services d’intermédiation en ligne incluent dans leurs conditions générales une description de tout traitement différencié qu’ils accordent, ou pourraient accorder, en relation avec des biens ou services proposés aux consommateurs par le biais de ces services d’intermédiation en ligne par, d’une part, soit le fournisseur lui-même, soit toute entreprise utilisatrice contrôlée par ce fournisseur et, d’autre part, d’autres entreprises utilisatrices. Cette description mentionne les principales considérations économiques, commerciales ou juridiques à l’origine de ce traitement différencié.

3.   Les descriptions visées […] couvrent notamment, le cas échéant, tout traitement différencié au moyen de mesures spécifiques que prend le fournisseur de services d’intermédiation en ligne ou d’un comportement qu’ils adoptent, en relation avec l’un des éléments suivants:

d)l’accès aux services, fonctionnalités ou interfaces techniques pertinentes pour l’entreprise utilisatrice ou l’utilisateur de site internet d’entreprise et qui sont directement associés à l’utilisation des services d’intermédiation ou des moteurs de recherche en ligne concernés, ou directement accessoires à cette utilisation, les conditions d’utilisation de ces services, fonctionnalités ou interfaces ou toute rémunération directe ou indirecte perçue pour cette utilisation.

Cet article pourrait s’appliquer aux APIs, ainsi si ces APIs servaient à un traitement privilégié, elles pourraient dans certains cas être soumises à plus de transparence. 

Néanmoins, en pratique, cette disposition s’appliquerait dans peu de cas comme nous le verrons ci-dessous.

Le cas UBER

L’application UBER eu le droit à un traitement privilégié : en 2017, il a été découvert qu’Apple avait accordé à UBER un entitlement pour une API privée permettant à l’app de lire le contenu de l’écran[7]. Au passage, cette dérogation exceptionnelle démontre qu’il est possible pour Apple d’offrir sélectivement des privilèges à certaines apps sans pour autant modifier son OS.

Apple n’a pas particulièrement expliqué ce geste et si cela se reproduisait aujourd’hui cela pourrait ressembler à un cas d’école pour la mise en application du règlement P2B, mais étonnamment P2B ne pourrait pas s’appliquer. En effet, P2B ne vise que les traitements différentiés qui bénéficient à l’opérateur de la plateforme (soit le fournisseur lui-même, soit toute entreprise utilisatrice contrôlée par ce fournisseur.) Or Uber n’étant pas contrôlé par Apple ce privilège n’aurait pas à être justifié d’après P2B.

L’enquête Apple Pay

En juin dernier, la direction générale à la concurrence a déclaré ouvrir deux enquêtes visant Apple pour abus de position dominante[8]. L’une d’elle visait le refus d’Apple d’ouvrir la fonctionnalité « tap and go » aux concurrents d’Apple Pay. En effet, seul le service Apple Pay peut bénéficier de cette fonctionnalité et les concurrents se considèrent injustement désavantagés.

Dans ce cas, contrairement au cas précédent, le service mis en avant appartient bien à la société qui déploie le service d’intermédiation en ligne. Pour autant, P2B ne vise que les traitements en relation avec des biens ou services proposés aux consommateurs par le biais de ces services d’intermédiation en ligne, or Apple Pay est un service intégré à iOS et n’est pas accessible depuis l’App Store.

Dans ce contexte; il n’est pas évident que le règlement P2B trouve à s’appliquer.

L’utilisation du Bluetooth en arrière-plan

Les applications de contacts tracing qui ont souhaité s’appuyer sur le bluetooth plutôt que sur la localisation se sont retrouvée limitées sur iOS du fait que les applications peuvent difficilement utiliser le bluetooth lorsqu’elles sont en arrière-plan. Les différents états se sont retrouvés contraints de faire un choix : développer une application qui fonctionnerait moins bien sur iPhone ou utiliser l’API commune à Apple et Google même si elle ne correspondait pas à leur besoin[9] et qui par ailleurs ne fonctionnait qu’avec la dernière version d’iOS (excluant ainsi 10% des utilisateurs d’iPhones[10]).

Pour beaucoup, le refus d’Apple se justifiait par le souhait de protéger la vie privée des utilisateurs, mais rien ne prouve que cet objectif a bien pesé dans le refus d’Apple. D’une part, les applications qui ont essayé de contournées la restriction d’Apple (et qui ont été accepté sur l’App Store) nuisaient à la sécurité des smartphones en incitant les utilisateurs à les laisser déverouillés [11] ou étaient plus intrusives en utilisant la géolocalisation[12]. D’autre part, toutes les documentations officielles d’Apple indiquaient que les restrictions étaient motivées par la volonté de réduire la consommation de ressources (batterie [13]  et mémoire[14]) des iPhones.

Actuellement, il demeure difficile de connaitre la motivation d’Apple puisque la société ne s’est pas exprimée sur le sujet et n’a par conséquent jamais eu a justifié son choix. Or en pratique, les règlement P2B pourraient trouver à s’appliquer.

En effet, Apple permet d’accéder à plusieurs applications pré-installée depuis l’app store. Même si les applications ne sont pas installables depuis l’app store, elles sont néanmoins visibles et entre en concurrence avec les services concurrents proposées par la plateforme[15]. Par ailleurs, certaines de ces applications utilisent le bluetooth même en arrière-plan. C’est notamment le cas de l’application « Find My » qui utilisent le BLE en arrière-plan pour permettre aux iPhones d’être retrouvés [16] . Ainsi Apple pourrait avoir à justifier la restriction d’accès aux fonctionnalités bluetooth en arrière-plan.

Une nécessité de plus de transparence

Le débat sur les applications de contacts tracing démontrent bien l’intérêt de la transparence : justifier les choix architecturaux des OS. En effet, Apple n’a pas eu a justifié du choix de refusé d’ouvrir l’accès aux BLE aux applications de contact tracing. Ce mutisme n’a pas été critiqué puisque la société s’est vue érigée en chevalier blanc protecteurs de la vie privée face aux états. Mais en l’absence d’explication cette posture est questionnable. Si il était avéré que la société avait effectué ce choix juste pour économiser les ressources des iPhones ou même de façon complétement arbitraire, le débat ne serait plus le même.

Image de couverture par Jay Goldman
https://creativecommons.org/licenses/by-nc-sa/2.0/


[1] https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32019R1150&from=EN

[2] « Platform-to-Business » : un premier pas vers les terminaux ouverts dans le règlement européen ! https://www.arcep.fr/larcep/pendant-ce-temps-a-bruxelles.html#c18616

[3] « Apple frees a few private APIs, makes them public » https://www.theregister.com/2017/06/13/apple_inches_toward_openness/

[4] « Apple bans over 250 apps that secretly accessed users’ personal info » https://www.theverge.com/2015/10/19/9567447/apple-banned-apps-youmi-privacy-personal-data

[5] Voir la section 2.1.5  des software requirements https://developer.apple.com/app-store/review/guidelines/#software-requirements

[6] Voir la section 2.3 de ,«iRiS: Vetting Private API Abuse in iOS Applications » par Zhui Deng, Brendan Saltaformaggio, Xiangyu Zhang, Dongyan Xu

[7] « Uber App Has Access to Special iPhone Functions That Can Record Your Screen » https://www.inc.com/business-insider/uber-apple-iphone-features-app-software.html

[8] Ainsi la restriction d’accès à certaines fonctionnalités NFC fait l’objet d’une enquête de la DG-Comp: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_1075

[9] « Why are Google and Apple dictating how European democracies fight coronavirus? » https://www.theguardian.com/commentisfree/2020/jun/16/google-apple-dictating-european-democracies-coronavirus

[10] L’API Apple nécessite iOS 13 alors que StopCovid ne nécessite qu’iOS 11 et TraceTogether iOS 10 https://gs.statcounter.com/ios-version-market-share/mobile-tablet/france

[11] « iOS a ‘major hurdle’ to contact tracing app » https://www.innovationaus.com/ios-a-major-hurdle-to-contact-tracing-app/

[12] https://twitter.com/je5perl/status/1248230776287776769

[13] « Because performing many Bluetooth-related tasks require the active use of an iOS device’s onboard radio—and, in turn, radio usage has an adverse effect on an iOS device’s battery life—try to minimize the amount of work you do in the background. » https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html

[14] « WWDC 2017: Because while your application is running in the background, the system may terminate it if it needs to free up more memory for the foreground application. » (https://asciiwwdc.com/2013/sessions/703 )

[15] « Apple Dominates App Store Search Results, Thwarting Competitors » https://www.wsj.com/articles/apple-dominates-app-store-search-results-thwarting-competitors-11563897221

[16] « Un service de localisation décentralisé et privacy by design entre appareils » https://linc.cnil.fr/fr/un-service-de-localisation-decentralise-et-privacy-design-entre-appareils

A la recherche des annonceurs qui me ciblent

Au mois de novembre, j’ai effectué  une demande de droit d’accès à Google. Après un délai d’un mois, Google m’a indiqué que le traitement de ma requête aller prendre du temps. Deux mois après cette prolongation, Google a répondu à ma requête… en m’indiquant ne pas pouvoir répondre à la plupart de mes demandes.

L’objet de ma demande

Ma demande est disponible ci-dessous, elle vise à obtenir un maximum d’informations concernant la façon dont je suis ciblé via les services de Google. Mon objectif est de comprendre d’une part comment mes données sont monétisées par Google, et surtout de connaître les annonceurs qui utilisent les outils de ciblage offerts par la société. Comme je l’ai détaillé dans ma contribution aux EGNum, je pense que la meilleure solution pour influer sur les plateformes est d’agir sur les annonceurs qui paient pour utiliser ces services publicitaires. Plus que les utilisateurs, ce sont les annonceurs qui in-fine contribuent au chiffre d’affaires des plateformes et ce sont eux qui ont réussi à obtenir le plus de concessions de la part des plateformes. Aussi ma requête devait me permettre de mieux identifier ces acteurs, mais c’est loin d’être une réussite.

Ma demande de droit d’accès

Trois mois pour un pdf de 6 lignes…

En effet, trois mois après ma demande initiale (ce qui correspond au délai maximal autorisé par l’article 12-3 du RGPD), la seule information que j’ai eue est la liste des annonceurs qui m’ont effectivement ciblé avec « Customer Match », c’est à dire ceux qui me ciblent en utilisant mon adresse mail. Cette liste est assez utile, et je vous invite d’ailleurs à faire une demande similaire à la fois pour votre information personnelle, mais aussi pour motiver Google à fournir une meilleure interface d’accès. Facebook offre une bien meilleur interface que Google qui n’offre qu’un PDF qu’il m’aura fallu attendre 3 mois, pourtant Facebook est très critiqué (à juste titre)  pour l’opacité de son système de ciblage alors que Google l’est moins. Cerise sur le gâteau, une jolie mention « Confidentiel, propriété de Google » figure sur le document. Au passage, et sans dévoiler leurs noms, les annonceurs qui me ciblent via Customer Match de Google sont les mêmes que ceux qui me ciblent via Facebook Custom Audience.

Rien sur les « Reminder Ads »

Concernant mes autres demandes, Google botte en touche. Tout d’abord, selon eux, il serait possible de savoir sur cette page quelles sociétés me reciblent (au passage, ils parlent de « reminder ads » c’est à dire de « publicité de rappel » plutôt que de retargeting). Je ne trouve cette information sur la page en question, mais n’hésitez pas à m’indiquer si vous avez plus d’informations concernant votre compte.

Enfin concernant la liste des annonceurs, Google indique ne pas gérer de base de données avec toutes les publicités vues par un utilisateur particulier (“does not maintain a database of every advertisement seen by a specific user. Account holders can visit My Activity to see the websites and apps they’ve visited on which Google ads were shown”). Cela ne signifie pas que Google n’a pas cette information, mais simplement qu’elle n’est pas facilement restituable. En effet, Google garde certainement pour chaque publicité la liste des utilisateurs qui l’ont vue. Pour recomposer la liste des publicités que j’ai vues, Google devrait regarder pour chaque campagne publicitaire si je figure bien dans cette liste. S’il est vrai que c’est sans doute compliqué,  je ne comprends pas l’intérêt d’exploiter pleinement le délai de 3 mois offert par le RGPD pour juste répondre qu’ils ne peuvent pas faire suite à ma demande tout en reconnaissant à demi-mot avoir les données.

Prochaines étapes

Je ne compte pas me satisfaire de cet échec. A moyen terme j’aimerais créer un outil pour collecter la liste des annonceurs qui me ciblent sur Google, comme le fait AdAnalyst pour les publicités de Facebook. En effet, l’extension permet aux utilisateurs de retrouver la liste des annonceurs qui les ciblent via Facebook et de savoir comment ils sont visés. Un tel outil permettrait techniquement de répondre à ma demande.

Ensuite, je vais reformuler des demandes de droits d’accès par étape pour obtenir un maximum d’informations sur les annonceurs. Par exemple, en procédant service par service (Google, Gmail, Youtube) et je pense demander quels sont tous les cookies identifiant qui ont été associés à mon compte, puis la liste des sites visités par ce cookies pour enfin obtenir la liste des publicités qui ont été affichées sur ces sites.

Bien sûr, je suis preneur de toutes suggestions concernant les deux types de solutions.

@vtoubiana

Réponse à ma demande

Image de couverture par Jay Goldman
https://creativecommons.org/licenses/by-nc-sa/2.0/

Qookie Fix: Intro et prochaines étapes

Rendre à César

Comme ce billet est long et que je ne suis pas sûr que vous le lirez dans son ensemble, je commence par remercier Guénaël Pépin pour m’avoir mis l’idée en tête via son tweet. Un grand merci aussi à Nymous sans qui l’extension serait devenue un gouffre de mémoire.

Le RGPD est arrivé

Comme tout le monde, j’ai constaté que les bandeaux cookies recommençaient à pulluler à l’approche de l’été. Ce qui est peut-être moins commun, c’est que j’étais heureux car l’utilisateur semblait enfin pouvoir consentir au dépôt de cookies au lieu d’être mis devant le fait accompli comme il l’a été durant plusieurs années. J’ai rapidement déchanté en découvrant le périple qu’il fallait accomplir pour s’opposer au dépôt de cookies.

Le bandeau auquel j’ai été le plus confronté est celui de Quantcast. Il permet de consentir très facilement. Mais il n’offre pas vraiment de choix car si on souhait s’opposer, les choses se compliquent puisqu’il est souvent nécessaire de décocher les cases une par une. Le pire étant qu’il faut répéter l’opération presque quotidiennement car dès lors qu’on ne consent pas, le bouton réapparaît fréquemment.

Peut-être coupable mais pas responsable

En fait, ce bandeau propose par défaut aux éditeurs de mettre un bouton « je refuse » sur leur bandeau (et d’ailleurs, si vous allez sur le site de Quantcast, vous le verrez apparaître) mais très très peu de sites le proposent. La plupart des éditeurs configurent le module pour que le bouton de refus n’apparaisse pas car, évidemment, ça décourage les utilisateurs qui ne voudraient pas consentir. A noter qu’une autre option permet aux éditeurs de choisir à quelle fréquence le bandeau réapparaît en cas de refus, et par défaut c’est « une fois par jour ».

Paramétrage du bandeau depuis le site de Quantcast

 

Il n’est pas certain qu’un consentement obtenu de cette façon soit valable. Il me semble, par contre, que Quantcast n’est pas attaquable puisque l’outil proposé permet, selon le paramétrage choisi, d’obtenir un consentement valable. Ce sont donc les éditeurs de sites qui le configurent de manière à « forcer » le consentement. Par conséquent, pour régler le problème il faudrait attaquer les sites un par un.

Bien que Quantcast ne soit pas responsable, la société communique sur le taux de consentement qui atteint 90%, au point qu’on en viendrait à se demander quel est l’intérêt d’offrir un choix à l’utilisateur.

Des contournements peu efficaces

Comme il est compliqué de simplement ignorer ces bandeaux, j’ai d’abord cherché à les contourner en utilisant systématiquement le mode « lecture » du navigateur. Malheureusement cette approche n’est pas utilisable sur tous les sites, et elle n’envoie en plus aucun signal aux éditeurs. Or, comme Quantcast met en avant les taux de consentement élevés, il devient important de pouvoir signaler que l’on s’oppose au suivi et d’avoir une influence sur ces chiffres.

Twitter a fini de me convaincre que je n’étais pas le seul à me préoccuper de cette situation et j’ai donc commencé à réfléchir à une extension qui équilibrerait le choix. Ajouter le bouton sur le bandeau était la partie facile, mais il restait à matérialiser le choix des personnes qui clique sur le bouton “s’opposer”.

Une solution simple

Quand une personne consent ou s’oppose via un bandeau Quantcast, son choix est sauvegardé dans un cookie. J’ai voulu répliquer un cookie d’opt-out Quantcast pour matérialiser l’opt-out mais je n’ai pas réussi à créer un cookie d’opt-out générique.

Comme je voulais une solution simple, il m’a fallu explorer une autre piste et, en analysant un peu le code du bandeau, et surtout en allant sur le site de Quantcast, je me suis rendu compte qu’il était simple de faire appel à la fonction d’opt-out. C’est donc ce que fait l’extension, dès qu’elle détecte la présence d’un bandeau Quantcast, l’extension fait apparaître un bouton « Je refuse » et lui associe la fonction d’opt-out prévue par Quantcast. L’extension n’a pas pour objectif de bloquer techniquement les trackers mais simplement d’offrir un vrai choix aux utilisateurs là où les dark patterns tentent de forcer le consentement. Par la même occasion, elle permet d’envoyer un signal aux éditeurs de sites puisqu’il est probable que ceux-ci prêtent attention aux taux de consentement.

Le Framework de l’IAB “Consent & Transparency”

Techniquement, l’extension est donc assez simple. Là où les choses se compliquent, c’est qu’elle est spécifique au bandeau Quantcast et qu’il est compliqué de l’adapter aux autres bandeaux cookies. A minima, il faudrait pouvoir l’adapter à toutes les solutions compatibles avec le framework de l’IAB.

De ce que j’en comprends, tous les bandeaux compatibles avec ce framework utilisent le même cookie de consentement. Les informations contenues dans ces cookies sont codées selon un algo proposé par l’IAB.

A la simple lecture de ces cookies, il n’est pas possible pour un utilisateur de savoir à quelles finalités il a consenti. C‘est problématique puisque la seule solution mise à disposition des utilisateurs lambda pour savoir à quelles finalités ils ont consenti est de retrouver le bandeau. Pour décoder le contenu de ces cookies, il faut réutiliser les scripts proposés par l’IAB (réadaptés ici). Au passage, je salue le fait que ces scripts soient mis à disposition sur Github avec une licence MIT. Une alternative consiste à installer l’extension re:consent de Cliqz qui est aussi disponible sous Firefox et Chrome.

Une fois le cookie décodé, on ne peut lire que des numéros de finalités. Or si l’IAB fournit une nomenclature pour les finalité 1 à 5, certains éditeurs et/ou fournisseurs de bandeaux font référence à des finalités non définies. Le cookie contient la liste des finalité auxquelles l’utilisateur a consenti. Donc pour proposer un opt-out complet : il suffit d’encoder un cookie avec une liste vide de finalités.

Next steps

Pour améliorer l’extension, il faudrait qu’elle soit compatible avec plus de bandeaux. La solution qui me paraît la plus simple pour offrir un opt-out sur tous les sites utilisant le framework de l’IAB est donc d’encoder un cookie avec aucune finalité. Reste la partie un peu plus compliquée qui est celle de la détection de tous les bandeaux compatibles avec le framework IAB. A ma connaissance, il n’y a pas de solution simple, la meilleur solution serait de détecter le cookie après coup ce qui est moins pratique.

La prochaine amélioration apportée consistera à empêcher que le bandeau ne réapparaisse une fois que l’on s’est opposé. N’hésitez pas à contribuer au code ou à donner des idées ici : https://github.com/vtoubiana/QookieFix/issues

In fine, ça restera sans doute une solution temporaire. Les autorités de protection des données vont sans doute clarifier les règles sur ce qui est acceptable et ce qui ne l’est pas, et après Safari et Brave, Firefox va activer une protection anti-tracker par défaut. Compte tenu des récents développements du navigateur de Google,  je ne serais pas étonné que Chrome en face de même.

 

 

 

 

Se mettre en conformité avec la réglementation sur les cookies via les « Content Security Policy »

Ce post explique brièvement comment les « Content Security Policy » peuvent être utilisées pour mettre votre site en conformité.

La réglementation sur les cookies

La réglementation sur les cookies impose aux éditeurs de site web d’obtenir un consentement informé des utilisateurs avant de déposer des cookies sur leurs terminaux. Un site doit donc vérifier qu’un consentement a été préalablement obtenu avant de déposer ses propres cookies et le même traitement s’applique pour toutes les tierces parties présentent sur ce site web. Si il est assez simple pour un site web de vérifier qu’il a obtenu le consentement au moyen d’un cookie, cette tâche s’avéré plus difficile pour les tiers car ils ne peuvent pas accède aux cookies de consentement déposés sur des domaines autres que le leur.
Par conséquent c’est souvent à l’éditeur du site de vérifier qu’il a obtenu le consentement avant d’appeler le contenu des tierces parties. Les outils de gestionnaires de Tag sont une solution élégante pour conditionner le dépôt de cookie à l’obtention du consentement correspondant. Une solution moins fine consiste à détourner le mécanisme des « Content Security Policy » pour empêcher l’appel des contenus tiers tant que le consentement n’a pas été obtenu.

Introduction aux “Content Security Policy”

Une “Content Security Policy” est une politique définit par l’auteur d’une application ou d’une page web et qui informe le client des sources qui seront autorisées à charger du contenu sur le site (“declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources”). Cette politique peut être vue comme une liste de contenus qui peuvent être chargés par le navigateur lors du chargement d’une page. Ces politiques peuvent être déclarées de deux façons: soit via le header HTTP, soit par le champ http-equiv présent dans l’entête HTML d’un document.

Déclaration d’une politique

Pour se mettre en conformité et empêcher que des contenus tiers ne soient déposés avant l’obtention du consentement, un site web peut déclarer une politique qui bloque le contenu provenant de sites tiers. Notez que cette approche n’est pas « cookie-centric » puisqu’elle permet de bloquer tous types de contenus et que par conséquent elle empêche aussi le chargement des services de calcul d’empreinte.
Une solution rapide de “cookie consent” consiste à vérifier au moment du traitement d’une requête si le consentement a été obtenu et d’adapter la CSP en fonction. Si le consentement n’a pas été obtenu la CSP n’autorisera que les ressources provenant de l’éditeur et bloquera les ressources provenant des tiers, si le consentement a été obtenu la CSP usuelle du site sera chargée.
Le plus simple pour un éditeur est d’utiliser une simple balise JavaScript pour insérer un champ http-equiv dans l’entête HTML du document (bien que cela ne soit pas forcément recommandé). Les quelques lignes ci-dessous devraient faire l’affaire:

if ( document.cookie.indexOf('hasConsent') < 0 ) {
 var hostname = window.location.hostname;
 if (hostname.indexOf("www.") ===0) hostname = hostname.substring(5);
 var meta = document.createElement('meta');
 meta.httpEquiv = "content-security-policy";
 meta.content = "script-src 'self' 'unsafe-inline' *." + hostname + "; img-src *." + hostname + "";
 document.getElementsByTagName('head')[0].appendChild(meta);
 }

Une solution légèrement plus compliquée consiste à utiliser le header HTTP. Le code pour accomplir cela est très proche et reste assez semblable mais l’approche est alors plus spécifique au serveur que vous utilisez. Par exemple si vous fonctionnez sur un environnement PHP le code devrait ressembler à cela :

if(!isset($_COOKIE["hasConsent"])) {
 $allowed_hosts = "*.unsearcher.org";
 header("Content-Security-Policy: script-src 'self' 'unsafe-inline' " . $allowed_hosts . "; img-src 'self' " . $allowed_hosts);
 }

Compatibilité

Le standard “Content Security Policy » est en cours de validation mais n’est toujours pas supporté par tous les navigateurs. A l’heure actuelle, Chrome et Safari supportent toutes les fonctionnalités requises, dont le support du tag http-equiv. Firefox supporte les politiques définies dans l’entête http mais ne tiennent pas compte du tag http-equiv. Enfin si Internet Explorer devrait bientôt supporter toutes les fonctionnalitésne actuellement ni l’entête HTTP ni l’entête HTML ne sont supports.

Quelques tests

En utilisant le proxy BURP il est possible de modifier le header HTTP d’un page afin de voir à quoi elle ressemblerait si cette approche était implémentée (c’est-à-dire en bloquant le contenu tiers) :

New York Times

 LeMonde

 

 

Conclusion

Cette solution n’est pas parfaite et présente l’inconvénient majeur de ne pas être supporteé par tous les navigateurs. Cependant elle permet de bloquer assez simplement tous les contenus tiers dans l’attente d’un consentement et est par conséquent complémentaire à la solution proposé sur le site de la CNIL et qui permet d’obtenir le consentement pour Google Analytics (le type de cookie first partie le plus utilisé).

L’impact de la Politique de Confidentialité de Google sur la publicité en ligne

Prés de deux ans après que Google ait annoncé la mise en place de sa nouvelle “Politique de Confidentialité”,  la CNIL sanctionne Google d’une amende de 150.000 euros. Google devra aussi publier un communiqué sur Google.fr pendant 48h. Si le montant peut sembler faible au regard des revenus de Google, il faut savoir que cela est dû au blocage du nouveau règlement européen qui aurait permit d’aller jusqu’à 2% du CA de Google (blocage dont le conseiller Privacy de Google en France  se  frotte les mains).

Dans ce post, je souhaite revenir sur l’impact qu’a eu la politique de Google sur le Web. La mise en œuvre des outils de traçage que cette politique de confidentialité autorise fut assez longue et n’est sans doute pas finie. Je m’intéresse uniquement à ce que cette politique permet en terme de croisement de données sur le Web, c’est à dire que je considère seulement les informations de votre profile Google or cela ne représente qu’une infime partie des données dont Google dispose.

Le croisement d’information avec DoubleClick

DoubleClick, la principale régie publicitaire sur le Web,  appartient à Google depuis 2007. Un récent papier des chercheurs de l’INRIA montre que DoubleClick est présent sur 50% des principaux sites Web. Concrètement Google vous suit, via cette régie publicitaire, sur prés d’1 site sur 2 que vous visitez. Quand Google a annoncée sa nouvelle politique de confidentialité, une phrase dans la politique de confidentialité laissait sous-entendre que Google ne croiserait pas de donner provenant des comptes Google avec les données issues du traçage via DoubleClick (“Le recoupement de données en provenance de cookies DoubleClick avec des données permettant de vous identifier n’est possible qu’avec votre accord explicite.”).

Beaucoup ont compris que Google garderait les donnée provenant de DoubleClick et celles provenant de Google complétement isolées. De fait, les profiles publicitaires construits par Google à cette époque ne semblaient pas provenir de données précises et comportaient souvent des erreurs. Malheureusement cette phrase ne couvre que le croisement de donnée directement  identifiantes et, une fois l’attention retombée, Google a corrigé les données utilisée pour le ciblage publicitaire.

 

Utilisation d’information en provenance du profile Google

En effet, plusieurs mois après l’annonce de sa nouvelle politique, Google a commencé à croiser les données provenant des profile Google avec les données issues du ciblage publicitaire. Ainsi, les publicités affichées par DoubleClick sont non-seulement adaptées aux sites web que vous visitez mais aussi aux données que vous avez indiquées lorsque vous avez créé votre compte Gmail (principalement Age et Sexe). Pour vous en apercevoir il suffit de se rendre sur la page de gestion des pub en étant logué sur votre compte GMail.

Page sur laquelle sont décrits comment vous êtes perçus par les publicitaires

Au début, cette personnalisation avancée ne se faisait que si vous aviez consenti via la page de “personnalisation des +1”  (voire ci-dessous) . Cela n’était pas évident car il était indiqué que vos pubs seraient personnalisées en fonction de vos “+1″ et des autres informations de profile”). Mais depuis quelques mois cela n’est plus le cas, Google se passe de votre autorisation pour croiser ces données.

En effet,  Google considère que votre autorisation n’est pas requise puisque ces données ne sont pas identifiantes. Pire, il n’est plus possible de refuser que Google utilise votre age déclaré dans ses pubs sans s’opposer à toute personnalisation.

Page qui permettait de vous opposer à la personnalisation des pubs en fonction de votre profile

Publicité ciblée en fonction de votre navigation sur d’autres sites

La politique de Google ne les empêche pas non plus d’enregistrer dans votre profile Google, les pages web que vous avez visitées et sur lesquelles étaient présentes des publicités DoubleClick. En pratique, vous verrez sur le moteur de recherche de Google, des publicités basées sur les sites web que vous avez visités. Cette fonctionnalité passe par la création de “Listes de Reciblage pour Publicité sur le moteur de Recherche” (RLSA en anglais) et permet aux annonceurs de vous afficher une pub sur Google Search si vous avez visité leur site.

Techniquement, Google a besoin de bidouiller pour que cela puisse marcher car quand vous visitez un site externe à Google, vous n’envoyez souvent que votre identifiant de cookie DoubleClick . Or vous avez un identifiant attribué par DoubleClick qui est différent de celui attribué par Google. Quand vous vous rendez sur le site de Google, vous montrer un identifiant différent donc Google ne devrait pas pouvoir savoir  quel site vous avez visité.

La bidouille de Google consiste à vous rediriger depuis le domaine doubleclick.net vers le domaine google.com. Du coup, vous présentez à la fois votre identifiant DoubleClick et votre identifiant Google, et Google saura où vous êtes allé  et pourra vous cibler en fonction de vos visites sur d’autres sites. Conclusion

Bien que Google ne soit pas en droit de combiner des informations identifiantes avec des informations obtenues via DoubleClick:

– Ils utilisent des informations provenant de votre compte Google pour vous ciblez en fonction de votre age et sexe sur les sites affiliés à DoubleClick.

– Ils enregistrent vos visites sur les sites affiliés à DoubleClick sur votre compte Google.

En bref, la politique de Google concernant la publicité en ligne se résume à ça:

  • [Ils] ne communiquent pas aux annonceurs les informations permettant d’identifier les utilisateurs.
  • [Ils] n’autorisent pas les annonceurs à diffuser des annonces comportant des informations à caractère sensible, telles que l’origine ethnique, la religion, l’orientation sexuelle, la santé, certaines catégories liées à l’argent, etc.