Privacy by Design - Matthias Dugué

Submitted by mmorandi on 5 September, 2018 - 08:53

Titre : Privacy by Design
Intervenant : Matthias Dugué, Tech Evangelist at alwaysdat
Lieu : Web2day - Nantes
Date : juin 2018
Durée : 28 min
Visualiser la vidéo
Licence de la transcription : Verbatim
Illustration : copie d'écran de la vidéo
NB : transcription réalisée par nos soins.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas forcément celles de l'April.

Description

Surgissant du passé, le concept de Privacy by Design devient populaire auprès des startups qui s’empressent de s’estampiller « Privacy compliant ». Mais protéger les données des utilisateurs, ça signifie quoi concrètement ? Quelles sont les mesures et les concepts nécessaires à la mise en place d’un service réellement Privacy by Design ? Quels sont les conséquences techniques et les pièges à éviter pour ne pas sombrer dans une formule creuse ? Comment l’écosystème Open Source peut-il, par nature, fournir les éléments essentiels à la protection de la vie privée de nos utilisateurs ?

De 1978 à aujourd’hui, voyons comment mettre en place une stratégie Privacy by Design, basée sur des solutions Open Source, réellement efficace.

Transcription

L’idée ça va être de parler de Privacy by Design pendant la demi-heure qui vient, à peu près. L’idée c’est de vous expliquer un peu le concept, pourquoi Privacy by Design, d’où ça vient quels sont les enjeux, techniquement qu’est-ce que ça implique.

Il y a des développeurs dans la salle ? Des concepteurs dans la salle ? OK ! Développeurs, architectes techniques, designers UX, des gens qui arrivent encore ; c’est génial ! Il y a de la place encore devant si vous voulez. OK ! Ça marche !

Qui a déjà entendu parler du concept de Privacy by Design ? OK ? J’ai une vingtaine de mains qui se lèvent dans la salle. Qui a déjà entendu parler du RGPD ou GDPR ? La salle entière lève la main. Qui n’en a jamais entendu parler ? OK ! Visiblement les médias font leur boulot. C’est plutôt une bonne chose.

L’idée c’est que ce règlement européen sur la protection des données personnelles, RGPD, GDPR, tout ça, prône Privacy by Design comme un core concept, concept essentiel à la protection de la donnée personnelle dans nos services et dans notre espace numérique. Le problème c’est que c’est un concept qui n’est pas forcément nouveau, mais c’est un concept qui est quand même assez nébuleux. Ça fait un joli petit bruit, ça fait pong ; c’est donc le moment où je n’ai pas de slide et où je vais tout faire à la voix si ça continue ; ça va être formidable ! J’invoque donc la régie pour faire un petit miracle ; en même temps je continue de vous parler un peu.

Je ne sais pas si vous avez vu le talk en Maxi [Salle Maxi, NdT] qui s’appelait « Homo Deus » [Homo Deus ou le syndrome Peter Pan, NdT] un tout petit peu avant. L’idée qui était présentée dans ce talk, qui était extrêmement intéressante et qui parlait d’intelligence artificielle et des progrès technologiques vers lesquels on se rend à l’heure actuelle, c’est qu’on est dans un environnement où, concrètement, on a une technologie qui avance à toute vitesse, qui va très vite, qui amène plein de nouveautés, mais on n’est pas forcément matures pour réussir à faire face à cette technologie qu’on fait monter et qui est un gain de puissance délirant. Donc il va falloir, à un moment ou à un autre, faire en sorte qu’on fasse un peu attention à ce qu’on fait et notamment attention à la donnée personnelle.

Là, mine de rien, j’essaie de vous amener sur des concepts un peu neufs à savoir qu’un grand pouvoir implique de grandes responsabilités – je pense que je vous apprends rien, celui-là vous l’avez déjà entendu quelque part ; vous en connaissez même la source ; l’idée c’est que les données personnelles des utilisateurs avec lesquelles on va jouer il va falloir en prendre soin. Déjà parce que ce ne sont pas les nôtres, les utilisateurs nous les confient et puis parce que, à terme, il va falloir les exploiter de façon intelligente et éthique.

La privacy aujourd’hui concrètement on en est où ?

Aujourd’hui, en 2018, la data on a beaucoup dit que c’était le pétrole du 21e siècle, que c’était quelque chose d’assez majeur, c’est ça qui nourrit nos algorithmes ; ce qui est important ce n’est pas l’algo, c’est la data, etc. Dans les faits c’est vrai. La data est le cœur essentiel de nos métiers, de nos business. Le problème c’est que ce n’est pas que du pétrole, c’est aussi que c’est une bulle économique délirante parce qu’on se retrouve dans un écosystème où on a des business qui sont financés par des investisseurs qui injectent une quantité de fric massive dans des start-ups, dans des nouvelles technos, dans des nouveaux concepts, etc., en espérant parier sur le bon cheval et qu’à la fin ça rapporte, et le cœur même de ce business, grosso modo, c’est la donnée personnelle qui va être collectée, analysée, monétisée, etc.

Donc on a des grosses boîtes qui pompent de la donnée parce que c’est leur modèle économique, parce que c’est comme ça qu’elles font rentrer du cash derrière et ce sont ces données-là qu’elles monétisent.
On a des petites boîtes qui collectent de la donnée et qui n’ont même conscience qu’elles collectent de la donnée. Je ne sais pas si vous avez déjà monté un PrestaShop1 ; je parle de PrestaShop parce que la majorité des tout petits business qui vendent en ligne généralement c’est le petit truc de base qu’elles utilisent, même si PrestaShop n’est pas si petit, mais si vous utilisez les templates de base de PrestaShop par défaut vous demandez à votre utilisateur, votre client, sa date de naissance, même si c’est pour lui vendre des stickers ; là il y a un problème, vous collectez trop de données, et souvent vous n’avez même pas conscience que vous collectez trop de données.
Vous avez des start-ups qui pompent de la donnée parce qu’elles voudraient faire comme les grands, parce que Facebook le fait donc c’est bien, il faut le faire, il faut faire pareil ! Et on a quantités d’étudiants en école de commerce qui montent des business où ils se disent qu’ils vont pomper de la donnée comme Facebook. Le problème c’est que Facebook aujourd’hui, eux leur modèle c’est de faire de la régie publicitaire donc c’est monétiser de la donnée personnelle de leurs utilisateurs et c’est tout ce qu’ils détestent faire. C’est-à-dire concrètement, dans les études de Facebook aujourd’hui, ils disent explicitement que s’ils pouvaient faire autrement que de la régie pub ils le feraient. Même Facebook n’a pas envie d’être Facebook ! Donc vouloir être comme Facebook, à un moment il y a comme un non-sens.

Donc on en est là. Ça pompe à tout-va, on récupère de la donnée, on récupère de la donnée, on se l’échange, ça circule dans tous les sens, on ne sait même plus où ça va !

Il y a des gens à qui ça parle cette image ? Il y a des gens qui savent ce que c’est ou pas ? Souvent les gens ne savent pas ce que c’est ; c’est cool ! Vous, derrière le streaming, je vous le dis tout de suite, personne n’a levé la main. Cette image c’est le logo de Cambridge Analytica en 2016 pendant la campagne de Trump.

Je vous rappelle le scandale Cambridge Analytica.

Cambridge Analytica est une filiale d’une plus grosse structure qui est un armateur et qui fait notamment de l’arme numérique, entre autres, des dispositifs de surveillance et tout ; l’idée qu’ils se disent c’est qu’ils vont mettre en place un dispositif qui va permettre un, de faire de la prédiction sur les tendances, notamment les tendances géopolitiques, et deux, essayer de faire de la manipulation de masse pour essayer d’orienter les résultats et voir si ça peut fonctionner ou pas. Pour faire ça, ils mettent en place un petit jeu sur Facebook, un quiz comme on en voit plein et comme on est nombreux à jouer dessus, quand on joue sur des quiz. Par ce biais-là ils vont récupérer les données des gens qui installent le jeu et qu’autorise le jeu sur la plateforme, mais ils vont aussi pomper les données des amis de ces gens-là. Et par ce biais-là – au début on a essayé de minimiser un peu l’impact puis petit à petit on s’est rendu compte que ça grossissait, ça grossissait – visiblement ils auraient récupéré la quasi-totalité des contenus ; la quasi-totalité ! C’est ce qu’ont tendance à révéler les dernières enquêtes sur le sujet.
C’est massif ; c’est énorme. Et ça utilise un trou de permission dans Facebook où on dit « à partir du moment où on autorise l’application on peut aussi récupérer les données des comptes amis, etc. »
On a beaucoup blâmé Facebook en disant « oui, il y a un trou dans les systèmes de permission, etc. » Sans doute que Facebook est parfaitement coupable dans l’histoire et que Facebook a sa part de responsabilité, ils ont beaucoup communiqué sur le sujet, certes, le problème c’est qu’à un moment les permissions étaient demandées à l’utilisateur. On a demandé aux gens : « Voulez-vous partager aussi les données de vos amis ? » Les gens ont dit oui ; les gens disent oui ! Parce qu’on a éduqué nos utilisateurs à ne pas lire nos permissions ; on leur a appris que c’était chiant, qu’il ne fallait pas lire ! Si on avait des conditions générales de dingue il fallait signer avec son sang en bas de la feuille et après on s’en foutait ! Donc les gens ne lisent pas. Ils cliquent ! Et le problème aujourd’hui c’est que votre utilisateur et votre utilisatrice s’en foutent de savoir comment ça fonctionne, quelle est la permission, quel est le droit d’utilisation, qu’est-ce qu’on va en faire. Ça ne les concerne pas ; ils s’en tapent !
Ils s’en tapent parce que si vous leur donnez trop de pouvoir eh bien c’est trop compliqué à comprendre ; il y a des pages de permission énormes ; vous êtes déjà allé dans les permissions Facebook ? Vous avez déjà vu à quoi ça ressemble ? Personne n’a vomi ? Sérieusement ! C’est impossible à comprendre ; c’est délirant ! Et tous les systèmes de permission avancée, tout, tout fonctionne comme ça ; c’est dingue ! Donc ça rend les choses trop complexes. Et en plus, ça a un effet pervers, c’est que vous donnez l’impression à votre utilisateur que vous le protégez bien parce que vous lui donnez la possibilité de régler plein de choses, alors qu’en fait ce n’est pas le cas. Peut-être que vous n’allez pas le protéger correctement à un endroit donné et ça, votre utilisateur n’en a pas conscience. Et quand il découvre ça et quand les données sortent, type Cambridge Analytica, tout le monde râle, en même temps tout le monde a cliqué. Parce que ce n’est pas un enjeu public ; les gens s’en foutent en fait. Les gens, il va falloir les protéger d’eux-mêmes parce que les gens ne peuvent pas se protéger tout seuls. Encore une fois, c’est ce qu’on disait juste avant dans ce fameux talk « Homo Deus », on n’est pas matures, donc il va falloir prendre des décisions pour les gens.

En 1999, David Gerrold qui est un auteur de science-fiction américain qui écrivait pour Sm@rt Reseller qui est un magazine de l’informatique de l’époque un article2 qui s’appelait « Future of computing » dans lequel il décrivait un peu le futur de ce qu’il imaginait pour les ordinateurs, etc. 1999 ; il y a 20 ans. Donc il explique qu’il a une télé, il a une radio, il a un PDA [personal digital assistant] – il y en a qui ont connu les PDA ? Il y a des gens qui hochent la tête ; vous aussi vous êtes vieux ! Bienvenus ! – j’ai un téléphone portable dans la poche, voilà, j’ai ce genre de choses, tout ça va fusionner dans un device qui fera à peu près cette taille-là, moins d’un centimètre d’épaisseur, la taille de l’écran sera probablement un peu variable ça dépendra de l’usage qu’on en a, avec une batterie dedans qui sera suffisamment autonome. Bref, il décrit précisément, très précisément ce qu’est le smartphone et il le décrit il y a 20 ans de ça. Et il conclut en disant : I call this device a Personal Information Telecommunication Agent, or Pita for short. The acronym also stand for Pain In The Ass, which it is equally likely to be, because having all that connectivity is going to destroy what's left of everyone's privacy. Et de fait, c’est ce qui s’est passé. Avec le smartphone on a abandonné les derniers petits lambeaux de vie privée qu’on espérait avoir dans nos espaces numériques et on s’est offert corps et âme aux gens qui cultivent notre donnée et qui la monétisent sans même nous rendre un centime. Je vous rappelle que ce que coûterait Facebook à un utilisateur aujourd’hui, c’est 5 euros par mois. C’est-à-dire que pour 5 euros par mois, ils n’auraient pas besoin de la pub pour se financer, de monétiser vos données que vous leur donnez gratos. Vos données !

Donc on en arrive au concept de Privacy by Design.

Privacy by Design ça date de 1995, quasi 25 ans. J’arrondis ; j’aime bien arrondir. En gros d’où ça vient ? C’est l’équivalent de la CNIL en Ontario, au Canada et l’équivalent de la CNIL aux Pays-bas qui se rassemblent, qui publient un rapport avec l’aide d’une faculté des Pays-bas et qui expliquent pourquoi la liberté numérique est importante, pourquoi la protection de la vie privée est importante ; qui érigent un concept Privacy by Design et qui considèrent que c’est de cette manière qu’on va réussir à protéger la vie des utilisateurs. C’est un travail universitaire, c’est assez dense, c’est assez touffu et surtout, ça n’a pas beaucoup d’applications pratiques ; on ne se rend pas trop compte de comment ça peut-être mis en place. La preuve c’est que 15 ans plus tard ça ne sera toujours pas le cas et dans un sommet qui rassemblera l’équivalent des CNIL internationales, donc tous les commissaires internationaux à la protection des données personnelles des individus, ils établiront ensemble que Privacy by Design est le concept essentiel nécessaire pour la protection des utilisateurs. 15 ans plus tard ! Là on en est à 25 et on vient de mettre en application un règlement européen qui dit « il va falloir penser à le faire ». C’est bien, on avance !

Comment ça se décrit ? Ce sont 7 lois qu’on a décrit sous le nom des 7 lois de l’identité que je vous décris rapidement.

En gros c’est :

il va falloir être proactif : vous ne pouvez pas attendre que votre donnée sorte, vous ne pouvez pas attendre qu’il y ait un problème, vous ne pouvez pas attendre qu’il y ait une fuite, vous ne pouvez pas attendre que vous ayez un souci au niveau de vos données ; il va falloir prévoir ça. Donc il va falloir prévoir d’où ça peut sortir, dans quel état ça peut sortir, savoir quelles sont les mesures à prendre. À partir du moment où vous avez de la donnée qui sort, de la donnée qui circule, qu’est-ce qui se passe quand on me pique de la donnée, parce qu’invariablement vos données vont fuiter un jour ou l’autre ; personne n’est à l’abri de ça, il va falloir vous le dire et l’accepter. Donc il va falloir prévoir ça. Il va falloir anticiper ;
il va falloir faire de la vie privée et de la protection des données personnelles le réglage par défaut, c’est-à-dire par défaut vous protégez la donnée. Point barre. Ce n’est pas j’en protège une partie ; c’est je protège l’essentiel de toute la donnée qui m’est confiée parce qu’on vous confie de la donnée ;
c’est inclus dans le design, c’est-à-dire c’est Core by Design, ce n’est pas un plugin en plus de votre système qui rajoute de la privacy ou etc. C’est inclus dans le système ;
c’est full fonctionality. En gros, ce n’est pas parce que vous désactivez certains services que vous perdez l’accès à certains éléments de votre produit. Votre utilisateur si, à un moment, il ne veut pas activer certaines permissions, eh bien ça ne devrait pas le pénaliser ; typiquement ce n’est pas parce qu’il refuse le tracking qu’il ne peut pas accéder au site. Vous avez déjà essayé de faire fonctionner des services avec un bloqueur de scripts tiers ? Je ne dis pas en no-script, juste un bloqueur de scripts tiers sur le Web aujourd’hui, c’est-à-dire des scripts qui ne sont pas servis par le domaine principal ? C’est mon cas ; 80 % du Web n’est pas navigable dans ces cas-là, c’est le bordel ! À un moment ce n’est pas normal et souvent parce que juste vous faites sauter le script des stats ;
il faut que ce soit de la sécurité end to end. Donc on protège de bout en bout, on chiffre de bout en bout, il n’y a pas de donnée qui n’est pas protégée à certains endroits ;
il faut que ça soit transparent pour vos utilisateurs. Il faut qu’ils sachent ce qui se passe s’ils ont besoin d’y accéder, s’ils le veulent ; il faut qu’ils puissent accéder à cette information-là et il faut que ça soit ouvert, documenté, disponible. Ce n’est pas quelque chose qu’on planque quelque part ; c’est librement accessible ;
et surtout, il va falloir faire user-centric, donc il va falloir faire en sorte que ce soit votre utilisateur qui soit au centre de la donnée ; pas votre service, par votre business ; votre utilisateur. C’est ce qui permettra à votre utilisateur d’être satisfait de ce que vous lui fournissez et de rester chez vous. C’est comme ça que vous gagnerez de l’argent puisqu’à la fin le cash c’est quand même le carburant ; on a tous besoin d’argent pour vivre ; je ne suis pas philanthrope à ce point-là !

En pratique comment ça se décline ?

Ça va commencer à la conception. Dès la conception il va falloir que vous conceviez des check-lists qu’il va falloir remplir pour chacune des features que vous donnez sur les jeux de données, sur la façon dont vous les manipulez ;
vous assurer que tous les gens qui vont intervenir sur le projet sont sensibilisés à ça, aussi bien en interne qu’en externe, tous vos prestataires ;
il ne va pas falloir demander plus de permissions que nécessaires, donc il faut concevoir ça avec les utilisateurs. Encore une fois ne faites pas sans vos utilisateurs ;
et bien sûr, il va falloir auditer sur la place de ces check-lists : il va falloir vérifier que ça fonctionne, il va falloir tester, etc.

Donc concrètement côté technique ça veut dire que chaque feature valide votre check-list ; vous la testez et vous le faites de façon automatique. Vous n’insérez pas de facteur humain dans l’histoire parce que plus vous insérez du facteur humain plus vous augmentez les risques. Ça veut dire que vous ne travaillez pas sur le jeu de tests issu de la prod. Vous vous imaginez bosser chez Facebook et bosser sur la prod pour vos tests ? Bon ! Je pense que tout est dit.

Vous oubliez des fragments de permission tout prêts, typiquement quand vous encapsulez de la Webapp sous forme d’app métier avec du Cordova, etc.
N’utilisez pas les frameworks de permission parce que ça vous demande l’intégralité des permissions de votre téléphone pour juste afficher une page web. Donc à un moment il va falloir faire finement : vous demandez les permissions explicites de ce dont vous avez besoin ; pas plus ! Idéalement vous ne demandez pas de permission sauf quand c’est vraiment nécessaire.

Et vous faites des tests fonctionnels sur des environnements multiples. Vous testez des scénarios. Vous vérifiez que ça respecte bien tout ce dont vous avez besoin et tout ce que vous avez validé en check-list.

À l’exécution ça veut dire quoi ?

Ça veut dire que vous ne collectez pas plus de données que nécessaires. Évidemment.
Vous minimisez tout ce qui est échangé avec les prestataires, les services tiers, les services sur lesquels vous vous appuyez. Ce n’est pas la peine de leur passer les infos dont ils n’ont pas besoin parce que ce sont des infos qui, de nouveau, se retrouvent dans la nature et que vous ne contrôlez plus et le contrôle restera important.

Il faut que pseudonimisiez la donnée. Tout le monde est à l’aise avec le concept de pseudonymisation ou pas ? Qui ne voit pas du tout ce que c’est ? OK ! La pseudonymisation ça consiste à dire que vous substituez dans vos jeux de données tout ce qui, potentiellement, permet d’identifier l’utilisateur. Je vous rappelle que ce qui caractérise une donnée personnelle c’est le fait que cette donnée puisse être rattachée précisément à un individu : une date de naissance, un nom, une adresse IP, un poids, une taille, une couleur d’yeux. À partir du moment où ça caractérise un individu c’est de la donnée à titre personnel. Donc quand vous pseudonymisez vous faites en sorte qu’on ne puisse plus relier la donnée à la personne à laquelle elle appartient. Donc vous masquez des choses, vous cachez des IP, vous les remplacez, etc.

Vous vérifiez tous vos formulaires : tout ce que vous demandez aux utilisateurs, tout ce que les gens doivent saisir vous vérifiez bien qu’il n’y a rien de sur-nécessaire, disons ça. Et vous supprimez régulièrement tout ce qui est collecté. Vous ne gardez pas les choses si ce n’est pas nécessaire.

Donc techniquement vous utilisez des services de gestion d’authentification déportée, typiquement de l’OpenID, et vous arrêtez de gérer l’identification et l’authentification en interne ne serait-ce que parce que quand on fait soi-même généralement c’est une ligne Maginot qu’on monte, donc on va essayer de faire des trucs un peu plus solides.

Vous hachez, vous chiffrez, vous tokenisez les données. Si vous ne faites pas de crypto, intéressez-vous à la crypto ça va être nécessaire, vous en avez besoin. Et si vous le faites déjà c’est bien.

Vous pensez à permuter, à substituer les jeux de données, encore une fois c’est de la pseudonymisation et surtout vous segmentez vos données. Vous utilisez des outils respectueux de ça, des outils statistiques type Matomo qui est l’ancien Piwik. C’est-à-dire vous ne travaillez pas sur des jeux de données précis mais sur des ensembles de données, sur des groupes de données, des segments d’utilisateurs, des segments qui correspondent à un ensemble donné de vos utilisateurs. Et c’est là-dessus que vous travaillez. Vous vous en foutez d’aller vérifier qui fait quoi précisément. Ce sont des tendances que vous voulez sortir.

Et puis faites passer des cron3 ; supprimez ce qui n’est pas utile. Quand vous avez fini de traiter de la donnée, elle dégage, vous ne la gardez pas, de toutes façons vous n’avez plus le droit.

Au niveau de votre utilisateur, de votre utilisatrice. À quoi ça correspond ?

Ça veut dire que vous lui fournissez des réglages simples, des choses qui soient faciles à comprendre. Vous ne lui demandez son consentement qu’à partir du moment où vous en avez explicitement besoin. Ce n’est pas la peine de le polluer avec des réglages qui ne sont pas nécessaires et qu’il ne va pas comprendre ou qu’elle ne va pas saisir, mais, quand vous lui demandez quelque chose, vous lui expliquez bien à quoi ça sert et vous lui permettez d’agir directement dessus.
Vous ne passez pas par des services externes si ce n’est pas nécessaire, donc on arrête les logins exclusivement via Facebook et compagnie. Vous ne partagez pas sur les réseaux sociaux par défaut ; c’est de l’opt-in et pas de l’opt-out.
Et surtout, vous séparez les consentements, ce que j’appelle share data versus analytics data, c’est-à-dire que ce n’est pas parce que votre utilisateur a choisi de ne pas vous donner de traces d’usage et de ne pas vous faire remonter de statistiques qu’il n’a plus le droit d’accès à votre service. Ce sont deux consentements, ce sont vraiment deux choses séparées.

Techniquement ça veut dire qu’il va falloir faire de la confidentialité différentielle sur vos bases de données. C’est un concept encore une fois universitaire, encore une fois un peu nébuleux. L’idée c’est que vous faites passer des outils sur vos bases de données qui vont vous permettre de travailler sur vos jeux de données sans compromettre la vie privée de vos utilisateurs.

Il y a deux travaux essentiels qui sont les plus aboutis aujourd’hui là-dessus ce sont les travaux de l’université de Cornell et un outil qui est développé par Uber qui s’appelle SQL Differential Privacy. Je vous invite à aller voir comment ça fonctionne. L’idée ça va vraiment être de faire en sorte que vous puissiez travailler sur des jeux de données qui sont neutres et que ce soit intégré directement à vos bases de données, parce que si vous voulez faire vous-même, vous allez vous arracher les yeux.

Encore une fois vous passez par des outils d’identité décentralisés, donc pas de login via Facebook, via Twitter, etc., on arrête avec ces conneries-là. Pas de jsSocials ou des scripts de partage sur les réseaux sociaux qui vont juste pomper des scripts à droit à gauche pour pouvoir les injecter dans vos pages et qui du coup, au passage, vont leaker plein de choses vers l’extérieur ; toujours très élégant.

Et puis, encore une fois, des outils aux traces d’usages respectueux. Si vous avez besoin de collecter de la trace d’usage eh bien vous le faites via des outils d’analytique que vous auto-hébergez, typiquement du Matomo autohébergé ou des choses comme ça ; ce sont des outils qui sont très efficaces pour le faire et largement suffisants. Vous n’avez pas besoin de recentraliser ça chez un Google Analytics, par exemple, qui va encore vous pomper des choses.

En fin de vie, parce que les services naissent, les services meurent, vous savez ce que c’est le cycle de la vie, tout ça, rappelez régulièrement aux utilisatrices leur confidentialité ; rappelez régulièrement aux utilisateurs qu’ils disposent d’un droit d’accès sur leurs données, qu’ils peuvent les récupérer. Ça veut dire que vous facilitez l’export des données dans des bons formats, dans des données que vous pouvez récupérer et que vous leur permettez d’avoir et de transférer ailleurs. Ça veut dire que vous supprimez les données quand un compte est fermé et que vous supprimez tout quand votre service ferme. Vous ne gardez rien, évidemment. À un moment, c’est un droit d’utilisation que vous avez ce n’est pas un droit de propriété.

Donc vous utilisez des frameworks de notification typiquement pour informer régulièrement votre utilisateur. Vous lui lancez des notifs en lui disant « tiens il y a telle permission qui vient d’arriver tu veux l’activer ou pas ? Il y a déjà un bouton qui permet de l’activer dedans. » Ça c’est bien.

Il y a des comptes sur Twitter qui recensent les bonnes pratiques niveau GDPR qui commencent à arriver, qui commencent à se mettre de plus en plus en place ; on voit des choses dégueulasses et on voit des choses qui sont vraiment très bien faites. Il faut vraiment ne pas hésiter à s’inspirer de ces travaux-là.

Mettez en place des API qui sont documentées ; vous exportez vers des formats ouverts et quand je dis ouverts c’est de l’open source, à un moment c’est simple à utiliser, à ré-exploiter. Vous avez déjà essayé de récupérer vos archives Facebook ? Il y a des gens qui ont déjà essayé ? C’est dégueulasse. Ce n’est que du fichier texte à plat ; il faut faire des parsers4 maison pour essayer de tirer parti de ce truc-là. Après ils vont vous dire mais c’est bon vous avez tout ? De fait, ils ont raison, on a tout ; ce n’est pas exploitable, mais on a tout !

Et puis à la fin quand c’est fini, c’est fini ! Vous fermez quoi et vous ne gardez rien.

Ça c’est Privacy by Design. C’est bien. Ce n’est pas suffisant.

Ce n’est pas suffisant parce que Privacy by Design encore une fois c’est 1995 et depuis 1995 je ne sais pour vous, mais moi mon usage du Web a changé. J’étais petit je suis devenu grand, j’ai fait d’autres choses, on collabore plus, on échange plus, on fait beaucoup moins gaffe à ce qu’on donne. Donc il y a un moment où il va falloir aller plus loin.

Fabrice Rochelandet qui est un chercheur qui travaille sur les questions d’éthique liée au numérique et à la vie privée explique que le concept de Privacy by Design est totalement aux antipodes de la souveraineté numérique des individus parce qu’on fait sans les individus ; on protège la privacy et on ne définit pas ce que c’est. Donc oui c’est nécessaire, c’est important. Oui c’est bien, non ce n’est pas suffisant ; il va falloir aller au-delà de ça.

Typiquement OWASP — tout le monde ce que c’est qu’OWASP ? Ouais ça va ? OK ! OWASP5 publie une liste qui s’appelle le Top 10 Privacy Risks et c’est la check-list de référence à partir du moment où vous souhaitez produire du contenu et des services qui soient respectueux de la donnée personnelle des individus. Ça veut dire que si déjà vous vous souciez de ces facteurs-là qui sont des facteurs de risques potentiels pour la donnée personnelle et que vous êtes capable de circonvenir à ça et de faire en sorte que ça ne se produise pas, vous êtes déjà dans la bonne direction et vous faites déjà un bon travail. Il va falloir que vous testiez aussi toutes vos fonctionnalités ne serait-ce que par rapport à ça. Intégrez ça dans votre processus de réflexion et de conception et vous serez déjà dans le bon axe.

Ça veut dire que concrètement ce que vous tracez c’est le parcours de la donnée ; ce ne sont pas les utilisateurs. On s’en fout de savoir qui a fait quoi à quel moment, etc. En revanche, vous avez besoin de savoir par où est passée la donnée, comment elle a été transformée, comment elle a été manipulée et où est-ce qu’elle est stockée après.

Ce sont des concepts de traçabilité. Ce sont des trucs qu’on a déjà dans tout ce qui est lié à l’alimentation depuis des années. Pourquoi on ne l’appliquerait aussi à la donnée personnelle ? C’est tout aussi important. Donc il faut tracer, il faut de la traçabilité dans vos données ; c’est de ça dont vous devez vous soucier, de ça et de la gestion des identités de vos individus.
Il va falloir faire en sorte que les gens aient un contrôle précis, fin sur leurs identités et que ça soit des choses séparées. J’ai une identité publique, j’ai une identité privée, j’ai une identité numérique ; si je choisis de ne pas rassembler les trois et de les segmenter, j’en ai le droit. On ne doit pas pouvoir me retrouver physiquement dans la vie publique si j’ai choisi que ma vie numérique était un alter ego distinct de ma présence physique. Et c’est à vous de veiller à ça ; ce n’est pas à vos utilisateurs. C’est à vous de leur fournir par défaut les réglages nécessaires.

Parce qu’il va falloir dépasser Privacy by Design, il va falloir aller au-delà de ça. Typiquement il va falloir penser la data comme un vivant périssable ; je parlais d’alimentation, c’est exactement vers ça que ça tend. Il va falloir penser que la donnée elle vieillit, elle rouille, elle pourrit et qu’à un moment il va falloir agir là-dessus ; il va falloir avoir un cycle de recyclage de la donnée.

Ça veut dire que chacun se doit de prévenir et d’alerter ; vous, développeurs, concepteurs, au sein d’une équipe, vous avez le devoir, le droit et la responsabilité de dire à un moment « non, ce qu’on fait là ce n’est pas éthique ; ça ne fonctionne pas et on n’a pas le droit de faire ça. » Ça veut dire qu’il va falloir mesurer chaque chose et les impacts de chaque petit élément ; ne pas penser au global mais penser précisément et s’assurer que tout ce que vous faites, à n’importe quel moment c’est réversible, c’est portable, on peut l’emmener ailleurs.

Donc on en arrive à des concepts de Privacy by default et pas by Design.

On va penser la donnée de façon à ce qu’on minimise au maximum les données collectées pour protéger la vie privée ; on va simplifier comme ça les choses pour les utilisateurs, on va faire en sorte qu’il n’y ait plus de difficultés à régler les permissions, les settings, etc., que tout ça soit mis de côté et, idéalement, ça sera le niveau de protection maximale par défaut.
Si par défaut vous arrivez à fournir un service en ayant un niveau de protection maximale, eh bien super ! Votre utilisateur pourra réduire après le niveau de protection, il sera libre de le faire, il n’y aura pas de souci là-dessus et votre service, en plus, continuera de fonctionner parce qu’il fonctionne déjà au niveau maximum. Donc il faut protéger au maximum.

Ou alors, ou plutôt et ensuite, il va falloir aller vers le Privacy by Using, c’est-à-dire qu’il va falloir éduquer les gens et on ne pourra les éduquer qu’à partir du moment où on aura réussi à les mettre dans ce processus-là parce qu’on va les guider, on va continuer à lancer des alertes, on va leur montrer que ce qu’on fait c’est respectueux d’eux, parce qu’on est respectueux de leurs données personnelles. On va chacun agir à notre niveau et, encore une fois, on fera de la privacy différentielle.

Je conclurais juste avec ça qui est une citation qui dit que « nul ne sera l’objet d’immixtion arbitraire dans sa vie privée, sa famille, son domicile ou sa correspondance, ni d’atteinte à son honneur et à sa réputation. Toute personne a droit à la protection de la loi contre de telles immixtions ou de telles atteintes. » Il s’agit de la déclaration universelle des droits de l’homme, article 12 ; c’est toujours en vigueur aujourd’hui !

Je m’appelle M4DZ.

[Applaudissements]