🚲 Tanguy Ortolo a écrit 12355 commentaires

Tu oublies tout simplement les gens qui ont acheté pour se loger puis ont un taf ailleurs, doivent vendre et acheter ensuite, mais dont le crédit courra toujours sur la somme initiale, donc grosse perte financière par rapport à la location initiale, et donc surface en moins en pratique (dommage hein).

Aucune perte ici. Une dépense initiale plus importante que celle qui aurait pu avoir lieu s'ils avaient acheté plus tard, ce qui est le premier cas que j'ai identifié.

Bah, si l'idée qu'il ne faut pas acheter pouvait se répandre et provoquer un bon vieux krach immobilier, ça ne pourrait faire que du bien :

• les gens qui ont acheté une maison pour y vivre n'y perdraient rien puisque s'ils y vivent, ils n'ont pas à la vendre et son prix ne leur change strictement rien (ils peuvent être dégoûtés d'avoir acheté avant le krach, mais ça n'a aucune conséquence pratique) ;
• les gens qui ont acheté pour stocker de l'argent y perdraient, mais ce n'est pas grave parce que de l'argent dans un coffre, même si ce coffre a une forme de maison, ne sert à rien et ne manque à personne s'il disparaît ;
• les gens qui ont acheté pour spéculer y perdraient, mais c'est une bonne chose parce que détourner la fonction normale de l'immobilier (loger des gens) pour en faire un support de spéculation, c'est mal ;
• les gens qui cherchent à acheter pour se loger y gagneraient, ce qui est une excellente chose parce que c'est quand même le but normal de l'immobilier ;
• les gens qui ont acheté pour se loger mais compte déménager n'y gagneraient ni n'y perdraient rien si les prix s'effondrent partout (moins cher vendu, mais maison suivante moins cher achetée).

Et bien figurez-vous que la réponse est…

Vu la façon dont tu poses la question, je m'attendais à une réponse intéressante. Sauf qu'en fait non.

(à quand OpenWrt vodka-pomme ?) ;-)

Pfiou, ça devient un truc de riche, OpenWrt, avec ce dernier cocktail, il faut acheter plein d'ingrédient, les précédents étaient plus simples, avec des ingrédients plus communs :

• Backfire : crème de whiskey, liqueur de café et vodka ;
• White Russian : liqueur de café, vodka et crème.

Quoi qu'il en soit : santé !

Non, seulement du Web.

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.