Un autre journal bookmark:
Kim Dotcom nous refait le coup mais cette fois depuis la Nouvelle Zélande, au soir du samedi 19 janvier, 18h48 !
Le service est pour l'instant plus présenté comme un stockage dans le cloud (comme Dropbox, Drive et cetera) mais avec un stockage de 50 GB à partir d'un compte gratuit. L'interface est simple et va droit au but, plutôt plaisant. Il n'y aurait pas d'option streaming proposé pour l'instant pour des raisons de sécurité à en croire la FAQ. Le site est difficilement accessible pour le moment, si vous n'arrivez pas y accéder, c'est normal pour un début !
Tiens la sécurité, parlons en, au cœur de cette nouvelle relance:
"MEGA est un acronyme récursif et signifie "MEGA Encrypted Global Access"".
C'est fiable tout ça ?
Mega:
https://mega.co.nz/
La FAQ:
https://mega.co.nz/#help_basics
# Oubli
Posté par znk . Évalué à 5.
Voilà ce qui est dit dans leur page "Sécurité & Protection" avec une faute à phishing en plus:
[^] # Re: Oubli
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Est-ce sérieux, crédible, toussa… http://www.undernews.fr/forum/telechargement-ddl-p2p/mega-xssed ?
[^] # Re: Oubli
Posté par Firwen (site web personnel) . Évalué à 1. Dernière modification le 20 janvier 2013 à 12:21.
La couche sécurité meme si elle a l'air sérieuse est pour le moins un poil mensongère.
Les clés sont stockés serveur side… certes elles sont "garanties" comme stockées chiffrées et déchiffrables uniquement grâce au mot de passe de l'utilisateur… mais rien ne garantie que c'est effectivement le cas…
Et même si c'est le cas, un accés au serveur permettrait théoriquement de mettre la main sur toutes les données des sessions connectées à cet instant.
[^] # Re: Oubli
Posté par jigso . Évalué à 10.
Si vous voulez continuer à utiliser MEGA, vous devez le faire par le biais d'une application client qui a été écrit par une personne dont vous avez confiance.
Voilà, enfin, on y vient : la seule vraie sécurité, c'est quand le code est libre, cad qu'on peut l'étudier, et surtout l'éditer et le recompiler pour l'utiliser en lieu et place des binaires fournis par le prestataire. Bien sûr il restera toujours des failles, - un code malveillant peut-être présent sous une forme obfusqué, les algos utilisés présentent peut-être des failles voulues ou non - mais ça limite énormément le pouvoir de nuisance.
Et donc oui, le combat extrémiste de la FSF pour le tout libre en rejetant le pragmatisme de l'utilisateur est tout a fait justifié.
[^] # Re: Oubli
Posté par Gabin II . Évalué à 5.
Malheureusement, ce n'est pas une vérité absolue, encore faut-il avoir les compétences d'analyser le code et quid d'un developpeur libre qui pète un cable et décide d'injecter de la malice dans son code?
GCC, tes pilotes de cartes réseau, OpenSSL, etc…
La sécurité reste avant tout basé sur une relation de confiance.
[^] # Re: Oubli
Posté par jigso . Évalué à 6.
La confiance n'exclue pas le contrôle.
[^] # Re: Oubli
Posté par Maclag . Évalué à 3.
Oui mais c'est là où on atteint les limites théoriques:
Exemple: je ne suis pas développeur, je ne suis pas capable d'analyser du code source.
Par contre, je suis riche et j'ai besoin d'une application assez sécurisée:
Je vais donc envoyer le code à faire développer à un développeur A, et à faire contrôler par un développeur B.
Comment je sais que B est vraiment capable d'auditer le code de A?
Comment je sais si B et A ne sont pas déjà de mèche et on trouvé un moyen de se mettre d'accord?
Comment je sais si A ne fait pas une connerie que B n'a pas vu passer?
Je ne peux pas, à moins de trouver un interlocuteur C, qui ne fait que réduire la proba que ça se passe mal.
Du coup, le commentaire auquel tu réponds est toujours valide: la compétence de l'utilisateur final pour auditer le code source est le seul gage de confiance absolu pour une appli peu répandue chez les gens compétents!!
Pour nous autres, malheureux, nous souhaiterions avoir les stats sur le client préféré des développeurs compétents et paranoïaques…
[^] # Re: Oubli
Posté par Octabrain . Évalué à 2.
"Du coup, le commentaire auquel tu réponds est toujours valide: la compétence de l'utilisateur final pour auditer le code source est le seul gage de confiance absolu pour une appli peu répandue chez les gens compétents!!"
s/peu répandue chez les gens compétents//, car qui te dit que c'est le même code qui tourne chez les "gens compétents" et chez les "non-compétents" ? De toute façon, avec une appli web qui peut changer à tout moment, tu es bien plus limité dans ton audit.
[^] # Re: Oubli
Posté par jigso . Évalué à 7.
Oui mais dans tous les cas le contrôle n'est vraiment possible que si le code est libre, c'était le sens de mon message. A partir du moment où le code est fermé, on est au niveau zéro de la sécurité. Bien sûr qu'il faut de toute façon accorder sa confiance à quelqu'un à un moment, mais on peut s'en remettre à l'intelligence collective pour considérer que les failles seront détectées et corrigées tôt ou tard. Et si on considère que même dans ce cas on ne peut faire confiance au système, on éteint la machine et on part sur une île déserte.
[^] # Re: Oubli
Posté par windu.2b . Évalué à 4.
Remplace 'code' par 'élection' et 'développeur' par 'citoyen', et tu retombes sur un cas très connu : un citoyen ne peut pas vérifier tous les bureaux de vote. Il doit donc faire confiance à tous les autres citoyens de son pays, qui, eux aussi, doivent faire confiance aux autres.
[^] # Re: Oubli
Posté par vlamy (site web personnel) . Évalué à 2.
Je crois que jigso parlait de confiance collective, en référence à l'hébergement de projets libres de grande réputation tels que Kernel, GNU, Apache, …etc. Ton analogie avec les élections vise un autre problème il me semble, celle de la chaine de confiance, qui vise à établir cette réputation. Il y a pas mal de gens qui font confiance au httpd d'Apache il me semble, et je ne pense pas qu'ils aient tord. C'est pas si facile que ça de mettre du code malicieux dans des projets libres bien organisés (déjà que contribuer c'est souvent chaud !), et encore plus s'ils sont populaires, puisque tout le monde veut et peut y contribuer.
Un autre aspect : du moment que l'auteur est authentifié, l'engagement est plus sérieux puisqu'il va contribuer à sa réputation (pour reprendre les termes théoriques utilisés en matière de sécurité). Quand tu publies du code libre, ou plus simplement un commentaire sur DLFP, beaucoup de gens peuvent le consulter (y compris anonymement) et le nom de l'auteur y est bien souvent attaché (avec plus ou moins de contrôle dessus, je vous l'accorde). Cet engagement incite à faire attention à ce que l'on publie, la plus légère des peines étant le désintérêt pour le code publié. Mais à l'inverse, si un développeur Kernel s'amuse à glisser une faille dans le code du noyau Linux et que (fatalement) on s'en aperçoit un jours, je ne donne pas cher de sa peau, ou du moins de sa réputation.
Par exemple, si on ne devait pas être authentifié dur DLFP pour poster un commentaire, il y aurait plus de conneries écrites.
Heu… à moins que…. je me trompe.
[^] # Re: Oubli
Posté par fearan . Évalué à 6.
facile tu publie le code et offre une récompense de 10k€ au premier qui publie un craque sur le code ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Oubli
Posté par Zylabon . Évalué à 4.
Si c'est chiffré sur la machine du client, qu'est-ce que ça change pour eux ? De plus, l'openssl sur mon raspberry pi chiffre à 8.4Mo/s en aes-128 et 7.3Mo en aes-256. Je trouve l'argument étrange étant donné qu'il repose sur les défauts d'une implémentation (qui sera corrigé sous peu j'imagine).
Please do not feed the trolls
[^] # Re: Oubli
Posté par Tonton Benoit . Évalué à 4.
Remplace openssl par une bibliothèque en JavaScript comme Mega et refait le test :D
Comme tu le dit c'est le CPU de l'utilisateur donc ils s'en foutent, ils ont donc du choisir l'algo et la taille de clé suivant ce qui reste acceptable en terme de performance et ne freeze/plante pas le navigateur d'une config moyenne de 2013.
# commentaire bookmark
Posté par bubar🦥 (site web personnel) . Évalué à 5. Dernière modification le 20 janvier 2013 à 10:49.
http://www.pcinpact.com/dossier/630-mega-le-dossier/2.htm
Ce que je retiens du très bon dossier de pcinpact :
Le point sur les reprises possibles me semble tout particulièrement intéressant…
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 9.
Ca doit faire plus de 30 ans que FTP le fait
[^] # Re: commentaire bookmark
Posté par bubar🦥 (site web personnel) . Évalué à 6.
Oui, merci le ouhaib …
Je ne connais pas un service de ce type (dl.free, hostingfile, multi, etc etc etc) qui permette ce service pourtant basique. Sur dl.free.fr par exemple une seule coupure de 20s suffit à "cloturer la session" : aucune possibilité de reprise, il faut recommencer.
merci le ouhaib…
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 1.
Oué et ca me les brise pas mal. Du coup je viens d'embarquer un serveur ftp dans mon projet. Un service d'upload en FTP et partage du fichier en bittorrent, ca éclate n'importe quelle archi web moisie à la mega.
[^] # Re: commentaire bookmark
Posté par oinkoink_daotter . Évalué à 2.
Et sinon, les chevilles, ça va ?
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 3.
Elles vont bien. Tu n'as pas compris, je comparais une architecture centralisé en web + protocole HTTP et une architecture décentralisé + protocole bittorrent. Cette dernière est à mon avis hautement plus scalable et adapté au partage de fichier que la première.
[^] # Re: commentaire bookmark
Posté par Sufflope (site web personnel) . Évalué à 2.
Ah oui OK d'accord.
[^] # Re: commentaire bookmark
Posté par fravashyo (site web personnel) . Évalué à 1.
en tout cas un outil comme jdownloader permet de faire une reprise chez 90% des hébergeurs.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: commentaire bookmark
Posté par coïn . Évalué à 7.
FTP, c'est bien le protocole non crypté qui peut faire transiter les mots de passes en clair, qui passe mal les proxy et qui dans 99% des installations ne gère pas la reprise ?
Désolé, mais le FTP est juste pas une option sur le web d'aujourd'hui.
PS: oui, je sais qu'on peut rustiner le ftp dans tous les sens pour essayer de le faire ressembler à un protocole moderne mais une brouette avec des jantes alu, ca reste une brouette :)
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 9.
En mode passif ça résout pas mal de problème et tu peux encapsuler FTP dans une socket SSL. FTP est une option très crédible pour Internet, mais si tu résume Internet au web ….
[^] # Re: commentaire bookmark
Posté par Firwen (site web personnel) . Évalué à 6.
FTP est un des rare protocole fichier qui a été conçu pour faire des transfers third party proprement et donc de la réplication inter-serveur, rien que pour ça.. il n'est pas prêt de mourir crois moi.
[^] # Re: commentaire bookmark
Posté par coïn . Évalué à 0.
dans le genre réplication, rsync est bien plus performant que FTP.
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 7.
Rsync me parait beaucoup plus compliqué à mettre en oeuvre pour un intérêt qui reste à démontrer quand on veut juste uploader des fichiers.
Pour développer mon client natif qui utilise FTP je n'ai eu qu'à utiliser cette classe QFtp. Et coté serveur FTP la gestion des users, quotas, droits d'accès, resume, sont natifs. Perso j'ai embarqué mon propre serveur FTP dans un thread en utilisant la classe cftpserver.
[^] # Re: commentaire bookmark
Posté par coïn . Évalué à 1.
rsync a au moins le bon goût de vérifier l'intégrité des fichiers avec des checksums, ce que ne permet pas le FTP. Pour les reprises, c'est quand même pratique, et ca évite les corruptions.
Après, que le FTP soit simple a programmer, en Quick and Dirty, ca parait logique. C'est un protocole simple, voir simpliste.
Sinon, pour info, il existe http://librsync.sourceforge.net/ jamais essayé.
On a bien eu la peau de telnet, il est temps d'envisager de laisser mourir FTP
[^] # Re: commentaire bookmark
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 8.
Simple, le FTP ? Mmmmm, gérer les deux canaux, le texte|binaire, le passif|actif, ça commence vite à tourner à l'usinagaz, je trouve.
[^] # Re: commentaire bookmark
Posté par Firwen (site web personnel) . Évalué à 2.
rsync ne supporte pas non plus le third party copy….
[^] # Re: commentaire bookmark
Posté par rakoo (site web personnel) . Évalué à 2.
J'vais peut-être poser une question bête, mais qu'est-ce que tu entends par third-party copy ?
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 20 janvier 2013 à 18:38.
Je pense qu'il parle de FXP.
Tu as deux sites distants que tu veux synchroniser l'un à partir de l'autre? Pas d'accès SSH à aucun des sites? Ta connexion chez toi est merdique et impossible de l'utiliser comme intermédiaire? FTP "classique" ne pourra pas te servir, mais FXP qui n'est qu'un cas de transfert FTP poussé jusqu'à ses retranchements va beaucoup te servir…
Note : FXP pouvant être exploité pour te faire chier si tu l'autorises à tout le monde sur tout les serveurs, les commandes FTP adéquates sont très souvent interdites sur un serveur "normal" n'en ayant pas besoin, mais si tu es pote avec l'admin tu peux.
[^] # Re: commentaire bookmark
Posté par rakoo (site web personnel) . Évalué à 0. Dernière modification le 20 janvier 2013 à 22:11.
Ah je vois. Il s'agit donc de passer outre la nature profondément centralisée de FTP pour faire des échanges entre deux serveurs distants. Ça me fait d'ailleurs penser à Murder, la solution de chez Twitter qui utilise un protocole d'hommes et une stratégie intelligente pour le transfert de données entre différents serveurs distants : Bittorrent. Je pense qu'il y a moyen de s'en servir astucieusement.
[^] # Re: commentaire bookmark
Posté par coïn . Évalué à 0.
Sur la page wikipedia, il est écrit :
Encore un trou dans la chaussette
[^] # Re: commentaire bookmark
Posté par Firwen (site web personnel) . Évalué à 5.
C'est bien cela Zenit, même si ça m'emmerde d’être d'accord avec toi juste par principe :D
Mais l'interet ne réside pas dans le fait de marcher si ta connexion est merdique, si tu vis en sibérie ou si ton admin réseau est un nazi.
Le principal intérêt est de pouvoir faire un grand nombre de mouvements rapides de gros fichiers entre serveurs qui ont une grosse bande passante, et ce sans surcharger le client, c'est trés TRES utilisé en environnent Grid.
Il y a autant de trous dans FTP que dans HTTP qui lui aussi fait ses auth en clair d'ailleurs….
Les problèmes de sécus s'évaporent simplement quand tu ajoutes la couche SSL/TLS, tout comme HTTP d'ailleurs…
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 8.
FTPS (avec une couche SSL) comme pour HTTP(S).
Mode passif.
Ce ne sont pas des rustines, c'est une évolution normale du protocole.
Au pire, si tu n'aimes vraiment pas FTP(S), il reste SFTP.
Je sais pas où tu traînes, mais 99% des serveurs auxquels j'ai eu affaire gèrent la reprise (sauf quand la reprise est volontairement interdite par l'admin, mais c'est une fonctionnalité voulue dans ce cas).
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 2.
Je suis pas sûr que SFTP gère la reprise par contre, mais bon comme tu dis FTPS fait le boulot.
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 3.
Comme pour FTP, il y a quelques surprises avec les vieux serveurs pour les reprises sur un fichier supérieur à 2 Go ou 4 Go, mais même le SFTP de CentOS 5 (donc de 2007) le gère très bien (ou alors mes fichiers se reprennent par la main de Dieu :) ).
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 2.
Il faut peut être activer une option dans la conf du serveur ssh, parce que de base j'ai testé sur un serveur ubuntu et le resume se faisait pas.
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 2.
Les « gens du web » ne connaissent pas le modèle OSI et ont tendance à tout faire passer dans du HTTP. Evitons de faire la même chose avec SSH.
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 3.
Théorie vs pratique.
TCP/IP a déjà suffisamment démontré que le modèle OSI avait des petits problèmes, et SSH a suffisamment montré sa compétence, je me permet de l'utiliser pour pas mal de choses (accès aux machines, tunnel, VPN, transfert de fichiers, rsync…) jusqu'à ce que tu me proposes des méthodes meilleures en pratique.
Bon, j'avoue hésiter encore entre SFTP et FTPS (deux modèles de sécurité différents, clé vs certificat) mais bien pour des raisons pratiques.
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 2.
Heu ? De quoi tu parles au juste ?
Oui, moi aussi, tout comme je me sers de HTTP pour beaucoup de chose. C’est pas pour autant que je trouve que c’est une bonne idée ?
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 2.
De quelle idée tu parles ? Si c'est d'encapsuler SFTP ou FTP dans HTTP, personne ne l'a émit il me semble. Pour ma part je parle d'upload FTP avec un client natif (ce qui ne veut pas dire obligatoirement un client FTP natif).
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 1.
Je parle d’encapsuler FTP dans SSH. Ça revient strictement au même que d’encapsuler FTP dans HTTP.
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 20 janvier 2013 à 15:29.
Ouch, qu'est-ce qu'il ne faut pas lire.
"SFTP" (SSH File Transfer Protocol) dont tout le monde parle aujourd'hui (SSH-2 ce n'est pas nouveau!) à part quelques "vieux" qui bidouillaient à une époque n'a rien à voir avec "Secure FTP" aka "FTP over SSH" Secure File Transfer Protocol. Je n'ai donc jamais parlé d'un FTP encapsulé dans SSH (on n'est pas en 2000, on est en 2012).
Ca n'a strictement rien à voir avec un quelconque FTP dans HTTP.
NB : Et même si tu parlais de FTP over SSH, ça n'a pas grand chose à voir non plus, FTP étant la couche applicative, et SSH la couche de sécurité, alors que FTP et HTTP sont tous les deux une couche applicative. Ce n'est pas parce que OSI ne met pas une couche "sécurité" qu'on ne peut pas en mettre une en pratique. On pourrait plutôt aussi mettre HTTP dans SSH pour rester dans la même idée que FTP dans SSH, mais certainement pas un truc FTP dans HTTP (imaginable pour passer les firewall certes, pas beau mais potentiellement utile, mais à ce niveau je taperai plutôt un FTP dans HTTPS pour avoir la sécurité en plus, je ne suis plus à ça près après avoir mis du SSH dans HTTPS pour passer le firewall de la boite. bref, pas beau ok, mais utile et c'est ce qui compte contre toutes les théories "évitons de").
[^] # Re: commentaire bookmark
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Ratai (tm)
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 2.
Oh la honte, l'âge me guette aussi… :)
[^] # Re: commentaire bookmark
Posté par 2PetitsVerres . Évalué à 7.
Il a juste commencé à compter les années à partir de 0, comme tout informaticien normalement constitué.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 0.
Mes mots étaient mal choisi, je parlais bien d’utiliser SSH pour faire du FTP.
Idem, je parlais d’utiliser HTTP pour faire l’équivalent de ce qu’on fait en FTP.
Elle n’existe pas la couche « sécurité ». SSH, SFTP, FTP, HTTP c’est couche 7, point.
[^] # Re: commentaire bookmark
Posté par Batchyx . Évalué à 4.
SSH2 est une couche de transport avec sécurité intégrée qui propose plusieurs applications multipléxées, dont la plus utilisée est le shell à distance. On peut le comparer avec avec un SCTP (Stream Control Transmission Protocol) sécurisé avec des applications intégrées.
Mettre SSH2 dans la couche 7 c'est un peu fort, ça ne se contente pas d'être que sur cette couche. En fait, c'est plutôt le genre de protocole à casser le modèle OSI en trois après qu'IP l'ai cassé en deux.
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 0.
SSH2 c’est de l’applicatif. Le transport c’est TCP.
Quelqu’un serait capable d’argumenté sur ce point ? Parce que là, j’ai toujours pas eu d’explication.
[^] # Re: commentaire bookmark
Posté par fredix . Évalué à 2.
TCP/IP n'implémente que 4 couches sur les 7 du modèle OSI.
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 1.
Et il pourrit allègrement les 4 qui restent (lien de démonstration déjà fourni, "j’ai toujours pas eu d’explication" fait sourire).
Il y a vraiment encore des gens pour parler de "couches" comme des couches OSI (parfaites, donc autonomes) avec TCP/IP? on parle de couches pour simplifier l'explication, mais c'est tout! J'attends de voir fonctionner TCPv4 sur IPv6… Si c'était des couches, on pourrait, mais on ne peut pas (ce qui pour moi est un défaut de conception, mais bon, c'est comme ça, il faut vivre avec).
TCP/IP (et tous les protocoles au dessus) est ce qu'il y a de pire en modélisation, mais voila : il est la, il marche. Théorie vs pratique, la pratique est la et pourrit la gueule des théoriticiens dans leur bureau. Vivement un théoriticien qui arrivera à faire un truc utilisable! :)
[^] # Re: commentaire bookmark
Posté par Kaane . Évalué à 3.
mais c'est tout! J'attends de voir fonctionner TCPv4 sur IPv6
Alors
1°) il existe des centaines de versions de TCP (avec du retry plus ou moins aggressif) mais à ma connaissance aucune qui s'appelle TCPv4.
2°) La couche TCP est la couche TCP. Elle est tout à fait adaptée à tout un tas de protocoles. Elle est extrèmement flexible et bien conçue. Son seul défaut est qu'il n'existe pas de RFC permettant de changer le mode de calcul de checksum suivant les besoins. C'est un défaut mineur, il suffit de mettre les infos significatives au bon endroit dans les paquets pour que ca passe. (A part les mecs qui ont écrits cette daube d'IPv6 tout le monde y arrive)
3°) Par contre IP (v4 ou v6) c'est une veritable horreur. IPv4 a été écrit sans tenir compte du mode de routage (qui du coup est assuré au petit bonheur la chance en couche 2,3 ou 4 suivant les cas ou l'age du capitaine) et IPv6 a été écrit en ne tenant compte QUE du mode de routage (Il suffit juste de changer l'ensemble de tout le matériel au niveau monde, de réécrire tous les kernels et toutes les applis et ça marche presque - enfin à part qu'on ne peut plus déclarer les ports avec ":" et que l'overhead explose littéralement).
Donc merci de ne pas cracher sur TCP qui n'a pas grand chose à se reprocher (par contre IP et principalement IPv6 vous pouvez y aller).
[^] # Re: commentaire bookmark
Posté par barmic . Évalué à 2.
Tiens je n'y avais jamais pensé, comment on fait pour les url ?
Comment on traduit http://1.2.3.4:8080/ en ipv6 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: commentaire bookmark
Posté par Anonyme . Évalué à 3.
[::ffff:1.2.3.4]:8080 ?
[^] # Re: commentaire bookmark
Posté par MrLapinot (site web personnel) . Évalué à 5.
Avec des crochets : http://[::ffff:1.2.3.4]:8080/
Source : RFC 3986, section 3.2.2.
PS : et évidemment, linuxfr ne parse pas l'url automatiquement !
[^] # Re: commentaire bookmark
Posté par Kaane . Évalué à 4. Dernière modification le 21 janvier 2013 à 18:11.
Comment on traduit http://1.2.3.4:8080/ en ipv6 ?
Ca, ça va c'est facile. La question drole c'est comment on passe un tableau de chemins smb windows sur un port custom en IPv6 ? Genre
[smb://1.2.1.3:8080\C$\toto][smb://1.2.1.3:8080\D$\tutu][smb://1.2.1.3:8080\D$\tata]
[^] # Re: commentaire bookmark
Posté par Zenitram (site web personnel) . Évalué à 4.
Désolé, mais quand un protocole calcule des choses sur des octets pas de sa couche (au hasard : l'en-tête IPv4), il y a un truc à se reprocher, et c'est bien ça que j'appelle "TCPv4" dans le sens où TCP est dépendant de sa couche inférieure, c'est lui qui le dit, "pas de changement dans le calcul du CRC possible" ou pas (ça devraitêtre formélement interdit de sortir de sa couche!). Tout format d'octet est sensé ne pas être dépendant de sa couche inférieure! Et c'est un reproche. TCP n'aurait jamais dû avoir à être adapté à un autre protocole, dire "TCP c'est si IPv4 bla bla et si IPv6 bla bla différent", c'est une mauvaise conception (non respect des couches, ce qui oblige à changer suivant la couche inférieure. Donc si on met TCP sur tartampion, hop on doit changer TCP, ridicule).
Certes, c'est "pas grand chose", mais c'est un reproche quand même, et une démonstration d'un mauvais design : un packet TCP ne devrait pas être modifié suivant quelle couche inférieure est utilisé (ça doit être transparent). On évitera de parler du protocole qui balance un autre protocole si il a envie, hein…
PS : ça ne change pas le fait que c'est le "moins pire" des protocoles, et il marche, lui, pour de vrai, contrairement aux théorie. Le fait de reconnaitre sa supériorité ne devrait toutefois pas te faire dire qu'il n'a pas grand chose à se reprocher pour cacher se défaut : il a des choses à se reproche, c'est tout, sans haine.
[^] # Re: commentaire bookmark
Posté par Kaane . Évalué à 5.
Désolé, mais quand un protocole calcule des choses sur des octets pas de sa couche (au hasard : l'en-tête IPv4)
Ca va être compliqué de valider la cohérence d'un paquet sans le lire. Il est obligatoire pour TCP de lire les octets sur la couche qu'il controle - Si le but de TCP était simplement de garantir que la capsule TCP elle même est valide ca serait plus simple (mais vachement moins interressant). Donc TCP doit lire les infos de la couche inférieure pour faire un CRC dessus, c'est la seule manière de la controller.
et c'est bien ça que j'appelle "TCPv4" dans le sens où TCP est dépendant de sa couche inférieure
Il n'est pas dépendant de la couche inférieure. Certes les octets sous jacents choisis pour le controle l'ont été avec IP en tête, mais rien n'empêche de faire passer d'autres flux en controle TCP (pour que ca serve à quelque chose il faut juste que les octets en question soient relativement significatifs de l'état du paquet. En IPv6 ca n'est pas le cas - et c'est une connerie dans la façon dont l'entête IPv6 a été créée).
On évitera de parler du protocole qui balance un autre protocole si il a envie, hein…
Tu peux m'expliquer ce que fout ICMP à signifier que la connexion est injoignable ? C'est une couche transport ICMP ? Ca te semble logique comme comportement que si le port existe TCP renvoit un ACK, mais que si il n'existe pas c'est ICMP qui renvoit un bricolage plus ou moins fiable en fonction du modèle du routeur, de l'OS du serveur et du sens du vent ? Je cherche à établir une connexion IP et au moment de la négo TCP c'est un message ICMP qui m'est renvoyé ? Le plus logique serait que je me prenne un TCP RST systématiquement et que si je veux vraiment savoir ce qui se passe, libre à moi de balancer des paquets ARP ou ICMP.
[^] # Re: commentaire bookmark
Posté par Spack . Évalué à 5.
Le niveau 7 est la nouvelle couche de transport. Y'a qu'à voir HTTP…
--> []
[^] # Re: commentaire bookmark
Posté par Batchyx . Évalué à 6.
Chez moi, un protocole de transport, c'est :
Et que fait la couche transport de SSH ? (RFC4253: The Secure Shell Transport Layer Protocol, ça ne s'invente pas)
Enfin bref, SSH2 sur TCP, c'est empiler un protocole de transport sur un protocole de transport. Et j'ai même pas encore parlé des applications qui tournent dessus. Surtout celle qui consiste à faire passer un flux TCP. C'est tellement marrant, IP qui fait du datagrame, TCP qui en fait un flux, SSH qui fait des datagrammes, qui transporte une application qui travaille en flux … Manquerai plus que du HTTP au dessus pour transporter un message ;)
Tu le fait un peu exprès quand même. Bon, je vais t'aider un peu:
Faut se rendre à l'évidence : le modèle OSI est mort sur internet. Il ne reste plus qu'à appeler les choses par ce qu'elles sont.
[^] # Re: commentaire bookmark
Posté par SamG . Évalué à 1.
Sûrement que le modèle TCP/IP est différent du modèle OSI : http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI#Le_monde_IP_et_le_mod.C3.A8le_OSI
[^] # Re: commentaire bookmark
Posté par Spack . Évalué à 3.
Un certificat, c'est juste une clé (publique) enrobée de chocolat. Le modèle de sécurité est globalement similaire, cryptographie par paire de clés privés/publiques pour faire transiter une clé de chiffrement symétrique.
Ce qui diffère, ce sont les protocoles : FTPS c'est du bon vieux FTP caché dans SSL, SFTP est une extension de SSH. Étant deux protocoles distincts, ils peuvent en effet ne pas être vulnérables aux même attaques.
# Mafia
Posté par pamputt . Évalué à 10.
Euh, il n'y a que moi à ne pas voir Mega comme un sauveur ? Pour ceux qui ne comprendrait pas, on parle quand même d'un service mafieux. Alors oui certes le mec à une grande gueule mais au final il se fait de l'argent sur du contenu protégé par le droit d'auteur. On pense ce qu'on veut du droit d'auteur et on peut s'asseoir dessus mais dans ce cas, utilisez des solutions qui n'enrichissent aucun intermédiaire (mafieux) au passage : eMule, Bittorrent, …
[^] # Re: Mafia
Posté par rakoo (site web personnel) . Évalué à 4.
C'est vrai en pratique mais est-ce que tu n'es pas en train de condamner l'intermédiaire ? Mega/Megaupload ne sont que des outils, de la même manière que le couteau n'est qu'un outil. Les pirates rabâchent pourtant bien suffisamment qu'il ne faut pas condamner l'outil mais bien son utilisateur.
Après tout, le FAI aussi se fait du beurre sur le transfert interdit de contenu protégé. Est-ce qu'on le condamne ? Bon, on me dit que Megaupload servait essentiellement à ça et est donc intentionnellement en marge de la légalité, alors que le FAI sert aussi à autre chose (ie. il fait passer tous les contenus). Mais si on regarde bien, le nouveau Mega ne rémunère pas les utilisateurs en fonction du nombre de téléchargements de leurs fichiers, on peut espérer que les méthodes mafieuses sont finies.
Tiens d'ailleurs c'est bien que Mega ne facilite pas autant le DDL qu'avant, peut-être que les gens arrêteront d'utiliser HTTP pour disséminer du contenu.
[^] # Re: Mafia
Posté par barmic . Évalué à 5.
Amesys n'est pas responsable de ce que les gouvernement font de leurs solutions ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par coïn . Évalué à 1.
Renault est-il responsable des morts sur la route ?
Amesys vend des solutions de cyber-surveillance, mais n'est pas responsable du fait que le kadafi a utilisé ces systèmes pour traquer et détruire des opposants. Sauf à prouver que Amesys a eu connaissance de la destination. C'est exactement ce qui était reproché à Megaupload, "avoir connaissance d'utilisation frauduleuse de leur outil, sans réagir".
C'est hors sujet, mais la France est un très gros exportateur d'armement (3 à 5ème leader, ça dépend des années), et on ne va pas venir pleurer parce que nos clients se servent de leurs armes pour tuer, ça serait hypocrite.
[^] # Re: Mafia
Posté par Zenitram (site web personnel) . Évalué à 2.
Parce que les gens ne sont pas hypocrites? ;-)
[^] # Re: Mafia
Posté par flagos . Évalué à 9.
Comment Amesys pouvait ne pas le savoir ? Quand tu vends des outils de surveillance de la population a un type comme khadafi, tu sais pertinemment a quoi ca sert derrière.
[^] # Re: Mafia
Posté par barmic . Évalué à 3.
Comme Kim pouvait ne pas savoir que MU était utilisé pour l'échange de fichiers illégalement ? Même les média grands publiques en parlaient.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par Kytrix . Évalué à 0.
Justement Kim prétendais le contraire, Or ils (lui et ses collaborateurs) se sont fait épingler car ils disposaient d'un moteur de recherche sur les fichiers hébergés et ils s'en servaient pour regarder des contenus illicites.
"Tiens quels sont les fichiers les plus téléchargés aujourd'hui ?"
"Est ce qu'un gentil utilisateur a uploadé le dernier films de bidule en UHD?"
Là avec Mega ils se protège du mieux qu'ils peuvent et leur service ressemble à presque n'importe quel service de stockage.
Reste à voir si certains s'en servirons pour du partage de contenu illégal.
[^] # Re: Mafia
Posté par fredix . Évalué à 5.
La plupart des trackers bittorrent privés demandent des "dons" et ca ne sert que très peu à partager des ISO Linux … Donc ou tous les outils de partage de fichiers sont illégaux ou ce ne sont que des outils. Mais il ne peut pas y avoir 2 poids 2 mesures.
[^] # Re: Mafia
Posté par Firwen (site web personnel) . Évalué à 1.
On est d'accord, mais il est for probable que le tapage médiatique entourant mega ( c'est passé en boucle sur la BBC auj .. ) remettent la question du financement des artistes et du piratage le devant de la scène.
C'est en quelque sorte un mal pour un bien, let's see
[^] # Re: Mafia
Posté par MTux . Évalué à -3.
Je ne crois pas que cela ait été prouvé.
D'ailleurs je me souviens que les contenus "illégaux" étaient rapidement supprimés.
Par ailleurs je suis choqué de voir toutes les insultes que se prend ce type de la part des gens, alors que tout le monde profitait abondamment de Megaupload. Donc on est contents de pouvoir partager gratuitement des choses, mais quand le service se fait fermer c'est "bien fait pour eux de toutes façons ils gagnaient de l'argent". Oui, une entreprise qui gagne de l'argent c'est toujours mal vu.
Certes mais ce ne sont pas toujours les plus pratiques ou les plus rapides.
[^] # Re: Mafia
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Je ne pensais pas qu'il existait des gens capables de soutenir la thèse suivant laquelle le succès de Megaupload n'est pas dû à la contrefaçon.
C'est quand même franchement culotté.
Peut-être que l'ensemble de ceux qui critiquent Kim Dotcom ne se confond pas totalement avec l'ensemble de ceux qui profitaient de ses services ?
Peut-être également que le fait d'avoir profité du service n'empêche de donner son avis quand même ?
Autre débat, rien à voir ici.
[^] # Re: Mafia
Posté par rakoo (site web personnel) . Évalué à 2.
Ça dépend. Si on mesure sur un seul utilisateur, tu as raison. Si on prend l'ensemble des intéressés comme base de travail, je doute qu'un protocole de P2P quelconque se fasse devancer par du HTTP. Du coup le choix entre P2P et DDL devient presque un choix social : est-ce que je ne pense qu'à ma gueule, ou est-ce que je pense aussi aux autres (et aux fournisseurs de tuyaux en passant). Alors, t'est de quel côté ? =]
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 3.
Une solution de direct download, au débit bridé pour ceux qui ne sont pas inscrits, limité à 1 téléchargement par IP, qui passe par un site web bourré de javascript avec un minuteur débile et un captcha à la con, avec des pubs de partout, et où les packages sont remplacés par des archives, le plus souvent dans un format fermé avec tous les inconvénients que cela procure, tu trouves que c'est « pratique » et « rapide » ? Oo
Quitte à faire du direct download, autant le faire façon old school, en récupérant des fichiers sur les ftp persos disséminés çà et là sur le net. Au moins on peut scripter, il y a une grande variété de sources, on utiliser des proxys, etc.
(Mais rien ne vaut le pair-à-pair).
[^] # Re: Mafia
Posté par brendel . Évalué à 1.
Certes mais les gros fichiers tu vas avoir du mal à les trouver sur des FTP disséminé ça et là. Le truc c'est que les gens qui utilisaient beaucoup Megaupload utilisais Jdownloader, qui te vire tous les inconvénients que tu as cité. D’ailleurs, si MegaUpload a gardé tout du long les captcha les plus simple du web, c'est pas pour rien. En gros, tu donnes à Jdownloader un gros copier coller de texte avec des liens au milieu, il identifie les lien megaupload (ou autres site ressemblants), télécharge le tout en te résolvant les captcha, et si ce que tu veux télécharger était en plusieurs parties rar (cas classique), il te le décompresse. En plus, je crois bien qu'il existe une version en ligne de commande, donc c'est scriptable :p.
[^] # Re: Mafia
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu es trop jeune, sans doute.
Jdownloader n'a rien inventé, il existe exactement la même chose pour FTP et Usenet.
[^] # Re: Mafia
Posté par brendel . Évalué à 1.
Pour Usenet, pas besoin d'être vieux, c'était encore très utilisé il y a quelques années (je ne sais pas aujourd'hui). Pour FTP, j'avoue que j'ai jamais vu de sites regroupant des liens de fichier "contrefaits" sur des FTP :) Avec la taille des fichiers actuels (sauf musiques), ça devient dur de trouver un particulier qui a assez de place ou/et bande passante.
Sinon, oui Jdownloader n'a rien inventé, c'est juste une interface plus sympa que le site pour télécharger sur megaupload et consort.
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 2.
Le débit n'est pas bridé ? Le téléchargement n'est pas limité à un fichier à la fois par IP ? Les packages ne sont pas compressés ?
Cas horrible. Déjà c'est un format fermé (on n'a pas inventé un format ouvert et plus performant il y a une dizaine d'années ?), ensuite, soit il s'agit de petits fichiers, et dans ce cas ça rassemble plusieurs fichiers en un (tu ne peux pas sélectionner ceux que tu télécharges), soit il s'agit de gros fichiers, et dans ce cas l'archive est découpée en plusieurs petits bouts. Sans parler du fait que la plupart du temps les gros fichiers sont des vidéos déjà fortement compressées, et pour lesquelles une compression supplémentaire n'apporte rien.
Bref, MafiaUpload et ses confrères, c'était vraiment le cumul de tous les inconvénients du direct download et de l'archivage, sans en avoir les avantages.
[^] # Re: Mafia
Posté par brendel . Évalué à 0.
Ben l’intérêt de megaupload c'est justement que y'avais un très bon débit même sans être inscrit. Cela dit c'est vrai les gens qui téléchargeaient beaucoup dessus avaient un compte. Ce qui est dommage (c'est mieu de donner cet argent aux artistes, mais impossible pour l'instant).
C'est claire, le seul intérêt étaient de découper pour passer la limite de taille megaupload. Mais bon y'a des outils qui découpent sans se taper la phase de compression. Mais c'est pour ça que je précisais que Jdownloader te corrige cet inconvénient : au final tu as le fichier recomposé, tu n'a même pas vu qu'il était en rar découpé.
Dans tous les cas, je suis d'accord avec toi hein : le DDL sur MU c'est enrichir des gens (pas prouvé que c'est des mafia si?) au lieu des artistes. Et si je télécharge de la contrefaçon, je préfère utiliser bittorent (j’enrichis pas plus les artistes, je sais). Je disais juste que il y avait moyen de se passer des inconvénients que du coup megaupload devenait le moyen le plus pratique et des fois le plus rapide d'obtenir des fichiers contrefaits.
[^] # Re: Mafia
Posté par Juke (site web personnel) . Évalué à 0.
Pourquoi ?
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 1. Dernière modification le 21 janvier 2013 à 15:44.
Mouais enfin si on commence à parler des copies d'œuvres non partageables, la situation est simple : il y en a qui achètent des galettes en plastique et enrichissent la MAFIAA, et il y a ceux qui vont chercher des copies sur les serveurs de DDL et qui enrichissent une mafia. C'est bonnet blanc et blanc bonnet. La seule différence c'est que la première est légale et la deuxième est illégale. Apparemment le côté illégal séduit bien plus les gens, quand bien même les deux camps commettraient les mêmes horreurs.
(À noter que certaines majors auraient touché des revenus indirectement via la pub présente sur MegaUpload. Alors les tipiaks du dimanche qui disaient « Je ne donnerai jamais un centime à la MAFIAA » et qui s'empiffraient sur MegaUpload, ils me font bien marrer.)
Tu plaisantes, là ? Kim Schmitz, c'est la petite mafia allemande. Il a un dossier assez rempli. Escroqueries, détournement de fonds, délits d'initié, évasions fiscales… Il a mis le pied dans à peu près toutes les magouilles qui étaient à sa portée. Sans parler de ses péripéties de fou du volant.
C'est dommage que tu ne mettes pas les artistes dans le même panier que « les gens ». Tu penses que les artistes massivement téléchargés ne sont pas des gens de la même espèce que ceux avec qui ils ont signé ? Tu n'a pas vu ces artistes à succès, dans un incomparable élan de démagogie, montrer leur tronche à tous les passants dans la MegaUpload song, vendant leur cul pour Kim Dotcom après l'avoir vendu pour la RIAA ? Violant un contrat avec une mafia pour aller collaborer avec une autre qui paye mieux, tout en tentant de nous faire croire qu'ils font ça par altruisme et par respect du public ?
Tu as vraiment envie de les soutenir, ces artistes qui se soumettent au système, et sont incapables de l'assumer ?
Ces démagos ne valent pas mieux que des Lars Ulrich ou des Gene Simmons, ce qui n'est pas peu dire.
[^] # Re: Mafia
Posté par Tit . Évalué à 2.
Pas trop compris ta diatribe, c'est quoi, c'est qui la MAFIAA? dans
[^] # Re: Mafia
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
MAFIAA est un terme parodique regroupant les pratiques douteuses de la MPAA et la RIAA.
[^] # Re: Mafia
Posté par Tit . Évalué à 3.
Merci
[^] # Re: Mafia
Posté par barmic . Évalué à 2.
Il ne faut tout de même pas mettre tout dans le même panier. Quand tu achète un disque (ou une musique sur un site de téléchargement légale), ce n'est ni la MPAA, ni la RIAA, ni la SACEM que tu paie. Tu commence par payer le revendeur et la maison de disque. Ensuite oui il y a une taxe de ces « protecteurs d'artistes », mais il existe une part (petite je ne le nie pas) qui va dans la poche du ou des artistes. De plus même si le Kevin moyen n'est pas content c'est l'artiste qui a fait le choix avec qui il traite. Ces 2 points : le fait que ce soit choisi par l'artiste et qu'il ai une petite rétribution direct, font tout de même une très grande différence (sans remettre en cause le problème des maisons de disque (il ne faut pas les oublier) et des {MP,RI}AA et SACEM).
C'est un peu n'importe quoi. Quand je vais chez ma boulangère acheter le pain, je donne une partie à la SACEM vu qu'elle achète ses disques de Johny Haliday.
Je pense qu'il y a une faute ce sont « ces » gens en particulier qui sont visés.
J'ai tout de même l'impression que tu t'excite un peu pour rien, il dis la même chose que toi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 1.
Ce que ta boulangère fait avec cet argent, tu n'es pas censé le savoir. On peut au moins t'accorder le bénéfice du doute (à moins que ta boulangère ait des posters "Vive Johnny - Vive la SACEM" partout dans la boulangerie, là tu fais ce que tu veux mais moi je changerais de boulangerie). En revanche fermer les yeux sur un accord entre deux entreprises, juste parce qu'on n'a pas envie de faire l'effort d'aller voir ailleurs, c'est complètement irresponsable.
[^] # Re: Mafia
Posté par barmic . Évalué à 2.
Dans l'absolue, tu serais pour faire une enquête de moralité avant de choisir à qui tu achète tel ou tel chose ?
À titre personnel je n'ai jamais eu à me détourner de MU, n'y étant jamais allé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 2.
Oui. Maintenir une liste d'entreprises à éviter, suivant ce qu'on sait d'elles, et quand on utilise un produit ou un service, vérifier si aucune entreprise de la liste n'est impliquée dans ce produit ou ce service. Bon, je ne le fais pas pour le moindre taille-crayon, mais pour le matériel informatique, par exemple, j'essaie de m'y tenir.
C'est super simple quand on achète du matériel sur Internet, on n'a pas à chercher bien loin pour trouver l'info, mais pour le reste, c'est pas toujours aussi simple. Mon rêve ce serait un monde où Claude Michu passe son smartphone devant le code-barres d'un produit avant de l'acheter, et le smartphone se connecterait à une base de donnée crowdsourcée qui lui indiquerait qui est l'entreprise qui est derrière ce produit, qui sont ses actionnaires, avec qui elle collabore, comment elle agit sur le plan écologique, politique, comment sont traités ses employés, est-ce que la description du produit est juste ou est-ce qu'elle est mensongère, etc.
Peut-être que la "main invisible du marché" prendrait alors plus de sens que dans un monde où les principaux critères de choix d'un produit sont le prix et la nimage sur l'emballage.
[^] # Re: Mafia
Posté par barmic . Évalué à 2.
Il ne reste qu'à définir ce qui est bon ou pas et/ou qui est habilité à le définir. Par définition moi ça me plaît pas. J'aime pas qu'on me dise ce qui est bien ou pas, c'est le genre de truc qui par toujours de traviole (on fini par ne plus rien filtrer car les règles sont trop larges, des fois par nécessité (aucune entreprise du secteur ne permet respect ses règles (ça ferrait mal en informatique de demander que les constructeurs respect un minimum leur employés))).
Tu connais du matériel informatique qui ne soit pas fabriqué dans des condition plus ou moins déplorables ?
Non elle ne prendra jamais le moindre sens. Ce que ferais ton système c'est juste d'assainir éventuellement le marché et encore ils trouveraient un moyen de contournement (tu arrête ton analyse au revendeur ou tu va jusqu'aux sous-traitant ?).
Note : dans la plupart des cas je fais un peu attention, mais affirmer globaliser cela n'est pas réaliste. De plus je laisse une grande marge de manœuvre. Pour reprendre l'exemple de la boulangère, elle fait et écoute ce qu'elle veut (et met les posters qu'elle souhaite dans sa boutique), je ne vois pas en quoi ça me regarde (tant que les dis posters son légaux). L'utilisation systématique de produits que je n'apprécie par contre m'intéresse et influence mon choix.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 1.
Ça c'est toi qui le fait. Je ne dis pas qu'il faut donner à tout le monde une liste maintenue par une autorité centrale qui a la Connaissance du Bien et du Mal. Chacun maintient sa propre liste.
Par exemple, quelqu'un qui pense que c'est mal de faire tuer des ouvriers syndicalistes mettra la Coca-Cola Company sur sa liste noire. Quelqu'un qui s'en fout, non. La puissance de Coca-Cola vient du fait que hélas, ceux qui ne s'en foutent pas sont bien moins nombreux que ceux qui s'en foutent. Mais il n'y a pas là-dedans d'autorité centrale qui décide pour tout le monde.
Ça dépend des secteurs. Dans le cas de l'OpenHardware, c'est facile à trouver. Par contre, dans le cas des smartphones, non. Dans ce cas il vaut mieux choisir justement celui qui est fabriqué dans les conditions les moins déplorables.
(Notons que ceci est un gros argument en faveur de l'OpenHardware, où un même produit n'est pas limité à un nombre restreint de constructeurs.)
Disons que notre responsabilité morale diminue lorsqu'on remonte la chaîne. Quand tu achètes un iPhone ta responsabilité morale dans les pratiques d'Apple et de Foxconn est très forte. Dans le cas des pratiques des extracteurs du minerai qui sert à fabriquer les composants, elle l'est un peu moins. Quant aux pratiques du fabricant des bateaux qui servent au transport des ressources jusqu'aux usines du sous-traitant, ta responsabilité y est négligeable (mais elle existe toujours). Après, il faut tenir compte de ces priorités et savoir doser entre ce que t'offre le marché et la conservation de ta propre morale.
[^] # Re: Mafia
Posté par barmic . Évalué à 2.
L'un des problèmes c'est que tu augmente la pression sur l'image de marque et le marketing d'une manière générale des marques. Les sous-produit de Coca Cola Compagnie vont moins montrer leur appartenance à la maison mère et tu va te diriger vers des compagnies qui font pas forcément mieux, mais qui sont un peu moins grosses ou qui se cachent mieux.
Comment sont fabriqué leur composants ? Ça représente une infime partie du marché qui ne couvre pas tout les besoins en terme de volume mais aussi de besoin (pas d'écran par exemple).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par fearan . Évalué à 3.
Si elle doivent se cacher pour faire leur saloperie c'est déjà mieux, car si elle se font chopper (et c'est probable), les marques finiront par trouver plus cher de fragmenter que de respecter la dignité humaine. Et si ça diminue leur puissance de lobbying au passage c'est encore mieux (oui c'est moins frappant de dire je suis tous ces machins fragmenté que de dire je suis bu par 50% de la population ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 1.
C'est possible, mais ça risque d'être de plus en plus difficile. Qui aurait su, il y a 30 ou 40 ans, pour les syndicalistes de Coca-Cola ? Nous vivons dans un société de plus en plus connectée, ou l'information circule de plus en plus vite, et où il sera de plus en plus difficile de cacher l'information qui intéresse les gens. Sans parler de l'effet flamby accompagnant toute tentative de la faire disparaître.
[^] # Re: Mafia
Posté par barmic . Évalué à 2.
D'ailleurs tu remarque que pour l'affaire des syndicalistes, tu (et tout ceux qui sont au courant) parlent de Coca cola, mais c'est loin d'être la seule multinationale. Sans en arriver au meurtre mais tout aussi atroce les constructeurs automobiles ont tendance à muter les responsables syndicales dans le poste où on peins les taules (et c'est tout a fait un hasard si c'est justement les postes qui entrain des problèmes respiratoires).
C'est juste une bataille médiatique et les grandes compagnies ont plusieurs longueurs d'avance dans le domaine.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par Moogle . Évalué à 4.
L'info circule vite, les fausses infos aussi, et les infos pertinentes sont noyées parmi les autres. Et pas grand monde n'a le temps ou la motivation de faire un vrai travail de vérification. Tu peux lancer demain un hoax pour dire que telle entreprise massacre des chatons, par exemple, et beaucoup vont y croire.
[^] # Re: Mafia
Posté par barmic . Évalué à 3.
C'est vrai, l'augmentation du volume d'information n'a pas était synonyme d'une augmentation de sa pertinence et de sa qualité (je ne sais pas comment c'était avant).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 3. Dernière modification le 22 janvier 2013 à 16:25.
Oui, on peut dire des choses fausses comme on peut dire des choses vraies. On peut aussi infirmer des rumeurs comme on peut confirmer des faits. On peut dire la même chose qu'on disait à Jimmy Wales lors des débuts de Wikipedia : « Tout le monde peut écrire n'importe quoi, les gens vont écrire tout plein de mensonges, personne ne prendra le temps de relire et de corriger, les gens sont cons, ils ne vont jamais chercher à croiser les sources, ça va sa casser la figure ton truc. ». Et aujourd'hui, Wikipedia, plus grosse encyclopédie du monde, avec une différence de fiabilité négligeable avec Britannica et Universalis dans les enquêtes réalisées régulièrement dessus. On peut dire ce que disait Microsoft des logiciels libres : « Si tout le monde peut les modifier, ça va être plein de malwares et plein d'erreurs… », même topo. On peut dire la même chose sur les forums où les gens viennent chercher de l'aide : « Les gens qui viennent sur doctissimo vont tous mourir dans d'atroces souffrances en ingérant les mauvais médicaments, les gens qui viennent sur hardware.fr auront leurs ordis qui explosent parce qu'on leur aura donné de mauvais conseils, etc. »
Ce que nous ont montré les expériences contributives sur Internet, c'est que la société est globalement plus bienveillante que malveillante ou dans l'erreur. Il y a plus de gens pour corriger les erreurs de Wikipedia que pour le vandaliser.
Tu peux avoir une vision de l'Internet comparable à celle des politiciens d'aujourd'hui, dire que c'est le far west, une zone de non-droit, et que si on donne à tout le monde le droit de dire n'importe quoi, la majorité des gens ne va chercher qu'à répandre des mensonges, des rumeurs, des canulars ou bien va persister dans l'erreur. Je pense que si c'était vraiment le cas, personne n'utiliserait Internet pour s'informer ou s'instruire.
[^] # Re: Mafia
Posté par barmic . Évalué à 1.
Ça c'est un fait. Ici même wikipedia est considérée comme une source apparentière alors que ce sont les sources de wikipedia qui devraient l'être.
La majorité peut être pas, mais combien de personnes se sont fait faussement bronsonisé sur twitter ? J'ai des exemples d'articles du 20h de France2 qui se basaient sur des boutades de journaliste de sites de jeux vidéos.
Donc sur des articles qui possèdent déjà beaucoup de ressources sur Internet. Si on regarde des articles qu'on ne trouve pas dans les autres encyclopédies alors on verra une chute probablement sensible de la qualité.
Je ne remet pas en cause les biens faits de Wikipedia. Je dis juste qu'ils ne faut pas se voiler la face. S'ils sont bons c'est aussi parce que les autres n'étaient pas parfait.
Il y a aussi des bots très efficaces.
Mais prend d'autres exemples comme les sites comparatifs ou les sites pour trouver des hôtels. Tu verra que les entreprises sont capables de se livrer des guerres assez importantes avec des moyens efficaces.
Rien avoir avec internet ça existait déjà avant. C'est juste dommage de croire en une sorte de « main invisible » qui va rétablir la vérité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par gnuzer (site web personnel) . Évalué à 1.
Il y a des bots qui corrigent, il y a des bots qui vandalisent. Ce qui importe ce sont les gens qui les écrivent.
Je pense que dire que les entreprises auront toujours une longueur d'avance et que les gens n'y feront jamais face, c'est s'avouer vaincu un peu vite. Une base données collaborative sur les produits et services vendus, n'aurait, je pense, pas moins de chances de marcher que Wikipedia. Mais ça n'est que mon avis.
[^] # Re: Mafia
Posté par barmic . Évalué à 1. Dernière modification le 22 janvier 2013 à 17:22.
C'est bien ça existe déjà depuis quelques temps maintenant. Tu peux scanner un code barre de produit au super marché et voir si c'est bon ou pas (au sens bon pour la santé). C'est plutôt bien fait (mais je ne me souviens plus du nom).
De manière plus globale ce que je veux dire c'est que ce que vous proposer (les boycottes continuels) ne fonctionnent pas. Les boycottes fonctionnent très rarement (comme avec MLK) sur des points ponctuels très suivi. Pour le reste c'est à peu près comme espérer la paie dans le monde, c'est joli mais ça va pas très loin.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mafia
Posté par Juke (site web personnel) . Évalué à 3.
Le service dont tu parles c'est open food facts
http://fr.openfoodfacts.org/
[^] # Re: Mafia
Posté par sifu . Évalué à 1.
Cela a l'air intéressant mais j'ai l'impression que l'origine des produits n'est pas mentionnée.
[^] # Re: Mafia
Posté par Juke (site web personnel) . Évalué à 2.
PTP !
[^] # Re: Mafia
Posté par sifu . Évalué à 1.
PTP ???
[^] # Re: Mafia
Posté par Moogle . Évalué à 4.
Ce n'est pas ce que je dis, je reconnais l'apport et la qualité de Wikipedia, de sites d'information, de beaucoup de forums, etc… Je note juste que ça ne dispense pas d'une vision critique : je vois beaucoup de hoax qui circulent par mail ou par réseaux sociaux, les commentaires des principaux sites d'information qui sont noyautés par l'extrême-droite, qui sait très bien comment répandre ses idées ou de fausses infos sur la toile, en profitant de la naïveté d'une grande partie de la population.
[^] # Re: Mafia
Posté par jice (site web personnel) . Évalué à 5.
En quoi MU était-il une Mafia ?
D'après Wikipedia :
[^] # Re: Mafia
Posté par fravashyo (site web personnel) . Évalué à 2.
Cela demande quand même à être démontré que c'était une "mafia".
Et d'ailleurs, si on s'en tient à la définition, en quoi MU avait-t-il infiltré la société civile et les institutions ? Il y avait des juges travaillant pour MU ? Des agents du FBI et des policiers travaillant pour MU ?
Et les activités "criminelles" ont-elles été autre chose que de la contrefaçon d'oeuvres sans accord des ayants droits, ou bien il y a eu du trafic de drogue, des meurtres, du racket etc ?
Sinon c'est aussi mal venu de parler de mafia dans ce cas, que de piratage avec le P2P
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Mafia
Posté par Moogle . Évalué à 2.
Quand tu vois le passé tumultueux de Kim, y'a quand même plus que juste de la contrefaçon :
http://fr.wikipedia.org/wiki/Kim_Dotcom#Premi.C3.A8res_startups_et_d.C3.A9m.C3.AAl.C3.A9s_judiciaires_.281994_.C3.A0_2001.29
[^] # Re: Mafia
Posté par fravashyo (site web personnel) . Évalué à 3.
ok, il a magouillé un peu comme certains hommes politiques du reste. Mais on cherche toujours le côté mafia, avec les gardes équipé de fusils d'assaut. Comprenez bien, je ne suis pas fan de kim dotcom, mais il ne faut pas non plus détourner la réalité plus qu'il n'a détourné de fonds :)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Mafia
Posté par Marotte ⛧ . Évalué à 2.
Pour moi MU est probablement un produit de la mafia. Ce n'est pas une mafia à proprement parler mais juste l'une de ses activités parmi d'autres activités de contrefaçon, et parmi encore d'autres activités de manière plus générale.
On peut dire que MU est le signe d'une infiltration de la (d'une) mafia dans l'hébergement de contenu sur internet. Après c'est pas les premiers à le faire, contrefaçon et botnet sont des activités qui intéressent les mafias depuis longtemps, MU a juste très bien marché.
[^] # Re: Mafia
Posté par Zenitram (site web personnel) . Évalué à 2.
La question est toujours : quel est le rapport entre de l'arnaque aux actionnaires ou du vol de numéro de CB et la mafia (qui se définit plus comme du chantage, de la pression sur les personnes)???
Un peu d'arguments s'il vous plait : comment définissez vous "mafia", et quel acte du Mr s'en approche?
Ou alors, dites en quoi l'argent du Mr vient d'activité mafieuses et de qui ça vient (sources).
Parce que pour le moment, ben : aucun rapport, vraiment aucun rapport entre MU et la Mafia, ni de près, ni de loin.
[^] # Re: Mafia
Posté par Marotte ⛧ . Évalué à 1.
Les activités de la mafia sont bien plus large que juste du chantage ou du racket. Liste non exhaustive : trafics en tous genre, armes, drogues, êtres humains. Vols. Et bien sûr meurtre quand quelqu'un gêne…
Là dans le cas MU c'était clairement se faire de l'argent (par la pub et par les abonnements) en encourageant et en permettant la contrefaçon d'œuvres. Les utilisateurs dont les fichiers étaient beaucoup téléchargé (ceux qui uploadaient des DVD par exemple) étaient rémunérés, me semble-t-il. Payer quelqu'un pour enfreindre la loi c'est parfois comme ça que ça marche la mafia.
Dit comme ça ça paraît n'être en effet qu'un délit isolé et pas une véritable association de malfaiteurs. Mais vu l'ampleur du truc je ne crois pas que seul Kim était impliqué. En tous cas certains gros bonnets devais le surveiller de près…
# Business Model
Posté par Guillaume Denry (site web personnel) . Évalué à 7. Dernière modification le 20 janvier 2013 à 18:31.
Megaupload a fonctionné parce qu'il était principalement basé sur la contrefaçon massive d'oeuvres sous copyright. Pour pouvoir fonctionner, les fichiers étaient donc disponibles en clair afin de les distribuer rapidement au plus grand nombre. C'était donc relativement simple de prouver l'infraction à la loi en analysant un serveur, à condition de mettre la main dessus.
En revanche, Mega a l'air de faire reposer son infrastructure sur du chiffrement de bout en bout, et d'une part :
1/ j'ai beaucoup de mal à comprendre en quoi il se distingue de tous les hébergeurs du marché qui proposent aussi du chiffrement avec clef privée locale
D'autre part :
2/ On ne pourra donc pas utiliser Mega pour distribuer massivement une copie contrefaite du dernier Pirates des Caraïbes sans filer à tous la clef de déchiffrement, ce qui fait que même les gens du FBI seront en mesure de savoir que le gros blob chiffré sur les serveurs de Kim Dotcom est en fait un film sous copyright. Ca m'étonnerait que ça soit infaillible juridiquement, ça.
Après, bon, j'imagine que l'objectif officiel de Mega n'est pas de remplacer Megaupload mais tout de même, n'est-ce pas un peu ce que les "gens" attendent de ce nouveau service ?
[^] # Re: Business Model
Posté par rakoo (site web personnel) . Évalué à 4.
Je pense que le principe est exactement le même que Zerobin : La protection côté client est surtout là pour dédouaner Mega (ou Zerobin) de toute responsabilité sur le contenu (puisqu'ils ne savent pas ce qu'ils ont sur leurs serveurs). On pourra tout de même répondre que cette intention est claire et est mauvaise; il faudra voir à l'usage.
Oui, mais cette identification ne pourra se faire qu' à postériori, c'est à dire après que le FBI lui a dit "Tu as du contenu protégé, supprime-le". Il n'y a aucun moyen pour Mega de savoir à priori qu'un contenu est litigieux… et donc tant qu'il est discret, il continuera à circuler. Là encore l'idée ressemble énormément à Zerobin.
[^] # Re: Business Model
Posté par Zenitram (site web personnel) . Évalué à 2.
Bah… Comme… hier avec MU, ou Aujourd'hui avec… Youtube.
Tu n'as pas l'obligation à priori de regarder le contenu.
Donc ça change rien : tant que tu ne regardes pas les fichiers, tu es coupable de rien (statut d'hébergeur), et quand tu reçois une notification c'est avec la clé donc tu peux voir ce que c'est.
Ca changerai si tu avais l'obligation de regarder les fichiers que tu reçois, mais aucun pays ne file actuellement cette obligation, donc HS.
Je doute que ça ait la moindre utilité juridique, par contre au niveau marketing…
PS : sans compter, ce qui est le plus rigolo, que le code est envoyé par le serveur, et comme personne ne va lire le code à chaque requête, c'est une sécurité uniquement de façade. Pour une vraie sécurité vis à vis du serveur de stockage, il faudrait que le "client" (web si il veut) et le serveur de stockage soient gérés par des personnes différentes avec une confiance forte dans le client (sources dispos, pas de MAJ possible à chaque requête…).
[^] # Re: Business Model
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Y'aurait aussi la possibilité plus tard d'intégrer une API cryptographique standardisée au sein des navigateurs.
http://www.w3.org/TR/WebCryptoAPI/
A voir l'implémentation et comment cela va être mis en relation avec des clients web qui prétendent l'utiliser alors qu'ils ne le font pas.
[^] # Re: Business Model
Posté par Juke (site web personnel) . Évalué à 1.
Le fait de proposer de la publicité et de faire un fond de commerce des données hebergées (youtube ou MU), ne transforme t-il pas l'hébergeur en éditeur ?
[^] # Re: Business Model
Posté par Zenitram (site web personnel) . Évalué à 1.
Youtube est toujours considéré hébergeur, plein de décisions de justice le confirment… MU est tombé car la part légal/piratage était trop faible pour croire que c'était non voulu + ils ont chopé le monsieur en train de parler de films piraté sur ses serveurs (donc il… savait).
En fait, si j'ai bien compris, c'est : tant que tu ne sélectionnes rien (que tu ne fais pas toi même un filtre), tu es hébergeur, même si tu as des publicités ciblées mises de manière automatique (tu ne sélectionnes toujours pas humainement).
J'y crois d'autant plus que Twitter refuse de filtrer sans décision de justice, et je pense pour la même raison (si ils se mettent à décider ce qui est inacceptable suite juste à des remarques de personnes sans décision de justice, ils deviendraient éditeurs car ayant une "ligne éditoriale", que ce soit suivant la loi FR ou US : il faut que ce soit manifestement illégal pour que tu puisses agir sans considérer être un éditeur. Ou OVH qui a demandé une décision de justice sur Wikileaks dont l'illégalité n'était pas manifeste alors qu'il ne se prive pas de virer des serveurs faisant du partage à outrance sans se prendre de procès au cul pour ça)
Bref : la différence entre hébergeur et éditeur, il me semble pour résumer, est un acte humain fait pour filtrer du non manifestement illégal, pas le fait qu'il y ai de la pub ou pas dessus.
[^] # Re: Business Model
Posté par coïn . Évalué à 1.
non, la différence est qu'un éditeur fait du filtrage de sa propre initiative. un hébergeur filtre sur demande externe (justifié ou pas, ce n'est pas un problème.
que l'acte de filtrage soit humain ou automatisé n'a rien à faire dans ce distinguo, la pub non plus.
[^] # Re: Business Model
Posté par Albert_ . Évalué à 2.
Ouhais mais et toute la procedure a ete juge illegale par la haute court de justice de NZ. Donc est il normal de ne pas respecter la loi ou est il normal de ne pas respecter la loi pour la faire respecter? Sans compter le lobbyisme des majors pour changer les lois pour etendre la duree du copyright avec application retro-active naturellement.
Le sujet est tellement simple et tout est tellement blanc et noir que le debat est toujours la.
# Ce que je remarque...
Posté par liberforce (site web personnel) . Évalué à 5.
C'est qu'ils sont très pro-Google Chrome, et que mon Firefox 18 tout neuf n'est pas assez bien pour lui. Ils font un peu la fine bouche là…
[^] # Re: Ce que je remarque...
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
En même temps, Chrome en est à la version 24 ! Ca fait quand même 6 versions de différence, Mega ne va quand même pas s'amuser à supporter des navigateurs de la préhistoire !
[^] # Re: Ce que je remarque...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Pas que Firefox, mais tout les autres navigateurs. Ils utilisent l'API FileSystem, qui n'est implémenté que dans Chrome (soit 30% des internautes). Pour rappel, cette API est encore un brouillon au W3C, et qu'elle ne fait pas du tout l'unanimité dans le working group. Certains la jugent trop complexe, d'autres qu'elle est limite coté sécurité etc… Chez Mozilla, ils testent d'autres solutions (implémentées pour Firefox OS notamment).
Coté sécurité justement, certains recommandent de ne pas utiliser Mega pour y stocker des fichiers sensibles :
[^] # Re: Ce que je remarque...
Posté par fravashyo (site web personnel) . Évalué à 1.
en fait l'intérêt d'un service d'hébergement, c'est de pouvoir utiliser des protocoles prévu pour ça, comme webdav (je ne sais pas si mega le fait, je n'ai pas cherché, je ne crois pas, et d'ailleurs je m'en moque), couplé éventuellement à du chiffrement initié en local (encfs ou autre), si bien que l'on n'a pas à se préoccuper ensuite si les données sont correctement sécurisées ou si le transfert l'est également par l'hébergeur, vu que c'est déjà chiffré en amont.
Ensuite, je ne m'amuserais pas à utiliser ce type de service comme un disque dur externalisé, sans redondance chez moi, vu que ça peut être fermé sans préavis, comme l'a été megaupload.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# Mega est open source
Posté par Moogle . Évalué à 1.
En tout cas, c'est Kim Dotcom qui le dit.
https://twitter.com/KimDotcom/status/294245061607182336
[^] # Re: Mega est open source
Posté par netsurfeur . Évalué à 2.
Kim Dotcom dit:
Je ne vis pas en quoi cela est particulier à l'Open Source.
Pour de l'Open Source, j'aurais plutôt dit: «You find a bug. You fix it.»
Si Mega est Open Source, où sont les sources ?
Je suis certain que Mega utilise énormément de logiciels Open Source, ça n'implique pas que Mega est Open Source.
[^] # Re: Mega est open source
Posté par Moogle . Évalué à 2.
Mon post était ironique. Il n'y a en effet rien d'open source dans Mega, Kim Dotcom est soit de mauvaise foi, soit ne connaît rien aux principes de l'open source.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.