Un nouveau format de fichier; IGF

La description ci dessous est relativement informelle pour faire comprendre l’utilité de ce nouveau format de fichier. Une spécification complète, en Anglais sera bientôt disponible pour toute développeur voulant proposer une implémentation. Enfin, vous pouvez me contacter (et voir sur GitHub) mon implémentation.

Le format de fichier HTML est une adaptation des formats de type SGML pour supporter simplement la notion d’hyperlien, mise en évidence par Tim Berners-Lee en 1991. A chaque fois qu’un client sélectionne un hyperlien, le serveur de la page courante analyse une balise « a », il lance une requête HTTP vers le serveur spécifié en préfixe de l’attribut « href ». Ce serveur retourne au client la page HTML classée dans l’arborescence désignée sous le suffixe du même attribut « href » de cette balise « a ».

Le principe est resté aujourd’hui le même sous HTML5 et le protocole HTTPS ne fait que chiffrer les transactions d’une session pour éviter qu’un individu analysant tous les échanges sur le canal de distribution (man in the middle), puisse lire ou reconstituer les données échangées.

Aucun support n’existe sur ces protocoles/formats pour supporter le Partage Marchand. Nous corrigeons en partie cette faiblesse en introduisant un nouveau format de fichier; Intangible Good Format, abrégé IGF.

D’abord, un fichier IGF est une encapsulation du fichier binaire qui est l’objet du partage marchand. Pour un ibook, ce sera vraisemblablement un PDF ou un ePUB. C’est le contenu de l’IG proprement dit, obligatoirement statique (son contenu ne change pas).

Le format IGF est composé d’un préfixe statique et d’un suffixe dynamique.

Le préfixe est décomposé par les éléments suivants, avec leur taille en octets spécifiée:

1. le codage utf8 du caractère ‘⊔’ (3 octets) pour définir le format de fichier de type IGF.
2. la version de la spécification de l’algorithme d’encodage/décodage, actuellement de valeur 1 et codée sur 1 octet.
3. le type (type mime) du fichier contenant l’IG; codé sur 2 octets
4. la taille de l’IG brut en octet, taille sur 8 octets
5. le prix initial de l’IG, payé par le premier acheteur. Ce prix est décroissant conformément à la loi du Partage Marchand. codé sur 4 octets
6. le revenu escompté final touché par le(s) créateurs de l’IG, sur 8 octets
7. le nombre d’auteurs ayant contribué à la création de l’IG (2 octet)

Après ces premiers 28 octets, pour chaque auteur:

1. l’identifiant (partie de la clé publique) de l’auteur (9 octets)
2. le ratio relatif de participation à la création (1 octet)

Ensuite, le fichier IGF contient l’IG lui même de la taille précédemment spécifiée

Ensuite, pour chaque auteur:

1. la signature (ECDSA), par cet auteur, du message constitué de préfixe (hors signature des autres auteurs), (132 octets). Cette signature porte aussi sur l’IG.

Maintenant, le fichier IGF contient une partie dynamique qui est nulle à la publication de l’IG. Pour chaque acheteur se présentant  pour acquérir l’IG

1. la date (EPOCH en minutes) de la transaction (4 octets)
2. l’identifiant de l’acheteur (9 octets),
3. une référence librement choisie par l’acheteur (2 octets),
4. la signature de la transaction (voir détail dans le code), (132 octets)
5. la clé privée de téléchargement de l’IG pour cet acheteur (12 octets)

Donc pour x auteurs et y acheteurs, et pour un IG de taille s, la taille du fichier IGF est de 28+142x+s+159y octets.

La première remarque est que les signatures des créateurs garantissent que ni l’IG, ni ses attributs commerciaux n’ont été modifiés depuis la publication. Ces signatures donnent l’accord sur les répartitions des revenus et il n’est pas possible d’en changer.

Le suffixe est en revanche dynamique et croit en taille au fur et à mesure que des clients achètent le bien. Il est de la responsabilité de l’acheteur de ne pas diffuser la clé secrète lui permettant d’accéder à un de ses achats en mode HTTPS. Ainsi, cette clé n’est pas visible d’un tiers.

Une API (Application Programming Interface) minimale permet de définir les opérations principales sur un fichier IGF, localisé par une url donnée (sans ajouter l’extension .igf).

• la donnée de l’url sans aucun argument retourne le prix courant du prochain achat.
• la requête GET « url?id » retourne le solde de l’utilisateur d’identifiant ‘id’ pour cet IG. id est noté en base64 sur 12 octets
• la requête GET « url?key » retourne l’IG binaire (penser à adapter le type mime). key est notée en base64 sur 36 octets; codage  base64(id acheteur sur 9 octets + position de l’acheteur sur 6 octets + clé sur 14 octets)
• la requête GET « url?transaction » ajoute un utilisateur au suffixe du fichier IGF. La transaction contient la signature de l’acheteur sur la référence de l’IG. Une transaction est codée ne base64 sur 196 octets (159/3*4). Cette requête retourne une clé pour lire l’IG pour cet utilisateur ou un message d’erreur. La principale raison de refus (outre une mauvaise signature) est l’utilisation d’un date dans le futur. Les achats étant classés par date, un anti-datage fait insérer la transaction dans la liste des anciens acheteurs, cet acheteur payera donc selon sa position, potentiellement plus que s’il avant utilisé la date présente.

Dans le cas de deux acheteurs lançant leur requête d’achat presque au même moment, l’un des deux (celui arrivé en second) payera légèrement moins que ce qui lui été affiché au moment de l’achat.

Pour calculer le solde en ⊔ du compte d’un utilisateur donné (pour autoriser un nouvel achat), il faut interroger la base de données (type Berkeley) des IGS pour avoir la liste des IGS impliquées par cet utilisateur (comme auteur ou comme acheteur) et faire la somme algébrique des requêtes de solde pour chaque url, pour cet utilisateur en lisant le fichier IGF.

Si le serveur (Apache) peut lire tout le contenu d’un fichier IGF, il n’est pas possible depuis un client d’avoir accès au fichier complet, seulement à l’IG si l’on dispose de la clé valide. Enfin la requête est obligatoirement en HTTPS pour ne pas passer en clair cette clé.

Tous les nœuds du réseau ne possèdent pas une copie de tous les IG disponibles car cela saturerait vite ces nœuds et surtout, l’administrateur du nœud aurait accès gratuitement à l’IG. En revanche, comme pour un partage de fichier en BitTorrent, si un acheteur affecte un serveur au partage marchand, et seulement après achat de l’IG, le protocole copiera l’IG sur le serveur de l’acheteur en utilisant un sous-ensemble de nœuds possédant déjà le fichier IGF.

Rappelons qu’il n’y a aucun DRM associé aux IGs. Un acheteur peut techniquement extraire l’IG qu’il a téléchargé pour le publier hors IGF, mais il casse de la sorte le principe du partage des frais vis à vis de l’auteur.Nous pensons que l’absence d’intermédiaires (GAFAM) et le mécanisme des prix dégressifs devrait être dissuasif du piratage.

Une légère adaptation du protocole sur le serveur retourne un IG marqué (tatouage) de l’ID de l’acheteur. Ce n’est pas un système infaillible pour un expert du format binaire de l’IG, mais l’extraction des tatouages demande un certain travail hors de portée de novices. La stratégie reste que cela devienne à terme « ringard », surtout pour les jeunes, de pirater un fichier en Partage Marchand. N’oublions pas qu’il est prévue une part de création monétaire en ⊔, pour donner un accès gratuit à la culture numérique, mais il faut pour cela une adoption relativement massive du protocole car les non-membre seraient désavantagés.