GuiGui's Show

« La nouvelle est tombée brutalement vendredi dernier : le site de streaming musical Grooveshark a fermé ses portes, après plus de huit années d’existence et une longue bataille judiciaire contre les majors de la musique, qui s’était conclue en 2014 par une cinglante condamnation pour violation du droit d’auteur. Sous la pression des ayants droit, les fondateurs du site ont préféré saborder leur navire et mettre un point final à l’aventure, plutôt que de devoir payer les 700 millions de dollars d’amendes auxquels la justice les avaient condamnés.

[...]

Du P2P rémunéré au streaming musical centralisé

[...]

Car à leurs yeux, Grooveshark portait en lui une forme de « vice fondamental »: si les industriels de la musique toléraient l’existence d’un service fonctionnant sur le principe du partage des fichiers par les individus, ils acceptaient de revenir sur un des fondements du droit d’auteur, qui veut qu’une oeuvre ne peut être distribuée sous une forme donnée qu’avec l’accord des titulaires de droits. Ne parvenant pas à trouver d’issue légale pour son modèle, Grooveshark s’est alors abrité derrière la responsabilité allégée dont bénéficient les hébergeurs de contenu sur Internet au titre du DMCA (Digital Millenium Copyright Act) aux Etats-Unis. Une plateforme ne devient responsable pour un contenu mis en ligne par ses utilisateurs que si elle ne réagit pas rapidement pour le retirer une fois qu’il lui a été signalé. Or c’est ce point qui a causé la perte de Grooveshark : les ayants droit sont parvenus à prouver devant les juges que la société avait demandé à des employés de charger eux-mêmes de fichiers sur la plateforme, ce qui a eu pour conséquence de leur faire perdre le bénéfice du « safe harbour » (sphère de sécurité) prévu par le DMCA.

[...]

Quelle différence entre Grooveshark et « l’offre légale » ?

La différence est en réalité extrêmement ténue. On peut même dire que Deezer n’est rien d’autre qu’un Grooveshark qui a réussi. En effet, il est bon de rappeler qu’à ses origines l’aujourd’hui respectable Deezer a également subi des accusations de violation de droit d’auteur. Le champion français du streaming avait en effet réussi à trouver un accord avec la SACEM en ce qui concerne les droits des auteurs, mais pas avec les producteurs de musique qui l’ont longtemps menacé de procès. Ce n’est qu’après coup qu’une entente a pu être entérinée, mais Deezer a bien été obligé lui-aussi à une époque de « passer en force », en mettant les titulaires devant le fait accompli de l’existence d’une offre.

Un site très proche de Grooveshark a d’ailleurs existé en France. En 2003, Radio.blog.club avait essayé de mettre en place un modèle d’écoute en streaming gratuit, financé par de la publicité. C’était d’ailleurs à l’époque le concurrent d’un certain BlogMusik, qui se se transformera ensuite en Deezer après avoir réglé ses problèmes juridiques. Mais la sanction a été lourde pour lui, puisque le site a été condamné en 2012 par la justice, avec un million d’euros d’amendes à verser pour ses fondateurs.

[...]

Comment les plateformes « achètent » leur survie…

Pourquoi les ayants droit se sont-ils acharnés à ce point sur Grooveshark, alors qu’ils laissent subsister des plateformes proches dans leurs principes de fonctionnement, comme YouTube ou SoundCloud ? Certes, il y a bien sûr le fait que Grooveshark a commis l’énorme erreur de faire partager des fichiers à ses propres employés, ce qui le rendait beaucoup plus facile à abattre en justice. Mais au-delà de cela, YouTube et SoundCloud ont accepté de faire évoluer graduellement leur modèle pour trouver un terrain d’entente avec les titulaires de droits.

YouTube a par exemple des accords de redistribution de recettes publicitaires qu’il génère avec certains producteurs, ainsi qu’avec des sociétés d’auteur comme la SACEM en France. Par ailleurs, il a déployé un système de filtrage automatique des contenus chargés par ses utilisateurs, le fameux ContentID, dit aussi « Robocopyright ». Cet algorithme fonctionnant à partir d’empreintes des fichiers fournies à YouTube par les titulaires de droits assure une forme de « police privée du droit d’auteur », en distribuant des sanctions (les « strikes ») aux utilisateurs qui chargent des contenus sans respecter le droit d’auteur. Le système permet à la plateforme d’exercer une surveilance constante des contenus, sans perdre le bénéfice de sa responsabilité allégée.

[...]

SoundCloud a connu exactement la même trajectoire. Un robocopyright a aussi été progressivement déployé pour filtrer les contenus et la plateforme a récemment noué un partenariat avec la société Zefr pour améliorer son efficacité. Cette évolution lui a permis de commencer à nouer des accords avec Warner Music, mais les négociations continuent toujours avec les autres majors. Au passage, l’implantation du robot a eu des conséquences non négligeables pour les utilisateurs. Car SoundCloud a longtemps été réputé comme un lieu privilégié sur la Toile pour le partage des mixes et des compilations de DJs. Or son algorithme repère automatiquement les empreintes des oeuvres qu’il est chargé de surveiller, sans distinguer s’il s’agit de morceaux entiers ou d’extraits réutilisés dans des créations dérivées. Depuis quelques temps, les DJ postant leurs mixes sur SoundCloud font donc l’objet de sanctions à répétition, à tel point que la communauté envisage à présent de migrer. SoundCloud en sera plus « propre », mais aussi bien plus pauvre…

[...]

D’une certaine manière, on peut dire que deux plateformes comme YouTube et SoundCloud ont « acheté leur survie » en acceptant de déployer ces systèmes de police privée du droit d’auteur. Pour les utilisateurs, cela signifie aussi qu’il faudra dorénavant se soumettre à une forme de « robotisation » de l’application du droit, provoquant de plus en plus de dommages collatéraux.

Même s’il change profondément leur nature, ce « deal » peut s’avérer juteux pour les plateformes. YouTube par exemple a lancé depuis la fin de l’année une offre de musique en streaming sur abonnement à partir des contenus partagés sur sa plateforme. En termes de profondeur de catalogue, il est le seul qui puisse être comparé à Grooveshark, parce que son principe repose aussi sur une alimentation par la foule.

Son modèle passera par des abonnements proposés aux utilisateurs en échange d’une suppression de la publicité qui devient de plus en plus envahissante sur YouTube. Evidemment, YouTube – et Google derrière lui, propriétaire du site – a négocié le montage de cette offre avec les majors de la musique. Mais la plateforme n’a pas hésité au passage à utiliser sa puissance pour tordre le bras des producteurs indépendants, qui ont été sommés d’accepter des termes contractuels défavorables sous peine d’être éjectés de l’offre gratuite.

[...]

Le seul point « positif » – si l’on peut s’exprimer ainsi – dans la fermeture de Grooveshark, c’est qu’il aura quand même fallu un procès en bonne et due forme pour arriver à ce résultat. On reste encore dans le cadre d’une décision de justice, offrant un minimum de garanties pour les droits de la défense. L’étape suivante que visent à présent les titulaires de droits, c’est d’être en mesure de contourner la justice pour faire pression directement sur les plateformes avec l’appui de l’Etat.

[...]

C’est une tendance lourde que l’on voit actuellement monter à travers des concepts comme « l’auto-régulation des plateformes » ou la mise en place de moyens extra-judiciaires de lutte contre la « contrefaçon à échelle commerciale », telle la Charte récemment négociée en France sous l’égide du Ministère de la Culture à propos de la publicité en ligne. Le prochain Grooveshark ne sera pas condamné par un juge : il sera éjecté de l’écosystème par un système de censure privée organisé sur une base contractuelle entre les titulaires de droits et des intermédiaires. C’est d’ailleurs ce qui avait commencé avec Grooveshark, puisque Google avait accepté en 2013 de ne plus afficher le site dans ses suggestions de recherche, avant même que le jugement final ne soit rendu en 2014. Ce type de réactions des intermédiaires techniques risque de se généraliser.

L’évolution du streaming dans la musique montre d’ailleurs à quel point un concept comme celui de « contrefaçon commerciale » ou de « site massivement contrefaisant » est évanescent. La différence entre Deezer, YouTube et Grooveshark n’est qu’une différence de degrés et pas de nature. Ceux qui acceptent « d’acheter leur survie » pourront subsister, mais à condition d’évoluer vers des modèles de plus en plus problématiques pour le respect des libertés… »

Via https://twitter.com/bortzmeyer/status/595173585007845376

Vu que le vote en séance publique à l'Assemblée est pour mardi 5 mai, j'ai encore contacté mon député (duquel je n'ai toujours aucune réponse, narmol quoi)...

« Monsieur le Député,

Je fais suite à mes mails « À propos du projet de loi relatif au renseignement » du 01/04/2015 et 12/04/2015.

Le projet de loi renseignement sera mis au vote dans notre Assemblée le 5 mai prochain.

Comme aucune des dispositions liberticides[1] n'a été retirée ni même amoindrie lors des discussions publiques à l'Assemblée les 13,14,15,16 avril derniers, je m'oppose toujours fermement à ce texte. Les promesses de saisine du Conseil constitutionnel par François Hollande et par des parlementaires de l'opposition ne constituent pas une garantie suffisante à mes yeux.

Je vous rappelle que les acteurs de l'Économie numérique française (mouvement « ni pigeons, ni espions - http://ni-pigeons-ni-espions.fr/fr/), les défenseurs des libertés (Syndicat de la Magistrature, le Syndicat national des journalistes, l’Ordre des avocats de Paris, (La Quadrature du Net, Amnesty International, Reporters Sans Frontières,... parmi de nombreux autres) ainsi que la société civile (manifestation du 2 mai à Lyon - http://www.zdnet.fr/actualites/loi-renseignement-premiere-manifestation-d-opposants-a-lyon-39818820.htm, inauguration de la place de la liberté surveillée à Brest - https://www.youtube.com/watch?v=7DV2P-eSlWI) restent mobilisés contre ce projet de loi. Les représentants du peuple français les ignoreront-ils ? Iront-ils à l'encontre de leur volonté ?

Quel est votre positionnement sur ce projet de loi ?

Je vous demande expressément de rejeter ce texte lors du vote de mardi prochain pour les raisons exposées dans mes mails précédents et rappelées en préambule de ce mail.

Cordialement.

[1] Contrôle complet du dispositif de renseignement par l'exécutif, aucun contre-pouvoir, pas de judiciaire, pas de réel recours pour le citoyen, la CNCTR est une commission purement consultative en manque de moyens, mise en place d'une surveillance de masse (via une collecte de masse sur les réseaux informatiques) perpétrée par de mystérieux algorithmes informatiques dont personne ne saura jamais rien, légalisation de techniques de renseignement intrusives déjà en usage sans débat démocratique pour offrir l'impunité aux agents de l'État,... »

Un énième rappel pour que ça rentre bien dans les esprits.

« Selon la presse allemande, l’Allemagne aurait espionné la France et l’Union européenne pour le compte de la NSA. Etonnament, pensent certains, la France se tait. Comme si finalement, il n’y avait pas là une sorte de cassure dans le couple franco-allemand.

[...]

Premier point, comme l’expliquait déjà Bluetouff en juin 2013, la collaboration très étroite entre la Grande-Bretagne, l’Allemagne et les Etats-Unis en matière d’écoute n’est pas une nouveauté. L’armée américaine et la NSA, évidemment, exploitent des bases monumentales dans ces pays. Des bases dans lesquelles les employés sont américains. Lorsqu’un pays donne le droit à un autre de mettre en place des stations d’écoute très sophistiquées et « autonomes » sur son sol, on est en droit d’imaginer que la collaboration dans ce domaine est maximale.

Deuxième point, il est désormais établi que les pays, amis plus ou moins proches, ont mis en place après le 11 septembre une gigantesque bourse d’échange de renseignements. Tu espionne machin, ça m’intéresse. Moi j’espionne truc et ça t’intéresse. Ça tombe bien, nos législations locales nous interdisent d’espionner machin ou truc, on n’a qu’à échanger ces données. #Spamoi qui l’ai fait, c’est mon copain. Ainsi, les Etats-Unis puisent en Grande-Bretagne les informations concernant leurs ressortissants et la Grande-Bretagne va chercher aux Etats-Unis les données concernant les sujets de sa majesté. Pratique.

Les Etats-Unis, comme l’avait déjà évoqué Reflets, ont une mauvaise connectivité avec l’Afrique. La France, à l’inverse, a de gros tuyaux qui passent par cette région. Les Américains utilisent donc des métadonnées récoltées par la France. Ceci, très probablement dans le cadre du mystérieux accord Lustre que la France refuse catégoriquement de commenter depuis la révélation de son existence. Jean-Jacques Urvoas allant même jusqu’à quitter la salle lorsque Reflets l’interrogeait sur ce sujet dans une réunion publique.

Cette collaboration asymétrique (les Etats-Unis ont des capacités d’écoute bien plus importantes) a bien entendu un volet désagréable. Lorsque Edward Snowden envisageait de demander l’asile à l’Allemagne, les Etats-Unis ont expliqué à leurs amis allemands qu’il n’en était pas question, sous peine de perdre l’accès à cette bourse d’échanges. »

« Au restaurant, à l'hôtel ou dans les bibliothèques, il est souvent possible d'utiliser un réseau internet wi-fi ou des postes informatiques en libre accès.

La CNIL a décidé d'intégrer dans son programme annuel des contrôles la thématique de l'internet en libre accès. Elle a effectué plusieurs contrôles des modalités de mise en œuvre de ce type de service auprès d'organismes privés et publics.

[...]

La CNIL a constaté lors des contrôles que de nombreux opérateurs de communication électronique conservaient des données portant sur le contenu des correspondances échangées ou des informations consultées (URLs) alors qu'ils ne sont pas autorisés à le faire (article L. 34‑1 VI du CPCE).

[...]

Or, les données de trafic doivent être conservées pendant 1 an à compter du jour de leur enregistrement ( Article R. 10-13 du Code des postes et des communications électroniques)

Les autres données collectées dans le cadre de l'offre d'internet en libre accès, telles que les informations d'abonnement, etc. doivent être supprimées régulièrement (article 6-5° de la loi n°78-17 du 6 janvier 1978 modifiée) lorsqu'elles ne sont plus nécessaires (désinscription ou inutilisation prolongée de l'abonnement).

[...]

Les opérateurs de communication électronique doivent délivrer une information aux utilisateurs de leur service sur les modalités de traitement de leurs données (article 32 de la loi n°78-17 du 6 janvier 1978 modifiée). Le support de cette information doit être le formulaire d'inscription au service. A défaut, l'information doit être fournie par voie d'affichage, dans une charte informatique, etc. (Voir les modèles de mention d'information).

[...]

Plusieurs opérateurs de communication électronique contrôlés utilisaient des outils de surveillance afin d'assurer la sécurité des postes informatiques, la gestion des tarifications, les impressions, etc.

L'utilisation de tels outils (consultation ou prise en main à distance, contrôle de l'historique de la navigation, etc.) est susceptible de donner accès à un grand nombre d'informations excessives au regard de la finalité pour laquelle elles sont collectées (identifiants-mots de passe, numéros de compte bancaire, etc). Le recours à de tels outils doit être évité ou un paramétrage limité doit être mis en place. »

Identifier les cas où un document store n'est pas adapté.

« MongoDB is a document-oriented database. Instead of storing your data in tables made out of individual rows, like a relational database does, it stores your data in collections made out of individual documents. In MongoDB, a document is a big JSON blob with no particular format or schema.

[...]

At the root, we have a set of TV shows. Each show has many seasons, each season has many episodes, and each episode has many reviews and many cast members. When users come into this site, typically they go directly to the page for a particular TV show. On that page they see all the seasons and all the episodes and all the reviews and all the cast members from that show, all on one page. So from the application perspective, when the user visits a page, we want to retrieve all of the information connected to that TV show.

There are a number of ways you could model this data. In a typical relational store, each of these boxes would be a table. You’d have a tv_shows table, a seasons table with a foreign key into tv_shows, an episodes table with a foreign key into seasons, and reviews and cast_members tables with foreign keys into episodes. So to get all the information for a TV show, you’re looking at a five-table join.

We could also model this data as a set of nested hashes. The set of information about a particular TV show is one big nested key/value data structure. Inside a TV show, there’s an array of seasons, each of which is also a hash. Within each season, an array of episodes, each of which is a hash, and so on. This is how MongoDB models the data. Each TV show is a document that contains all the information we need for one show.

[...]

It’s got some title metadata, and then it’s got an array of seasons. Each season is itself a hash with metadata and an array of episodes. In turn, each episode has some metadata and arrays for both reviews and cast members.

It’s basically a huge fractal data structure.

[...]

All of the data we need for a TV show is under one document, so it’s very fast to retrieve all this information at once, even if the document is very large. There’s a TV show here in the US called “General Hospital” that has aired over 12,000 episodes over the course of 50+ seasons. On my laptop, PostgreSQL takes about a minute to get denormalized data for 12,000 episodes, while retrieval of the equivalent document by ID in MongoDB takes a fraction of a second.

So in many ways, this application presented the ideal use case for a document store.

[...]

There is a really important difference between Diaspora’s social data and the Mongo-ideal TV show data that no one noticed at first.

With TV shows, each box in the relationship diagram is a different type. TV shows are different from seasons are different from episodes are different from reviews are different from cast members. None of them is even a sub-type of another type.

But with social data, some of the boxes in the relationship diagram are the same type. In fact, all of these green boxes are the same type — they are all Diaspora users.

A user has friends, and each friend may themselves be a user. Or, they may not, because it’s a distributed system. (That’s a whole layer of complexity that I’m just skipping for today.) In the same way, commenters and likers may also be users.

This type duplication makes it way harder to denormalize an activity stream into a single document. That’s because in different places in your document, you may be referring to the same concept — in this case, the same user. The user who liked that post in your activity stream may also be the user who commented on a different post.

[...]

We can represent this in MongoDB in a couple of different ways. Duplication is any easy option. All the information for that friend is copied and saved to the like on the first post, and then a separate copy is saved to the comment on the second post. The advantage is that all the data is present everywhere you need it, and you can still pull the whole activity stream back as a single document.

[...]

You can also see why this is dangerous. Updating a user’s data means walking through all the activity streams that they appear in to change the data in all those different places. This is very error-prone, and often leads to inconsistent data and mysterious errors, particularly when dealing with deletions.

[...]

There is another approach you can take to this problem in MongoDB, which will more familiar if you have a relational background. Instead of duplicating user data, you can store references to users in the activity stream documents.

With this approach, instead of inlining this user data wherever you need it, you give each user an ID. Once users have IDs, we store the user’s ID every place that we were previously inlining data. New IDs are in green below.

[...]

This eliminates our duplication problem. When user data changes, there’s only one document that gets rewritten. However, we’ve created a new problem for ourselves. Because we’ve moved some data out of the activity streams, we can no longer construct an activity stream from a single document. This is less efficient and more complex. Constructing an activity stream now requires us to 1) retrieve the stream document, and then 2) retrieve all the user documents to fill in names and avatars.

What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead.

[...]

Let’s return to TV shows for a second. The set of relationships for a TV show don’t have a lot of complexity. Because all the boxes in the relationship diagram are different entities, the entire query can be denormalized into one document with no duplication and no references. In this document database, there are no links between documents. It requires no joins.

On a social network, however, nothing is that self-contained. Any time you see something that looks like a name or a picture, you expect to be able to click on it and go see that user, their profile, and their posts. A TV show application doesn’t work that way. If you’re on season 1 episode 1 of Babylon 5, you don’t expect to be able to click through to season 1 episode 1 of General Hospital.

[...]

Once we started doing ugly MongoDB joins manually in the Diaspora code, we knew it was the first sign of trouble. It was a sign that our data was actually relational, that there was value to that structure, and that we were going against the basic concept of a document data store.

Whether you’re duplicating critical data (ugh), or using references and doing joins in your application code (double ugh), when you have links between documents, you’ve outgrown MongoDB. When the MongoDB folks say “documents,” in many ways, they mean things you can print out on a piece of paper and hold. A document may have internal structure — headings and subheadings and paragraphs and footers — but it doesn’t link to other documents. It’s a self-contained piece of semi-structured data.

If your data looks like that, you’ve got documents. Congratulations! It’s a good use case for Mongo. But if there’s value in the links between documents, then you don’t actually have documents. MongoDB is not the right solution for you. It’s certainly not the right solution for social data, where links between documents are actually the most critical data in the system.

[...]

When MongoDB is all you have, it’s a cache with no backing store behind it. It will become inconsistent. Not eventually consistent — just plain, flat-out inconsistent, for all time. At that point, you have no options. Not even a nuclear one. You have no way to regenerate the data in a consistent state.

When Diaspora decided to store social data in MongoDB, we were conflating a database with a cache. Databases and caches are very different things. They have very different ideas about permanence, transience, duplication, references, data integrity, and speed.

[...]

Remember that TV show application? It was the perfect use case for MongoDB. Each show was one document, perfectly self-contained. No references to anything, no duplication, and no way for the data to become inconsistent.

About three months into development, it was still humming along nicely on MongoDB. One Monday, at the weekly planning meeting, the client told us about a new feature that one of their investors wanted: when they were looking at the actors in an episode of a show, they wanted to be able to click on an actor’s name and see that person’s entire television career. They wanted a chronological listing of all of the episodes of all the different shows that actor had ever been in.

We stored each show as a document in MongoDB containing all of its nested information, including cast members. If the same actor appeared in two different episodes, even of the same show, their information was stored in both places. We had no way to tell, aside from comparing the names, whether they were the same person. So to implement this feature, we needed to search through every document to find and de-duplicate instances of the actor that the user clicked on. Ugh. At a minimum, we needed to de-dup them once, and then maintain an external index of actor information, which would have the same invalidation issues as any other cache.  »

Via http://www.gcu-squad.org/2014/11/mongo-or-not-mongo/

:D

Via http://lehollandaisvolant.net/?id=20150428185651

« Depuis que les piratages de Comodo et DigiNotar ont fait prendre conscience du peu de sécurité qu'apportent les certificats X.509, plusieurs solutions ont été proposées pour combler les failles des autorités de certification. La proposition de ce RFC consiste à permettre à un client d'épingler (to pin) les clés cryptographiques d'un serveur HTTP utilisant TLS, c'est-à-dire à s'en souvenir pendant une durée spécifiée par le serveur. Ainsi, même si un faux certificat est émis par une AC, il ne sera pas accepté.

[...]

Parmi les solutions élaborées, il y a DANE, qui s'appuie sur le DNS (RFC 6698), mais Google préfère les certificats à la lumière du jour du RFC 6962 et l'épinglage (pinning) des clés, dans ce tout nouveau RFC 7469.

[...]

L'épinglage fait partie des techniques TOFU (Trust On First Use) : la première fois qu'un client se connecte au serveur, il ne peut pas savoir si la clé est bonne (il doit se fier à la validation X.509, avec ses limites). À la première connexion, le client HTTP (par exemple un navigateur Web) doit espérer qu'il n'y a pas d'homme du milieu ayant réussi à obtenir un faux certificat (pour cette raison, une attaque persistente, comme celle du ministère des finances, citée plus haut, ne serait pas empêchée par l'épinglage). Aux connexions suivantes, le client HTTP pourra par contre vérifier l'identité du serveur, grâce à la clé épinglée, c'est-à-dire gardée en mémoire. Ce n'est pas idéal (imaginez un homme du milieu ayant un faux certificat pour la première connexion et épinglant ses propres clés, empêchant ainsi toute correction ultérieure !) mais c'est un progrès sur la situation actuelle (valider les clés est un problème difficile en cryptographie).

[...]

Elle définit un nouvel en-tête HTTP, Public-Key-Pins:. Présent dans une réponse HTTPS, cet en-tête indique au client HTTP que ce serait souhaitable qu'il épingle, qu'il mémorise, la clé publique. Le contenu de l'en-tête Public-Key-Pins: est le condensat de la clé publique utilisée pour TLS, condensat encodé en Base64 (RFC 4648). L'algorithme de condensation est indiqué dans la valeur de l'en-tête. Aujourd'hui, c'est forcément SHA-256 (RFC 6234). La clé est l'encodage DER du champ subjectPublicKeyInfo du certificat X.509 (à noter que les cas des clés brutes du RFC 7250 ou des clés PGP du RFC 6091 ne semblent pas traités, car elles n'ont pas les problèmes des certificats X.509). Une directive max-age est obligatoire dans l'en-tête HTTP, pour indiquer le nombre de secondes que doit durer l'épinglage (après quoi le client HTTP « oublie » la clé). Voici un exemple :

Public-Key-Pins: max-age=604800;
       pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="

[...]

Autre directive facultative, report-uri indique à quel URI le client doit signaler les erreurs résultant de l'épinglage. En effet, on peut prévoir que, comme avec toute technique de sécurité, il y aura des problèmes. Par exemple, des webmestres changeront de clé et oublieront de modifier le Public-Key-Pins:. Il est donc important que ces problèmes soient détectés rapidement. Ce signalement se fera selon la technique décrite plus loin en section 3. Attention aux conséquences pour la vie privée ! La très détaillée section 5 couvre ce risque d'intrusivité.

[...]

À noter qu'un deuxième en-tête est défini, Public-Key-Pins-Report-Only:, qui a exactement la même syntaxe, mais une sémantique différente : le client HTTP teste la clé épinglée et, si elle est fausse, le signale à l'URI indiqué par report-uri (qui devient donc obligatoire), mais n'empêche pas l'accès au serveur. C'est utile pour tester avant le vrai déploiement.

[...]

Par exemple, l'épinglage peut avoir des conséquences néfastes si on s'est fait voler sa clé privée : normalement, on génère une nouvelle clé, un nouveau certificat et on demande à l'AC de re-signer. Mais on ne pourra pas l'utiliser car la clé publique correspondant à la clé volée est toujours épinglée dans des tas de navigateurs. On peut réduire ce problème en diminuant la durée d'épinglage. Mais, alors, on réduit aussi la durée de la protection dans le cas où une AC génère un certificat mensonger. Un compromis est donc nécessaire. Une approche possible est d'épingler, non pas la clé du serveur mais une clé intermédiaire dans la chaîne des certificats. Supposons que la société Example, qui gère example.com soit cliente de l'AC SmallAC qui a elle-même son certificat signé par une AC très largement reconnue, BigAC. En épinglant la clé de SmallAC, on se protège contre un vol de la clé privée d'example.com, et contre un faux certificat, même émis par BigAC. La société Example reste vulnérable à un faux certificat produit par SmallAC mais cela diminue sérieusement le nombre d'acteurs qui peuvent attaquer Example.

[...]

On a vu plus haut qu'on pouvait avoir plusieurs clés dans l'en-tête Public-Key-Pins:. Une des utilisations de cette possibilité est le cas où on a une clé de réserve (backup pin), non utilisée mais gardée en un endroit différent de la clé du certificat actuel. Ainsi, si, pour une raison ou pour une autre, la clé est inutilisable, la clé de réserve peut prendre le relais immédiatement puisqu'elle est déjà épinglée.

[...]

Autre cas où l'épinglage peut avoir un effet néfaste, celui de l'épinglage hostile. Imaginons un méchant qui obtienne un faux certificat. Il détourne le trafic (par exemple par un empoisonnement DNS) et envoie les gens vers son serveur HTTPS, qui semblera légitime, en raison du faux certificat. Avec l'épinglage, il peut même prolonger son attaque en épinglant sa clé. Si le site légitime n'avait pas été visité avant, ou s'il ne faisait pas d'épinglage, l'attaque peut réussir, bloquant le client HTTPS sur la clé de l'agresseur pour la durée max-age spécifiée par ledit agresseur. Il n'y a pas de solution miracle pour ce problème. Une possibilité est de précharger les clés de sites connus dans le navigateur. Une autre est d'utiliser les certificats au grand jour du RFC 6962.

[...]

Autres risques, ceux pour la vie privée (section 5). Un serveur peu sympathique peut utiliser l'épinglage comme une sorte de cookie discret. Par exemple, il peut mettre une petite image dans un sous-domaine, épingler des fausses clés pour ce sous-domaine (une différente par visiteur) et attendre les signalements à report-uri pour identifier un client HTTPS unique. Des sites différents peuvent même coopérer pour avoir le même report-uri, pour suivre un client à travers plusieurs sites.

À noter aussi que les signalements d'un problème de validation contiennent la chaîne de certificats utilisée. Cela peut permettre d'identifier l'utilisation de faux certificats par telle ou telle organisation. C'est plutôt une bonne chose pour détecter des attaques comme celle effectuée au ministère des finances mais cela ne sera évidemment pas apprécié de ceux qui veulent faire du détournement de trafic.

[...]

Le RFC recommande aussi que l'utilisateur puisse accéder facilement à la liste des clés épinglées et aussi, ce qui me semble plus contestable, qu'il puisse la modifier, par exemple en désépinglant les clés. Cela me semble dangereux car cela peut ouvrir une voie à l'ingénierie sociale (« il y a un petit problème technique, si l'accès vous est refusé, cliquez sur Clear all pinned keys »).

[...]

(Tom me fait remarquer à juste titre qu'une clé de secours est obligatoire - section 4.3 - et que donc il faut toujours au moins deux pin-sha256. J'ai simplifié.)  »

« Le protocole HTTP définit plusieurs codes de retour pour une redirection (« la ressource que tu cherches n'est pas ici, va voir là »). La section 6.4 du RFC 7231 classe ces trois codes de retour en notant que deux désignent des redirections temporaires (302 et 307) et qu'un désigne une redirection permanente (301). Deux codes permettent au client HTTP de remplacer, pour la nouvelle requête, la méthode POST par un GET (301 et 302), un autre ne le permet pas (307). Si vous avez suivi, vous avez noté qu'il manquait un code voulant dire « redirection permanente mais sans changer la méthode HTTP ». C'est l'objet du nouveau code décrit à l'origine dans le RFC 7238, et désormais normalisé dans ce RFC, le code 308. »

« L'auteur de la retranscription précise au journal, dans un second temps, que "des modifications peuvent être apportées, tant que ces dernières n’altéraient pas l’esprit de l’intervention". Et se ravise finalement, par mail : "Au final, ce qui a été dit deux fois dans la même lancée (après plusieurs autres) a été ramassé en une fois, celle où il y a 'par nature et par essence', écrit cette personne. Mais je conçois très bien que l’effet en soit amoindri. Je vais remanier ça afin que ce soit la phrase d’entrée qui apparaisse." A l'heure où cet article est publié sur francetv info (20h20), la modification n'a toujours pas été apportée. »

Sans aller jusqu'à parler de malhonnêteté ciblée sur le dossier du projet de loi renseignement comme le fait cet article, je trouve cela très éclairant sur la qualité des retranscriptions de l'ensemble des interventions qui se produisent dans notre parlement.