larlet-fr-david/david/blog/2016/donnees-responsabilite/index.md

title: Données et responsabilité
slug: donnees-responsabilite
date: 2016-03-04
chapo: Une fuite de données n’a pas d’odeur mais peut exploser à tout moment.

> The smog of personal data is the carbon dioxide of privacy. We’ve emitted far too much of it over the past decades, refusing to contemplate the consequences until the storms came. Now they’ve arrived, and they’ll only get worse, because the databases that haven’t breached yet are far bigger, and more sensitive than those that have.
>
> Like climate change, the privacy catastrophes of the next two decades are already inevitable. The problem we face is preventing the much worse catastrophes of the following the decades.
> 
> <cite>*[Forget Apple's fight with the FBI - our privacy catastrophe has only just begun](http://www.theguardian.com/technology/2016/mar/04/privacy-apple-fbi-encryption-surveillance)* ([cache](/david/cache/20a8f3d9244fbc71f7916fb0ee79c637/))</cite>

J’évoquais la [date de péremption des données](http://www.internetactu.net/2015/10/20/faut-il-une-date-de-peremption-pour-les-donnees/) ([cache](/david/cache/8f33334066da6322f51118b15e39e482/)) dans un [récent article](/david/blog/2016/opendata-liens-casses/) qui commençait à être trop long pour détailler ce point. Que ce soit la métaphore du nucléaire ou celle du CO2, nous avons une énorme [responsabilité](/david/stream/2015/02/28/) à stocker de la donnée en raison de sa [toxicité cachée](https://www.schneier.com/blog/archives/2016/03/data_is_a_toxic.html) ([cache](/david/cache/59766e274e416b779aafc7618fd56afa/)). **Une fuite de données n’a pas d’odeur mais peut exploser à tout moment.**

La parade me semble être de ne pas considérer la donnée comme étant [propriétaire](/david/blog/2013/proprieterre/) mais uniquement locataire du service. Chaque donnée soumise étant reliée à un bail renouvelable menant à sa suppression dans le cas contraire :

* on éduque ainsi l’utilisateur qui prend conscience du cycle de vie de ses données tout en l’assurant que celles-ci seront finalement détruites ;
* on anticipe sur l’espace de stockage à provisionner pour les prochain(e)s mois/années en cas de fermeture du service par exemple ;
* on développe en prenant en compte cette contrainte dès l’origine du produit pour se questionner sur la pérennité des liens associés.

**La responsabilité est partagée entre le locataire qui décide de la durée et le propriétaire qui garantit une sécurité contre rétribution.** Aucune donnée n’est stockée indéfiniment sans action périodique et manuelle de l’utilisateur. Les récentes fuites devraient nous alarmer sur notre niveau de prétention à vouloir stocker des données sans date de péremption tout en assurant leur sécurité. Le succès de Snapchat devrait nous motiver à trouver de nouveaux modèles car il existe une demande pour de la donnée éphémère choisie. La monétisation devrait davantage s’intéresser à la qualité et à la fraicheur du graphe qu’à sa taille, c’est là qu’est la valeur aujourd’hui. La suppression volontaire de données — au même titre que la suppression de fonctionnalités — est trop peu discutée à mon goût dans la communauté.

*Au passage, j’ai installé [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) suite à [un article sur une attaque ciblée](http://fusion.net/video/271750/real-future-episode-8-hack-attack/) ([cache](/david/cache/7191aa1575c9355fd8d7207808f56794/)) et le nombre de connexions effectuées sans pouvoir en identifier clairement la source est assez déprimant…*