Le SDK comme illustration de la standardisation du numérique

Fin d’année 2018, se tient le C3 - Chaos Communication Congress - à Leipzig (35ème édition de l'événement). L’association Privacy International fait une présentation intitulée « How Apps on Android Share Data with Facebook » (Comment les applications sur Android partagent leurs données avec Facebook) en rajoutant le sous-titre : « même si vous n’avez pas de compte ». En février 2019, une étude du Wall Street Journal (notamment repris par le Defensive Lab Agency) se penche également sur le sujet : onze applications de santé (contrôle du pouls, suivi du cycle menstruel, etc.) sont analysées et indiquent la même chose, que les données sont « envoyées à Facebook sans qu’on y soit connectée ou sans même qu’on y ait un profil ».

Un point est particulièrement intéressant à souligner ici, et s’inscrit dans la ligne de ce qui a été rédigé dans notre 6ème Cahier IP « La forme des choix » : la question de la standardisation par les usages. Le principal problème mis en avant par ces deux études est bien celui de l’outil utilisé pour créer ces applications : le kit de développement logiciel (ou SDK).

Des SDK pointés du doigt

Ce SDK (pour Software Development Kit) est une sorte de canevas d’outils de création de logiciels et d’applications pour les systèmes d’exploitation de votre smartphone (iOs, Android, Windows, etc.).
Pourquoi le SDK de Facebook est-il pointé du doigt ici ? Pour des raisons qui ne sont pas tellement nouvelles, à savoir des interrogations autour de transfert de données vers Facebook, via une application ou une navigation. En mai 2017, Facebook avait reçu une sanction de 150 000€ de la CNIL, après une première mise en demeure en janvier 2016. La sanction s’appuyait sur deux observations :

• Combinaison massive de données personnelles pour ciblage publicitaire
• Tracking des internautes, via le cookie datr.

Les récentes études (Privacy International, Wall Street Journal) sont intéressantes car les données ne sont plus ici collectées directement par le réseau social, ni par l’utilisation de traqueurs lors de la navigation, mais par l’utilisation d’applications smartphone développées à partir d’un SDK fourni par celui-là. Le cœur de la critique réside ainsi dans le fait que l’utilisateur ignore que son application de santé est conçue dans un canevas Facebook, et qu’il est exposé à l’envoi de ses données à un outil affilié au réseau social de Mark Zuckerberg.

Si les données sont envoyées, elles le sont dans le cadre d’utilisation d’un outil analytics (mesure d’audience) : c’est donc l’éditeur qui choisit ce qu’il envoie. Il peut ainsi faire ses propres graphes et  indicateurs (qui sont ses utilisateurs, quels sont leurs usages, etc.), de la publicité ciblée (si c’est son modèle) ou  affiner son produit et/ou service proposé dans l’application. Dans sa communication, Facebook dit n’en faire rien de plus que ce qui est contracté avec l’éditeur : la mise à disposition de l’outil d’analytics, et potentiellement la publicité ciblée (voir l’article du WSJ).  

L’identifiant publicitaire

Les deux études pointent également la présence d’un identifiant qui est propre à l’utilisateur du smartphone : l’identifiant publicitaire. Et ceci n’est pas nouveau non plus : Le LINC l'évoquait déjà en novembre 2014 dans les conclusions du projet Mobilitics, réalisé en partenariat avec l’Inria (Voir la Lettre IP sur cette question ici et l’encart ci-dessous).

Malheureusement ceux-ci ne sont ni simples à trouver, ni faciles à comprendre :  sur les iPhones, il faut se rendre dans les réglages de confidentialité, accéder à l’option « publicité » et activer le suivi publicitaire limité ; sur  Android,  alors  que  l’on  pourrait s’attendre  à  pouvoir  accéder  à  ce  paramètre dans les réglages du téléphone, il faut en réalité se rendre dans l’application « Paramètres Google » et activer une option « désactiver annonces par centres d’intérêt ».

Dans son étude, Privacy International veut s’assurer que Facebook ne stocke pas d’informations émanant de l’application et liées à l’identifiant publicitaire : « Le 29 octobre 2018, un membre de l’équipe a soumis une requête via un formulaire en ligne que propose Facebook pour les individus non-inscrits sur sa plateforme, et a demandé l’accès à toutes ses données relatives à l’identifiant Google qui avait été utilisé dans notre recherche […] » (p. 17).
Facebook leur a donc répondu qu’ils n’avaient aucune trace de cet identifiant, mise à part « cette demande précise ». Privacy International a fait également une actualisation de l’étude début mars, dans laquelle elle fait le point sur les applications qui avaient été étudiées en décembre dernier, mais ne revient pas sur ce point précis. Le profilage était au cœur de la mise en demeure (qui a été levée depuis) par la CNIL de l’entreprise Vectaury en février 2019.

Blackbox, cargo cult, « by design » et centralisation

Il est intéressant ici de noter la diffusion du canevas Facebook, qui est utilisé par des centaines d’applications, et potentiellement par des millions d’individus. Le choix d’utiliser ce cadre de création pour son application peut s’expliquer, à l’instar de l’utilisation d’un Wordpress ou de tout autre outil de gestion de contenu, par une accessibilité et une facilité à structurer et configurer.

Si l’on étend la réflexion sur le sujet, c’est bien une uniformisation des outils qui est questionnée ici. L’existence de standards d’usage, ou standards de fait soulève des interrogations autour du choix des futurs modèles, qu’ils soient technologiques ou de design. Les modèles utilisés sont le plus souvent ceux des géants du numérique, qui ont la puissance de feu pour les diffuser partout, et potentiellement d’en faire le seul modèle d’usage. Le cahier IP6 fournit deux bonnes illustrations de ceci, le premier dans le cadre d’un format, le second sur les interfaces :

Le cas du format kml (utilisé pour la géolocalisation) créé par Keyhole Inc., rachetée par Google en 2004, est à ce titre exemplaire tant il est devenu la norme. Le KML est désormais le format le plus utilisé par l’ensemble des outils ayant recours à la géolocalisation. Le Material Design de Google entre quant à lui dans une stratégie d’influence B2B. Sur une plateforme dédiée, et sur la base de travaux menés en grande partie en interne, l’entreprise prodigue conseils et astuces pour « soutenir des innovateurs dans [leur] domaine ». Ce projet, lancé en 2014, propose ainsi de fusionner au sein d’une charte graphique et ergonomique « les principes classiques du bon design avec les innovations de la technologie et de la science ». Il s’agit, en mettant à disposition différents outils tels que des systèmes d’icônes, ou des palettes de couleurs, de permettre le développement, selon Google, d’un « système de base unique qui harmonise les expériences utilisateur entre les plateformes et dispositifs ».

Ceci n’est pas une problématique nouvelle, on la retrouve notamment dans les librairies de codes : les développeurs évoquent la question du « cargo cult programming », cette tendance à utiliser ou à intégrer des morceaux de codes déjà existants dans la construction d’un logiciel, alors qu’une partie est totalement inutile (au mieux). Il peut y avoir plusieurs explications à ce phénomène, en particulier le fait d’éviter de redévelopper une fonction déjà existante (on évite ainsi de réécrire du code) - cela permet également à des développeurs moins aguerris de pouvoir créer des programmes ou applications facilement.

C’est donc bien la notion de « protection de la vie privée dès la conception » de l’article 25 du RGPD (privacy by design) qui est soulevée ici : que ce soit le SDK ou les librairies de code, ce sont les outils et l’assemblage de ces outils qui sont préférés à la création d’un outil adapté spécifiquement aux besoins (même si bien plus facile à dire qu'à faire).

Plusieurs exemples récents dans l’actualité montrent ces problématiques des positions dominantes dans le numérique : que ce soit le choix de Microsoft de ne pas intégrer Firefox dans ses modèles de navigateurs compatibles avec certains de ses produits, la bataille entre Spotify et Apple ou encore la prochaine amende prévue par Margrethe Vestager contre Google. La demande de la Sénatrice américaine Elizabeth Warren de démanteler les GAFA rentre également dans cette logique.

Quel rôle pour les institutions ?

Dans notre Cahier IP6, la question est posée à l’échelle de la relation homme-machine au niveau des interfaces numériques, et donnait des pistes pour l’accompagnement des acteurs : « [les travaux de recherche autour du design] doivent dorénavant alimenter très directement des outils de régulation et de politiques publiques. Une occasion pour les régulateurs d’intégrer davantage la réflexion sur le privacy by design et le privacy by default sans pour autant étendre excessivement ses actions ».

Par ailleurs, le RGPD permet de redistribuer le jeu des données, entre l’individu (qui disposait déjà de son droit d’accès, de rectification, etc.) et les institutions ou entreprises, notamment à travers la portabilité. Il pourrait dès lors faire office de levier dans une optique de meilleure répartition des cartes sur le web, à travers une meilleure maîtrise des données personnelles (par l’individu comme par les prestataires d’outils ou de services).

Dans son ouvrage « La Norme sans la Force », Zaki Laïdi étudie la capacité de soft power des projets normatifs politiques, portée à l’échelle européenne (versus un hard power étasunien). Le RGPD et ses finalités pourraient agir ainsi comme base pour la création de standards (norme régulatrice) plus éthiques dans ces échanges de données… L’adéquation du Japon au RGPD et l’adoption du LGPD au Brésil semblent montrer une dynamique qui va dans ce sens.