Carnet de notes

Catégorie : Architectures ouvertes

  • Formats de livres numé­riques avec DRM

    Parce que ça peut servir à d’autres :

    Nom Editeur Formats Utilisé par Commen­taires
    Adept Adobe ePub, pdf, ascm Majo­rité, Kobo, B&N, Sony, Google DRM stan­dard utilisé partout. Il peut s’at­ta­cher au maté­riel ou à un compte Adobe indé­pen­dant.
    Micro­soft Micro­soft lit Micro­soft Aban­donné
    Kepub (Adept) Kobo (Adobe) kepub Kobo Il s’agit d’un ePub avec quelques données en plus. Les fichiers peuvent être télé­char­gés au format ePub + DRM Adobe stan­dard
    Topaz Amazon azw, tpz Amazon Nouveau format Amazon, basé sur son précé­dent format Mobi­po­cket
    Mobi­po­cket Amazon mobi Amazon (ancien) Format créé par Mobi­po­cket (racheté par Amazon). Fonc­tionne avec un système de PID (clef unique par maté­riel)
    Ignoble (basé sur adept) B&N (Adobe) B&N Exten­sion du DRM ADEPT d’Adobe où on utilise nom et numéro de CB comme clef (pour dissua­der de parta­ger)
    eRea­der B&N pdb, pml B&N (ancien), Palm Ancien format B&N, qui utilise lui aussi le nom et le numéro de CB comme clef pour frein social au partage
    FairP­lay Apple Apple Interne à Apple, pas de recherche de faille à ce jour
    BBeB Sony lrx, lrs Sony Aban­donné

    Hormis Apple Fair­play, tous les formats non aban­don­nés sont actuel­le­ment cassés. Le jeu du chat et de la souris est clai­re­ment en faveur de la souris depuis deux ans que le jeu à commen­cer. Vu le faible niveau d’ob­fus­ca­tion, on peut même penser qu’il n’y a pas vrai­ment de volonté de rendre ces systèmes de DRM vrai­ment effi­caces. Vu le coût finan­cier et utili­sa­teur d’une mise à jour fréquente du système, ils n’ont d’ailleurs pas tout à fait tort.

    Il reste qu’en une recherche simple sur Google, on tombe sur des archives zip qu’il suffit de faire manger à Calibre pour d’un coup pouvoir impor­ter et conver­tir les fichiers proté­gés de manière trans­pa­rente. C’est d’une simpli­cité telle que je me vois même plus faci­le­ment expliquer comme cracker le DRM que d’ex­pliquer comment gérer sa biblio­thèque avec les DRM.

    La musique a fini par aban­don­ner ces systèmes, on ne peut qu’es­pé­rer la même chose pour l’édi­tion. Entre temps je cherche des argu­ments pour accé­lé­rer la suite.

  • Le web ouvert recule

    On se garga­rise de HTML 5 ou CSS 3, on idéa­lise Wiki­pe­dia et Crea­tive Commons, mais côté web ouvert soyons clairs : Nous recu­lons, et à marche forcée. Ça devient d’au­tant plus préoc­cu­pant que même les plus geeks ne font plus que des décla­ra­tions de prin­cipe sur le sujet, sans le soute­nir par des actions et réali­sa­tions.

    En quelques jours DailyMo­tion aban­donne OpenID, Google lance Google+ et TweetDeck aban­donne son support pour StatusNet. Même les projets libres ne font plus que le mini­mum syndi­cal de ce côté là. C’est une tendance de fond, sous prétexte de simpli­fi­ca­tion de l’ex­pé­rience utili­sa­teur.

    Ce n’est pas un problème de geek

    Je ne suis pas d’ac­cord avec ceux qui prétendent que c’est un problème de geek. Ces préoc­cu­pa­tions sont déjà à l’es­prit des utili­sa­teurs « non experts » :

    • Suis-je obligé de rester si je ne veux pas perdre mes données, mon adresse ou mes connexions ?
    • Puis-je commu­niquer avec des personnes sur des services tiers ?
    • Pourquoi ai-je besoin de gérer 15 iden­ti­fiants avec des mots de passe diffé­rents ?
    • C’est quand même gênant que ce site en sache autant sur moi, non ?
    • Non, ça ne me plait pas mais bon, je n’ai pas le choix, si ?

    Parlez en autour de vous, vous verrez que la plupart des gens ont bien ces problèmes à l’es­prit. Certains ont même déjà des expé­riences doulou­reuses de chan­ge­ment d’adresse (email du FAI), de commu­niquer avec des rela­tions qui sont sur deux plate­formes diffé­rentes et incom­pa­tibles, ou de migra­tion de données.

    Le tout c’est de ne pas abor­der l’angle tech­nique, qui lui effec­ti­ve­ment n’in­té­resse que le geek. Décen­tra­lisé ? c’est quoi qu’est-ce ?

    Diaspora ? Jabber ? StatusNet ? aucun inté­rêt

    Si rien n’avance, c’est que ce que nous propo­sons en alter­na­tive n’a que peu d’in­té­rêt. En propo­sant un remplaçant décen­tra­lisé à Face­book ou à MSN ce qu’on propose c’est de réali­ser main­te­nant et volon­tai­re­ment l’apo­ca­lypse dont on cherche à se proté­ger pour plus tard : perte des données, de son adresse, de ses rela­tions, et des inter­ac­tions avec le reste du monde.

    C’est même encore moins inté­res­sant puisque les services alter­na­tifs sont souvent moins abou­tis et n’au­ront d’in­té­rêt que si on réus­sit aussi à faire migrer toutes ses rela­tions (et qu’elles aussi y réus­sissent), ce qui n’ar­ri­vera pas.

    Même ceux qui n’ont pas encore de compte, donc pas de donnée ou d’adresse à perdre, n’ont pas vrai­ment le choix : Ils sont contraints par le choix des autres, sauf à rester seuls dans leur coin.

    Autant dire que les gens sensés préfèrent attendre que le pire arrive, quitte à ce que ça revienne au même. Ceux qui migrent le font par idéo­lo­gie ou par convic­tion, pas pour des raisons pratiques et prag­ma­tiques.

    Gérer son iden­tité

    Il nous faut pour­tant avan­cer et pour cela nous avons deux options : Créer le nouveau service ultime qui accueillera tous les utili­sa­teurs, en le faisant « bien » selon nos critères de liberté, de contrôle de son iden­ti­fiant, de vie privée, etc. ou s’oc­cu­per de la brique fonda­men­tale qui nous pose problème : la gestion d’iden­tité.

    J’ai besoin d’une brique pour gérer ce qui suit :

    • Annon­cer et prou­ver mon iden­tité
    • Présen­ter des infor­ma­tions diffé­rentes en fonc­tion de mon inter­lo­cu­teur
    • Accé­der aux infor­ma­tions que les autres me partagent
    • Délé­guer un service à un tiers tout en gardant le contrôle sur mon iden­ti­fiant
    • Avoir un iden­ti­fiant simple, mémo­ri­sable et mani­pu­lable par tous

    Si j’ai ça ensuite on pourra bran­cher des services unitaires dessus sans avoir à rempla­cer Face­book en entier.

    Du mieux

    Mais surtout, pour que ça fonc­tionne, il faut présen­ter mieux que l’exis­tant. Nous devons avoir un plus fonc­tion­nel immé­diat à propo­ser. Cet inté­rêt ne doit pas être simple­ment un inté­rêt tech­nique ou à long terme.

  • Bon chas­seur et mauvais chas­seur : archi­tec­tures et données person­nelles

    Pour proté­ger les données des utili­sa­teurs il y a des bonnes archi­tec­tures et des mauvaises archi­tec­tures.

    C’est aussi simple que cela. Ne vous lais­sez pas dire que tous les systèmes sont faillibles, qu’il y a de bonnes raisons, ou que ce n’est pas impor­tant. C’est vrai, mais il reste que votre archi­tec­ture peut être bonne ou mauvaise. Ça aura un impact un jour ou l’autre, plus rapi­de­ment que vous ne l’es­pé­rez.

    Stocker en clair c’est mal

    Des gens meilleurs que vous s’y sont lais­sés prendre. Des socié­tés solides se sont faites avoir. Y compris des gens qui avaient de bonnes raisons tech­niques ou fonc­tion­nelles de faire ainsi.

    Rien ne change, si vous stockez les mots de passe en clair (ou de façon déchif­frable), un jour une faille logi­cielle ou système y donnera accès et vous aurez un gros problème avec vos utili­sa­teurs.

    Dans le meilleur des cas vous serez préve­nus rapi­de­ment et vous aurez juste une très mauvaise publi­cité comme Sony récem­ment, avec le risque de perdre la confiance de tous vos clients. Dans le pire… vous ne le remarquez que trop tard et vous pouvez mettre la clef sous la porte avec des problèmes juri­diques, finan­ciers et humains insol­vables.

    Ne pas utili­ser SSL / TLS pour les commu­ni­ca­tions réseau c’est mal

    Des gens meilleurs que vous s’y sont lais­sés prendre. Des socié­tés plus solides se sont faites avoir. Ai-je besoin de tout répé­ter ?

    Si vous ne chif­frez pas toutes les commu­ni­ca­tions réseau avec vos clients dès que vous trans­fé­rez des données sensibles, vous prenez un risque impor­tant pour la sécu­rité des dites données. Chif­frer unique­ment la phase d’au­then­ti­fi­ca­tion ne suffit pas, quoi qu’on vous dise.

    Vos utili­sa­teurs ont besoin d’une connexion sécu­ri­sée. Tout le reste n’est que bidouillage et mauvaise archi­tec­ture. Tôt ou tard il y aura un abus d’un état, d’un FAI, d’une entre­prise, d’une école, qui aura un peu de publi­cité et qui vous posera un problème impor­tant.

    Chif­frer avec la clef de déchif­frage sur le serveur c’est mal

    Non, je ne vais pas me répé­ter encore une fois, si ce n’est pour dire que vous n’êtes pas un cas spécial.

    Chif­frer et déchif­frer sur le serveur en lais­sant la clef sur place, c’est comme avoir une porte blin­dée avec serrure trois points et lais­ser la clef sous le pot de fleur à côté. Pour faire court, si c’est le serveur qui chiffre, déchiffre, et gère la clef, c’est comme si vos données étaient en clair, ou presque.

    Drop­box avait fait de la publi­cité autour de la sécu­rité de leur service. Ils avaient une unique clef de chif­frage, sur leur serveur. Les utili­sa­teurs ont râlé, fait de la mauvaise publi­cité, et même porté plainte. D’au­cuns ont dit que ce n’était pas impor­tant.

    Voilà hier qu’un problème tiers a donné accès pendant quatre heures à toutes les données de tout le monde, sans mot de passe. Ça ne serait pas arrivé si chaque client gérait sa propre clef, sans la parta­ger avec Drop­box.

    Les râleurs n’avaient pas de boule de cris­tal, ce qui est arrivé était évident. On savait que ça arri­ve­rait, et on peut dire que les consé­quences ont été les extra­or­di­nai­re­ment faibles par rapport aux risques. La prochaine fois ce sera bien plus gênant.

    Quelle que soit la raison, une mauvaise archi­tec­ture reste mauvaise

    Il se peut qu’on soit obligé d’uti­li­ser une mauvaise archi­tec­ture. Il se peut que cette mauvaise archi­tec­ture soit un compro­mis accep­table, ou même souhai­table en fonc­tion de besoin spéci­fiques.

    C’est rare, tout le monde a tendance à se penser dans le cas excep­tion­nel alors que ce n’est pas le cas, mais ça peut arri­ver. Mais, même dans ce cas, il ne faut pas perdre de vue que ça reste une mauvaise archi­tec­ture, et qu’on en subira les consé­quences.

    Il y a des bonnes et des mauvaises archi­tec­tures, c’est ainsi. Faites ce que vous pensez le mieux, il se peut que vous ayez de bonnes raisons de choi­sir la mauvaise archi­tec­ture (même s’il y a toutes les chances que vous fassiez erreur). Mais quelles que soient ces raisons, elles ne trans­for­me­ront pas votre mauvaise archi­tec­ture en « bonne » archi­tec­ture. Vous venez de choi­sir une mauvaise archi­tec­ture pour de bonnes raisons, voilà tout. Et vous allez le payer.