🚲 Tanguy Ortolo a écrit 12091 commentaires

En les buttant ?

C'est marrant, pour moi c'est encore un exemple où la plèbe éteint son cerveau dès qu'elle est face à un écran, et accepte sans réfléchir donc des choses qui serait inadmissibles sous une forme matérielle. Je ne sais pas trop ce qu'on peut faire contre ça, à part éduquer laborieusement les gens.

Ce n'est pas ce que j'appelle prendre en charge les commentaires ça. C'est comme si tu disais que ton dernier modèle de voiture roule au GPL, à condition d'ajouter un réservoir et un commutateur pour cela : désolé mais ça ne s'appelle pas une voiture au GPL ça.

Autrement, si on va par là, Linux est un excellent moteur de blog, avec beaucoup de fonctionnalités, il suffit d'y installer un système GNU, un serveur Web prenant en charge le PHP, puis Wordpress…

Je confirme, tu as fait ton site avec Pelican, et il ne prend pas en charge les commentaires. Pelican ne prend pas en charge les commentaires, j'entends. Ton site les prend en charge, à condition toutefois d'activer JavaScript, mais pas avec Pelican.

Pelican est un générateur de blog entièrement statique, Microbe est un site dynamique. Du coup, en pratique, un blog Pelican peut être généré chez soi et hébergé sur un serveur Web statique, là où Microbe a besoin d'un serveur d'application Python. En revanche, Pelican ne prend pas en charge les commentaires, alors que Microbe si.

Ah, enfin un moteur de bloc conçu sur un système simple — le système de fichiers — et prenant en charge les commentaires !

Ça manque toutefois d'une démo, je trouve.

Je sais. Comme on peut le voir, c'est loin d'être clair, mais cette pratique est minoritaire et largement critiquée, ce qui montre bien que c'est loin d'être un impératif moral évident.

La moralite dit que tu doit respecter le choix de distribution de l'ayant droit. Point a la ligne.

Non, de la même façon, cela n'est absolument pas une évidence morale, mais une conséquence secondaire d'un système conçu — ou censé être conçu — pour répondre à certains impératifs moraux.

La première façon de montrer cela, c'est en remarquant que cette contrainte, en ce qui concerne les droits patrimoniaux, est limitée dans le temps, et prend fin 70 ans après la mort de l'auteur : si la morale impliquait de respecter la volonté de l'auteur en matière de droits patrimoniaux, cela devrait être illimité, ce qui serait vu comme une tyrannie parce qu'incompatible avec le domaine public.

Une seconde façon de montrer cela consiste à remarquer que dans d'autres domaines, une telle contrainte — respecter la volonté de l'auteur — est parfaitement inexistante et serait vue comme inacceptable. Par exemple, dans le domaine des monuments, il serait intolérable qu'un architecte interdise toute photographie. Ce serait pourtant la volonté de l'auteur de ce qui peut être vu comme une œuvre d'art, mais rien n'impose que cette volonté doive s'appliquer pour n'importe quoi.

Concernant les violations de GPL, je tiens à rappeler que cette licence a été conçue comme un palliatif à au système de droit d'auteur, jugé néfaste, et utilise volontairement ce système pour en tirer le meilleur parti possible, pour le bien des utilisateurs avant celui de l'auteur. C'est pourquoi, contrairement au cas présent de visionnement illicite d'une émission indisponible autrement, qui ne nuit à personne, une violation de GPL nuit aux utilisateurs, à qui est dénié ce qui leur revient de droit.

Je ne vois vraiment pas le rapport, mais la réponse est évidemment non.

Je me place du point de vue de la moralité pour examiner le devoir de respect du droit d'auteur. Le système de droit d'auteur n'est pas une évidence morale. Le respect aux artistes, le droit de vivre de son travail utile, oui, mais le système pratique actuel du droit d'auteur non : ce n'est pas la notion de morale qui a directement inspiré la contrainte d'autorisation préalable pour toute utilisation d'une œuvre pendant toute la vie de son auteur et 70 ans après sa mort, il s'agit là d'un système complexe conçu — ou prétendument conçu — pour être au service du bien. Ce système n'est pas le seul candidat pour cela, il y en a d'autres qui ont leurs avantages et leurs inconvénients.

Donc, ceci étant posé, on a un point d'application précis, à savoir : est-il bien, mal ou indifférent d'utiliser un réseau clandestin pour violer le droit d'auteur afin de regarder une émission qui n'est pas diffusée ici ? Il y a probablement d'autres façons de raisonner que la mienne, mais personnellement, je regarde la différence de résultat entre les différentes alternatives :

• si on ne regarde pas l'émission de façon illicite : les auteurs et distributeurs officiels ne touchent pas un rond de la part du spectateur potentiel, et celui-ci ne profite pas de cette émission ;
• si on regarde l'émission de façon illicite : les auteurs et distributeurs officiels ne touchent pas un rond de la part du spectateur potentiel, et celui-ci profite de cette émission ;
• si on regarde l'émission de façon licite : cette possibilité n'existe pas.

Du côté des auteurs et distributeurs officiels, il n'y a aucune différence entre les deux situations. Pour le spectateur, la seconde est préférable. Celle-ci n'ayant aucune autre conséquence que de participer au bien-être du spectateur, elle est préférable tout court et rien ne s'oppose, moralement parlant, à la choisir.

Dans le domaine du respect du monopole temporaire sur l'information, la rigidité est soluble dans les attaques à répétition contre les spectateurs honnêtes. En clair, les industriels du divertissement de masse sont très forts pour transformer de guerre lasse un spectateur honnête et scrupuleux en contrefacteur sans vergogne.

Bon, je crois que je viens de comprendre. Le départ de l'attaque n'est pas ce que je pensais : ici, le client se connecte volontairement à l'attaquant, qui ne dissimule pas son identité, par exemple parce qu'il fournit un service particulier, sans savoir que celui-ci va tenter une attaque.

Ensuite ou en parallèle, l'attaquant se connecte à un serveur dont le client est également utilisateur.

Enfin, l'attaquant bidouille ses deux connexions — avec le client et avec le serveur attaqué — de façon à obtenir une situation où il peut se faire passer pour le client auprès du serveur.

C'est ce que j'appelle la corruption d'une autorité de certification : l'amener, quel que soit le moyen, à émettre un certificat pour un nom différent du sien propre. Et non, ce n'est pas forcément très difficile, mais là encore, il s'agit d'une faille qui n'a rien de spécifique avec le cas de la triple poignée de main donc on parle ici.

Je ne pense pas qu'il faille chercher à comprendre : le monde du monopole temporaire sur les œuvres audiovisuelles a ses raisons que la raison ignore.

Il n'y a à ma connaissance que deux réponses raisonnables à ces délires : cesser de les regarder, ou les regarder par des moyens clandestins. La première solution est la plus dommageable, pour le spectateurs — qui ne profite plus de ces œuvres — et pour l'exploitant — dont la publicité n'est plus regardée —, le second n'est dommageable pour personne et revient en pratique à la situation précédente, dans ce cas où la publicité est incluse dans les vidéos en question.

Non, je dois vraiment avoir loupé quelque chose, parce que ce que je lis de l'explication a l'air très clair : le client se connecte à l'attaquant en pensant qu'il s'agit du serveur, et celui-ci lui fournit son propre certificat à la place de celui du serveur. Il s'agit là du scénario le plus classique de MiTM, qui est irréalisable avec une utilisation normale de TLS, et qui nécessite soit la corruption d'une autorité de certification soit une négligence grave de la part de l'utilisateur.

Je n'ai pas la moindre idée de ce que c'est que Comedy Central, Colvert Report et John Stewart, mais il s'agit visiblement de vidéos : franchement, quand l'offre légale ne marche pas, pourquoi se prendre la tête à essayer de contourner leurs conneries, quand tout ça est disponible sur le réseau clandestin qui lui, fonctionne à merveille ?

Moralement, on ne peut pas reprocher à quelqu'un de ne pas acheter ce qu'on refuse de lui vendre, ou de ne pas regarder la publicité qu'on refuse de lui montrer… La contrefaçon ne retirer jamais rien à personne, mais peut parfois créer un manque à gagner, or dans ce cas, il n'y a justement aucun manque à gagner, donc pas de scrupules à avoir.

Super, donc en gros il faut que l'utilisateur se connecte sans faire exprès à un site qui ressemble disons, à celui de sa banque, mais qui n'a pas le même nom, et qu'il se comporte comme si c'était vraiment le site de sa banque ? Dans ce cas, la faille principale exploitée n'est pas dans le client, ni dans le serveur, mais entre la chaise et le clavier.

Ce n'est pas évident à vérifier, parce que les cookies qu'ils placent sont codés (nom et valeur d'une seule lettre ou chiffre), mais j'espère que c'est documenté, en tout cas à mon avis ils utilisent ces cookies pour cela seulement : stocker les préférences choisies par l'utilisateur.

Vu l'étape 1, cette faille n'est vraiment pas problématique :

1. Le client demande la connexion : il envoie des données aléatoires (que l’on appelera ici CR pour Client Random) qui serviront à établir le master secret ainsi que la liste des algorithmes qu’il connait.
2. L’attaquant reçoit le CR et le transmet au serveur, mais en indiquant qu’il ne connait que RSA (ou DHE, mais cela ne semble pas fonctionner avec ECDHE).
3. Le serveur envoie à l’attaquant le SR (pour Server Random) et le SID (identifiant de session) qui serviront eux aussi à la construction du master secret, et indique qu’il utilise RSA. Ce message est transmis sans modification au client.
4. Le serveur envoie son certificat à l’attaquant et l’attaquant transmet son certificat au client.

Notez cette dernière sous-étape : à ce moment-là, le client s'aperçoit que le certificat ne correspond pas au nom du serveur auquel il essaie de se connecter, détecte donc une possible attaque MiTM, et abandonne la connexion.

Cette attaque ne peut donc se faire que dans un des cas suivants :

• corruption d'une autorité de certification, pour que le pirate puisse obtenir un certificat reconnu pour le nom du serveur ;
• négligence du client, qui accepte de se connecter sans vérifier le certificat du serveur.

Bref, c'est une faille qui semble simplement aggraver un cas classique d'attaque MiTM.

Mon dieu mais quel aigris tu fais !

Ah bon ? Je n'ai pas écrit ma remarque précédente — il faut des cookies pour ça — comme un reproche, mais comme une précision, rien de plus…

Évidemment il faut accepter les cookies pour ça.

C'est comme ça que je procéderais. Éditer les fichiers login et gdm3 ou lightdm pour en retirer l'inclusion de common-auth.

C'est marrant, ça rejoint un test à la con que j'avais fait, et avec lequel, à l'époque, Google donnait des résultats pitoyables sur les noms de personnes, et où DuckDuckGo l'enfonçait complètement.

Dans ce cas tu ne devrais pas être content que la page de résultats de DuckDuckGo prenne de la place pour afficher une barre qui ne sert que si tu veux faire une nouvelle recherche, ce que tu pouvais déjà faire en 1. remontant en haut de la page ou 2. retournant à la zone de recherche de ton navigateur.

Ce n'est pas du tout une évidence, il pourrait y avoir un bouton dessiné à côté de la barre de navigation par exemple, ou un geste à effectuer sur l'écran, ou un bouton physique pour cela…

sauf que dans la pratique si j'avais du systématiquement dû relancer mes requêtes dans un autre moteur, je n'aurais pas continué à utiliser ddg.

Évidemment, mais lorsqu'il s'agit d'une petite partie des recherches, c'est parfait.

je suis un grand fan de la zone dédiée à la recherche mais il me semble que les navigateurs sans zone dédiée permettent de changer de moteur dans la zone d'url. midori le permet en tous les cas.

Oui, mais si le contenu de cette zone a été remplacé par l'URL, il faut saisir à nouveau sa recherche.

je trouve personnellement que google est rarement plus pertinent que ddg. quand je ne trouve pas quelque chose sur ddg je tente la recherche sur google et c'est rare que je trouve mieux.

Ça, c'est tout l'intérêt d'une zone dédiée à la recherche et distincte de la zone d'URL : on peut très rapidement relancer la même requête avec un autre moteur de recherche. Cela facilite largement l'adoption d'un nouveau moteur de recherche : on ne passe pas à DuckDuckGo de façon traumatique, on se met à l'utiliser sans nécessairement abandonner ce qu'on utilisait avant.