Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( Duh… je crois qu'un facepalm s'impose. On lit beaucoup de choses sur Internet concernant l'ignorance crasse de ces « ayant droits » mais ce genre de situation dépasse l'entendement… Dans le même genre, savez-vous pourquoi, sur Neuf TV, les chaines telles que TF1 ou M6 sont transportées en chiffré sur le réseau ? Réponse : parce que les ayant droits l'exigent. Évidemment, ça ne semble même pas venus à l'esprit de ces « décideurs » qu'empêcher l'interception de ces flux ne sert strictement à RIEN étant donné qu'il est beaucoup plus simple d'acheter une carte tuner TNT à 30 € et d'enregistrer directement depuis l'hertzien, avec en prime une meilleure qualité ! Par contre pour empêcher de regarder la Neuf TV sur autre chose que le décodeur (par exemple sur un PC), ah pour ça c'est très efficace. Quel gâchis. Dans un autre domaine, on passera aussi sur le fait que d'autres « ayant droit » se croient toujours en guerre contre la copie de Bluray à travers HDCP et AACS alors que ça fait des lustres que n'importe qui peut copier n'importe quel Bluray sans aucune difficulté à l'aide d'un logiciel gratuit (ou presque). Monde de fous. Qui plus est, les technologies mises en place servent généralement à crypter le toyau (RTMPE) ou a rendre l'accès plus complexe (SWFVerif, token exchange), pas à crypter le contenu lui-même. En terme de sécurité, c'est cassé depuis bien longtemps (RTMPE == RC4 avec un échange obfusqué de clés DH (hum) dans l'échange initial entre le player et le server FMS/Wowza/whatever, quant à SWFVerif == SHA256 du player Flash vérifié par le serveur (et obfusqué lui aussi dans un XTEA à 2 balles)). Bref, rien qui ne tienne bien longtemps face à du rev-eng : il serait temps que les ayants-droits comprennent que curl est maintenant linké par défaut avec la librtmp et que des outils comme rtmpdump/rtmpgw (http://rtmpdump.mplayerhq.hu/) deviennent de plus en plus à la portée du script-kiddie moyen. Les nouvelles méthodes de diffusion (HTTP chunks + adaptive streaming) qui sont peu à peu en train de remplacer les protocoles propriétaires pour des raisons de coûts de licences serveurs et d'efficacité de cache dans l'infrastructure Internet d'aujourd'hui vont nécessairement faire revenir les mesures de sécurité sur le contenu (encryption AES128 des payload contenannt les keyframes vidéo, encryption d'un paquet audio sur n pour rendre la bande son insupportable à écouter, etc ...), avec récupération des clés out-of-band par le client, selon un protocole variable (SSL dans le cas d'Apple HTTP LIve Streaming, SSL + certificats individuels dans le cas d'Adobe Flash Access 2, etc.). En gros, la sécurité va se déplacer du canal de distribution au contenu lui-même, c'est le grand retour des DRM (c'est vendredi, c'est permis) ;-) Cordialement, Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Martin Le 22 oct. 2010 à 00:39, Rémi Bouhl a écrit : Le 21/10/10, BORONSKI MARTINmartin.boron...@m6.fr a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Rémi. -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On est devenu gentils :) Plus sérieusement, entre techos, on trouve tjs un terrain d'entente qui peut satisfaire tout le monde. Le 22 oct. 2010 à 00:17, Radu-Adrian Feurdean a écrit : On Thu, 21 Oct 2010 22:55:08 +0200, BORONSKI MARTIN martin.boron...@m6.fr said: On serait ravi de mettre en place notre propre CDN avec du (paid/free) peering là où on peut pour soulager les FAIs et optimiser nos dépenses. Le pb est qu'un service comme M6 Replay nécessite pas mal de Gbps. On avait simulé l'année dernière un tel scénario, mais à 35K€ / 10G (prix public constaté l'année dernière sur l'AS12322), ça restait bien plus cher que de passer par un CDN. Quand on s'appelle M6 (ou TF1) la vieille methode Ca va etre comme ca ou on coupe le service ca ne marche plus ? Je me souviens que ca avait marche il y a quelques annees (toujours avec Free). Si ce n'est plus le cas, c'est interessant a savoir. -- Radu-Adrian Feurdean raf (a) ftml ! net -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Ce n'est clairement pas simple de rassurer les ayants-droits (on en sait quelque chose chez Dailymotion aussi ^_^), mais c'est dans l'air du temps : avec l'avènement de la balise vidéo dans HTML5 par exemple, ainsi que du streaming sur mobiles, il va bien falloir trouver des solutions qui les rassurent tout autant. En ce qui concerne le P2P, des solutions comme Giraffic sont également séduisantes, et ne sont pas nécessairement antinomiques avec l'approche de distribution par fragments (cette approche facilite par essence le découpage de gros contenus, nécessaire à la distribution P2P). Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Cordialement, Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Bonjour Martin, Je ne pense pas que le P2P soit plus séduisant, même su papier. Le P2P transfère en effet le cout de transport du fournisseur de contenu vers le FAI. Quand le fournisseur de contenu n'a pas de revenu, le FAI rale et utilise du DPI pour que ce cout n'entraine pas de problèmes de capacité. Quand le fournisseur de contenu a un revenu lie a ce contenu, le FAI va surement revenir vers le le fournisseur et lui demander ce que le CDN lui aurait fourni comme revenu directement. De plus il est impossible pour le fournisseur de s'assurer de la qualité d'un service P2P, alors que c'est possible avec un CDN ou via peering/pay peering/transit. C'est sans parler des économies d'échelles, du pouvoir de négociation d'un CDN. Je me souviens quand la BBC a essaye d'utiliser le CDN de L3. L'expérience a été de courte durée. Le transit est bien plus cher qu'un peering. Aucun FAI n'aime payer le prix premium de transit pour du trafic qui devrait etre local. Les 3 Français ont peut-etre un accord de peering avec L3 et s'en moquent peut-etre, ou peut-etre pas ... Bref, c'est pas simple ;) Thomas On 22 Oct 2010, at 07:57, BORONSKI MARTIN wrote: On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Martin Le 22 oct. 2010 à 00:39, Rémi Bouhl a écrit : Le 21/10/10, BORONSKI MARTINmartin.boron...@m6.fr a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Rémi. -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On 22 oct. 2010, at 08:47, Pierre-Yves Kerembellec wrote [description de techniques DRM qui ne résisteront pas longtemps a un reverse engineering] ce qui n'aidera en rien, vu que le contenu se retrouvera de toutes facons sur les sites pirates dans la demi-heure qui suit...--- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Article sur le NAT64 chez Networkworld
L'article complet est ici (en anglais): http://www.networkworld.com/community/blog/testing-nat64-and-dns64 En résumé, les nouveaux réseaux IP seront déployés avec uniquement le support des adresses IPv6. Comme il existe encore énormèment de services qui ne sont disponibles qu'en IPv4, il faut cependant trouver moyen d'y accéder. C'est là qu'intervient la technologie NAT64. Le principe est simple: - les machines utilisent un resolver DNS spécial (DNS64) qui créée des enregistrements à partir des adresses des serveurs IPv4. - ces enregistrements DNS pointent sur un dispositif qui fait de la translation d'adresse entre les mondes IPv4 et IPv6. De cette façon, il est possible de déployer des réseaux uniquement IPv6 et de limiter les investissements nécessaires pour gérer IPv4 à un nombre très réduit de machines. Au moins un FAI (au Royaume-Uni) a déployé un système NAT64 en production. Il est possible de l'utiliser en changeant simplement l'adresse de son premier résolveur DNS. J'ai testé le dispositif et c'est bluffant: pour un poste client tout fonctionne exactement comme avec un NAT IPv4 vers IPv4 classique. -- Francois Tigeot, Zefyris --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Thu, Oct 21, 2010 at 10:55:08PM +0200, BORONSKI MARTIN wrote: On serait ravi de mettre en place notre propre CDN avec du (paid/free) peering là où on peut pour soulager les FAIs et optimiser nos dépenses. Le pb est qu'un service comme M6 Replay nécessite pas mal de Gbps. On avait simulé l'année dernière un tel scénario, mais à 35K€ / 10G (prix public constaté l'année dernière sur l'AS12322), ça restait bien plus cher que de passer par un CDN. Si les conditions ont évoluées, on est à la disposition des FAIs pour avancer en top priorité sur un tel scénario, d'autant plus que les technologies de streaming ont pas mal évoluées et deviennent bien plus simples à exploiter en interne, sans passer forcément par des CDNs. pourquoi ne pas pousser vos clients, pour les FAI en disposant, a utiliser les plateformes de VoD du-dit FAI ? (cas de 12322 que vous prenez en exemple) ca soulagerait d'autant vos plateformes CDN on net, et donc reduction de cout et augmentation de la qualité pour tout le monde... Martin Le 21 oct. 2010 à 22:40, Sébastien FOUTREL a écrit : Effectivement le M6 Replay des boxes ne passe pas par du transit. (le plus souvent par des montages plutot sales au gré des FAIs). Le site web lui utilise des CDN pour la diffusion. Pas envie d'avoir son propre CDN (dommage). Apres, comme dit precedement, si c'est le meme acteur qui facture 2 fois la BP, il a tout compris :) Bien a vous. Le 21 octobre 2010 11:49, Romain Tournier tout...@idest.org a écrit : On Thu, Oct 21, 2010 at 07:42:36AM +0200, Vivien GUEANT wrote: Le 21/10/2010 00:52, MM a écrit : Parceque c'était le provider le moins cher et que le délais est pas du tout gênant quand on fait du streaming ? Cogent ? ;) Bon, il est vrai que L3 est (était ?) assez agressif sur ses tarifs. Ils est tout de même dommage de charger une transatlantique pour un service français vu par un public français - ou alors L3 a de la capacité à ne plus savoir quoi en faire ... Ce qui est dommage également, c'est d'utiliser du transit là où il serait possible de mettre un peering. Si je résume la situation chez Free : - Dailymotion paye pour du paid-peering lol ? - Google à un peering privé gratuit - M6 replay oblige Free à payer du transit pour ses vidéos pourtant M6 replay fonctionne parfaitement sur ma freebox... et j'ai pas souvenir que ca passe par le transit... mais bon, je ne dois pas assez connaitre le chemin des packets... Level3 est un fournisseur de transit pour Free : /*Free */ /*Bande passante: *//*Fournisseurs: */ 2004 10 Gbps OpenTransit, Telia, Sprint 2005 10 Gbps Open Transit, Teleglobe 2006 40 Gbps Teleglobe, Level(3) 2007 40 Gbps Teleglobe, Level(3) 2008 80 Gbps Teleglobe, Level(3) 2009 160Gbps Teleglobe, Level(3) et le monde s'est arreté debut 2009... le choix des transitaires peut varier au cours du temps faisant apparaitre et disparaitre les fournisseurs et varier la capa... -- Romain --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Romain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Article sur le NAT64 chez Networkworld
On Fri, 22 Oct 2010 10:51:59 +0200, Francois Tigeot ftig...@zefyris.com wrote: L'article complet est ici (en anglais): http://www.networkworld.com/community/blog/testing-nat64-and-dns64 En résumé, les nouveaux réseaux IP seront déployés avec uniquement le support des adresses IPv6. Comme il existe encore énormèment de services qui ne sont disponibles qu'en IPv4, il faut cependant trouver moyen d'y accéder. C'est là qu'intervient la technologie NAT64. Le principe est simple: - les machines utilisent un resolver DNS spécial (DNS64) qui créée des enregistrements à partir des adresses des serveurs IPv4. - ces enregistrements DNS pointent sur un dispositif qui fait de la translation d'adresse entre les mondes IPv4 et IPv6. De cette façon, il est possible de déployer des réseaux uniquement IPv6 et de limiter les investissements nécessaires pour gérer IPv4 à un nombre très réduit de machines. Au moins un FAI (au Royaume-Uni) a déployé un système NAT64 en production. Il est possible de l'utiliser en changeant simplement l'adresse de son premier résolveur DNS. J'ai testé le dispositif et c'est bluffant: pour un poste client tout fonctionne exactement comme avec un NAT IPv4 vers IPv4 classique. C'est en cours de déploiement dans mon appart aussi, avec comme objectif de ne plus avoir d'adresse IPv4 sur mes machines :3 Ça marche bien, par contre quand tu ne passes pas par le DNS pour obtenir les IP, ça marche tout de suite moins bien... (exemple: Bit Torrent) Pour ceux que ça intéresse, http://www.viagenie.ca/publications/2009-11-06-3gpp-ietf-ipv6-shanghai-nat64.pdf (avec entre autre la justification du NAT64 face au NAT-PT) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Article sur le NAT64 chez Networkworld
On Fri, Oct 22, 2010 at 10:51:59AM +0200, Francois Tigeot ftig...@zefyris.com wrote a message of 29 lines which said: - les machines utilisent un resolver DNS spécial (DNS64) qui créée des enregistrements à partir des adresses des serveurs IPv4. Pour BIND, cela n'apparaitra dans les versions officielles qu'avec la 9.7.quelquechose. - ces enregistrements DNS pointent sur un dispositif qui fait de la translation d'adresse entre les mondes IPv4 et IPv6. À noter que les RFC ne sont pas encore publiés et beaucoup ne sont pas terminés. Technologie mouvante, donc. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Article sur le NAT64 chez Networkworld
On Fri, Oct 22, 2010 at 11:02:47AM +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote a message of 43 lines which said: Ça marche bien, par contre quand tu ne passes pas par le DNS pour obtenir les IP, ça marche tout de suite moins bien... (exemple: Bit Torrent) Ou bien les sites Web qui te pointent vers des URL où les adresses Ipv4 apparaissent littéralement : http://groups.google.com/group/ipv4literals --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Car les services de VoD du-dit FAI ne sont pas accessible depuis un PC (cas de 12322) alors que M6Replay l'est ? Ceci-dit, ça serait bien que le live soit _aussi_ accessible depuis les PC chez 12322... -_- Au passage, je viens de refaire un petit tour sur M6Replay, j'adore l'option Eteindre la lumière qui permet ... d'afficher la pub windows phone en presque plein écran tout autour de la vidéo :-D http://tmp.soete.org/m6replay.jpg Thomas Le 22 octobre 2010 11:37, Romain Tournier tout...@idest.org a écrit : On Thu, Oct 21, 2010 at 10:55:08PM +0200, BORONSKI MARTIN wrote: On serait ravi de mettre en place notre propre CDN avec du (paid/free) peering là où on peut pour soulager les FAIs et optimiser nos dépenses. Le pb est qu'un service comme M6 Replay nécessite pas mal de Gbps. On avait simulé l'année dernière un tel scénario, mais à 35K€ / 10G (prix public constaté l'année dernière sur l'AS12322), ça restait bien plus cher que de passer par un CDN. Si les conditions ont évoluées, on est à la disposition des FAIs pour avancer en top priorité sur un tel scénario, d'autant plus que les technologies de streaming ont pas mal évoluées et deviennent bien plus simples à exploiter en interne, sans passer forcément par des CDNs. pourquoi ne pas pousser vos clients, pour les FAI en disposant, a utiliser les plateformes de VoD du-dit FAI ? (cas de 12322 que vous prenez en exemple) ca soulagerait d'autant vos plateformes CDN on net, et donc reduction de cout et augmentation de la qualité pour tout le monde... Martin Le 21 oct. 2010 à 22:40, Sébastien FOUTREL a écrit : Effectivement le M6 Replay des boxes ne passe pas par du transit. (le plus souvent par des montages plutot sales au gré des FAIs). Le site web lui utilise des CDN pour la diffusion. Pas envie d'avoir son propre CDN (dommage). Apres, comme dit precedement, si c'est le meme acteur qui facture 2 fois la BP, il a tout compris :) Bien a vous. Le 21 octobre 2010 11:49, Romain Tournier tout...@idest.org a écrit : On Thu, Oct 21, 2010 at 07:42:36AM +0200, Vivien GUEANT wrote: Le 21/10/2010 00:52, MM a écrit : Parceque c'était le provider le moins cher et que le délais est pas du tout gênant quand on fait du streaming ? Cogent ? ;) Bon, il est vrai que L3 est (était ?) assez agressif sur ses tarifs. Ils est tout de même dommage de charger une transatlantique pour un service français vu par un public français - ou alors L3 a de la capacité à ne plus savoir quoi en faire ... Ce qui est dommage également, c'est d'utiliser du transit là où il serait possible de mettre un peering. Si je résume la situation chez Free : - Dailymotion paye pour du paid-peering lol ? - Google à un peering privé gratuit - M6 replay oblige Free à payer du transit pour ses vidéos pourtant M6 replay fonctionne parfaitement sur ma freebox... et j'ai pas souvenir que ca passe par le transit... mais bon, je ne dois pas assez connaitre le chemin des packets... Level3 est un fournisseur de transit pour Free : /*Free */ /*Bande passante: */ /*Fournisseurs: */ 2004 10 Gbps OpenTransit, Telia, Sprint 2005 10 Gbps Open Transit, Teleglobe 2006 40 Gbps Teleglobe, Level(3) 2007 40 Gbps Teleglobe, Level(3) 2008 80 Gbps Teleglobe, Level(3) 2009 160Gbps Teleglobe, Level(3) et le monde s'est arreté debut 2009... le choix des transitaires peut varier au cours du temps faisant apparaitre et disparaitre les fournisseurs et varier la capa... -- Romain --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Romain --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Bonjour à tous, Déja, merci pour ce thread très on-topic et intéressant. J'ai une remarque relative à cette histoire de P2P-VoD: je ne comprends pas en quoi le fait d'utiliser cette techno de diffusion ou une autre a une incidence sur le piratage des contenus. A priori, le flux n'est visible que par des utilisateurs ayant installé une application client spécifique, qui, j'imagine, ne redistribue les paquets qu'a des peers ayant un token approprié et/ou sous forme cryptée - ce qui fait qu'un autre client doit etre aussi authentifié que le client initial. J'ai l'impression que l'ayant droit de l'histoire réagit à un accronyme à trois lettres: P2P == je distribue mes contenus en clair sur bittorrent, ce qui n'est manifestement pas le cas ici. Bien sur, il est toujours possible de casser les limitations et protections du client P2P-VoD, mais comme le soulignait quelqu'un dans le thread, tous les contenus sont de toutes façons disponibles illégalement. Je ne crois pas que cela serait plus facie avec cette techno. Et dans ce contexte, réduire le cout des solutions légales me parrait etre la meilleure chose à faire, dans la mesure ou cela peut permettre (on peut réver) de réduire leur prix, et donc l'attractivité des version pirates. Un autre point qui me fait réagir: le P2P reporte le cout sur l'ISP - c'est sans doute vrai, mais long terme, c'est peut-être bénéfique: cela aurait tendance à pousser les ISP à continuer de construire des réseaux adaptés à cette architecture, c'est à dire (pardonnez ma terminologie ghetto) fortement maillés. En tant qu'ingénieur, utilisateur et meme cityoyen, je prefere un réseau permettant des hauts débits entre utilisateurs à un réseau optimisé pour quelques gros emetteurs, ce qui semble non seulement être un casse-tete pour tout le monde, mais en plus représente l'inverse de ce que le net a apporté, et des raisons de son succès: l'echange entre individus, pair à pair, pas forcement à tous les niveaux techniques mais en tout cas dans l'utilisation finale. My 20 cents :p Stefan 2010/10/22 BORONSKI MARTIN martin.boron...@m6.fr On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Martin Le 22 oct. 2010 à 00:39, Rémi Bouhl a écrit : Le 21/10/10, BORONSKI MARTINmartin.boron...@m6.fr a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Rémi. -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Il me semble d'ailleurs que Spotify utilise ce genre de technologie pour diffuser son contenu musical afin de réduire ses coûts d'infrastructure. https://www.spotify.com/int/help/faq/tech/network-connections/ 2010/10/22 Stefan P deubeul...@gmail.com: Bonjour à tous, Déja, merci pour ce thread très on-topic et intéressant. J'ai une remarque relative à cette histoire de P2P-VoD: je ne comprends pas en quoi le fait d'utiliser cette techno de diffusion ou une autre a une incidence sur le piratage des contenus. A priori, le flux n'est visible que par des utilisateurs ayant installé une application client spécifique, qui, j'imagine, ne redistribue les paquets qu'a des peers ayant un token approprié et/ou sous forme cryptée - ce qui fait qu'un autre client doit etre aussi authentifié que le client initial. J'ai l'impression que l'ayant droit de l'histoire réagit à un accronyme à trois lettres: P2P == je distribue mes contenus en clair sur bittorrent, ce qui n'est manifestement pas le cas ici. Bien sur, il est toujours possible de casser les limitations et protections du client P2P-VoD, mais comme le soulignait quelqu'un dans le thread, tous les contenus sont de toutes façons disponibles illégalement. Je ne crois pas que cela serait plus facie avec cette techno. Et dans ce contexte, réduire le cout des solutions légales me parrait etre la meilleure chose à faire, dans la mesure ou cela peut permettre (on peut réver) de réduire leur prix, et donc l'attractivité des version pirates. Un autre point qui me fait réagir: le P2P reporte le cout sur l'ISP - c'est sans doute vrai, mais long terme, c'est peut-être bénéfique: cela aurait tendance à pousser les ISP à continuer de construire des réseaux adaptés à cette architecture, c'est à dire (pardonnez ma terminologie ghetto) fortement maillés. En tant qu'ingénieur, utilisateur et meme cityoyen, je prefere un réseau permettant des hauts débits entre utilisateurs à un réseau optimisé pour quelques gros emetteurs, ce qui semble non seulement être un casse-tete pour tout le monde, mais en plus représente l'inverse de ce que le net a apporté, et des raisons de son succès: l'echange entre individus, pair à pair, pas forcement à tous les niveaux techniques mais en tout cas dans l'utilisation finale. My 20 cents :p Stefan 2010/10/22 BORONSKI MARTIN martin.boron...@m6.fr On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Martin Le 22 oct. 2010 à 00:39, Rémi Bouhl a écrit : Le 21/10/10, BORONSKI MARTINmartin.boron...@m6.fr a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Rémi. -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Il me semble d'ailleurs que Spotify utilise ce genre de technologie pour diffuser son contenu musical afin de réduire ses coûts d'infrastructure. En effet, Spotify utilise allégrement du P2P dans son réseau de distribution, ce qui ne pose visiblement pas de problème aux ayants droit. Quelques chiffres intéressants sur la provenance des contenus joués: - 10% proviens du CDN de Spotify - 35% du P2P - 55% du cache (client lourd) Source: http://www.nada.kth.se/~gkreitz/spotify-p2p10/kreitz-spotify-p2p10.pdf -- Ludovic Fauvet (etix) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Un autre point qui me fait réagir: le P2P reporte le cout sur l'ISP - c'est sans doute vrai, mais long terme, c'est peut-être bénéfique: cela aurait tendance à pousser les ISP à continuer de construire des réseaux adaptés à cette architecture, c'est à dire (pardonnez ma terminologie ghetto) fortement maillés. En theorie, oui, en pratique ce n'est pas aussi facile. Il n'y a toujours pas d'agrégation naturelle des IP par zones géographiques. Quand tu prend un service L2TP chez un LLU, il te le termine normalement a un des gros DC du pays (ou il est aussi facile de trouver du transit) ... Ceci dit, je suis d'accord que cela serait mieux, et que avec l'augmentation du volume de trafic, je garde espoir. C'est bien pour cela que je supporte un IX regional : http://thomas.mangin.com/data/pdf/EPF%205%20-%20Mangin%20-%20IXLeeds.pdf Les CDN mettent des serveurs juste a cote des BRAS, _dans_ les réseaux, pour la même raison. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On 22 Oct 2010, at 11:20, Ludovic Fauvet wrote: - 55% du cache (client lourd) Source: http://www.nada.kth.se/~gkreitz/spotify-p2p10/kreitz-spotify-p2p10.pdf Merci pour la source. Tu as donne la raison : client lourd propriétaire et ferme, même si le protocole est maintenant connu. http://despotify.se/ Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Article sur le NAT64 chez Networkworld
Stephane Bortzmeyer wrote: À noter que les RFC ne sont pas encore publiés et beaucoup ne sont pas terminés. Technologie mouvante, donc. Oui, mais déjà en prod. Ca se sent qu'il y a un gros besoin derrière. En fait, après coup ce qui m'étonne, c'est que ça n'ait pas été inventé plus tôt. -- Francois Tigeot, Zefyris --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Et l'équipe de Spotify a bloqué l'accès aux comptes gratuits (donc rémunérés par la publicité) via les logiciels tiers mais a laissé l'accès libre aux comptes payant ... :-) Thomas Le 22 octobre 2010 13:01, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : On 22 Oct 2010, at 11:20, Ludovic Fauvet wrote: - 55% du cache (client lourd) Source: http://www.nada.kth.se/~gkreitz/spotify-p2p10/kreitz-spotify-p2p10.pdf Merci pour la source. Tu as donne la raison : client lourd propriétaire et ferme, même si le protocole est maintenant connu. http://despotify.se/ Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Article sur le NAT64 chez Networkworld
On 22 Oct 2010, at 12:01, Francois Tigeot wrote: Stephane Bortzmeyer wrote: À noter que les RFC ne sont pas encore publiés et beaucoup ne sont pas terminés. Technologie mouvante, donc. Oui, mais déjà en prod. Ca se sent qu'il y a un gros besoin derrière. En fait, après coup ce qui m'étonne, c'est que ça n'ait pas été inventé plus tôt. En prod ou ca ? la ? http://aaisp.net.uk/kb-broadband-ipv6-nat64.html Si c'est ta référence, donne moi en une autre STP. Adrian supporte IPv6 tres fortement ce qui est plus facile pour lui que d'autres puisqu'il a son propre hardware fait maison. Je ne pense pas que NAT64 soit vu comme une technologie critique pour le moment, du moins pas encore. http://www.uknof.org.uk/uknof16/Kennard-IP64mapping.pdf Ceci dit, l'idée fait son chemin :) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Article sur le NAT64 chez Networkworld
Thomas Mangin wrote: On 22 Oct 2010, at 12:01, Francois Tigeot wrote: Stephane Bortzmeyer wrote: À noter que les RFC ne sont pas encore publiés et beaucoup ne sont pas terminés. Technologie mouvante, donc. Oui, mais déjà en prod. Ca se sent qu'il y a un gros besoin derrière. En fait, après coup ce qui m'étonne, c'est que ça n'ait pas été inventé plus tôt. En prod ou ca ? la ? http://aaisp.net.uk/kb-broadband-ipv6-nat64.html Oui, c'est à Andrews Arnold que je pensais. J'ai arrêté de chercher après les 5 premiers résultats de Google. Ceci dit, l'idée fait son chemin :) En effet; j'ai du chercher en tout et pour tout 1/4 d'h donc ça ne veut pas dire grand chose, mais je me souviens avoir vu pas mal de discussions/projets, à la fois en logiciel ou chez les constructeurs... -- Francois Tigeot, Zefyris --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 11:56:03 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: En theorie, oui, en pratique ce n'est pas aussi facile. Il n'y a toujours pas d'agrégation naturelle des IP par zones géographiques. Bah, de toute façon l'IPv4 est mort et l'IPv6 qui sera déployé mondialement d'ici 3 mois va gérer ça parfaitement :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit : On Fri, 22 Oct 2010 11:56:03 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: En theorie, oui, en pratique ce n'est pas aussi facile. Il n'y a toujours pas d'agrégation naturelle des IP par zones géographiques. Bah, de toute façon l'IPv4 est mort et l'IPv6 qui sera déployé mondialement d'ici 3 mois va gérer ça parfaitement :) Oui, c'est bien ça le planning: - Dans un mois on aura DNSSEC de partout, jusque dans les machinbox Dans deux mois la totalité des routeurs saura gérer les routing beacon qui ont planté Internet il y a quelques semaines, et dans trois mois c'est au tour d'IPv6. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Eric Pernot Marketing Manager +33681762075 www.Interoute.fr Sent from my BlackBerry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Oui... et ? :-) On Fri, 2010-10-22 at 16:46 +0200, Eric Pernot wrote: Eric Pernot Marketing Manager +33681762075 www.Interoute.fr Sent from my BlackBerry --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/2010 16:46, Eric Pernot a écrit : Eric Pernot Marketing Manager +33681762075 www.Interoute.fr Sent from my BlackBerry --- Liste de diffusion du FRnOG http://www.frnog.org/ Nous sommes ravis de savoir que tu téléphones avec une BaieNoire, mais peut-on avoir le contenu du message ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/2010 16:52, Clement Cavadore a écrit : Oui... et ? :-) Comme c'est vendredi, je pense qu'il voulait juste ajouter une illustration de contenu crypté transpoté sur le réseau par un protocole propriétaire et (ah ah ah) inviolable, ce qui permet de sauvegarder sa valeur pour les ayants-droits. Ah il est vide euh ben comme beaucoup d'autres contenus sous copyright en fait ;-) Cordialement, -- Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Bah c'est tout, je m'presente, je m'appelle Henri, j'voudrais bien reussir ma vie etre aimeee. Ou alors son doit a rippe... Pis c'est vendredi :) Yves Dubromelle a dit le 22/10/2010 16:52 : Le 22/10/2010 16:46, Eric Pernot a écrit : Eric Pernot Marketing Manager +33681762075 www.Interoute.fr Sent from my BlackBerry --- Liste de diffusion du FRnOG http://www.frnog.org/ Nous sommes ravis de savoir que tu téléphones avec une BaieNoire, mais peut-on avoir le contenu du message ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Non, c'est un gars du marketing, et super bon de surcroit : Il a réussi à faire parler de lui et de sa boite sans prononcer un mot ! Bon vendredi ;)--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/2010 17:04, FRnOG a écrit : Bah c'est tout, je m'presente, je m'appelle Henri, j'voudrais bien reussir ma vie etre aimeee. Et bien, enchanté Henri FrnOG ! C'est vendredi aussi.. ;) @+ Gilou --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. Martin Le 22 oct. 2010 à 11:56, Stefan P a écrit : Bonjour à tous, Déja, merci pour ce thread très on-topic et intéressant. J'ai une remarque relative à cette histoire de P2P-VoD: je ne comprends pas en quoi le fait d'utiliser cette techno de diffusion ou une autre a une incidence sur le piratage des contenus. A priori, le flux n'est visible que par des utilisateurs ayant installé une application client spécifique, qui, j'imagine, ne redistribue les paquets qu'a des peers ayant un token approprié et/ou sous forme cryptée - ce qui fait qu'un autre client doit etre aussi authentifié que le client initial. J'ai l'impression que l'ayant droit de l'histoire réagit à un accronyme à trois lettres: P2P == je distribue mes contenus en clair sur bittorrent, ce qui n'est manifestement pas le cas ici. Bien sur, il est toujours possible de casser les limitations et protections du client P2P-VoD, mais comme le soulignait quelqu'un dans le thread, tous les contenus sont de toutes façons disponibles illégalement. Je ne crois pas que cela serait plus facie avec cette techno. Et dans ce contexte, réduire le cout des solutions légales me parrait etre la meilleure chose à faire, dans la mesure ou cela peut permettre (on peut réver) de réduire leur prix, et donc l'attractivité des version pirates. Un autre point qui me fait réagir: le P2P reporte le cout sur l'ISP - c'est sans doute vrai, mais long terme, c'est peut-être bénéfique: cela aurait tendance à pousser les ISP à continuer de construire des réseaux adaptés à cette architecture, c'est à dire (pardonnez ma terminologie ghetto) fortement maillés. En tant qu'ingénieur, utilisateur et meme cityoyen, je prefere un réseau permettant des hauts débits entre utilisateurs à un réseau optimisé pour quelques gros emetteurs, ce qui semble non seulement être un casse-tete pour tout le monde, mais en plus représente l'inverse de ce que le net a apporté, et des raisons de son succès: l'echange entre individus, pair à pair, pas forcement à tous les niveaux techniques mais en tout cas dans l'utilisation finale. My 20 cents :p Stefan 2010/10/22 BORONSKI MARTIN martin.boron...@m6.frmailto:martin.boron...@m6.fr On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux plateformes à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, davantage de points of failure à surveiller, ... Bref, c'est pas simple ;) Martin Le 22 oct. 2010 à 00:39, Rémi Bouhl a écrit : Le 21/10/10, BORONSKI MARTINmartin.boron...@m6.frmailto:martin.boron...@m6.fr a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin Sauf que ces technologies (y compris RTMP de Adobe) permettent également de capturer le contenu. Sous Linux, c'est dingue le nombre de choses théoriquement impossibles à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué sous Windows). Les ayants-droits semblent pourtant se satisfaire de cette situation, vu que 95% des gens ne savent même pas que le fichier est accessible si on s'en donne la peine. Possible qu'avec un joli enrobage du protocole BitTorrent dans un front-end maison, et un dossier de stockage pas mieux caché que ce que fait FlashPlayer, ils n'y voient que du feu. C'est jouable? Rémi. -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Martin Boronski Directeur Technique
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
C'est exactement ce qu'on a en tête : - (Adobe) HTTP Adaptative Streaming + DRM - (Apple) HTTP Live Streaming avec AES Plus simple à diffuser et plus simple à exploiter. Martin Le 22 oct. 2010 à 08:47, Pierre-Yves Kerembellec a écrit : Qui plus est, les technologies mises en place servent généralement à crypter le toyau (RTMPE) ou a rendre l'accès plus complexe (SWFVerif, token exchange), pas à crypter le contenu lui-même. En terme de sécurité, c'est cassé depuis bien longtemps (RTMPE == RC4 avec un échange obfusqué de clés DH (hum) dans l'échange initial entre le player et le server FMS/Wowza/whatever, quant à SWFVerif == SHA256 du player Flash vérifié par le serveur (et obfusqué lui aussi dans un XTEA à 2 balles)). Bref, rien qui ne tienne bien longtemps face à du rev-eng : il serait temps que les ayants-droits comprennent que curl est maintenant linké par défaut avec la librtmp et que des outils comme rtmpdump/rtmpgw (http://rtmpdump.mplayerhq.hu/) deviennent de plus en plus à la portée du script-kiddie moyen. Les nouvelles méthodes de diffusion (HTTP chunks + adaptive streaming) qui sont peu à peu en train de remplacer les protocoles propriétaires pour des raisons de coûts de licences serveurs et d'efficacité de cache dans l'infrastructure Internet d'aujourd'hui vont nécessairement faire revenir les mesures de sécurité sur le contenu (encryption AES128 des payload contenannt les keyframes vidéo, encryption d'un paquet audio sur n pour rendre la bande son insupportable à écouter, etc ...), avec récupération des clés out-of-band par le client, selon un protocole variable (SSL dans le cas d'Apple HTTP LIve Streaming, SSL + certificats individuels dans le cas d'Adobe Flash Access 2, etc.). En gros, la sécurité va se déplacer du canal de distribution au contenu lui-même, c'est le grand retour des DRM (c'est vendredi, c'est permis) ;-) Cordialement, Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
C'est ce que nous faisons en déployant nos services directement dans les boxes. Mais bcp de gens consomment encore sur le PC ou sur iPhone/iPad. Et là, on ne peut pas délivrer depuis les streamers des ISPs. Idem sur les TVs connectés et tous les nouveaux devices (tablettes, ...) qui débarquent, il faut un CDN. Martin Le 22 oct. 2010 à 11:37, Romain Tournier a écrit : pourquoi ne pas pousser vos clients, pour les FAI en disposant, a utiliser les plateformes de VoD du-dit FAI ? (cas de 12322 que vous prenez en exemple) ca soulagerait d'autant vos plateformes CDN on net, et donc reduction de cout et augmentation de la qualité pour tout le monde... -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22 oct. 2010 à 09:20, Pierre-Yves Kerembellec a écrit : As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du HTML5, en dehors d'un token ? On y réfléchit et mes équipes me poussent pour qu'on fasse le saut, mais sans sécurité state of the art et sans outils de monétisation (oui, je sais, on en revient tjs à l'argent ...), c'est pas simple. Ce n'est clairement pas simple de rassurer les ayants-droits (on en sait quelque chose chez Dailymotion aussi ^_^), mais c'est dans l'air du temps : avec l'avènement de la balise vidéo dans HTML5 par exemple, ainsi que du streaming sur mobiles, il va bien falloir trouver des solutions qui les rassurent tout autant. En ce qui concerne le P2P, des solutions comme Giraffic sont également séduisantes, et ne sont pas nécessairement antinomiques avec l'approche de distribution par fragments (cette approche facilite par essence le découpage de gros contenus, nécessaire à la distribution P2P). Cordialement, Pierre-Yves -- Martin Boronski Directeur Technique M6 Web 110 avenue Jean Jaurès 69007 Lyon Mobile : +33 6 71 97 83 44
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/2010 18:00, BORONSKI MARTIN a écrit : Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( Pourquoi ne pas inclure ce genre de clients directement dans les boxes, et rendre ainsi cela plus transparent ? Quand on voit la facilité avec laquelle on nous parle d'inclure du DPI dans les boxes, on se dit que tant qu'à les alourdir autant que ça serve vraiment :) On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Car encore actuellement, si l'on souhaite utiliser un service web on n'est pas obligé de passer par la box de l'opérateur ? Si on ne souhaite pas de téléphonie ni de télévision, on peut encore utiliser un modem standard. Après, mettre le DPI directement dans les boxes, quid de l'utilisateur qui vire la box pour mettre un modem standard a la place ? Il faut regarder du côté du DSLAM pour ne plus dépendre de l'utilsateur et là ce sont les FAI qui vont être content ;-) Le 22 octobre 2010 18:07, Yves Dubromelle taera...@dubronetwork.fr a écrit : Le 22/10/2010 18:00, BORONSKI MARTIN a écrit : Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( Pourquoi ne pas inclure ce genre de clients directement dans les boxes, et rendre ainsi cela plus transparent ? Quand on voit la facilité avec laquelle on nous parle d'inclure du DPI dans les boxes, on se dit que tant qu'à les alourdir autant que ça serve vraiment :) On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 2010-10-22 at 18:00 +0200, BORONSKI MARTIN wrote: C'est ce que nous faisons en déployant nos services directement dans les boxes. Mais bcp de gens consomment encore sur le PC ou sur iPhone/iPad. Et là, on ne peut pas délivrer depuis les streamers des ISPs. Idem sur les TVs connectés et tous les nouveaux devices (tablettes, ...) qui débarquent, il faut un CDN. Voilà pourquoi a mon avis, les TV connectées consort sont AMHA un non-sens, et ne peuvent pas avoir un avenir florissant. Consommer de la video sur le PC, avec un navigateur en simple internaute, pourquoi pas, je n'ai par exemple pas de télévision chez moi (et ne suis pas abonné à une offre 3P), mais si on a une télé, autant utiliser des technos adaptées par le FAI (multicast), et non de l'unicast de bourrin. Donc la STB du FAI. digression personnelle - Dommage que le multicast public n'existe pas ou peu chez les plus gros FAI résidenciel mondiaux - Dommage que les offres résidencielles actuelles sont OBLIGATOIREMENT fournies avec un service de TV et/ou Téléphone. Essayez aujourd'hui d'avoir la fibre sans TV ou Téléphone... - OK je peux aussi ne pas utiliser le service, mais si j'ai un service comme celui-ci, pourquoi les impots ne me tomberaient pas dessus pour la redevance télé ? :)) /digression -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du HTML5, en dehors d'un token ? On y réfléchit et mes équipes me poussent pour qu'on fasse le saut, mais sans sécurité state of the art et sans outils de monétisation (oui, je sais, on en revient tjs à l'argent ...), c'est pas simple. Pour ce qui est de la balise video sur iDevice, HTTP Live Streaming + AES128 + clé via SSL est supporté (Apple-centric). Pour une future norme playlists + chunks + sécurité des chunks dans les balises vidéo des différents vendeurs de navigateurs, il y a les discussions au niveau FOMS WHATWG (auquel nous sommes un peu associés), mais ça se cherche (forcément, c'est pas simple de mettre tout le monde d'accord). Qui plus est, dès qu'on parle de DRM (ou assimilé, au sens large), on a en face le monde de l'open-source qui ne veut pas trop aborder le sujet ... bon, on s'éloigne un peu (voire même carrément) du sujet de la ML, la suite en privé si tu veux ... ;-) Ce qui est important dans ces technologies d'un point de vue opérateur (donc plus dans le sujet de la liste), c'est que cette fragmentation et le fait de déplacer la sécurité dans le contenu lui-même plutôt que dans le tuyau amènent l'augmentation de la cachabilité des contenus à tous les niveaux de l'infrastructure Internet (proxy-caches de l'origine, CDN intermédiaire (éventuellement), proxy-caches FAI,, poste client, etc.). Tout le monde reçoit finalement le même contenu, et dans le cadre d'une imposition de sécurité par un ayant droit X ou Y, seuls les clients qui ont accès aux clés peuvent lire ce contenu. Le réseau (et le protocole de transfert) devient donc agnostique de ce point de vue, et l'idée est justement d'éparpiller au maximum ces fragments pour que l'effet cache soit lui-aussi optimal. Sans même penser aux utilisations commerciales, le simple fait de passer sur ces technologies permet également une plus grande pénétration dans les entreprises, y compris pour de la diffusion live (ce qui ne passe pas ou très mal actuellement). De plus en plus d'opérateurs mettent en place des proxies-cache transparents dans leur core-network, voire même déploient leurs propres CDN pour minimiser les coûts de transit externes (logique, même s'ils ont des 100aines de GB avec des tiers 1, c'est quand même le nerf de la guerre). Utiliser HTTP comme protocole de transport est la garantie que ces déploiements peuvent être opérationnels relativement vite (comparés à du déploiement de serveurs RTMP par exemple, pour les raisons de coûts de licences et/ou de scalabilité à grande échelle). Ce n'est clairement pas simple de rassurer les ayants-droits (on en sait quelque chose chez Dailymotion aussi ^_^), mais c'est dans l'air du temps : avec l'avènement de la balise vidéo dans HTML5 par exemple, ainsi que du streaming sur mobiles, il va bien falloir trouver des solutions qui les rassurent tout autant. En ce qui concerne le P2P, des solutions comme Giraffic sont également séduisantes, et ne sont pas nécessairement antinomiques avec l'approche de distribution par fragments (cette approche facilite par essence le découpage de gros contenus, nécessaire à la distribution P2P). Cordialement, Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Bonjour Le 22 oct. 2010 à 18:00, BORONSKI MARTIN martin.boron...@m6.fr a écrit : Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal Je vais peut-être écrire une bêtise mais nous sommes vendredi donc je tente : Message pour les chers ayants-droit : le flux est décodé sur le poste client pour que l'utilisateur puisse le voir et rien ne garantit qu'il n'y a pas un bout de code sur ce poste client qui s'amuse à récupérer ce flux décodé. Valentin--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22 oct. 2010 à 18:00, BORONSKI MARTIN martin.boron...@m6.fr a écrit : C'est ce que nous faisons en déployant nos services directement dans les boxes. Mais bcp de gens consomment encore sur le PC ou sur iPhone/iPad. Proposition : mettre un petit message ou une banderole indiquant que M6Replay est dispo sur la TV quand l'adresse IP provient d'un FAI dont c'est le cas, juste pour info. Et aussi donner un moyen simple de retrouver sur la TV le contenu qu'on s'apprêtait à regarder sur l'ordinateur (comme un code à taper avec la télécommande). Valentin--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/2010 18:13, Thomas SOETE a écrit : Car encore actuellement, si l'on souhaite utiliser un service web on n'est pas obligé de passer par la box de l'opérateur ? Ce n'est pas ce que je propose. Ce n'est pas parcequ'un service existe dans la box qu'on est obligé de passer par lui. Si je décide que le routeur de ma Freebox est vraiment trop naze je le débranche et je me met iptable. De la même façon si je me passe de la box pour la TV, je doit pouvoir encore accéder au service standard. Mais vu le nombre d'abonnés qui mettent du vrai modem à la place de leur box, on conserve les avantages de bande passante du P2P globalement. Si on ne souhaite pas de téléphonie ni de télévision, on peut encore utiliser un modem standard. Après, mettre le DPI directement dans les boxes, quid de l'utilisateur qui vire la box pour mettre un modem standard a la place ? Il faut regarder du côté du DSLAM pour ne plus dépendre de l'utilsateur et là ce sont les FAI qui vont être content ;-) Le 22 octobre 2010 18:07, Yves Dubromelletaera...@dubronetwork.fr a écrit : Le 22/10/2010 18:00, BORONSKI MARTIN a écrit : Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( Pourquoi ne pas inclure ce genre de clients directement dans les boxes, et rendre ainsi cela plus transparent ? Quand on voit la facilité avec laquelle on nous parle d'inclure du DPI dans les boxes, on se dit que tant qu'à les alourdir autant que ça serve vraiment :) On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Article sur le NAT64 chez Networkworld
On Fri, 22 Oct 2010 10:51:59 +0200, Francois Tigeot ftig...@zefyris.com said: De cette façon, il est possible de déployer des réseaux uniquement IPv6 Deployer, oui, c'est certes possible meme si encotre tres difficile. Par contre faire vivre un reseau v6-only (tout en restant v6-only), faut avoir des nerfs d'acier et surtout pas de gens a faire pression (style PDG) pour mettre du v4 quand ca ne marche pas. Deja que dans certains endoits on a du mal a faire marcher le v6 tout court. Je sais qu'il y a des gens qui l'ont essaye, mais il sont pas vraiment mr. Toutlemonde. Tiens, puisqu'on est vendredi, je me rappelle certines installs de CentOS 5.2 ou pour mettre la route par default v6 il fallait utiliser ::/1 et non pas ::/0, a cause de bug bizzare. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 18:00:06 +0200, BORONSKI MARTIN martin.boron...@m6.fr wrote: Le 22 oct. 2010 à 09:20, Pierre-Yves Kerembellec a écrit : As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du HTML5, en dehors d'un token ? As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du ? (remplacer par une technologie qui permet à l'utilisateur de voir une vidéo, et en particulier sur le web) Oui bon, troll, mais c'est vendredi... On y réfléchit et mes équipes me poussent pour qu'on fasse le saut, mais sans sécurité state of the art et sans outils de monétisation (oui, je sais, on en revient tjs à l'argent ...), c'est pas simple. Mon avis qui vaut ce qu'il vaut : de toute façon, le contenu est diffusé illégalement (quoi que dans le cas de M6, pas tant que ça). Mais ça veut dire que des réseaux mafieux se mettent en place pour diffuser ce contenu hors de tout contrôle. Alors que s'il était diffusé officiellement dans les mêmes conditions (gratuit, simple, pas de client/plugin spécifique et lourd, toussa), le contrôle serait assuré par la non nécessité de créer des réseaux alternatifs. Et les ayants droit peuvent fournir un meilleur service que les pirates, avec une qualité garantie, l'exhaustivité du contenu, ... Sans oublier la monétisation, avec du contenu HD, l'accès aux historiques, le téléchargement des contenus... (oh, je viens de voir un bisounours chevauchant une licorne) D'ailleurs, qu'est-ce que tu entends par outils de monétisation exactement ? La pub ? Sinon pour sécuriser de la vidéo en HTML5, j'ai quelques idées à la con, mais je vois assez bien comment les contourner :/ Dans la catégorie contournable mais chiant à contourner : découper la vidéo en petit morceaux, chiffrer chaque morceau avec une clef différente, et les déchiffrer avec du Javascript. Pour le fun, changer l'algo de chiffrement régulièrement (ou même, faire un générateur d'algo de chiffrement qui en génère un nouveau pour chaque vidéo, mais ça devient un peu gore). Pas besoin d'un chiffrement compliqué, le but du jeu est juste de faire chier, donc mettre des bits en trop par ci par là, passer des trucs au XOR, faire du chiffrement de César, ... Une autre idée : toujours avec une vidéo en morceaux, ne donner le morceau suivant que si le client donne une checksum calculée sur le morceau précédent (même topo : on change l'algo souvent, et la clef est donnée au JS en échange d'un token par exemple). Variante : un seul morceau, mais tout les XXX octets le client envoi une requête avec la checksum, sans quoi le téléchargement est coupé. Ah et bien sûr, ça n'est pas la peine de le préciser mais je le fais quand même, la base c'est de ne pas utiliser des URL prédictibles... My 42 cents... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Et, rien n'empeche de l'executer ton JS ;-) C'est le même principe qu'en flash où est inclus dans le .swf une routine appelée par le serveur lui permettant de savoir si le player est bien le bon (et pas un lecteur tiers). Mais du swf ça s'analyse/exécute aussi ... :-). Intel a bien essayé avec le HDCP de continuer la chaine de confiance jusqu'au diffuseur (on pourrait donc aussi imaginer que ce soit l'écran qui déchiffre le contenu et pas la machine) ... mais la master-key HDCP a été leaké :/ Le 22 octobre 2010 19:56, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : On Fri, 22 Oct 2010 18:00:06 +0200, BORONSKI MARTIN martin.boron...@m6.fr wrote: Le 22 oct. 2010 à 09:20, Pierre-Yves Kerembellec a écrit : As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du HTML5, en dehors d'un token ? As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du ? (remplacer par une technologie qui permet à l'utilisateur de voir une vidéo, et en particulier sur le web) Oui bon, troll, mais c'est vendredi... On y réfléchit et mes équipes me poussent pour qu'on fasse le saut, mais sans sécurité state of the art et sans outils de monétisation (oui, je sais, on en revient tjs à l'argent ...), c'est pas simple. Mon avis qui vaut ce qu'il vaut : de toute façon, le contenu est diffusé illégalement (quoi que dans le cas de M6, pas tant que ça). Mais ça veut dire que des réseaux mafieux se mettent en place pour diffuser ce contenu hors de tout contrôle. Alors que s'il était diffusé officiellement dans les mêmes conditions (gratuit, simple, pas de client/plugin spécifique et lourd, toussa), le contrôle serait assuré par la non nécessité de créer des réseaux alternatifs. Et les ayants droit peuvent fournir un meilleur service que les pirates, avec une qualité garantie, l'exhaustivité du contenu, ... Sans oublier la monétisation, avec du contenu HD, l'accès aux historiques, le téléchargement des contenus... (oh, je viens de voir un bisounours chevauchant une licorne) D'ailleurs, qu'est-ce que tu entends par outils de monétisation exactement ? La pub ? Sinon pour sécuriser de la vidéo en HTML5, j'ai quelques idées à la con, mais je vois assez bien comment les contourner :/ Dans la catégorie contournable mais chiant à contourner : découper la vidéo en petit morceaux, chiffrer chaque morceau avec une clef différente, et les déchiffrer avec du Javascript. Pour le fun, changer l'algo de chiffrement régulièrement (ou même, faire un générateur d'algo de chiffrement qui en génère un nouveau pour chaque vidéo, mais ça devient un peu gore). Pas besoin d'un chiffrement compliqué, le but du jeu est juste de faire chier, donc mettre des bits en trop par ci par là, passer des trucs au XOR, faire du chiffrement de César, ... Une autre idée : toujours avec une vidéo en morceaux, ne donner le morceau suivant que si le client donne une checksum calculée sur le morceau précédent (même topo : on change l'algo souvent, et la clef est donnée au JS en échange d'un token par exemple). Variante : un seul morceau, mais tout les XXX octets le client envoi une requête avec la checksum, sans quoi le téléchargement est coupé. Ah et bien sûr, ça n'est pas la peine de le préciser mais je le fais quand même, la base c'est de ne pas utiliser des URL prédictibles... My 42 cents... -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 18:13:46 +0200, Clement Cavadore clem...@cavadore.net wrote: digression personnelle - Dommage que le multicast public n'existe pas ou peu chez les plus gros FAI résidenciel mondiaux Que quelqu'un m'arrête si je me trompe, mais l'espace d'adressage multicast IPv4 est un peu serré pour être utilisable publiquement, non ? D'ailleurs, où en est le multicast IPv6 ? Est-il routé globalement, chez certains opérateurs seulement, chez personne, ...? - Dommage que les offres résidencielles actuelles sont OBLIGATOIREMENT fournies avec un service de TV et/ou Téléphone. Essayez aujourd'hui d'avoir la fibre sans TV ou Téléphone... - OK je peux aussi ne pas utiliser le service, mais si j'ai un service comme celui-ci, pourquoi les impots ne me tomberaient pas dessus pour la redevance télé ? :)) /digression D'où la question : pourquoi s'embêter à faire des solutions qui plaisent aux geeks alors qu'ils ne regardent pas la TV ? :D -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Entre les adresses GLOP et autres, il y a déjà de quoi faire joujou un minimum... :) Que quelqu'un m'arrête si je me trompe, mais l'espace d'adressage multicast IPv4 est un peu serré pour être utilisable publiquement, non ? D'ailleurs, où en est le multicast IPv6 ? Est-il routé globalement, chez certains opérateurs seulement, chez personne, ...? Très tunnellisé, Renater (coucou Jérome) est assez moteur dans l'histoire (google m6bone :)) D'où la question : pourquoi s'embêter à faire des solutions qui plaisent aux geeks alors qu'ils ne regardent pas la TV ? :D Par rapport au multicast: Je suis bien d'accord, il serait un peu débile de le déployer globalement, vu l'usage qui en est fait sur le net. Mais avec un multicast massivement déployé, les évenements live passeraient comme une lettre à la poste (reste le probleme du on demand, certes :)) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 20:03:45 +0200, Thomas SOETE thomas+fr...@soete.org wrote: Et, rien n'empeche de l'executer ton JS ;-) C'est le même principe qu'en flash où est inclus dans le .swf une routine appelée par le serveur lui permettant de savoir si le player est bien le bon (et pas un lecteur tiers). Mais du swf ça s'analyse/exécute aussi ... :-). 100% d'accord, d'où le contournable mais chiant à contourner. Faut quand même sortir le moteur de JS et le framework multimédia pour obtenir une vidéo regardable et sauvegardée sur le disque dur. Ok, ça prend quelques lignes de pyqt, mais c'est largement moins à la porté du script kiddie que du RTMP. Surtout si tu fais chier avec des tokens et des numéros de session... Mais en fin de compte, si l'utilisteur peut voir la vidéo sur son PC, c'est bien qu'elle est décodée par son PC... La bataille est perdue à partir de ce moment là :/ Intel a bien essayé avec le HDCP de continuer la chaine de confiance jusqu'au diffuseur (on pourrait donc aussi imaginer que ce soit l'écran qui déchiffre le contenu et pas la machine) ... mais la master-key HDCP a été leaké :/ Un joli gag oui :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Article sur le NAT64 chez Networkworld
Radu-Adrian Feurdean wrote: On Fri, 22 Oct 2010 10:51:59 +0200, Francois Tigeot ftig...@zefyris.com said: De cette façon, il est possible de déployer des réseaux uniquement IPv6 Deployer, oui, c'est certes possible meme si encotre tres difficile. Par contre faire vivre un reseau v6-only (tout en restant v6-only), faut avoir des nerfs d'acier et surtout pas de gens a faire pression (style PDG) pour mettre du v4 quand ca ne marche pas. Deja que dans certains endoits on a du mal a faire marcher le v6 tout court. On peut espérer que les choses sont en train de s'améliorer, surtout qu'un jour on n'aura plus le choix. Le gros intérêt de cette techno c'est que ça permet d'avoir une certaine compatibilité v6/v4 qui manquait depuis le début et d'éviter de jeter encore plus de pognon en l'air à patcher l'existant sans espoir d'amélioration. -- Francois Tigeot, Zefyris --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On Fri, 22 Oct 2010 20:15:18 +0200, Clement Cavadore clem...@cavadore.net wrote: Par rapport au multicast: Je suis bien d'accord, il serait un peu débile de le déployer globalement, vu l'usage qui en est fait sur le net. Mais avec un multicast massivement déployé, les évenements live passeraient comme une lettre à la poste (reste le probleme du on demand, certes :)) C'était peut être pas flagrant, mais je plaisantais : d'un point de vue trafic sortant pour le réseau émetteur c'est quand même pas la même chose en multicast et en unicast... D'ailleurs je me demande si il n'y aurait pas d'autres applications potentiellement plus utilisées. Par exemple un site très fréquenté (disons google) pouraît diffuser ses images principales (disons http://www.google.fr/images/srpr/nav_logo14.png) en boucle en multicast. Certes, cela est actuellement impossible, mais et si c'était possible, est-ce que ça serait une bonne idée ? -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
A propos de P2P + DRM, je signale juste pour ceux qui ne connaissent pas http://www.ubicmedia.com et sons système http://www.pumit.com (PC only pour le moment, à cause de Steve Jobs...) qui a démarré il y a bientôt 4 ans... J'y ai bossé de début 2007 à fin 2008, j'en suis toujours actionnaire : les majors US finisent enfin à regarder de très près ce système, qui permet de contrôler les usages d'un film (par mis en relation directe du consommateur avec l'ayant roit qui définit la contrepartie, marchande ou non, au visionnage du film) tout en favorisant sa copie par tous moyens, y compris le P2P, le préchargement sur des disques durs ou clés USB vendus dans le commerce, etc etc. Tout est imaginable, mais un système aussi ouvert effraient les majors qui manquaient encore d'imagination. cela change, nécessité fait loi :-) Déjà utilisé par quelques indépendants qui ont compris que le P2P est bien moins cher et efficace pour distribuer des films : - http://www.westcoasttheory.fr/ - http://goldmenlefilm.kanarifilms.fr/ Fin du HS du vendredi, mon mail perso est dispo pour ceux qui veulent en savoir plus... ça peut s'implémenter sur des box de FAI, aussi :-) -- Pierre - Original Message - From: BORONSKI MARTIN To: Stefan P Cc: Rémi Bouhl ; frnog@FRnOG.org Sent: Friday, October 22, 2010 6:00 PM Subject: Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ? Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. Martin Le 22 oct. 2010 à 11:56, Stefan P a écrit : Bonjour à tous, Déja, merci pour ce thread très on-topic et intéressant. J'ai une remarque relative à cette histoire de P2P-VoD: je ne comprends pas en quoi le fait d'utiliser cette techno de diffusion ou une autre a une incidence sur le piratage des contenus. A priori, le flux n'est visible que par des utilisateurs ayant installé une application client spécifique, qui, j'imagine, ne redistribue les paquets qu'a des peers ayant un token approprié et/ou sous forme cryptée - ce qui fait qu'un autre client doit etre aussi authentifié que le client initial. J'ai l'impression que l'ayant droit de l'histoire réagit à un accronyme à trois lettres: P2P == je distribue mes contenus en clair sur bittorrent, ce qui n'est manifestement pas le cas ici. Bien sur, il est toujours possible de casser les limitations et protections du client P2P-VoD, mais comme le soulignait quelqu'un dans le thread, tous les contenus sont de toutes façons disponibles illégalement. Je ne crois pas que cela serait plus facie avec cette techno. Et dans ce contexte, réduire le cout des solutions légales me parrait etre la meilleure chose à faire, dans la mesure ou cela peut permettre (on peut réver) de réduire leur prix, et donc l'attractivité des version pirates. Un autre point qui me fait réagir: le P2P reporte le cout sur l'ISP - c'est sans doute vrai, mais long terme, c'est peut-être bénéfique: cela aurait tendance à pousser les ISP à continuer de construire des réseaux adaptés à cette architecture, c'est à dire (pardonnez ma terminologie ghetto) fortement maillés. En tant qu'ingénieur, utilisateur et meme cityoyen, je prefere un réseau permettant des hauts débits entre utilisateurs à un réseau optimisé pour quelques gros emetteurs, ce qui semble non seulement être un casse-tete pour tout le monde, mais en plus représente l'inverse de ce que le net a apporté, et des raisons de son succès: l'echange entre individus, pair à pair, pas forcement à tous les niveaux techniques mais en tout cas dans l'utilisation finale. My 20 cents :p Stefan 2010/10/22 BORONSKI MARTIN martin.boron...@m6.fr On a été approché par plusieurs éditeurs de ce type de solutions, et elles sont toutes très séduisantes. Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je préfère ne pas prendre de risque. J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si c'est aussi le taux de perte financière en perdant certains de nos contenus, ça n'a plus de sens. Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire du transit sur les contenus sensibles, mais du coup ça fait deux
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Yves Dubromelle wrote: Pourquoi ne pas inclure ce genre de clients directement dans les boxes, et rendre ainsi cela plus transparent ? C'est l'idéal. Dès 2007 on (les fondateurs de UbicMedia) a approché les FAI et constructeurs de box français : jusqu'à maintenant, et cela est tout juste en train d'évoluer depuis quelque ssemaines, les ayants droit ( = majors du cinéma US) obligent les FAI à faire du streaming vers les box, et leur interdisent le téléchargement par peur du piratage. Et pour la VOD sur PC elles imposent les DRM Microsoft avec lesquels elles ont protégé tous leurs catalogues... PUMit résoud élégamment le problème de l aVOD, puisque le fichier downloadé est totalement inutilisable sans qu'un stream représentant 1% du contenu ne soit streamé pour le compléter et permettra au petit soft PUMit reader de reconstituer à la volée le flux MPEG-4 envoyé sur la carte vidéo du PC, ou l'interface vidéo de la box. 100% des abonnés ADSL et satellite sot de fait éligibles à de la VOD en vraie HD. 1% d'un stream ça passe sur de la 3G et même du GPRS pour de la qualité DVD, et cela passe aussi sur de l'ADSL à 1 Mb/s pour de la vraie HD..., celle en 1920 x 1080 encodé en très bonne qualité à 30 fps sans aucun artefact, soit des streamns de 30 à 40 Mb/s : 1% cela ne fait, et les 20 Go du film brouillé passent en P2P en quelques heures, faut juste pas lancer le download à 18 h si l'on veut voir le film à 20 h mais avec un bon EPG qui remplit un aniede download cela se gère... Si vous ne m'arrêtez pas je serai intarissable, heureusement pour vous ce week-end je ne suis pas là :-) -- Pierre Col --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
On 22 oct. 2010, at 22:17, Pierre Col wrote: Valentin Descamps wrote: Je vais peut-être écrire une bêtise mais nous sommes vendredi donc je tente : Message pour les chers ayants-droit : le flux est décodé sur le poste client pour que l'utilisateur puisse le voir et rien ne garantit qu'il n'y a pas un bout de code sur ce poste client qui s'amuse à récupérer ce flux décodé. Non, vraiment, désolé mais là tu te trompes : sur Windows on peut garantir que l eflux ne sera pas intercepté entre un soft qui génère le flux MPEG-4 et l'écran qui l'affiche en passant par la carte vidéo. Sinon en effet PUMit n'aurait aucun sens : les labos techniques des majors US et MovieLabs ont validé PUMit sur PC tout récemment, et croyez-moi ils ont désespérément essayé de craquer le truc dans tous le sens pour nous renvoyer dans nos foyers :-) . Sur Mac, en revanche en passant par le stack QuickTime on ne peut pas protéger le flux qui peut être intercepté : la seulesolution aujourd'huiserait de développer du bas niveau pas portable dans les tréfonds de la gestion vidéo de MacOS X c'est pas dans les moyens actuels de UbicMedia... C'est aussi pourquoi Apple a de grosse difficultés avec les majors US... ca n'empeche pas de passer par la sortie dvi / hdmi, et un fpga pour déchiffrer l'éventuel hdcp pour capturer le flux non compressé au format numérique bref, y'a toujours un trou... a moins de faire des systemes implantables dans l'etre humain (et encore), je crois que les ayants droits ne se fassent des illusions sur le fait que leur chers contenus sont protégés par un quelconque DRM--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Hum ... a partir du moment ou un algorithme peut le déchiffrer, le même algo dans un autre programme peut le déchiffrer. C'est comme ça, on peut rien y faire, et la sécurité par l'opacité n'est qu'une question de temps et de patience. On a bien vu ce que ça donnait avec CSS / AACS / BD+ / FairPlay / ... même les DRM microsoft étaient crackée il y a quelques temps (je sais pas si ça a évolué). Je ne connais pas a l'heure actuelle une seule techno qui a tenu le coup ! Le 22 octobre 2010 22:17, Pierre Col p...@9online.fr a écrit : Valentin Descamps wrote: Je vais peut-être écrire une bêtise mais nous sommes vendredi donc je tente : Message pour les chers ayants-droit : le flux est décodé sur le poste client pour que l'utilisateur puisse le voir et rien ne garantit qu'il n'y a pas un bout de code sur ce poste client qui s'amuse à récupérer ce flux décodé. Non, vraiment, désolé mais là tu te trompes : sur Windows on peut garantir que l eflux ne sera pas intercepté entre un soft qui génère le flux MPEG-4 et l'écran qui l'affiche en passant par la carte vidéo. Sinon en effet PUMit n'aurait aucun sens : les labos techniques des majors US et MovieLabs ont validé PUMit sur PC tout récemment, et croyez-moi ils ont désespérément essayé de craquer le truc dans tous le sens pour nous renvoyer dans nos foyers :-) . Sur Mac, en revanche en passant par le stack QuickTime on ne peut pas protéger le flux qui peut être intercepté : la seulesolution aujourd'huiserait de développer du bas niveau pas portable dans les tréfonds de la gestion vidéo de MacOS X c'est pas dans les moyens actuels de UbicMedia... C'est aussi pourquoi Apple a de grosse difficultés avec les majors US... -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le jeudi 21 octobre 2010 à 23:40 +0200, BORONSKI MARTIN a écrit : Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est interdit par nos ayants droits :( On doit se contenter de technologies classiques comme Flash ou Silverlight. Malheureusement, nous n'avons pas trop le choix. Martin On pourrait tout à fait avoir un client p2p embarqué dans une applet silverlight. En flash c'est moins probable, la gestion de la ram et des sockets est vraiment pourrie (surtout limitée). Par contre, comme la probabilité d'avoir des sources dispo pour une demande de contenu est faible car ça implique que l'applet soit chargée sur le même fichier au même moment. Donc l'infra de distribution classique devrait persister. Donc ça ne vaut pas le coup de s'y pencher. -- Jérôme Nicolle 06 19 31 27 14 signature.asc Description: Ceci est une partie de message numériquement signée
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
BORONSKI MARTIN wrote: Je pense qu'un modèle P2P+DRM devrait être assez convaincant sur le papier, mais il reste 2 problèmes : - les chunks, même DRMisés, se retrouvent dans la nature ... et ça c'est mal - il faut installer un client pour supporter tout cela, et ça c'est aussi mal, car ça rend l'expérience utilisateur plus complexe : je me connecte, je dois installer un logiciel qui dans une minorité de cas va me faire des écrans bleus / rideaux gris / plantages / ... et ensuite j'aurai peut-être accès au contenu ... autant continuer à pirater :( On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. Ah ? Flash/Silverlight/Autres niaiseries c'est pas un truc en plus à installer, source de plantages ? -- Julien. attachment: julien.vcf
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Tss, tss et vous avez quoi derrière pour décoder ce flux sous win ? Une fois que l'on à le code on enregistre et on peux le redistribuer via d'autres canaux. Pumit n'a déja aucun sens pour moi avec une simple page web et avec un bouton contact qui demande de taper l'adresse du support :) Enfin je en sais pas vous ne savez même pas faire une simple page web bonjour la pub. Désolé on est encore vendredi. Pour ubcdmedia certes vous fournissez le player mais désolé je suis comme beaucoup de gens (aussi bien window que linux), je me suis paramétré mon ou mes lecteurs vidéos pour avoir mes préférences vis à vis de la calibration de mes écrans, de mes enceintes et de mon home cinema sur mon petit réseau interne. Je ne vais pas m'amuser à changer de player pour chaque type de film que je vais regarder qu'ils viennes ne ubcd ou d'amazon. Bref c'est pareils avec tout (livres, vidéos et autres médias). Personnellement pour l'utilisateur qui a des thunes et qui veut rentabiliser son matos vous pouvez laisser tomber. Ca me rappelle la tendance realplayer sortie à l'époque bref vous vous cassez les dents d'avance. Cordialement, Le Fri, 22 Oct 2010 22:17:06 +0200, Pierre Col p...@9online.fr a écrit: Valentin Descamps wrote: Je vais peut-être écrire une bêtise mais nous sommes vendredi donc je tente : Message pour les chers ayants-droit : le flux est décodé sur le poste client pour que l'utilisateur puisse le voir et rien ne garantit qu'il n'y a pas un bout de code sur ce poste client qui s'amuse à récupérer ce flux décodé. Non, vraiment, désolé mais là tu te trompes : sur Windows on peut garantir que l eflux ne sera pas intercepté entre un soft qui génère le flux MPEG-4 et l'écran qui l'affiche en passant par la carte vidéo. Sinon en effet PUMit n'aurait aucun sens : les labos techniques des majors US et MovieLabs ont validé PUMit sur PC tout récemment, et croyez-moi ils ont désespérément essayé de craquer le truc dans tous le sens pour nous renvoyer dans nos foyers :-) . Sur Mac, en revanche en passant par le stack QuickTime on ne peut pas protéger le flux qui peut être intercepté : la seulesolution aujourd'huiserait de développer du bas niveau pas portable dans les tréfonds de la gestion vidéo de MacOS X c'est pas dans les moyens actuels de UbicMedia... C'est aussi pourquoi Apple a de grosse difficultés avec les majors US... -- --- Refuznik --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?
Le 22/10/10, Julien Reitzeljul...@reitzel.info a écrit : BORONSKI MARTIN wrote: On a tenté ce type de clients qques années de cela, c'était un calvaire pour nos internautes. On préfère rendre l'expérience utilisateur la plus smooth possible : je me connecte et j'ai la vidéo de suite. C'est ce qu'on a trouvé de plus efficace pour luter autant que possible contre le piratage. Ah ? Flash/Silverlight/Autres niaiseries c'est pas un truc en plus à installer, source de plantages ? Si, mais c'est la même sauce de partout. Pour le consommateur lambda ça fait partie de son navigateur, il l'installe la première fois qu'on lui dit de l'installer, et après ça marche partout. À tel point que y'a des gens qui ont vraiment du mal à comprendre quand on leur dit J'ai pas Flash. Ah bon, mais comment tu fais sur le Web? _ Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
