GuiGui's Show

Supposons un Debian GNU/Linux installé sur un ordinateur monocarte d'architecture arm64. Supposons que cet ordinateur tombe définitivement en panne. Pas d'ordinateur monocarte de remplacement donc on souhaite que cet ordinateur soit remplacé par une machine virtuelle... dont l'architecture est amd64. Donc les binaires ne sont pas compatibles, on peut pas juste copier le rootfs de l'un à l'autre.

Donc il faut extraire la liste des logiciels installés pour les installer sur la machine virtuelle vierge. Sauf qu'on ne peut pas exécuter un dpkg --get-selections sur la source sauf à se prendre la tête avec de l'émulation qemu.

Si l'on a accès au rootfs de l'ordinateur en panne, on peut extraire cette liste depuis /var/lib/dpkg/status :

grep -B1 "Status: install ok installed" /var/lib/dpkg/status | grep -Po "(?<=Package: ).*" | tr '\n' ' '

Pour une raison qui m'échappe, ça va aussi faire remonter des logiciels d'une ancienne version majeure de Debian. Genre moi j'ai eu la libgcrypt11 qui était celle de Wheezy alors que j'utilise Jessie et que la libgcrypt20 est installée...

Un autre point d'éducation civique discuté cet après-midi sur le chan IRC d'ARN : en France, lors de la nomination d'un gouvernement, est-ce qu'il y a une approbation systématique de ce gouvernement par l'Assemblée nationale ?

Oui et non, plutôt non. Le système de double investiture s'est terminé avec la 4e République. Il est remplacé par les articles 49.1 et 50.1 de la Constitution.

Le 49.1 permet au gouvernement, s'il le souhaite, de demander l'approbation d'une politique générale ou de son programme. C'est ce qu'on nomme le vote de confiance. Si l'Assemblée refuse (ce n'est jamais arrivé ;) pour la simple raison que le Premier ministre est toujours issu de la majorité à l'Assemblée pour justement éviter ce type de couperet et parce que le Premier ministre est responsable devant le Parlement et surtout, toujours pour le problème de "je suis un-e gentil-le député-e qui veut son investiture et se voir confier des missions intéressantes voire un job dans un ministère), vlam le gouvernement est défait obligatoirement. C'est une coutume de soumettre le nouveau gouvernement à l'approbation de l'Assemblée depuis 1993 (avant, les Premier ministres se sentaient légitime par leur nomination par le Président lui-même élu par le peuple donc ils n'utilisaient pas le 49.1) mais ce n'est pas une obligation.

Le 50.1 permet de faire une déclaration thématique qui peut être votée mais qui n'engage à rien. C'est ce qu'a fait Valls sur le pacte de responsabilité et de solidarité, par exemple

Après 7h30 de débats, les députés, réunis à l'Assemblée à nationale, ont voté la prolongation de l'Etat d'urgence, six jours après l'attentat à Nice. Plusieurs mesures, comme la fouille des bagages et des véhicules, ont également été adoptées.

J'ai écouté les causeries (je refuse de nommer ça « débats » vu la médiocrité ambiante) des député-é-s et voilà ce que j'en retiens.

• Les prétextes ultimes : il faut de l'efficacité + les Français-e-s sont en colère, ils-elles veulent des résultats. Sur ces deux motifs, on peut faire n'importe quoi.
  
  
• Il y avait aussi un contexte politique : le groupe Les Républicains cherchait clairement à affirmer la ligne de leur parti (autorité, sécurité, etc.) comme s'il était en campagne. Mais ce parti cherchait aussi à éviter les reproches (préjudiciables à l'élection à venir) qui seront formulés de toutes parts lors de l'éventuel prochain attentat en mode "c'pas notre faute, on avait tout bien proposé au PS qui n'a rien voulu entendre mais votez pour nous en 2017, quand on aura les mains détachées, on pourra vous protéger efficacement". C'est à gerber.
  
  

• Avec ces prétextes, on a eu le pire du sécuritaire :

  • NKM : agence de renseignement digitale unique comme la NSA. Nos services ne sont pas assez versés dans le digital . Alala les doigts, ça en fascine plus d'un-e ! :) ;
    
    
  • Prolongation de 10 mois voire 1 an histoire de pas refaire les mêmes débats indéfiniment. Si, si, ça a été dit comme ça par Ciotti ;
    
    
  • Pour certains parlementaires, les associations qui construisent et occupent les lieux de culte sont responsables des propos. Ah bah voilà, y'a pas que dans le numérique qu'ils ne savent pas faire la part des choses ! ;
    
    
  • Centres de rétention ou bracelets électroniques pour toutes les personnes fichées S s'il y a des « raisons sérieuses de penser que ». Mais bien sûr. Peine indéterminée, privation de liberté par le juge administratif, disproportionnalité, société de la suspicion, tout y est… ;
    
    
  • Assignation à résidence : obligation de présence chez toi de 12 à 24 mois -> ouais donc tu deviens prisonnier -> privation de liberté sans juge -> interdit ;
    
    
  • Virer le cadre + les conditions + les autorités habilitées à en faire des contrôles d'identité. Mais bien sûr. Histoire de faire encore plus de faciés et d'emmerder tout citoyen ! ;
    
    
  • Retrait de la carte de séjour si poursuivi (pas condamné ! ) pour toute infraction pénale (toute !) … retour de la déchéance de nationalité … retour des exclusions …
• On notera la rhétorique utilisée notamment par Les Républicains (et le FN) car ça en dit très très long : il faut mettre de côté la Constitution au profit de la sécurité ; La France serait face à un « désarmement pénal » (très "drôle" après le passage de la loi de réforme pénale y'a quelques mois) ; envoyons les terroristes loin, osef de ce que ça produit tant que c'pas chez nous (oui, très bel effet Nimby) ; le gouvernement doit abandonner « sa vision idéologique sectaire de l'état de droit » ; il faut adapter l'état du droit ; il faut un gouvernement de guerre ; il faut une justice d'exception conduite par une Cour de sûreté de l'État ; appel à la guerre à l'étranger en mode USA contre Al-Qaïda ; la vision EU et française de l'immigration est de la naïveté ; guerre ; effort de guerre ; réarmement ; l'état d'urgence, c'est l'état de droit (dit plusieurs fois par des députés Les Républicains)
  
  
• Les député-e-s qui ont été le plus loin dans la surenchère sécuritaire selon moi (liste non ordonnée) : Guillaume Larrivé (LR), Christian Jacob (LR), Éric Ciotti (LR), Valérie Boyer (LR), Jacques Bompard (Debout la France).
  
  
• Je note que les député-e-s commettent sans arrêt les mêmes fautes déjà sanctionnées par le Conseil Constitutionnel comme la rupture d'égalité, les peines automatiques (qui sont interdites, principe fondamental d'individualisation des peines), etc. C'est les ministres (et donc les conseillers cachés) qui doivent apprendre aux parlementaires à faire la loi… … … Je passe sur le fait que même hors numérique, les député-e-s causent de ce qu'ils-elles ne connaissent pas : la méconnaissance de ce que sont les fiches S a été criante.

Au final :

• 515 votant-e-s, 489 pour, 26 contre . Qui a voté quoi : http://www2.assemblee-nationale.fr/scrutins/detail/%28legislature%29/14/%28num%29/1326 ;
  
  
• Prolongation pour 6 mois (notons que le gouvernement a demandé 3 mois, le reste, c'est les parlementaires ;) ) ;
  
  
• Retour des perquisitions administratives (au cas où les terroristes n'auraient pas tout planqué en plus de 6 mois … ) ;
  
  
• Retour des perquisitions informatiques. J'ai pas encore regardé le cadre dans lequel elles se dérouleront… ;
  
  
• Contrôle d'identité + fouille des véhicules et des bagages sans accord du proprio et sans passer par un procureur (la loi de réforme pénale a accordé la fouille des bagages aux parquets) ;
  
  
• Non-automatisation des réductions de peine pour les terroristes condamnés ;
  
  
• Vidéosurveillance des cellules de détention (y compris provisoire) ;

Ma lecture du brouillon des lignes directrices relatives à l'application de la neutralité des réseaux concocté par le régulateur européen des télécoms + ma réponse à la consultation publique organisée par le même régulateur du 6 juin au 18 juillet 2016.

Généralités

• Je rappelle que le Règlement européen propose une bonne définition de la neutralité des réseaux (qu'il nomme « Internet ouvert » :'( ) : « Les utilisateurs finals ont le droit d’accéder aux informations et aux contenus et de les diffuser, d’utiliser et de fournir des applications et des services et d’utiliser les équipements terminaux de leur choix, quel que soit le lieu où se trouve l’utilisateur final ou le fournisseur, et quels que soient le lieu, l’origine ou la destination de l’information, du contenu, de l’application ou du service, par l’intermédiaire de leur service d’accès à l’internet. ». On a donc un cadre général protecteur (cet article 3(1) ) que des exceptions viennent restreindre.
  
  
• Les régulateurs nationaux sont là pour surveiller et assurer l'application des garde-fous permettant un traitement équitable et non discriminatoire sur les services d'accès à Internet ainsi que la protection de l'innovation et des droits afférents des utilisateurs (considérant 1). C'est bien de le dire. :)
  
  
• Considérant 3 : les régulateurs européens ont déjà constaté des mesures de gestion du trafic qui bloquent ou ralentissent des applis et services ! Ils ont constaté que ces mesures affectent un nombre significatif d'utilisateurs. Biiiiiiien. Respect My Net ( https://respectmynet.eu/ ) n'aura pas été inutile ! \o/
  
  
• Paragraphe 6 : les régulateurs nationaux peuvent prendre en compte les politiques d'interconnexion et les pratiques des FAI si celles-ci limitent les droits des utilisateurs (ceux prévus à l'article 3(1) du Règlement européen, le cadre général) et/ou si elles permettent de contourner le Règlement européen. Bien. Le paragraphe 89 va dans le même sens. Mais le paragraphe 47 indique que l'article 3(3) du Règlement européen, qui cause du traitement équitable tout ça, n'est pas applicable aux interconnections. Or, le paragraphe 89 dépend de l'article 3(3) dernier paragraphe. C'est donc confus. :S
  
  

• Paragraphe 8 et suivants : seuls sont soumis au règlement européen les fournisseurs de communications électroniques au public qui englobent réseaux de communication publics + services de communication électroniques publics.

  • Service d'accès à Internet = service de communication électronique. VPN qui offre un acccès à Internet = service de communication électronique aussi. \o/
    
    
  • Publics = pas ouverts uniquement à un groupe restreint, tout le monde peut y souscrire donc : le hotspot d'un restaurant ou café, s'il est limité aux clients, n'est pas public, même chose pour les réseaux d'entreprises / universités, etc.
    
    
  • Les FSI sont protégés (considérés comme des utilisateurs à l'extrémité du réseau) par la régulation s'ils ne sont pas leur propre FAI (Google et Wikipedia, s'ils étaient basés en EU ne seraient donc pas concernés, par exemple car ils sont leur propre opérateur réseau).

• Paragraphe 16 : même si un accès Internet se définit comme l'accès à toutes les extrémités de ce réseau (sauf contraintes techniques ou légales) ne peut pas être vu comme une obligation de fournir une connectivité IPv6 et IPv4. Bien vu, les grozopérateurs… Pourtant IPv6 est nécessaire au maintien d'un Internet ouvert. Exemple : quand le RIPE et les LIR seront à sec et que l'on n'a pas migré : comment je monte un FAI associatif ? 99,99 % des LIR veulent que le FAI monte une interconnexion avec lui au nom du principe "je dois pouvoir router tout mon réseau". Or, les interconnexions coûtent cher, surtout si le LIR est à Paris et que tu montes un FAI en province. Ça sera une structure d'exclusion. De même si je veux monter un service : je devrais le faire chez un gros hébergeur qui aura encore des IPv4. Concentration des acteurs.

  • Correction par Benjamin : l'approche est pertinente en terme de régulation mais elle est sur le long terme. Il vaut mieux attaquer sur le fait que les FAI ne distribuent pas une IP publique sur les accès Internet mobiles et que l'utilisateur ne peut donc pas fournir les services de son choix. Et que le problème va arriver très vite sur les accès fixe. Histoire de mieux présenter l'urgence au BEREC.
• Paragraphe 17 : si c'est prévu dans le contrat, tout accès avec des applis et services en moins (exemple : ban de la VOIP) ou qui donne accès à quelques bouts d'Internet présélectionnés est considéré comme un service à sub-Internet et enfreint l'article 3.3 du règlement européen (paragraphe 52). Si c'est fait techniquement, sans contrat, alors c'est une infraction au règlement européen. \o/
  
  

Liberté de choisir son terminal d'accès (plutôt décevant)

• Considérant 5 (+ paragraphes 23 et suivants) : les utilisateurs peuvent utiliser l'équipement terminal de leur choix. Les FAI ne devraient pas en imposer ni restreindre le choix. C'quoi un terminal ? Un truc connecté (in)directement à l'interface publique d'un réseau de communication, c'est-à-dire le point physique où le service est fourni à un abonné.
  
  
• Pour un accès mobile, ça devrait être le modem, la puce baseband d'un ordiphone. Pour un accès fixe, ça devrait être le modem. Il est d'ailleurs séparé de la box sur les offres fibre. Donc, l'utilisateur devrait pouvoir remplacer sa box. Voir http://blog.fdn.fr/?post/2016/05/18/Liberte-de-choix-du-terminal
  
  

• Pour moi, c'est incomplet :

  • Ça ne dit pas clairement si le point de terminaison = box ou modem. L'interface publique du réseau de communications électroniques, c'est le modem car il cause la norme du réseau (genre la couleur de la fibre, les fréquences câbles, etc.). Donc leur définition va plutôt dans notre sens. Mais, paragraphe 51, on a « Endpoint-based congestion control 11 (a typical example is Transmission Control Protocol (TCP) congestion control) does not contravene Article 3(3) first subparagraph since, by definition, it takes place within terminal equipment and terminal equipment is not covered by the Regulation. ». Or, la box ne cause pas TCP. :S
    
    
  • Ce point est un point central de la régulation car le paragraphe 75 dit que les restrictions mises en place côté utilisateurs sont hors champ de la régulation. Même chose pour le contrôle de la congestion dans le paragraphe 51 (or, le tag QoS peut être mis par le terminal pour déclencher l'action de priorisation dans le backbone). Donc des pans entiers de la régulation dépendent de la liberté de choix du terminal.
    
    

  • Sur les offres FTTH, pour juste avoir accès à Internet, il faut que le routeur de remplacement envoie un vendor-id (attribut dans la requête DHCP, voir https://www.neufbox4.org/wiki/index.php?title=Bypasser_sa_neufbox#Le_.22Vendor_class_identifier.22 ) soit générique soit spécifique à un réseau (RIP) ou localité donnée ! Qui peut se permettre un tcpdump de sa connexion pour le trouver ?! Le choix du terminal n'est pas garanti !

    • Correction de Benjamin : attention, le BEREC est plus composé de juristes que d'ingénieurs. Donc attribut dans un protocole, ça leur passe au-dessus de la tête. :D
  • Quid des offres triple-play et de leurs services spécialisés ? La liberté ne s'applique plus. Ça devrait ! Ça ne nuit pas aux droits des utilisateurs mais ça incite à garder la box pour profiter des services greffés sur le service d'accès à Internet que sont la téléphonie et la télévision et que l'utilisateur paye tous les mois. Donc ça peut nuire aux droits des utilisateurs, pour reprendre la classification du BEREC sur les offres zero-rating.
    
    

  • Je n'ai pas de vraies idées pour corriger ça.

    • Je pense que les FAI doivent indiquer, sur la facture, le prix de chaque service vendu dans le bundle tripe-play : TV, téléphone, location de la box. Ainsi, le consommateur éclairé peut comparer le prix de l'offre de téléphonie incorporée à celle d'un autre acteur (OVH, par exemple). Même chose pour la box : la location est-elle rentable ? Au bout de combien de mois ? Est-ce que je déménage souvent ? À chacun-e de juger. Pour que le consommateur éclairé puisse avoir une chance de choisir un routeur différent, il faut que les spécifications techniques (numéro de VLAN, identifiants, vendor-id, etc.) de la fourniture des services de l'offre triple-play soient publiques. C'est de la transparence nécessaire à un marché en concurrence pure et parfaite, ça devrait plaire à l'UE.
      
      
    • Il faut que la régulation impose des offres d'accès à Internet nue (sans téléphonie ni TV ni autre service dépendant) qui soient sans surcoûts, accessibles facilement sur simple demande et clairement identifiable dans le catalogue des grozopérateurs. Mon FAI est un FAI, pas un fournisseur de TV, il est temps de revenir aux bases. :-
• Paragraphe 25 : Est-ce que le terminal fait partie du réseau du FAI ? Il doit y avoir une raison technique objective. Super, merci, ça n'aide pas vraiment. :( Free faisait ça pour ne pas facturer la location à ses clients et pour éviter de publier le code source modifié…
  
  

Zero-rating (plutôt décevant)

• Paragraphe 33 : même si c'est sans impact réel sur les droits et libertés, je n'aime pas le fait qu'un FAI me propose un accès gratuit à un service (genre une plateforme de streaming de musique) pendant une période donnée quand je m'abonne : un FAI c'est un FAI, il n'a pas à proposer ça ! Pas plus qu'un assembleur d'ordi (voir http://www.guiguishow.info/2013/12/31/va-te-faire-foutre-uefi/ ).
  
  

• Considérant 7 : d'éventuels contrats entre FAI et clients sur des tarifs pour des débits et des volumes différenciés, des caractéristiques techniques ou toute pratique commerciale ne doivent pas restreindre les droits des clients (ceux du cadre général, article 3(1). C'est le cadre général du Règlement.

  • Acheter 50 Mo de trafic ou 200 Mo ou 5 Go = OK. Mais évidemment, des pratiques commerciales différentes en fonction des catégorie de trafic peuvent influer les droits des utilisateurs sans les restreindre. facepalm ! « peuvent » ! :'(
• Zero rating : prix = 0 pour le trafic d'une appli ou d'une catégories d'applis donc ça ne compte pas dans le forfait. Quand le forfait arrive à 0, ces applis doivent aussi être limitées ou bloquées (selon la politique de l'opérateur) sinon ça constitue une infraction au Règlement européen. Très juste. Plus le plafond des données mobiles est bas, plus la tentation pour le client d'utiliser des applis zero-ratées sera forte. Très juste aussi. Privilégier une catégorie d'applis c'est moins mal que de privilégier une appli. Concurrence "déployale" intrasectorielle pas OK, concurrence "déloyale" intersectorielle OK… Mouais.
  
  
• Pour décider si ce genre de pratiques réduisent concrètement les droits des utilisateurs, les régulateurs européens doivent prendre en compte : la dominance de l'acteur concerné sur son marché (FAI comme FSI), si la mesure a un impact sur la diversité des applis et contenus et services auxquels l'utilisateur peut accéder (où que les FSI peuvent diffuser), si les FAI posent des barrières à l'entrée de nouveaux FSI, si un FSI est matériellement contraint de quitter le marché, si y'a de la concurrence (nombre de FAI + nombre d'utilisateurs impactés), l'impact sur la liberté d'expression et la pluralité des médias, etc.
  
  
• Pour moi, c'est incomplet :
  • On est sur du cas par cas. Chaque pratique prendra du temps pour être examiné puis sanctionné, par chaque régulateur national. Or, certains cas sont gravissimes comme SFR qui "offrira" un accès à Libération car c'est la même maison mère. C'est une sorte d'attaque par déni de service de la part des opérateurs sur les régulateurs télécoms. D'autant que cela crééra des habitudes d'utilisation chez les utilisateurs qui n'auraient pas forcément plébiscités ce service ou application sans cet aspect "gratuit". Si ça peut limiter les droits, comme le dit le BEREC, pourquoi ne pas les interdire totalement ? Le Règlement européen autorise uniquement les accords entre utilisateurs et FAI qui ne limitent pas les droits des premiers.
    
    
  • Je me méfie de l'appréciation du BEREC (paragraphe 45) : si un FAI propose un prix différencié pour le trafic d'une appli ou d'une catégorie d'applis et que ce prix est plus élevé, alors ça crée une forte désincitation d'usage et donc c'est de nature à limiter les droits des utilisateurs. En revanche, "offrir" gratuitement une appli ou catégorie d'applis, ça crée juste une incitation économique (paragraphe 39)… N'importe quoi. Offrir telle appli ou catégorie d'applis OU faire payer toutes les applis plus chères sauf une, c'est exactement la même chose et ça produit le même impact : qui continuera sérieusement à payer l'appli non zero-ratée ?!
    
    
  • Le zero-rating limite forcément la liberté de choix des utilisateurs et la liberté de fournir des services/applications : si je n'ai pas d'audience parce que le jeu est truqué, c'est pas cool. Il faut payer pour accéder à mon information/contenu et pas à celle d'autres acteurs.
    
    

Gestion du trafic - Qualité de service (plutôt bon)

• Principe général du règlement européen (article 3(3) : les FAI doivent traiter tous les trafics équitablement, sans discrimination ou interférence sans s'occuper de l'émetteur, du récepteur, du contenu ou du terminal utilisé.
  
  
• Les mécanismes de gestion de congestion utilisées sur les extrémités du réseau (exemple : TCP, ECN) ne sont pas concernés (paragraphe 51). Les mécanismes dans les routeurs comme AQM sont OK tant qu'ils sont agnostiques des applications utilisées. C'est un bon début. Mais justement, quid de DiffServ/IntServ où le marquage serait effectué sur le terminal et l'action de priorisation/congestion prise par le réseau ? Ce point est tenable uniquement si j'ai le contrôle total de mon terminal d'accès…
  
  

• Le principe général n'empêche pas les FAI de prendre des mesures de gestion du trafic raisonnables mais elles doivent être transparentes, non discriminantes, proportionnées, et basées exclusivement sur un besoin différencié d'une qualité de service de la part d'une catégorie de trafic. Ces mesures ne peuvent regarder le contenu (au-delà de la couche de transport, ni discriminer le trafic chiffré, paragraphes 66 et 67) ni être maintenues plus longtemps que nécessaire.

  • Des mesures de gestion de trafic qui distinguent des catégories de trafic objectivement différentes sur le plan technique (sensibilité à la perte de paquets, sensibilité à la latence, etc.) (paragraphe 59) sont OK. Genre différencier la VOIP (latence) ou SSH (perte de paquets) : OK. Prioriser le VLAN de management : OK.
    
    
  • Transparentes : le dire à l'utilisateur sur brochure, sur site web, pas noyé dans CGV.
    
    
  • Elles sont légitimes si elles permettent un meilleur usage efficace global du réseau (paragraphe 61).
    
    
  • Elles ne sont pas basées sur des considérations commerciales (paragraphe 65). On ne peut donc pas facturer différemment des catégories de trafic différentes. \o/
    
    
  • Pas plus longtemps que nécessaire : dans le temps. On peut procéder à des déclenchements auto mais leur activation récurrente est louche et les régulateurs devraient regarder si la mesure est vraiment raisonnable.
    
    
  • Toute pratique qui va au-delà de ces mesures raisonnables de gestion du trafic en bloquant, ralentissant, altérant, restreignant, qui interfère, dégrade ou discrimine certains contenus, applis ou services ou des catégories enfreint le règlement européen (74 et suivants). \o/

• Considérant 11 : la compression de données sans modification du contenu est autorisée parce qu'elle participe à l'optimisation globale du réseau et que ça rend service à l'utilisateur.

  • J'y suis opposé : ça signifie que le FAI possède des proxy transparents par lesquels transite mon trafic web non chiffré ! Ces machines ont les URL dans leurs journaux. On interdit aux FAI d'aller plus haut que la couche transport pour leurs mesures de gestion du trafic dans les paragraphes 66 et 67 et dans le CPCE mais là, lala ?! Ce n'est pas au FAI de décider mais aux extrémités du réseau : le site web auquel j'accède propose gzip, mon navigateur accepte. De même que La Poste ne réorganise pas mes colis. Au moins, la compression et mise en cache de SFR ( voir https://reflets.info/sfr-man-in-the-middle-oui-cest-particulierement-grave/ ) ne passera pas car elle altère le contenu, c'est déjà ça mais c'est peu.

    • Correction de Benjamin : la compression sans perte est une fonctionnalité des couches basses : la modulation du signal fait de la compression en permanence. Le secret des correspondances ne se lit pas comme ça : un routeur qui voit passer un mail, pas de problème, un anti-spam qui traite le mail sans le retenir, pas de problème. Le traitement fait par GMail sur le mail : pas bien mais GMail = droit US. La compression est un détail technique. Le proxy compresse parce que le navigateur indique qu'il sait gérer la compression. Il lui est déjà interdit de logguer ce qu'il voit passer. Il le fait peut-être mais la consultation ne peut rien contre ça. Ce n'est pas l'endroit.

• Paragraphe 75 : « In contrast to network-internal blocking put in place by the ISP, terminal equipment-based restrictions put in place by the end-user are not targeted by the Regulation. ».

  • Àmha : toute mesure de gestion de trafic, raisonnable ou non (comme dans cet extrait), devrait être mise en place en accord avec le choix de l'utilisateur qui peut le changer à tout moment sans frais et facilement (une option compréhensible dans l'interface de la box). Ça veut aussi pour les services gérés comme la TV dont il sera dit plus loin qu'elle est sur un réseau séparé (VLAN) et fortement priorisée : je dois pouvoir décider si je veux que la catégorie de trafic "VOIP" soit priorisée ou non.

• Des mesures de gestion du trafic déraisonnables (qui dépassent le cadre général, quoi) peuvent être prises pour :

  • Respecter la législation européenne ou nationale, décisions des autorités publiques, etc. Donc oui, bloquer, restreindre, limiter l'accès, etc. c'est possible suite à une décision administrative ou judiciaire.
    
    

  • Préserver l'intégrité et la sécurité du réseau, du service fourni ou celle du terminal utilisateur.

    • C'est mignon mais du coup, bloquer le port 25 (SMTP, envois de mails) pour éviter le spam et la transmission de virus, comme le fait Orange, ça m'empêche de fournir une application ou un service, qui est un droit protégé par l'article 3(1) du Règlement européen ! Comme toute mesure de gestion du trafic, ce genre doit être désactivable par l'utilisateur à tout moment, sans frais et facilement.
      
      
    • Correction par Benjamin : ce n'est pas ici qu'il faut le dire. Car ici, j'attaquerai des pratiques utiles et nécessaires au maintien des réseaux donc mon attaque serait vaine.

  • Mitiger une congestion imminente, exceptionnelle (pas prévisible, pas souvent) ou temporaire (répétée mais limité dans le temps (ex: mobile) ou qui ne justifie pas un investissement d'augmentation de la capacité réseau).

    • Proportionnelles : ralentir est mieux que bloquer (paragraphe 88) et pas pour contourner les principes généraux de gestion de trafic définis plus haut (paragraphe 86). Normal mais bien de le rappeler.
      
      
    • Pas plus longtemps que nécessaire ;
      
      
    • Si une gestion de congestion agnostique (celle définie dans le cadre général) ne suffit pas ;
      
      
    • Pour autant que les catégories équivalentes de trafic fassent l'objet d'un traitement égal ;
      
      

    • Les régulateurs doivent surveiller si les opérateurs dimensionnent correctement leur réseau. Une congestion récurrente et de long terme ne peut être couverte par cette exception (paragraphe 89). Une gestion de congestion qui vise une appli ne devrait pas être acceptée comme substitue pour des changements structurels du réseau. \o/

      • Ce dernier point permet de patcher Free et son pass prioritaire pour la VOD (déjà pas réglo d'un point de vue droit de la consommation : je ne peux pas te demander un supplément pour réussir à te rendre le service que je t'ai déjà vendu). Selon l'interprétation qu'on en a, ça peut aussi résoudre le problème des interconnexions sous-dimensionnées (Orange versus Cogent pour Mégaupload, Free versus Youtube, etc.). Pour moi, il faut faire attention au paragraphe 47 qui indique que l'article 3(3) du Règlement européen, qui cause du traitement équitable tout ça, n'est pas applicable aux interconnections. Or, le paragraphe 89 découle de l'article 3(3) dernier paragraphe. Le 47 vise l'article 3(3) en entier, 89 une partie. 47 limite 89.
        
        
      • De plus : mes intercos font-elles partie de mon réseau ? Dans le cadre d'une PNI, probablement oui puisque c'est consenti. Dans le cadre du transit, ça se discute fortement. Est-ce qu'un FAI dois trouver un meilleur chemin (aka un autre transitaire ou monter un peering) pour satisfaire mes internautes qui utilisent tel service qui marche pas bien (débit, latence, etc.) ? :/ Le but de tout opérateur réseau est de relier tout le monde à tout le monde (mêmes les premiers paragraphes le disent) donc si les clients de ce FAI sont intéressés par tel service, il est logique que le FAI fournisse de la bonne connectivité vers ce service… sans devenir fournisseur à ce service uniquement… Tranche gorge pour les petits FAI qui n'ont pas les moyens de s'installer dans un des datacenters où le FSI est accessible en peering.
• Article 3.4 du règlement : données persos dans le cas d'une mesure de gestion du trafic = antispam ou juste savoir que t'as explosé ton forfait Internet mobile (ça nécessite de raccrocher ta conso à ton forfait donc de savoir qui tu es). Merci Benjamin.
  
  

Services gérés (plutôt bon)

• Services gérés : services autres que l'accès à Internet qui sont optimisés pour des contenus, des applis ou des services quand cette optimisation est nécessaire pour atteindre un niveau de qualité spécifique que le best-effort ne permet pas d'atteindre (terminologie et paragraphe 95). Ce n'est pas uniquement de la QoS qui vise plutôt à optimiser la qualité globale du réseau plutôt que la qualité d'une appli (ou d'une catégorie d'applis) en particulier.
  
  
• L'optimisation doit être objectivement (sur des critères techniques genre latence, gigue, etc.) nécessaire pour attendre le niveau de qualité contracté sur les fonctionnalités clés du service (paragraphe 97 et 107).
  
  
• Les services gérés ne remplacent pas un accès Internet, ils ne nuisent pas à la disponibilité et à la qualité globale de l'accès à Internet (paragraphe 97).
  
  
• La capacité du réseau doit être suffisante pour fournir le service en plus de l'accès à Internet (paragraphe 98) et, si ça ne passe pas, c'est le service spécialisé qui doit disparaître (113-114). \o/
  
  
• Il ne suffit pas d'accorder une priorité à un service sur l'accès internet général pour que ça devienne un service géré. Ce type de pratiques contournerait les limites posaient plus où concernant les mesures de gestion de trafic. Ça doit se faire sur un réseau séparé au niveau logique (VLAN quoi). Paragraphe 106.
  
  
• Tant sur le court que sur le long terme, les services gérés ne doivent pas conduire à une détérioration de la qualité générale du service d'accès à l'internet pour les utilisateurs finaux. Paragraphe 112.
  
  
• Les régulateurs devraient vérifier si une application pourrait être fournie sur l'accès à Internet avec le même niveau de qualité convenu et engagé. Paragraphe 101. L'évaluation se fait au cas par cas et actualisée (108).
  
  
• Le paragraphe 118 va un peu à l'encontre de ce qui se dit dans les paragraphes précédents : un service géré peut limiter la capacité d'un seul utilisateur tant qu'il est informé. Cela induit également un défaut de transparence qui doit être précisé dans les paragraphes découlant de l'article 4(1)d.
  
  

• Cas concrets : selon ces lignes directrices,

  • La VOIP ne peut pas être un service géré : ça peut-être fourni avec le même niveau de qualité sur un service d'accès à Internet. Des prestas le font comme OVH. De plus, des FAI comme Free, permettent de recevoir les appels à destination de la ligne fixe partout dans le monde via un compte SIP. Donc ça fonctionne sur Internet.
    
    
  • Pour la TVIP (hors VOD), l'idée est de dire que seule une diffusion multicast permet de servir tous les utilisateurs dans de bonnes conditions donc de fournir la TV à un niveau efficace attendu par le consommateur. À l'heure actuelle, on n'a aucune offre TV multicast sur le net ni quasi aucun point d'interconnexion inter-opérateurs multicast. Donc c'est un service géré pour le moment (et pour encore longtemps) mais pas à cause d'une impossibilité technique. Voir : http://blog.fdn.fr/?post/2016/05/20/La-diffusion-de-la-television-lineaire-comme-service-gere L'ennui, c'est que la VOD du FAI, unicast, passe aussi sur ce VLAN dédié et donc est priorisée… et pas celle de ses concurrents car des offres de vidéos en unicast, y'en a des pelles.
    
    
  • Un VPN MPLS multi-sites qui ne donne pas accès au net peut-être un service spécialisé. Tout à fait.
• Pour moi :
  • Il faut dégager le paragraphe 118. : on ne peut en aucun cas limiter le trafic internet sinon l'utilisateur ne veut pas un accès internet mais un accès au service géré donc l'utilisateur n'a pas à acheter un accès à Internet et le FAI n'a pas à vendre un accès à un/des service-s comme un accès à Internet. L'analyse qui consiste à dire que l'utilisateur a souscrit à ce service spécialisé et que donc la diminution de la capacité de sa ligne est acceptable serait vraie uniquement si des offres non tripe-play étaient accessibles (facilement identifiables dans les catalogues des FAI).
    
    
  • Même problème de deni de service sur les régulateurs qu'avec les offres zero-rating surtout que, cette fois-ci, les régulateurs nationaux devront actualiser leurs évaluations. Mais on ne peut rien dire : le Règlement les autorise explicitement. :(
    
    

Transparence (blabla libéral habituel)

• Les régulateurs demanderont à ce que les opérateurs publient quelques informations dans leurs contrats et ce, de manière compréhensible/claire/actualisée (sur la brochure ou sur un bout de site web). Notamment les débits minimum (en dessous, le FAI pourra être sanctionné), normal/courant/réaliste et maximal de leurs offres. Même chose pour la latence, la gigue et la perte de paquets. Même chose pour les mesures de gestion de trafic qu'ils prennent et ça doit être plutôt concret, pas de grandes généralités et dire les impacts sur l'expérience de l'utilisateur. Même chose pour les services gérés.
  
  
• Je n'aime pas le paragraphe 127 : dans la version concise des débits, l'opérateur peut choisir de communiquer ses débits vers des services et applications populaires. L-O-L. On aura le même biais qu'avec les testeurs de vitesse qui ont des mires de mesure dans les réseaux des gros FAI. Sans compter que le FAI mettra en avant ses plus belles interconnexions. Sans compter que ça fait de la pub pour un service donné. Quid des autres ? Ils ne sont pas forcément plus mauvais…
  
  
• Les FAI doivent mettre en place des moyens permettant à leurs utilisateurs d'émettre des plaintes relatives à leurs droits au moins en ligne (formulaire web ou email) + éventuellement téléphone ou poste. Moyen de savoir où en est cette plainte, etc.
  
  

Supervision (sans avis)

• Les régulateurs nationaux doivent superviser : les conditions commerciales, les restrictions éventuelles des droits, les mesures de gestion de trafic non conforme, la transparence des offres, et la qualité des offres des FAI.
  
  
• Ces régulateurs peuvent demander des infos aux FAI et conduire des investigations concernant les mesures de gestion du trafic.
  
  
• Les régulateurs peuvent imposer de cesser des atteintes au Règlement, imposer des minimums de qualité de service, imposer des mesures pour assurer de la capacité réseau nécessaire
  
  

Ma réponse à la consultation du BEREC :

Hello,

I'm participating to this consultation on Net Neutrality guidelines as a French citizen considering exercising his liberties (freedom of expression, freedom of information, ...) requires an open Internet. My contribution is realised on my spare time. My professional job is as a software developer but I never worked for an ISP or a CAP.

Firstly, I deplore this consultation is only in English (guidelines are only available in English, "Contributions should be sent preferably in English", ...) because it prevents some small actors like citizen and small ISPs from participating: reading legal documents in English isn't mandatory for setting up a little ISP in a small city in France.  Doing this, BEREC tries to restrict participation to those only from historic nationwide ISP lobbyists!  This is unacceptable.

Then, I approve and give my full support to paragraphs 17, 59, 60, 65, 66, 67, 74, 86, 88, 89, 97, 101, 107, 108, 113, 114. I strongly encourage you to keep them as-is in the final guidelines.

On paragraph 16

An IAS end-user requires IPv6 to "provide applications and services" (article 3(1)). Public IPv4 addresses are exhausted. However, a public IP address is required to provide applications, services, or contents. In France, nationwide ISPs do not provide public IPv4 addresses in their mobile IAS. IPv6 is the only way for ISPs to satisfy to the obligations as stated in article 3(1) of the Regulation for now and in the future.

Moreover, in a few years from now, a new ISP won't be able to enter the market: there won't be any more public IPv4 addresses available to them. It will then provide its end-users with IPv6 access. If the IPv6 contents, services, applications still are in minority as it is the case today, this ISP won't be able to sell IAS as no potential client will be interested in it because he cannot do something with its connection. This technical consideration will be a reason for market exclusion. ISPs and CAPs must deploy IPv6 from now to prevent this.

On the use of the terminal equipment of their choice (paragraphs 23-25)

The BEREC analysis is weak and incomplete.

You're wrong in paragraph 51: Endpoint-based congestion control takes place on my computer behind the terminal! On a home IAS, the terminal is the home-router, i.e. the equipment between my private home network and my ISP's network; between my computers, tablets, smartphones, and Internet. On a mobile IAS, the terminal is my smartphone's baseband module. As I can choose my smartphone model, I can choose my terminal.  BEREC must clearly state that the home-router is the terminal (called "box" in France: LiveBox, FreeBox, NeufBox) and that the terminal isn't part of the ISP's network because it is part of the end-user's domestic material (like are tables, chairs, TV, ...).
In France, changing the home-router on a FTTH IAS is very hard: the terminal must send a technical information (called "DHCP vendor-id attribute") to the ISP in order to connect to its network and obtain its public IP address. This information is specific to an ISP, or even a geographic area!  The information isn't communicated by the ISP to the end-user when signing the contract. Other IAS technical characteristics are also hidden from the end-user (e.g. "VLAN ID"). The freedom the end-user has of choosing his terminal under article 3(1) is then restricted as the end-user must have solid technical knowledge in the matter in order to find out his IAS' technical characteristics if he wishes to replace his terminal. Yes, I'm only talking about IAS specifically, not associated services (telephony, television). NRAs must be vigilant about this;

In France, all nationwide ISPs attach services to the IAS, like telephony, television (linear broadcasting or VOD) or videogames in a bundle billed about €30 per month. These bundled services do not directly limit the end-user rights but are more likely to influence end-users’ exercise of the rights defined in Article 3(1) to keep the home-router provided by their ISP in order to benefit from the additional services they pay each month even if they won't actually use them. Consequently:
*NRAs must force ISPs to publish all their IAS and specialised services' technical specifications (e.g. vendor-ID, VLAN-ID, ...). This way, any constructor will be able to sell alternatives to the ISP's home-router still allowing access to both the IAS and the specialised services. Each end-user will then be able to effectively choose his own terminal. This effort on transparency is necessary for a perfect competition.

• NRAs must force ISPs to clearly indicate the home router renting costs on the end-user's montly bill. This way, end-users will be aware of the effective costs of this rent and will be able to make an informed decision to buy a home-router independetly from their ISP. End-users must be free to refuse the ISP's home-router. In this case, end-users cannot be billed by the ISP for renting the router.

• NRAs must force ISPs to propose IASes alone, without any specialised services. Such offers must be less costly than the offers bundling services (Internet + telephony + TV + …).  They must be easily recognisable in the ISP's catalogue.  ISPs are network providers, not services providers (like TV or telephony).

This is a crucial point in the Regulation because several other paragraphs are based on this assertion, like paragraphs 75 et 51. IAS restrictions or congestion control mechanisms applied on the end-user side may only be excluded from the Regulation if the terminal choice is fully under the end-user's control. Otherwise, Regulation and end-user rights violations (e.g. traffic management measures, discriminatory congestion control, restrictions, …) will be observed.

On the zero-rating offers (paragraphs 37 – 45)

I strongly second BEREC analysis on paragraph 38.

I strongly disapprove BEREC analysis from paragraph 45 stating that "Commercial practices which apply a higher price to the data associated with a specific application or class of applications are likely to limit the exercise of end-users’ rights because of the potentially strong disincentive" although that a commercial zero-rating practice only "creates an economic incentive to use". It is a strange analysis: applying a zero price to an application or to a category of applications OR applying a higher price to an application or to a category of applications have the same impact on the end-user's choice: who will seriously continue paying the non-zero-rated application?!

The zero-rating practice inherently limits end-users right, notably their right to "provide applications and services" (article 3(1)): my own service or application stays invisible and has no audience as the market is tricked as customers have to pay to access my service or application while access to concurrent services or applications is free! This highly discourages innovation on the Internet.

Each NRA will have to evaluate and potentially sanction each ISP's own practice. It is a loss of time and resources for NRAs. Even if a practice gets sanctioned, it will have created an habit on the public to use a specific service or application. A public that might not have adopted it if it wasn't for the zero-rating offer. A zero-rating offer from an ISP may durably create a strong distortion on services and applications markets.

For those reasons, BEREC must prohibit zero-rating offers on the ground they inherently limit end-users from exercising their rights, which infringes article 3(2).

On the traffic management measures (paragraphs 46-89)

Paragraph 51: NRAs must make sure no traffic management measures (like ECN, DiffServ (RFC 2474), ...) are set up by ISPs on home-routers without the end-user knowledge to ensure that ISPs don't circumvent to the Regulation.

BEREC must add an additional guideline: every traffic management measure set up by the ISP, whether reasonable or not, and whether on the network or the end-user terminal, must be under the whole control of the end-user. The end-user must be able to easily (with e.g. a clear and comprehensible option in the ISP-provided home-router) and without any additional cost, disable (or enable) any traffic management measure.

• As an end-user, I must be able to disable prioritisation of VoIP applications or any other traffic category, even if it is offered as a sepcialised service.
• As an end-user, I must be able to disable a technical blockage of an application or service my ISP would have set up, because I "shall have the right to (...) provide applications and services" (article 3(1)).  For example, in France, a traffic management measure is set up by many ISP to prevent the end-users' computer from sending emails in order to avoid it sending spams in case it has been infected by a virus. As an end-user, I can decide to disable this traffic management measure in order to propose a legitimate emailing service on my IAS. In France, many nationwide ISPs, like Orange or Darty, prevent me from sending emails from my home IAS, restraining my rights under article 3(1). Some other ISP, like Free or SFR, open the emailing service via an opt-out option. The latter approach is the right one and NRAs must to strongly encourage it.

I second paragraphs 6 and 89: « NRAs may take into account the interconnection policies and practices of ISPs in so far as they have the effect of limiting the exercise end-user rights under Article 3(1). » and « if there is recurrent and more long-lasting network congestion in an ISP's network, the ISP cannot invoke the exception of congestion management ». 
But, BEREC needs to clarify paragraph 47: an interconnection of poor quality (capacity, latency, jitter, ...) between two ISPs necessarily create an incentive for the end-users to favour a service or an application (the fastest one) over a technically and functionally equivalent concurrent offer. In such a case, the ISP has restricted the end-user choice, which is an infringement on article 3(1). It is even worse if the privileged service is the ISP's one.
ISPs must provide the same level of quality to virtually all end-points of the Internet. NRAs shall monitor the ISPs interconnection quality and apply sanctions on the ISPs if necessary. In France, the ARCEP works on this matter for a couple of years.
Paragraph 47 probably means that an interconnection between two ISPs isn't an end-user IAS. If yes, this point is OK.

On specialised services (paragraphs 95-123)

Paragraph 109: the linear broadcasting IPTV example is biased: some French ISPs provide broadcasting IPTV service and their own VOD service in one single specialised service considering that it all is television after all. Those ISPs then prioritise their own VOD service to the detriment of concurrent VOD services. This is a circumvention of article 3(3) of the Regulation. NRAs must be vigilant on this point.

Paragraph 118: an ISP shall not, in any circumstances, limit the end-user's network capacity. This must always be considered an infringement to the Regulation by NRAs, even if the end-user has been informed (Article 4(1)(c)). If limiting the end user's capacity was acceptable, it would mean the end-user didn't mean to subscribe to an IAS but to the specialised service, so consequently the ISP should not have sold an IAS to the end-user as it is not what he needed. Moreover, in France, specialised services are sold in a commercial bundle (so-called "triple-play" offer) at a charm pricing in an incentive way to prevent the end-user from requesting an IAS without specialised services. These bundled offers aren't easily recognisable in the ISPs' catalogue.

Best regards.

Ce qui nous donne approximativement cela en français :

Bonjour,

Je participe à cette consultation sur les lignes directrices relatives à la Neutralité des Réseaux en tant qu'un citoyen français qui considère qu'un Internet ouvert est nécessaire à l'exercice de ses libertés (liberté d'expression, liberté d'information, etc.). Ma contribution est réalisée sur mon temps libre. Mon métier est programmeur informatique mais je n'ai jamais travaillé pour un FAI ou un FSI.

Pour commencer, je déplore que cette consultation se déroule exclusivement en anglais (les lignes directrices sont uniquement publiées en anglais, "Contributions should be sent preferably in English", etc.) car cela nuit à la participation de petits acteurs comme les citoyens ou les petits FAIs : il n'est pas nécessaire de savoir lire des documents légaux pour créer un FAI dans une petite ville de France. Le BEREC essaye de restreindre les participants au cercle des lobbyistes des FAI d'envergure nationale historiques. C'est inacceptable.

Ensuite, j'approuve et je soutiens fortement les paragraphes 17, 59,60,65,66,67, 74, 86,88,89, 97,101,107,108,113,114. Je vous encourage vivement à les conserver dans les lignes directrices finales.

Concernant le paragraphe 16

Un utilisateur final d'un IAS a obligatoirement besoin d'IPv6 pour « provide applications and services » (article 3(1)). Il n'y a plus d'adresses IPv4 publiques disponibles. Pourtant, il faut une adresse IP publique pour fournir une application, un service ou un contenu. En France, les FAI d'envergure nationale ne fournissent pas d'adresse IPv4 publique sur leurs accès Internet mobiles. IPv6 est le seul moyen pour les FAI de satisfaire aux obligations de l'article 3(1) du Règlement dès aujourd'hui.

De plus, dans quelques années, un nouveau FAI ne pourra pas entrer sur le marché : il ne pourra pas obtenir d'adresses publiques IPv4. Il fournira donc à ses utilisateurs finaux un accès Internet exclusivement IPv6. Si les contenus, services ou applications IPv6 sont minoritaires comme c'est le cas aujourd'hui, ce FAI ne pourra pas vendre son accès à Internet : aucun client potentiel ne sera intéressé parce qu'il n'aura aucun usage de sa connexion. Cette considération technique sera un motif d'exclusion du marché. Les FAI et les FSI doivent déployer IPv6 dès aujourd'hui pour empêcher cela.

Concernant la liberté de l'utilisateur final d'utiliser le terminal de son choix (paragraphes 23-25)

L'analyse du BEREC est faible et incomplète.

Vous vous trompez dans le paragraphe 51 : le contrôle de la congestion est effectué par mon ordinateur situé derrière le terminal. Sur un accès à Internet fixe, le terminal est le routeur domestique, c'est-à-dire l'équipement entre mon réseau domestique privé et le réseau de mon ISP, entre mes ordinateurs, tablettes, smartphones et Internet. Sur un accès à Internet mobile, le terminal est le module baseband de mon smartphone. Comme j'ai le choix de mon smartphone, j'ai le choix du terminal. Le BEREC doit clairement affirmer que le routeur est le terminal et qu'il ne fait pas partie du réseau du FAI.

En France, changer de routeur domestique sur un accès à Internet FTTH est très difficile : une information technique (nommée « attribut DHCP vendor-id ») doit être envoyée par le terminal afin d'être connecté au réseau et d'obtenir son adresse IP publique . Cette information est spécifique à un opérateur voire à une zone géographique ! Cette information n'est pas communiquée par le FAI à l'utilisateur final à la signature du contrat. D'autres caractéristiques techniques du service d'accès à Internet sont également dissimulées à l'utilisateur final (exemple : « VLAN ID »). Donc, la liberté de choix du terminal par l'utilisateur final n'est pas effective puisque celui-ci doit avoir de solides compétences en informatique pour obtenir les caractéristiques techniques de son service d'accès à Internet s'il désire changer de terminal. Je parle bien exclusivement du service d'accès à Internet, pas des services associés (téléphonie, télévision). Les autorités nationales de régulation doivent être très vigilantes sur ce point.

En France, tous les FAI d'envergure nationale associent des services au service d'accès à Internet comme un service de téléphonie ou de télévision (linéaire ou VOD) ou de jeux vidéos dans un forfait mensuel facturé moins de 30 €/mois. Ces services incorporés ne limitent pas directement les droits des utilisateurs prévus à l'article 3(1) mais ils sont de nature à fortement inciter les utilisateurs finaux à conserver le routeur domestique fournit par leur FAI pour profiter des services qu'ils payent tous les mois même s'ils ne les utilisent pas ! En conséquence :

• Les autorités nationales de régulation doivent imposer aux FAIs la publication de toutes les spécifications techniques (exemples : « vendor-id », « VLAN-ID », etc.) de leur service d'accès à Internet et de tous les services associés à celui-ci. Ainsi, n'importe quel fabricant de routeurs pourra vendre des routeurs domestiques alternatifs à ceux des ISP qui permettent de profiter du service à Internet et des services associés. Tout utilisateur final pourra donc choisir le terminal de son choix. Cet effort de transparence est nécessaire à une concurrence pure et parfaite.
• Les autorités nationales de régulation doivent imposer aux FAI d'indiquer, clairement, sur leur facture mensuelle, le prix de la location du routeur domestique. Ainsi, les utilisateurs finaux auront connaissance de la non-gratuité de cette location et pourront décider d'acheter un routeur domestique indépendant de leur FAI. Les utilisateurs finaux doivent être libres de refuser le routeur domestique proposé par le FAI. Dans ce cas, l'utilisateur final ne peut pas être facturé pour cette location par le FAI.
• Les autorités nationales de régulation doivent imposer aux FAI de proposer des offres de service d'accès à Internet nu, sans aucun service ajouté. Ces offres doivent être moins chères que les offres groupées (Internet + téléphone + TV + etc.). Elles doivent être facilement identifiables dans le catalogue du FAI. Un FAI est un fournisseur de réseau, pas un fournisseur de services comme de la télévision ou de la téléphonie.

Ce point est un point central du Règlement car plusieurs points reposent dessus comme les paragraphes 75 et 51. Des restrictions du service d'accès à Internet ou les mécanismes de contrôle de la congestion appliqués côté utilisateur final peuvent être hors champ de la régulation seulement si l'utilisateur a le choix complet de son terminal. Sinon, des violations du Règlement et des droits des utilisateurs finaux (exemples : mesure de gestion du trafic, contrôle de la congestion discriminatoire, restrictions, etc.) seront encore constatées.

Concernant les offres « zero-rating » (paragraphes 37-45)

J'appuie fortement l'analyse du BEREC énoncé au paragraphe 38.

Je désapprouve fortement l'analyse du BEREC énoncée dans le paragraphe 45 selon laquelle une « Commercial practices which apply a higher price to the data associated with a specific application or class of applications are likely to limit the exercise of end-users’ rights because of the potentially strong disincentive » alors qu'une pratique commerciale de zero-rating « creates an economic incentive to use ». C'est une analyse étrange : appliquer un prix = 0 pour une application ou une catégorie d'applications OU appliquer un prix plus élevé pour une application ou une catégorie d'applications a le même impact sur la décision de l'utilisateur final : qui continuera sérieusement à payer l'application à laquelle le zero-rating ne s'applique pas ?!

La pratique du zero-rating limite obligatoirement les droits des utilisateurs finaux, notamment leur droit de "provide applications and services" (article 3(1)) : mon service ou application reste invisible et n'a aucune audience parce que le marché est truqué puisqu’il faut payer pour accéder à mon service ou application alors que l'accès aux services et applications des autres acteurs est gratuit ! Cela décourage fortement l'innovation sur Internet.

Chaque pratique de chaque FAI devra être évaluée et éventuellement sanctionnée par l'autorité nationale de régulation de chaque pays membre de l'UE. C'est une perte de temps pour ces autorités. Même si une pratique est sanctionnée, elle aura créé une habitude entre un service ou une application et un public. Un public qui ne l'aurait pas forcément adopté sans l'offre de zero-rating. Une offre de zero-rating proposée par un FAI peut déséquilibrer durablement des marchés de services et d'applications.

Pour ces raisons, le BEREC doit interdire les offres de zero-rating au motif qu'elles limitent obligatoirement l'exercice des droits des utilisateurs, ce qui enfreint l'article 3(2).

Concernant les mesures de gestion du trafic (paragraphes 46-89)

Paragraphe 51 : les autorités nationales de régulation doivent veiller à ce que les mesures de gestion du trafic (ECN, DiffServ (RFC 2474), …) ne soient pas configurées par le FAI, à l'insu de l'utilisateur final, sur les routeurs domestiques qu'ils fournissent sinon, le Règlement est contourné.

Le BEREC doit ajouter une ligne directrice supplémentaire : toute mesure de gestion du trafic, raisonnable ou non, mise en place par le FAI, sur son réseau ou sur le terminal de l'utilisateur final, doit être sous le contrôle intégral de l'utilisateur final. L'utilisateur final doit pouvoir désactiver (et activer) facilement (avec une option compréhensible dans l'interface du routeur domestique fourni par le FAI), sans surcoût, toute mesure de gestion du trafic. 

• En tant qu'utilisateur final, je dois pouvoir désactiver la priorisation des applications VOIP ou de toute autre catégorie de trafic même si c'est un service spécialisé.
• En tant qu'utilisateur final, je dois pouvoir désactiver le blocage technique d'une application ou d'un service réalisé par mon FAI car "shall have the right to (...) provide applications and services" (article 3(1)). Par exemple, en France, une mesure de gestion du trafic est mise en place par quelques FAI pour éviter que l'ordinateur de l'utilisateur n'émette des emails afin qu'il ne puisse pas émettre des spams s'il a un virus. En tant qu'utilisateur final, je peux décider de désactiver cette mesure de gestion du trafic afin de proposer un service d'emails légitime depuis mon service d'accès à Internet. En France, des FAIs d'envergure nationale limitent mon droit prévu à l'article 3(1) en m'empêchant d'envoyer des emails depuis mon accès Internet fixe comme Orange or Darty. D'autres FAIs ouvrent le service d'emails en opt-out comme Free or SFR. La dernière approche est la bonne et elle doit être encouragée par les autorités nationales de régulation.

J'approuve les paragraphes 6 et 89 : « NRAs may take into account the interconnection policies and practices of ISPs in so far as they have the effect of limiting the exercise end-user rights under Article 3(1). » et « if there is recurrent and more long-lasting network congestion in an ISP's network, the ISP cannot invoke the exception of congestion management ». 
Mais, le BEREC doit clarifier le paragraphe 47 : la mauvaise qualité (capacité, latence, gigue, etc.) d'une interconnexion entre deux FAI incite obligatoirement les utilisateurs finaux à privilégier un service ou une application (la plus rapide) au détriment d'un concurrent techniquement et fonctionnellement équivalent. Dans ce cas, le FAI a limité les choix de l'utilisateur final, ce qui est une infraction à l'article 3(1). C'est encore pire si le service privilégié appartient au FAI.
Les FAIs doivent offrir le même niveau de qualité vers « virtually all end-points of the Internet ». Les autorités nationales de régulation doivent surveiller les interconnexions des FAI et sanctionner les FAI si nécessaire. En France, l'ARCEP travaille sur cette question depuis plusieurs années.
Le paragraphe 47 signifie probablement qu'une interconnexion entre deux FAI n'est pas un service d'accès à Internet pour utilisateur final. Si c'est bien le cas, ce point est OK.

Concernant les services gérés (paragraphes 95-123)

Paragraphe 109 : l'exemple de la TV linéaire est un exemple biaisé : en France, les FAIs fournissent leur service de télévision linéaire et leur service de VOD dans un même service géré en considérant que tout ça, c'est de la télévision. Ces FAIs priorisent donc leur propre service de VOD au détriment des services de VOD concurrents. C'est un contournement de l'article 3(3) du Règlement. Les autorités nationales de régulation doivent être vigilantes sur ce point.

Paragraphe 118 : un FAI ne doit en aucun cas limiter la capacité réseau d'un utilisateur final. Cela doit obligatoirement être considéré comme une infraction au Règlement, même si l'utilisateur final est informé (Article 4(1)(c)). Si une limite de la capacité réseau de l'utilisateur final était acceptable, cela signifierait que l'utilisateur final n'a pas voulu souscrire à un service d'accès à Internet mais au service géré donc le FAI n'aurait pas dû vendre un service d'accès à Internet et l'utilisateur final n'aurait pas dû acheter un service d'accès à Internet car ce n'est pas ce dont il a besoin. De plus, en France, les services gérés sont fournis dans un package commercial (nommé « offre triple-play ») à un prix psychologique qui incite l'utilisateur final à ne pas réclamer une offre d’accès à Internet sans service géré. De plus, les offres sans services gérés ne sont pas facilement identifiables dans les catalogues des FAIs.

Cordialement.

Un énorme merci à b4n ( http://ban.netlib.re/shaarli/ ) pour son aide sur la traduction. Merci au groupe de travail « régulation » de la FFDN ( https://www.ffdn.org/fr/ ) pour l'accueil et la motivation.

Rappel : Il reste que ce week-end pour défendre la neutralité des réseaux au niveau européen. La manière la plus simple de contribuer à cela est de se rendre sur https://savetheinternet.eu/en/#act et de remplir le questionnaire composé de 5 questions. Cela génère un mail automatique qui prend en compte vos réponses et qui, si vous le validez, sera envoyé au régulateur européen des télécoms. Y'en a pour 5 minutes…

Note : vous pouvez aller sur la version française du questionnaire, https://savetheinternet.eu/fr/#act pour comprendre le questionnaire et les explications mais il n'est pas recommandé d'envoyer un mail en français car le régulateur européen des télécoms ne donne aucune indication sur leur lecture / prise en compte.

Les internautes ont jusqu'au 18 juillet pour participer à la consultation publique sur la neutralité du net et demander la correction de certaines lacunes.

Branle-bas de combat général pour la neutralité du net en Europe. Neuf mois après l’adoption par le parlement européen de la recommandation sur le marché unique des communications électroniques, qui met en place un cadre pour la neutralité du net, les défenseurs d’un strict respect de ce principe essentiel montent au créneau pour tenter de corriger certaines lacunes du texte.

C’est tout le sens de la campagne Save The Internet, qui cherche à peser de tout son poids sur les réflexions de l’organe des régulateurs européens des communications électroniques (ORECE, ou BEREC en anglais). En effet, les règles de procédure de l’ORECE prévoient que la participation du grand public aux débats, mais pour un temps limité seulement : du 6 juin au 18 juillet 2016.

[...]

Afin de les pousser à participer, le site web Save The Internet propose une version simplifiée et en français du questionnaire (la version détaillée peut aussi être remplie, mais elle a le désavantage d’être en anglais et de requérir plus de temps). Il ne faut vraiment qu’une poignée de minutes pour contribuer. Selon le compteur installé par les organisateurs de la campagne, plus de 160 000 personnes ont répondu.

[...]

La campagne a d’ailleurs reçu jeudi un soutien de poids en la personne de Tim Berners-Lee, le créateur du web, mais aussi de Lawrence Lessig (professeur de droit à l’université Harvard à l’origine des licences Creative Commons) et de Barbara van Schewick (professeur de droit à l’université Stanford).

Dans une lettre ouverte publiée sur Web Foundation, ils appellent à se mobiliser avant le 18 juillet 2016 pour peser sur la décision finale de l’ORECE, en les incitant à boucher les failles existantes sur la définition actuelle de la neutralité du net. Les trois personnalités refusent ainsi les voies rapides sur Internet, la pratique du Zero Rating, la discrimination du trafic et les services spécialisés.

Dans les exceptions à la neutralité du Net, il y a les services gérés. Le consensus actuel est que la télévision linéaire (celle de papa, avec de la pub entre et dans les émissions, par opposition à la télévision de rattrapage qui se fait en ligne, avec de la pub partout aussi et du flash) est forcément un service géré. Ce consensus s'appuie beaucoup plus sur des pratiques actuelles et sur des choix techniques douteux que sur une réalité intangible.

[...]

Quand le principe de la neutralité du Net a commencé à s'imposer, les opérateurs ont essayé d'y échapper en créant la notion de service spécialisé, aussi appelés services gérés : des services qui demandent une qualité particulière sur le réseau et sont donc en-dehors du champ de la neutralité du Net. Il y en a deux classiques en France, la télévision et le téléphone. Pour ces deux services, quand ils sont vendus dans le cadre d'un abonnement unique via une box, il y a une priorisation du trafic : sitôt qu'on allume le décodeur télé, de la bande passante est consommée en priorité par ces flux et ça se ressent sur l'accès à Internet, surtout en ADSL (en fibre ça ne se sent pas, en câble les techniques sont vraiment différentes).

Plusieurs angles d'analyse s'opposent et se complètent pour essayer de caractériser ce qui est un service géré, et parmi les services gérés ce qui est légitime et ce qui ne l'est pas.

Notre angle habituel (côté Fédération FDN et Quadrature du Net) est qu'un service géré qui est équivalent, fonctionnellement, à un service disponible en ligne est une entrave à la libre concurrence : l'opérateur privilégie son propre service (ou celui de son partenaire, c'est égal) en lui offrant une jolie priorisation sur le réseau, contre les services de ses concurrents disponibles en ligne.

Un angle habituel des opérateurs est la nécessité de la priorisation : le service de vidéo demande une priorisation pour que les vidéos soient fluides même quand bittorrent tourne en tâche de fond. Mais il est difficile d'expliquer que c'est vrai pour les vidéos payantes des opérateurs (sur le service de VOD de leur offre télé, par exemple) alors que la priorisation n'est pas disponible pour les vidéos payantes de YouTube (si, si, il y en a, on peut louer des films sur YouTube).

Un angle nouveau proposé par les opérateurs est de comparer l'état du réseau selon que le service est géré ou qu'il ne l'est pas, toutes choses étant égales par ailleurs. Si le réseau est dramatiquement plus chargé, ou mis en danger, ou rendu moins efficace, bref, s'il y a un dommage sur le réseau, c'est qu'il faut que ce soit un service géré. Cet argument a été avancé par quelqu'un pendant la réunion qui s'est tenu le 11 mai au matin dans les locaux de l'ARCEP[1] et je m'y suis opposé sur des bases techniques. Opposition légère, et rapide, de principe, je n'avais pas le temps d'expliquer.

Sur le fond, l'argument est bon. Si un service en passant de géré à normal crée des dommages sérieux sur le réseau, alors il devrait être géré. Reste que ce n'est pas le cas de la télé.

Le cas de la vidéo à la demande est enfantin

Pour la vidéo à la demande, l'analyse est simple. Pas de vraie différence sur le réseau entre la vidéo diffusée par la plateforme de vidéo à la demande (VOD) de l'opérateur et celle diffusée pas un acteur externe, Netflix ou YouTube par exemple. Donc, ce n'est pas défendable.

L'utilisateur final a payé son accès au réseau, sous la forme d'un abonnement. Il paye le visionnage de la vidéo à la plateforme de vidéo. Si le réseau marche mieux pour une plateforme que pour une autre, c'est un abus de position dominante, et une atteinte très claire au principe d'accès à un réseau ouvert.

Le stress imposé sur le réseau par le visionnage d'une vidéo à la demande, que ce soit sur un site Web, ou au travers du décodeur télé sur la plateforme de l'opérateur, est de la même nature. Il ne diffère qu'en fonction de la vidéo (haute définition ou pas), et par la source du trafic (un point A du réseau au lieu d'un point B du réseau), pas par la nature de la charge induite par le visionnage lui-même. Sur ce service là, l'argument "dommage sur le réseau" n'est donc pas opérant.

Le simple fait que l'opérateur privilégie son offre en prévoyant un câblage spécifique sur la box est un problème. La prise où on branche le décodeur télé est un accès spécial au réseau, cet accès passe par des voies privilégiées pour que les flux télé et VOD soient priorisés. Les flux de VOD de toutes les offres du marché, quel que soit le fournisseur, devraient passer par cet accès priorisé. La priorisation du trafic n'est pas en elle-même un problème. C'est le fait que cette priorisation se fasse pour une seule plateforme qui est un problème. En fait, savoir si la priorisation a lieu pour les offres de VOD de l'opérateur, ou d'un opérateur concurrent, ou de Netflix, ou de Télé Bocal, devrait être automatique et non-discriminant. Ou au choix et sous le contrôle de l'utilisateur final. Mais pas au choix de l'opérateur.

Fonctionnement de la diffusion de la télévision linéaire en IP

Techniquement, la télévision linéaire est diffusée en multicast[2]. C'est un cas intéressant, tout le monde voit le même flux, à la même seconde, la même image en même temps. L'idée est que, quel que soit le nombre de téléspectateurs, on ne va transporter les informations qu'une seule fois. Et pour obtenir cet effet, on utilise du multicast.

[...] Le principe du multicast est radicalement différent. Le réseau sait que c'est un flux (de quoi, il s'en fiche, c'est un flux). Quand je veux regarder une chaîne donnée, mon décodeur télé envoie un message au routeur juste au-dessus dans le réseau disant "Je veux recevoir le flux de Télé Bocal". Si le routeur reçoit déjà le flux en question (mon voisin regarde déjà cette chaîne) alors il copie le flux vers moi et c'est fait. Sinon, il propage la demande au routeur suivant, jusqu'à remonter au serveur qui émet le flux. L'effet sur le brin du réseau qui va chez moi est assez faible. On a mis en œuvre un protocole de routage plus complexe, mais il y a bien un seul exemplaire du flux qui arrive chez moi, comme avant, comme en unicast. En revanche, sur les grands axes du réseau, un seul exemplaire du flux est transporté. Cet exemplaire sera dupliqué à chaque point de connexion, pour aller vers les zones où quelqu'un regarde la chaîne, et seulement ces zones-là.

Du coup, en effet, si on remplace la diffusion de la télévision linéaire en multicast par des flux web en unicast, on crée un stress considérable sur le réseau, les grands axes du réseau se retrouvent avec le même flux en plusieurs millions d'exemplaires, au lieu d'un exemplaire unique. Mais... ce n'est pas la priorisation, ou un changement de priorisation, qui produit cet effet. Ce n'est pas de rendre prioritaire les flux des bouquets télé autres que celui de l'opérateur qui produit cet effet. Ce qui produit cet effet, c'est qu'on a changé de technologie. On est passé d'une diffusion multicast à une diffusion unicast.

Si on reste sur la même technologie, à savoir multicast... Mais, peut-on rester sur la même technologie ? Globalement, la réponse simple est oui. Oui. Un émetteur de flux multicast est défini par une adresse IP [...] Et il existe des milliers millions d'adresses IP identifiées comme multicast. Et je ne parle là que d'IPv4, en IPv6, il y en a beaucoup plus. Pour le moment, entre les grands opérateurs d'Internet, les flux multicast ne sont pas routés. Sur les points d'échange, on ne fait pas passer ces flux là. Si on voulait le faire, on déstabiliserait ces points d'échange[4]. Mais le concept de point d'interconnexion multicast entre deux réseaux est un concept raisonnable, qui ne demande pas des équipements nouveaux, mais simplement des équipements actuels et un effort de configuration.

À tel point que certains opérateurs, de petite taille, commencent à fournir ce type de plateforme d'interconnexion multicast, pour aider d'autres petits opérateurs à diffuser des flux de télévision. C'est donc faisable. Pas encore à grande échelle, mais uniquement parce que les grands acteurs du secteur ne veulent pas le faire.

Nous proposons qu'il y ait des points d'interconnexion multicast sur le réseau IP européen, comme il y a des points d'interconnexion pour les flux unicast. Certaines interconnexions sont payantes, d'autres sont gratuites, on pourrait fonctionner sur les mêmes bases. Chaque émetteur de flux télé vient se connecter sur un de ces points (via son fournisseur d'accès à Internet) et dispose d'une adresse IP multicast. France Télévision a une de ces adresses, le groupe Canal+ aussi, Télé Bocal aussi, etc.

Quand le décodeur télé d'un abonné demande à regarder une chaîne... hé bien il se passe la même chose qu'à l'heure actuelle, une demande de souscription IGMP[5] circule sur le réseau vers l'adresse IP qui émet le flux, et chaque routeur sur le trajet se met à gérer son exemplaire du flux, et à dupliquer vers les personnes qui le souhaitent. En clair, sur la théorie, on ne change rien.

Sauf que tout d'un coup, tous les abonnés de tous les FAIs de toute l'Europe ont accès à toutes les chaînes de télévisions de tous les bouquets de tous les pays.

Oh, et les chaînes payantes ? C'est assez simple. Soit le contrôle d'accès à ces chaînes payantes est fait sur le réseau, et alors il continue d'être fait sur le réseau : le routeur qui est au bout de ma ligne n'accepte ma demande de recevoir un flux que si j'ai l'abonnement qui correspond. Soit le contrôle est fait par le terminal : le flux est chiffré, et mon décodeur télé ne pourra déchiffrer le flux que si j'ai l'abonnement correspondant. Il y aurait sans doute des efforts à faire pour généraliser le contrôle d'accès par le réseau, mais j'y reviendrai.

Mais sur le principe, je peux depuis Paris souscrire aux chaînes de cinéma diffusées par les grands bouquets polonais, ou tchèques, ou espagnols.

En ce moment, la Commission européenne fait des grands moulinets avec les bras sur les histoires de geoblocking[6] et sur le Digital Single Market[7]. Ils luttent contre le fait que des plateformes acceptent de diffuser des flux aux abonnés français mais refusent ces diffusions aux abonnés allemands ou américains. Ce qui fait que les copains en séjour aux USA, quand ils veulent regarder un peu de télé franchouillarde, passent par des VPNs pour être vus comme venant de France. C'est stérile. C'est débile. C'est la main invisible du marché.

Notre idée d'un réseau multicast ouvert et public, routé comme il devrait l'être[8], permet de faire du marché de la télévision un vrai marché européen. Non pas qu'une chaîne de télévision en polonais ait une chance de prendre 40% des parts de marché en France, mais qu'un polonais qui est en séjour en France ait accès à des informations en polonais. Le citoyen européen qui se déplace en Europe peut prendre des nouvelles de chez lui. Il est un peu plus chez lui partout en Europe. Et il nous semble que tout ça a du sens.

[...] Le mécanisme que nous proposons pose tout de même une difficulté pour les chaînes payantes. Pas une difficulté de principe, on l'a vu, mais une difficulté contractuelle. En effet, il faut que le routeur au bout de ma ligne sache si je suis abonné ou pas à une chaîne. Or la transaction commerciale a eu lieu, en toute logique, entre la chaîne de télévision (ou son mandataire, mais ça ne change rien) et moi. Il n'est pas logique que l'opérateur soit partie prenante à cette transaction. Il faut donc prévoir un mécanisme simple et portable. Par exemple que l'opérateur puisse interroger une plateforme avec une question du type "l'abonné XXX (identifiant unique) peut-il accéder au flux YYY". Cette plateforme n'est pas très différente, dans son principe, de ce qui se fait pour la portabilité des numéros de téléphone. [...]

Effet de fourniture

Le règlement européen insiste, dans sa définition d'un accès ouvert au réseau, sur le fait que l'utilisateur final peut accéder au service de son choix. Notre proposition fait que l'utilisateur final peut accéder au service télé de son choix via le réseau. C'est donc parfaitement cohérent. Et l'approche contraire qui est que l'utilisateur ne peut accéder qu'au service de télévision linéaire de son opérateur est fondamentalement contraire au texte européen.

Mais il y a plus, comme disent certains juristes. En effet le règlement européen indique clairement que l'utilisateur doit pouvoir fournir le service de son choix. Dans notre approche, c'est possible. Chacun peut avoir une adresse multicast s'il le souhaite, et donc se mettre à émettre, depuis chez lui si la vitesse de son accès le permet, un flux de télévision. Et l'Europe entière pourrait regarder ce flux, sans que sa ligne soit plus chargée que d'habitude.

Le texte du règlement européen est très clair. Il ne dit pas qu'il doit y avoir plusieurs acteurs de marché dans le monde de la télévision. Il dit que chaque utilisateur final doit pouvoir proposer les services de son choix. La vision que nous proposons d'un réseau multicast ouvert, interconnecté, routé, pour le réseau de diffusion de la télévision linéaire est la seule qui permet ça.

Il n'y aurait plus qu'un seul FAI

Le représentant d'un grand opérateur qui défendait le point lors de la réunion de l'ARCEP m'a répondu, outré, comme si j'étais le pire des ignobles, qu'il n'y aurait alors plus qu'un seul FAI. Me dire ça. À moi.

En effet, pour lui, ce qui permet à plusieurs FAIs d'exister, c'est que les offres sont différentes, c'est que les bouquets de télé sont différents, c'est que les films disponibles en vidéo à la demande sont différents. Il devait croire en 2000 que c'est pour le portail qu'un abonné choisissait entre Orange et Free. Et qu'une fois la mode du portail passée, et elle est passée depuis 2008, l'univers entier allait s'écrouler. Il croit donc que si tous les abonnés peuvent accéder par le réseau à toutes les offres de télé, alors tous les FAIs auront le même service, et qu'il n'y aura plus de marqueur différenciant.

Mon analyse à moi, c'est qu'il n'y a qu'un seul Internet. Et que tous les FAIs fournissent un accès au même Internet. Et la proposition qui est faite ici est simplement de réintégrer dans ce réseau Internet unique les flux multicast que les opérateurs ont mis de côté.

Je redoute que sur ce point son approche et la mienne ne puissent pas être réconciliées. Mais voilà, c'est bien mon approche qui est soutenue par le règlement européen, contribuer à ce qu'il n'y ait qu'un seul Internet, et que tous les citoyens d'Europe puissent y accéder de la même manière où qu'ils soient en Europe.

Microsoft, qui refusait depuis 2013 de fournir aux autorités américaines les données stockées en Europe d’un utilisateur de ses services, a été entendu en appel, jeudi 14 juillet. La cour d’appel des États-Unis pour le second circuit à New York a validé l’argument des avocats de la firme de Redmond. Selon eux, autoriser Washington à émettre des mandats pour accéder aux données stockées à l’étranger foulerait aux pieds les législations nationales et créerait un dangereux précédent.

Appel donc il doit encore y avoir des voies de recours mais c'est déjà encourageant.

La Commission européenne a adopté mardi matin le Privacy Shield, le cadre juridique qui remplace le Safe Harbor et présume que les données personnelles exportées vers les États-Unis bénéficient d'un niveau de protection équivalent à celui offert par le droit européen. Applaudi par Microsoft, l'accord est critiqué par les défenseurs de la vie privée.
[...]
Les CNIL européennes réunies dans le groupe G29, elles, devraient se prononcer le 25 juillet prochain.

Se prononcer = émettre un avis purement consultatif, hein.

Pour un résumé de ce que contient le Privacy Shield, voir http://shaarli.guiguishow.info/?2QNnaA

J'ai eu envie de me re-visionner cette conférence car on y apprend des choses comme les débuts de VLC et le foirage HADOPI en dehors de la sécurisation des accès et de la riposte graduée.

Pour voir cette conf' : https://video.passageenseine.fr/w/kzwCAquNt4cSRaDDvpCDjn

Débuts :

• VLC est né à l'École Centrale Paris au milieu des années 1990. À cette époque-là, Bouygues (oui, oui, les maçons de TF1, tout ça) lance un défi à l'association VIA qui gère le réseau du campus et qui aimerait bien un réseau plus performant et Ethernet (celui de l'époque étant sur la techno Token Ring) : trouvez un usage qui sature votre réseau actuel et nous vous en payons un autre. VIA décide de se lancer dans le streaming vidéo de flux MPEG-2. :D
  
  
• 1998 : reboot du projet. Nouveaux objectifs : open source, modulaire, multiplateforme. Le changement de licence pour la GPL 2 devient effectif en 2001 (le temps d'obtenir l'accord de l'école).
  
  
• Postulat de VLC : être souple, s'adapter aux situations car dans le multimédia, tout le monde croit tout savoir sur tout mais implémente mal.
  
  

VideoLAN, l'association derrière VLC :

• Lors de la première rencontre VideoLAN Dev Days (rencontre annuelle autour de VLC) de 2008, il est décidé de monter une association afin de payer les serveurs nécessaires à l'hébergement du site web et de la galaxie de projets, d'organiser les Dev Days, de financer les déplacements dans des événements/conférences et d'intenter des recours législatifs (lire ci-dessous).
  
  
• Ce n'est pas dit dans la vidéo mais pour faire un don à ce projet important que beaucoup d'entre nous utilisent, c'est par ici : https://www.videolan.org/contribute.html .
  
  

Stats et anecdotes :

• Je ne savais pas que x264, implémentation libre d'un codec pour la norme vidéo H264 (ou MPEG-4 AVC) était une initiative de la team VLC.
  
  
• VLC est le premier lecteur de DVD sous Mac. :O
  
  
• Plus de 900 000 téléchargements par jour en 2013. 1 Mac sur 6 utilise VLC. VLC est dans le top 15 des logiciels winwin les plus utilisés. VLC est le logiciel français le plus utilisé dans le monde.
  
  
• Fonctions méconnues : screencasting, mur de vidéos, karaoké, pilotable en console (cvlc) + lire une vidéo en ASCII coloré en utilisant la libcaca (vlc -vout caca mavideo.mkv), pilotage via une interface web (cas d'usage : télécommande sous Android d'une espèce de media-center).
  
  
• Streaming vidéo sur BitTorrent : il faut que les blocs soient ordonnés, il faut être capable de se déplacer dans la vidéo, il faut seeder pendant qu'elle est visionnée, etc. Complexe (client BT complet). VLC ne supporte pas BitTorrent. tribler (financé par l'UE) est basé sur VLC et le fait. D'après mes essais, ça "marchepo" sous une Debian stable car ça utilise une vieille lib...
  
  
• VLC est sur les PCs des parlementaires français depuis 2007. :)
  
  
• Menus interactifs dans les Blu-ray : BD-J c'est-à-dire du Java. :DDDD
  
  

DRM ou MTP (mesures techniques de protection, en français) :

• La vocation des DRM, ce n'est pas de limiter le piratage, c'est la possibilité, pour les majors, de contrôler l'intégralité de la chaîne de distribution. Preuve : SlySoft est une société commerciale basée aux Antilles (qui existe encore en 2016) qui passe son temps à faire du reverse-engineering de DRM, c'est son cœur de métier ! Les DRM ne valent rien techniquement mais l'industrie continue car ça permet aux majors et à toute une industrie d'empocher une patente pour être distributeur (de matériel avec le logo Blu-ray dessus…).
  
  
• Les DRM sous forme de clés (DVD, Blu-ray, ebooks) sont stupides par essence : on vous donne le contenu et la clé qui le chiffre et on vous dit « surtout, ne regardez pas la clé !!! ». Forcément que ça ne fonctionne pas et que ça entraîne la surenchère entre industriels de la culture et libristes.
  
  
• DVDCSS - protection du DVD - années 1990 - clés de 56 bits (dû à la législation US qui restreignait la taille du matériel crypto exporté à l'étranger) - révocation prévue mais impossible (car le lecteur ne peut pas être mis à jour après sa vente) - libdvdcss bruteforce, il n'embarque pas de clés contrairement à DeCSS qui utilise la clé volée.
  
  
• Blu-Ray : 4 mesures de protection : AACS, BD+, HDCP, Macrovision. Elles peuvent s'enchaîner.
  • AACS : évolution de DVDCSS, système par clés (une par lecteur (logiciel), une clé par Blu-ray), spécifications publiques (ce sont les seules à l'être parmi tous les DRM !).
    • Révocation d'un modèle de lecteurs ou de toute une gamme ou même un constructeur entier KiMarche ! AACS est un arbre de 64 niveaux qui regroupe un sous-arbre pour chaque équipementiers (genre Sony, LG, PowerDVD, etc.) puis, pour chaque, un sous-arbre par gamme puis, des feuilles pour chaque modèle de lecteurs. Sur les Blu-Ray, la clé change tous les trois mois. Si votre lecteur est révoqué, vous n'êtes plus en mesure de lire le contenu du disque par le mécanisme de l'arbre. Tout l'enjeux est donc de trouver une clé de lecteur valide. De plus, il y a un système de liste noire : votre lecteur (physique) va lire cette liste en premier et s'il trouve la clé de votre logiciel, booom, le lecteur ne peut plus lire aucun Blu-ray (même vos vieux Blu-ray, même si vous les aviez acquis légalement). Il faut reflasher le firmware…
      
      
    • Marquage audio : comment les majors peuvent-elles savoir quel lecteur s'est fait pwned sa clé ? En fonction de votre lecteur (et donc de sa clé), vous n'allez pas lire la même table des matières donc le même fichier sonore. Exemple : 150 versions différentes d'une même séquence est embarquée sur le Blu-ray et votre lecteur en lit une et une seule ! Il suffit de scanner les réseaux d'échange et de comparer le marquage présent dans chaque fichier publié avec une base de données.
      
      
    • Évidemment, tout ça repose sur l'inexistence de lecteurs physiques de Blu-ray qui n'implémenteraient pas le système de liste noire sinon tout s'écroule. On en revient au fait que les DRM, c'est le contrôle de la chaîne de distribution : pour poser le logo « Blu-ray » sur ton lecteur, il faut être certifier sinon procès donc il faut respecter toute la norme dont AACS. Si tu ne mets pas le logo Blu-ray, tu vends pas.
      
      
  • BD+ : machine virtuelle Turing complète. Chaque disque peut arriver avec son propre code de "sécurisation". Utilisé par 20 % des disques sur le marché (en 2013, donc) principalement par la Warner.
    
    
  • HDCP : pour pirater, au lieu de casser les protections ci-dessus, il suffit de se positionner entre la carte graphique et l'écran et de dupliquer le flux brut ici. HDCP lutte contre ça : il faut une chaîne de confiance. Chaque appareil vérifie que le suivant est bien autorisé : lecteur DVD physique, OS, drivers, carte graphique, écran). La clé maîtresse d'Intel s'est retrouvée dans la nature… Donc HDCP est tout cassé.
    
    
  • Macrovision : déjà présent sur les VHS : décale les phases de chaque ligne donc ça brouille un peu. Suffit d'implémenter l'algorithme inverse et lala.
    
    
• Qu'est-ce qui a permis à Blu-ray de l'emporter sur HDDVD ? Ce n'est pas la différence de stockage (25G versus 50G), tout ça. La clé maître des HDDVD a été volé sur des machines visiblement non sécurisées.
  
  

L'aspect légal (ou comment la HADOPI a foiré une autre de ses missions…) :

• EUCD, directive européenne sur le droit d'auteur, transposée par la DADVSI de 2006. Arrivée des DRM, limiter la diffusion d'outils de contournement des DRM. L'April fait un recours devant le Conseil d'État qui répond : dans le cadre de la loi DADVSI, un logiciel libre peut contourner les DRM dans le cadre de l'interopérabilité et il ne peut y avoir de renoncement par voie contractuelle à ce droit.
  
  
• Mesure technique de protection pas définie. De quel droit d'auteur parle-t-on ? De celui des auteurs de l'œuvre fixé sur le support ? L'auteur de la MTP (c'est un logiciel comme un autre) ? Du logiciel du lecteur ? On suppose, bien évidemment, que le législateur a voulu définir le droit des auteurs de l'œuvre fixé sur le support.
  
  
• Un protocole, un format, une méthode de chiffrement, de brouillage ou de transformation ne constituent pas une MTP. Article L331-5 du CPI. C'est pour ça qu'on peut plaider (sans certitude) que DVDCSS, qui utilise une clé statique, est uniquement une méthode de chiffrement et n'est donc pas une MTP. Aucun doute qu'AACS et BD+ sont des MTP.
  
  
• DADVSI crée l'ARMT : l'autorité de régulation des mesures de protection chargée de gérer l'interopérabilité des mesures des protections. Autorité bidon car mission bidon. Elle n'a rien fait de 2007 à 2011. ARMT est intégrée dans HADOPI.
  
  
• VideoLAN cherche à éclaircir la loi avec l'ARMT.
  • Rencontre à OVEI (On Vous Explique Internet) en 2011. L'HADOPI ne sait même pas qu'elle a cette compétence. Pas moyen de dialoguer, VLC se fait traiter de pirates, voleurs, etc. et se voit demander d'adresser une demande écrite.
    
    
  • Saisine pour avis (pas en contentieux car VideoLAN vient en amie, pleine de bons sentiments, cherche à comprendre la loi, etc.) en 2012. Questions : est-ce qu'on peut diffuser le code source de libaacs (qui implémente juste des spécifications publiques) ? Le code compilé ? Sous forme de lib ou dans VLC ? L'idée étant de trancher où se trouve la limite définie par la loi DADVSI entre l'interopérabilité et l'aide au contournement de MTP (qui est interdit). Comment peut-on diffuser les clés ? Car il faut signer un contrat avec AACS-LA pour obtenir les clés… sauf que ce contrat impose d'implémenter HDCP… VLC ne peut pas le faire sous nux ou Mac ou BSD puisqu'il n'y a pas de chaîne HDCP existante !
    
    
  • S'en suivent réunions et consultations auxquelles VideoLAN n'est jamais invitée et est informée de ces réunions à venir dans la presse.
    
    
  • Février 2013 : consultation bidon (le rapport était déjà écrit, c'était histoire de gagner du temps) et étrange : on ne fait jamais une consultation publique pour éclaircir un point de droit.
    
    
  • Avril 2013 : réponse à côté de la plaque : ne diffusez pas les clés, elles ne font pas partie du code (quid alors de la mise en œuvre effective de l'interopérabilité permise par la loi ?). Pas de réponse au reste… … … Donc VideoLAN ne sait pas si elle peut diffuser le source de libaacs… Presque 2 ans pour… rien à part faire tourner VideoLAN en rond. Merci, l'ARMT / HADOPI !

Le règlement européen sur la neutralité du net adopté en novembre 2015 est extrêmement faible puisque consensuel. Ce sera donc aux régulateurs nationaux des télécoms, l'ARCEP en France, de définir les termes, les contours et les pratiques qui sont acceptables et celles qui ne le sont pas. Ensuite, tout cela permettra à ces mêmes régulateurs d'effectuer leur taff de régulation à proprement parlé.

L'autorité européenne qui chapeaute les régulateurs nationaux, le BEREC, a publié, début juin, son brouillon de lignes directrices sur la mise en œuvre des règles concernant la neutralité des réseaux c'est-à-dire de quelle manière les régulateurs télécoms nationaux appliqueront et feront appliquer le règlement européen. C'est disponible ici : http://berec.europa.eu/eng/document_register/subject_matter/berec/public_consultations/6075-draft-berec-guidelines-on-implementation-by-national-regulators-of-european-net-neutrality-rules . Une traduction collaborative est disponible ici : https://quadpad.lqdn.fr/TradBEREC

Ce même organisme conduit une consultation publique en ligne sur ce brouillon de directives : http://berec.europa.eu/eng/news_consultations/ongoing_public_consultations/3771-public-consultation-on-draft-berec-guidelines-on-implementation-of-net-neutrality-rules . « Contributions should be sent preferably in English ».

C'est l'occasion d'essayer de faire fléchir la position du régulateur national vers nos convictions et d'obtenir une définition claire et une protection de la neutralité des réseaux dans toute l'UE.

La FFDN bosse sur une réponse. Je vous invite à participer en votre nom propre pour montrer l'implication de la société civile.

La deadline pour répondre à la consultation publique du BEREC est le 18 juillet à 14h CET. Dans une semaine, donc.

ÉDIT DU 11/07/2016 À 17H15 : Plutôt que de répondre directement, from scratch à l'adresse mail fourni par le BEREC, vous pouvez répondre au questionnaire de https://savetheinternet.eu/en/#act . Ce formulaire génère une réponse pré-écrite qui sera directement envoyée au BEREC suite à une validation de votre part. Vous pouvez lire le formulaire en français sur https://savetheinternet.eu/fr/#act pour bien tout comprendre mais le mieux est d'utiliser le formulaire en anglais car le BEREC ne donne aucune garantie que le mail sera pris en compte / traduit / lu. FIN DE L'ÉDIT.