L’illusion de la publication de données anonymes

Le gouvernement anglais propose des extractions des données des élèves. On peut même en voir des exemples. Évidemment, ces données sont dites anonymisées. Et chacun se rassurera, une fois les identifiants des enfants éliminés des données, il ne s’agit plus de données personnelles, et rien d’affreux n’a été divulgué.

C’est une erreur.

L’opération d’anonymisation la plus courante (1) consiste à ne pas fournir les champs des bases de données qui contiennent les identifiants des individus. Selon la base, il pourra s’agir des noms et adresses, des numéros d’immatriculation à différents services, des adresses mails voire pour les plus scrupuleux, des pseudos adoptés sur le net (2).

Une fois publiée (largement ou selon un business plan spécifique), la base ainsi obtenue s’ajoute au vaste ensemble des bases disponibles sur les personnes. Le problème n’apparaît qu’à ce moment-là. Tant qu’on la considère seule, elle est effectivement anonyme. Il en va tout autrement si on la considère dans l’ensemble : le croisement de deux bases permet de ré-identifier les informations. Le schéma est le suivant. Considérons deux bases d’informations : l’une contient des données sensibles mais est anonymisée (on ne peut pas identifier les individus) – BAnon. L’autre ne contient pas de données sensibles et contient l’identification – BIdent. Si ces deux bases contiennent des informations communes, celles-ci peuvent servir de clef de jointure entre les bases. Une clef de jointure est un dispositif épatant qui sert à établir une relation (3) entre les
informations de BAnon et celles de BIdent. Cette relation peut être de 3 types, en fonction des éléments de jointure, et, pour une jointure donnée, en fonction des individus :

• a – Les informations d’une personne de BAnon correspondent aux informations d’une seule personne de BIdent : pour ces personnes BAnon+BIdent n’est plus anonyme du tout; la ré-identification est stricte ;
• b – Les informations d’une personne de BAnon correspondent à n (supérieur à 2) informations de personnes dans BIdent. La réidentification est incomplète; il y a ambiguïté ;
• c – Les informations d’une personne de BAnon ne correspondent à aucune information de personnes dans BIdent. La ré-identification a complètement échoué.

Le nombre de cas où la ré-identification est stricte donne la pertinence du croisement effectué dans un cas de recherche de masse. Il peut être très faible et pourtant très pertinent si il s’agit au contraire d’une recherche ciblée.

Le cas b est le plus intéressant, et le plus fréquent aussi. On sent bien (ça se démontre mathématiquement) que le caractère important est le facteur discriminant des éléments de la clef de jointure, d’un point de vue statistique (exploitabilité de la ré-identification en masse) et d’un point de vue individuel (ré-identification d’une personne particulière).

Par exemple, la clef de jointure « latéralisation » donne une répartition en seulement 3 catégories. Elle ne réduit que d’un facteur 3 l’ambiguïté statistique de la ré-identification. En revanche, la répartition dans les 3 catégories n’est pas équiprobable : pour les ambidextres reconnus, la latéralisation peut être une clef pertinente.

Les recherches portent donc sur les ensembles d’éléments d’information qui forment de bonnes clefs de jointure, en fonction des buts poursuivis.

Voici un exemple classique (désormais) de la ré-identification. La connaissance des 3 informations « jour de naissance », « sexe » et « zipcode » permet de ré-identifier correctement 87% de la population US (4). Ce chiffre serait probablement plus élevé en France avec le code postal qui réduit considérablement l’ambiguïté grâce au grand nombre de communes. Nous fournissons assez facilement ces informations qui ne semblent pas sensibles, sans savoir qu’alors, elles permettent de ré-identifier des bases anonymisées et d’accéder à des données sensibles.

Le principe est générique : il s’applique aux données privées des personnes, mais aussi aux données sensibles des entreprises. Les moyens informatiques permettent aujourd’hui de croiser plusieurs bases, augmentant la possibilité de trouver de bonnes clefs de jointures.

La conséquence est claire : la sensibilité d’une donnée ne dépend pas que d’elle-même ; elle dépend aussi (surtout) des informations qu’elle permet de retrouver, ainsi que des informations qu’elle permettra de retrouver dès lors qu’une nouvelle base sera rendue accessible. Il est donc bien difficile d’être en phase avec les lénifiants discours sur l’innocuité d’une fuite d’informations parce qu’elle ne contient que des données « non sensibles ».

 

1 – Il existe une autre technique d’anonymisation : l’agrégat statistique. Il s’agit non plus de publier les données brutes mais de n’en fournir que des versions statistiques. Le demandeur décrit les agrégats dont il a besoin, le responsable des données calcule les agrégats et lui fournit. Les informations individuelles ne sont plus anonymisées, elles sont complètement diluées dans le calcul. L’information est moins riche, mais permet malgré tout d’atteindre la majorité buts avouables recherchés.

2 – Ces opérations sont issues des travaux de construction des données de test des systèmes informatiques. Pour fabriquer un jeu de test représentatif sans avoir à le concevoir, le plus simple est de copier la base de production contenant les données réelles. Mais dans cette manœuvre, des personnels non habilités pourraient accéder à des données sensibles. On élimine donc les données sensibles, délicatement pour ne pas trop réduire le critère de représentativité.

3 – Ce mécanisme a été inventé très exactement pour cela dans les systèmes de bases de données dites relationnelles.

4 – http://latanyasweeney.org/work/identifiability.html

Syndrome Solution

En informatique désormais, on ne fabrique plus ni des applications ni des logiciels, on fabrique des solutions. Et on les vend. Il ne s’agit pas de nouveaux systèmes, non, ce sont les mêmes qu’avant, c’est habile.

Cela dit, un logiciel sert à résoudre des problèmes i.e. des questions soulevées ; il faut donc bien s’y intéresser, à ces questions : c’est la partie difficile. De deux choses l’une. Soit on s’attelle au problème et on y réfléchit. Mais c’est long, coûteux et sans garanties (parfois on n’y arrive même pas, c’est embêtant). Soit on le nomme ; c’est épatant comme le simple fait de nommer un problème donne l’impression de l’avoir résolu. Grisé par cette illusion qui emporte sur des nuages de rhétorique surplombant des abîmes d’incompréhension, il semble alors facile de passer à la solution. D’autant que la solution, d’autres la possèdent, précisément.

– La solution à quel problème, au fait ?

– Mais voyons, peu importe puisqu’on a la solution, vous dis-je. Vous voulez du Céhereme? Tiens, j’en ai une boite juste derrière moi sur l’étagère, là, vous voyez bien. Un Ehesbé ? Le gros carton devant vous. Un Bépéhem ? Vous le voulez quand ? Il faut que je réserve un container, mais pas de soucis, on s’occupe de toute la livraison.

– Votre Ehesbé, il est facile à prendre en main ?

– Un jeu d’enfants, mon bon monsieur, un jeu d’enfants. De plusieurs enfants, certes, mais enfin, c’est un gros carton. Trois semaines pour l’installer en trois clics, à peine six mois pour vous faire la main, tellement tout est intuitif et ordonné, adapté et adaptable, standard et générique, pointu et facile à comprendre. Comptez éventuellement quelques semaines obligatoires de formations par nos soins (forfaits individuels), et hop, vous voilà fins prêts pour passer en production.

–  Et ce sera adapté à mon prob… Pardon, à mon contexte ?

– Oui, moyennant quelques mois supplémentaires et sous réserve que vous sachiez très exactement ce que vous voulez faire, que ça corresponde exactement au contenu théorique du gros carton, et que le packaging ait été bien fait. On a parfois de ces surprises !

– Et si ça ne correspond pas ou si le carton n’est pas complet ?

– Si le cas se présente, c’est assez fréquent alors on connaît bien, ne vous inquiétez pas, vous nous appelez. On dépêche illico quelqu’un directement chez vous et à vos frais, et pour une facturation modique on vous aide à diagnostiquer les lacunes et à tout mettre en place dans le carton.

– Et vous adaptez le contenu du carton ?

– Oui, bien sûr, c’est un peu plus cher et ça prend un peu de temps, mais rien de déraisonnable.

– Le gros carton, je peux y jeter un œil ?

– Mais très certainement, voyez comme tout est bien écrit dessus, lisiblement, et comme la fermeture est proprement apposée. C’est de la bel ouvrage, professionnel à souhaits. Notez que ce que vous voyez est un exemple pas forcément représentatif, le votre pourra varier, d’ici à la livraison.

– Et à l’intérieur ?

– Dedans, c’est pareil, tout est judicieusement rangé pour un montage très précis et sans risques. D’ailleurs, je vous montre la notice, je ne peux pas ouvrir le carton, c’est assez secret et sensible, comme technologie, vous comprenez bien.

– Il n’y a aucun texte, tout est en images !

– Évidemment, de nos jours on n’écrit plus, ça limite drastiquement les défauts de traductions qui étaient si pénibles pour nos clients.

– Et vous m’affirmez qu’avec ça je traite tous mes cas ?

– Tous peut-être pas, par exemple, vous avez une machine à café ? J’ai là un assortiment de dosettes : en un seul carton vous avez des dosettes pour toutes les marques. C’est pratique, même plus besoin de se préoccuper de la marque de la votre au moment de la commande, vous voyez d’ici le progrès !

Diagnostique : un logiciel n’est pas plus une solution en entreprise qu’une clef de 17 en mécanique. L’utilisation d’un logiciel peut être une solution à un problème clairement posé pour peu qu’elle soit en adéquation avec le problème. Poser clairement le problème et définir l’utilisation adéquate sont les points importants à traiter. Les évacuer par un tour de passe-passe rhétorique a comme unique conséquence d’augmenter les difficultés et de générer de la dette.

Cryptography and service design

A very interesting post from Ben Adida introduced here by Mitchell Baker (Chairperson of the Mozilla Foundation) explains some points about cryptography and its useability to protect our private data.

Sure, cryptography is not magic and the Key Management is a real problem when thinking about cryptography in a widely used system.

But only if you consider services the way they are designed today.

Ben Adiba takes some examples, lets review them.

– Sony needs to be able to charge your credit card, which requires your billing address. They probably need to do that whether or not you’re online, since you’re not likely to appreciate being involved in your monthly renewal, each and every month.

Do you remember the time when to charge someone for a service you had to send him a bill ? This had two purpose : let her accept the service and request for the payment. It was a well understood and accepted process. Now, because we have computers, we accept the automated charging and the difficult opt-out process. It’s not a faith with computers. We are able to design computerized processes that do not eliminate the need for the service provider to request acceptance. And in the new design, guess what? Sony does not need to store your billing information in their datacenters. Information needed would be provided by the user software in a transactional encrypted packet built with data stored in the user environment (maybe a memory thumb or her phone…). And yes, I’d accept to be involved in my monthly renewal. At least, I would be pleased to have the choice.

– Meanwhile, Dropbox wants to give you access to your files everywhere. Maybe they could keep your files encrypted on their servers, with encryption keys stored only on your desktop machine? Yes… until you want to access your files over the Web using a friend’s computer.

Why the key should have to be stored somewhere else than on my, let’s say, phone? Nowadays I carry it always with me and it can store a lot of keys, protected, if I’m cautious. Useable with any computer I need. Provided that the client part of the service is designed well enough to avoid storing a copy of things into the computer disk.

– And what if you want to share a file with a friend while they’re not online? Somehow you have to send them the decryption key.

Well, I just have to be able to request the service to built a version of my file encrypted with the public key of my friend. This has another benefit: I am now able to revoke permissions or grant them for a limited amount of time without changing my personnal encryption key. Of course, to be able to design a good user experience, we need to automate a lot of things like knowing precisely what information is needed by the service and so, we need standards. Technical standards are not enough, we need semantic models of the dialog between user, client software and service software.

Ben has something (not complete) about that:

– Maybe you’re thinking you can use public-key encryption, where each user has a keypair, publishes the public encryption key, and keeps secret the private decryption key? Now we’re back to “you can’t get your data back” if the user loses their private key.

It’s true only if I consider that my data reference is the service provider storage or if I avoid any backups. Even without encryption what garantee have I that my data won’t be lost by the service provider ? Leaking data is not the only problem with the cloud. I still need backups.

– The more useful the product, the closer the decryption key has to be to the encrypted data.

The rule is that we can only protect pathes to data, not data itself. The nearest to the data you put protections, the less ramifications of pathes you have to protect. So if my reference (or my only copy) is stored inside the service provider storage, protections must be in the service provider systems. But all data does not have to be stored away from me to provide a good product: I’m writing this post in a javascript editor provided by wordpress in its web application. I can save regular drafts of my writings and if I don’t the application do it for me on a regular basis. But it does this inside the provider storages. Maybe it could do this also, or only, and automatically, in a special place on my computer (disabled when I write with another one)?

There are solutions to this kind of problems. We have technologies. And we have to use them right.

Technology is not a solution. Using technology is.

Syndrome du « Chez nous c’est pas pareil ! »

Ce syndrome prend de multiples formes partageant toutes comme manifestation la justification de la refonte de ce qui a déjà été fait maintes fois :

• soit parce qu’on ne veut pas modifier ce qui existe mais qu’on ne maîtrise plus ;
• soit parce qu’on veut expliquer l’inutilité des réflexions de synthèse (l’architecture, par exemple) et la toute puissance des bricolages locaux ad hoc ;
• soit parce qu’on met l’accent sur de subtiles nuances en perdant de vue la masse des ressemblances ;
• soit encore parce qu’un problème nouveau est bien plus intéressant qu’un problème déjà traité.

Mais rendons-nous à l’évidence, le manque de maîtrise de nos systèmes est en grande partie la conséquence des lacunes d’architecture et des vues localisées des concepteurs, et les problèmes réellement nouveaux ne sont pas si nombreux.

Le symptôme le plus vicieux de ce syndrome est l’arrogante idée qu’on (une personne, une équipe, une entreprise, une corporation…) est bien mieux placé pour aborder un problème que l’ensemble de nos prédécesseurs. Ce n’est pas toujours aussi explicite que ça, certes, mais c’est compris dedans aussi sûrement qu’une nouvelle taxe se retrouve dans le prix de vente. Ce symptôme, à son tour, entraîne des conséquences physiologiques : les entités ne peuvent pas communiquer correctement (les services organisationnels travaillent différemment, les logiciels traitent d’objets différents, les personnes utilisent des vocabulaires différents…), et la vision générale du système se dilue dans la multiplicité des composants locaux. La boucle de rétro-action positive est bouclée, le système se décompose et la maîtrise se perd inexorablement, enchâssée qu’elle est dans une dogmatique difficile à rompre.

Models and the enterprise

Building software for an enterprise used to be like building tools for a mechanic. Requesting needs, writing specs and building softwares pieces was like requesting what operation the mechanic has to do, observing the characteristics of the metal parts he handles and building special pliers or screwdriver.

This is no more the good metaphore.

Now, the enterprise must be seen as a system. Maybe a complex one (it’s not mathematically proven). It is no more made of real things (people, buildings, machines, papers, trash cans…) in one hand and softwares in the other one, it’s the result of the tight interconnection of all those parts. And interconnections are very, very important. If we continue to build softwares as little pieces of tools that match some very local needs (as we are used) we will not even bring an unneeded complexity (we call that complexification) but also a lot of failures when we try to promote localy designed tools to a broader level.

As a whole, the enterprise has now gained the right to be treated like other systems : we build models for earth, sea, climate, planes, processors, even for phones. We must build models for enterprises too. With models we are able to simulate the behaviour of earth and planes. We are able to predict (with some degree of error, of course) the state of a systems in a near or far future. We are able to take decisions related to some criteria that seems important. We should be able to do the same with enterprises. Why not? Why is this a so extraordinary thought? Because we are not *used* to it? Com’on!..