🚲 Tanguy Ortolo a écrit 12224 commentaires

Il ne faut pas utiliser de pseudo nom de domaine imaginaire lorsqu'on veut donner un exemple : truc.tld, mondomaine.com, moi.domain, toutes ces horreurs sont à proscrire à cause du risque de collision avec un nom de domaine qui pourrait exister.

À la place, il faut utiliser les noms de domaines standards réservés pour cet usage : example.com, example.org, example.net, example.edu, ainsi que les pseudo-noms de domaines de niveau supérieur example, invalid et test.

Je ne vois pas Mozilla dans la liste des auteurs de cette lettre. Savez-vous s'ils ont été contactés, ou s'ils s'en fichent ?

La vidéo ne serait pas disponible sous un format librement lisible par hasard ?

À ce que je vois, il s'agit d'URI de type URL. Est-ce vraiment pertinent ? Tout comme les schémas news, mid et magnet, cela me semble un mésusage des URL pour ce qui devrait être des URN…

Cela répond au problème de faire transiter le mot de passe en clair, ce qui est la question de ce fil.

Oui, ça y répond, c'est même une des deux solutions que j'ai indiquées, à savoir : la mauvaise, où le mot de passe est stocké en clair sur le serveur.

donc non, pas besoin de transferer un mot de passe en clair, ou d'équivalent au mot de passe.

Si. Dans l'exemple que tu donnes, le mot de passe en question, stocké en clair côté serveur, c'est la clef HMAC.

Dynamique, je sais ce que ça veut dire, une liste aussi je sais ce que c'est, SPF je connais, mais qu'est-ce que c'est qu'une liste SPF ?

Qu'est-ce que c'était que ce truc au juste ?

Je prends les devants avant qu'on ne me réplique qu'avec l'identification Digest de SIP, le mot de passe n'est pas stocké en clair : c'est techniquement exact mais ce qui est stocké, qui est un hachage du mot de passe et d'une information de domaine, est suffisant pour s'identifier, et constitue donc le mot de passe réel.

À noter que, pour pouvoir ne stocker qu'un hachage du mot de passe sur un serveur, il faut que ce mot de passe soit transmis en clair au code de vérification lors des tentatives d'identification. Ce problème peut être résolu de deux façons :

• une bonne : sécuriser l'étape d'identification avec une couche de chiffrement comme TLS ;
• une mauvaise : passer à un système d'identification par défi-réponse, qui implique… de stocker le mot de passe en clair sur le serveur !

À noter qu'au moins un protocole, SIP, interdit « pour raisons de sécurité » les identifications par mot de passe simple, et propose à la place, toujours « pour raisons de sécurité » une identification par défi-réponse…

Personnellement, je me fiche de la loi lorsqu'elle contrevient à la morale. Cette application précise du droit est immorale, et je ne vois aucune raison de la respecter. Je paie pour avoir le droit de faire des copies privées, j'en fait, point. La morale est supérieure à la loi.

Effectivement : payer pour avoir le droit de l'enregistrer ce flim loué en VàD, je l'ai fait en achetant mon disque dur.

Mais sinon, pour info, ton ensemble n'est pas libre, vu que ton BIOS n'est pas libre non plus.

Ça n'a rien à voir : un logiciel libre, obtenu à partir de code libre uniquement, peut être exécuté sur n'importe quel ordinateur prenant en charge le jeu d'instruction visé. Cet ordinateur peut être libre ou non, ça n'affecte en rien le binaire utilisé.

Ca tombe bien, un navigateur est un logiciel, pas l'ensemble.

Et ce logiciel, libre donc, provenant d'un code libre uniquement (et donc pas d'une clef secrète que l'utilisateur n'a pas), il peut ou il ne peut pas décoder du verrouillé ?

Ce qui fournit la fonctionnalité de lecture, donc qui décode la vidéo à l'aide d'une clef fournie par un composant tiers non libre, ce n'est pas le logiciel libre. C'est le binaire résultant de la compilation d'un logiciel libre, puis de la signature par une clef secrète. Et les sources d'un tel binaire, c'est l'ensemble du code source du logiciel d'origine et de la clef secrète : si la clef secrète n'est pas libre, l'ensemble n'est pas libre.

Ben surtout qu'on paie pour avoir le droit d'enregistrer hein.

Ben si le décodage n'est pas fait par un logiciel libre, c'est un plugin.

Bon, c'est de l'ordre du plugin ça. Pas grand chose de différent avec la situation actuelle avec Flash, question liberté.

Il y a autre chose : les DRM font principalement chier les utilisateurs, mais aussi les distributeurs, parce que ça leur coûte et que ça complique la distribution, en étant par exemple plus ou moins compatible avec les différentes plate-formes existantes. Du coup, la distribution sans DRM a un avantage concurrentiel.

Avec une normalisation par le W3C, les DRM seraient nettement moins coûteux pour les distributeurs, ce qui est à éviter à tout prix. Les DRM doivent coûter un maximum aux distributeurs, et dans l'idéal ce coût devrait devenir rédhibitoire.

Un logiciel qui ne fonctionne plus s'il a été modifié, je regrette mais ce n'est pas libre.

Est-ce vraiment un tatouage ? On voit parfois des messages d'erreur au démarrage (invalid boot sector) qui ne sont pas dus à un verrouillage, mais simplement à la merdicité du BIOS, qui refuse de démarrer les disques durs qui n'ont pas une partition marquée active.

Incompatible avec toutes les définitions du logiciel libre surtout : ce n'est pas libre, c'est tout.

et ne sera sans doute jamais dans les nagivateurs libre comme chromium ou firefox

Tu peux enlever le « sans doute » : un système de verrouillage efficace ne peut pas être mise en œuvre dans un logiciel libre : soit il n'est pas libre, soit il n'est plus efficace.

Il devait penser à un système GNU/Linux

Possible, mais dans ce cas il faut le préciser. Linux, c'est un noyau, et c'est justement celui qui est utilisé par Android.

Il semble que l'on assiste à la disparition lente de SilverLight. Cette technologie créée par Microsoft ne s'est pas exportée sous Linux et surtout Android.

Rectification : cette technologie ne s'est pas exportée sous Linux, notamment Android.

Copier cent fois : Android est un système Linux.