GuiGui's Show

Hum, intéressant : une loi allemande de fin 2015 entre en application en août 2016 et permet de se passer du routeur loué par le FAI.

Up until now, Internet service providers (ISPs) in Germany determined the router users had to use to connect to the Internet. The user had no say in this decision. This changes on August 1. A new law will allow users choose the device that gets installed in their homes.

"Compulsory Routers" are what we call the devices imposed on users, forbidding them from using any other appliance to access the Internet. Compulsory routers are often the subject of critical security flaws which users can't legally or technically fix themselves. They are also known to be incompatible with certain network devices and standards, like IPv6, or to support only a small number of important features.

However, the legal situation was ambiguous and ISPs defined the first router or modem after the wall socket as part of their network. They could thus bar users from controlling the technology installed within their own homes [...]

from August 1 onwards, clients of German internet providers are allowed by law to use any terminal device they choose. Regardless of whether it is a DSL or cable connection, the ISP will have to supply the information you need to connect an alternative router to use the Internet and telephone network.

Ho, donc les spécifications seront connues ?! Genre le FAI te cache pas le DHCP vendor-id ou le VLAN ID comme en France ?! :O Vaaaaache. Ça semble trop beau.

Soit l'erreur suivante lors d'un apt-get update :

« E: Erreur de GPG : ftp://ftp.uk.debian.org stable-updates InRelease : Les signatures suivantes ne sont pas valables : NODATA 2 »

Solution :

Keep an eye on your /tmp/ -- I had run out of disk space

Dans mon cas, j'avais monté un tmpfs trop petit sur /tmp.

C'est très vicieux comme message d'erreur car ça foire pour une seule distribution d'un dépôt apt (ici : jessie-updates), toujours le même donc on est tenté d'accuser ce dépôt…

Bref, pensez à bien dimensionner vos tmpfs. Attention : bien dimensionner, ça ne veut pas dire de se contenter de doubler/tripler la valeur affichée par un du -hs pour en prévoir l'usage. Nonononono.

Il y a des logiciels (apt, mysql, etc.) qui écrivent de gros fichiers temporaires de manière instantanée (même un while true ne permet pas de les voir avec leur taille complète, pour donner un ordre de grandeur). MySQL y écrit le temps d'une requête (et si vous utilisez tiny tiny rss en conservant beaucoup d'items bah il vous faudra un /tmp de plusieurs centaines de Mo), apt y écrit le temps d'un update, etc.

Pensez aussi à un upload HTTP traité par PHP (fichier ou même envoi d'un billet de blog, voir http://shaarli.guiguishow.info/?ShqsQg ) : le fichier sera temporairement stocké dans /tmp. Votre tmpfs devra donc être plus grand que upload_max_filesize et post_max_size.

Pour rappel : l'espace d'un tmpfs n'est pas pré-réservé : il n'est pas consommé en RAM tant qu'il n'est pas utilisé. Seule la quantité utilisée est consommée en RAM. ;)

Perso :

• Sur un serveur (ou un laptop ou autre) qui a 4G de RAM ou plus, je n'hésite pas : 1G sur /tmp direct ;
  
  
• Sur un serveur plus modeste en RAM (1G, 2G) avec un usage faible (mail, jabber, etc.), je file 20M de tmpfs ;
  
  
• Sur une machine modeste en RAM avec un usage conséquent (site web fréquenté, tiny tiny rss, etc.), je file 500M.

Sur des machines équipées de SSD (ou de DRBD), je monte aussi des tmpfs là où les applications web écrivent des données temporaires. Genre /var/tmp (mais attention à allouer suffisamment d'espace, genre 50M car mkinitramfs et autres écrivent ici le temps d'une mise à jour), genre tmp et cache de shaarli ou data/cache de dokuwiki ou le système de cache d'un CMS.

Merci à b4n ( http://ban.netlib.re/shaarli/ ) qui a su jouer de la pokéflute auprès d'un moteur de recherche pour obtenir la bonne réponse. \o/ Je ne trouvais rien à part des histoires de proxy ou de corruption de la base de données apt ou du keyring… Et oui, je case pokéflute pour faire genre que je suis à la mode.

Tout est dans le titre de ce shaarli : encore en 2016, il faut toujours mettre au moins une adresse IPv4 d'un récursif DNS dans /etc/resolv.conf , même en dernière position. Sinon des logiciels seront incapables de résoudre les noms de domaine. Un exemple ? mtr : « No nameservers defined. »

Attention si vous sauvegardez vos systèmes avec tar. C'est super mega simple et pratique à restaurer mais il y a des petites choses à savoir :

--numeric-owner

Par défaut, tar sauvegarde les UID et GID sous forme textuelle. Ça veut dire qu'il lit le UID+GID d'un fichier, qu'il regarde à quoi ces ID correspondent dans /etc/{passwd,group} et qu'il sauvegarde les intitulés qu'il a trouvés. Ça suppose deux choses :

1- que l'utilisateur et le groupe existent lors de la restauration ;
2- de créer l'archive sur le système lui-même.

Exemple : si vous sauvegardez vos LXC depuis l'hôte, c'est bien les fichiers /etc/{passwd,group} de l'hôte qui seront utilisés pour faire la traduction numéro->nom, pas les /etc/{passwd,group} de votre LXC donc, quand vous restaurerez votre sauvegarde, vous aurez des fichiers/dossiers qui n'appartiennent pas aux bons utilisateurs, ce qui empêchera les logiciels de démarrer.

Pour éviter cela, il faut utiliser --numeric-owner lors de la sauvegarde.

--xattrs

Par défaut, tar ne sauvegarde pas les file capabilities, ces droits très précis/fins que l'on accorde à une application au lieu de les setuid/setgid (ce qui leur donne plus de droits que ce dont elles ont besoin). L'exemple classique est ping, à qui on attribue la capability « cap_net_raw » pour qu'il puisse créer des sockets raw ICMP.

Pour sauvegarder les capabilites, il faut utiliser --xattrs lors de la sauvegarde. Il y a visiblement une subtilité lors de la restauration : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775495 .

Je parle des file capabilites mais c'est la même chose pour les ACL POSIX et/ou les contextes SELinux : tar ne les sauvegarde pas par défaut, il faut le demander explicitement.

Autant réparer une restauration qui n'a pas les bons UID/GID, c'est compliqué sans connaître les permissions d'origine (mais on peut les retrouver depuis les scripts de post-installation mais ça nécessite de retrouver quel package a livré tel fichier/dossier et ça, c'est chiant), autant réparer les capabilites, ça se fait plutôt bien. Les capabilites ne sont pas positionnées dans l'archive tar contenue dans un paquet debian (.deb, tout ça). dpkg ne s'en occupe pas non plus. C'est les scripts de postinstall qui s'en occupent. Il suffit donc de lire tous ces fichiers et de retrouver ceux qui affectent des capabilites : grep -R "setcap" /var/lib/dpkg/info/*.postinst. Il suffit d'exécuter manuellement les commandes setcap que l'on trouve et c'est réglè.

Pas de relatif

Si vous faites une sauvegarde relative, du genre cd / && tar --exclude='./tmp' --exclude='./dev' -cpJf save.tar.lzma ., ça complique la restauration : il vaut mieux faire : cd / && tar -cpJf save.tar.lzma bin boot [...]. Il faut réaliser la backup depuis la racine si l'objectif de la sauvegarde est de restaurer tout un système d'un coup.

Petite info intéressante qui va dans ce sens : on peut tar xf une arborescence sur un système en fonctionnement (genre cd / && tar xf save.tar.lzma) mais on ne peut pas cp ou mv une arborescence sur un système en fonctionnement (ici, rootfs est le dossier extrait par tar) :

# cp -R rootfs/* /
cp: cannot create regular file '/bin/bash': Text file busy
cp: cannot create regular file '/bin/cp': Text file busy
cp: cannot create regular file '/lib/x86_64-linux-gnu/ld-2.19.so': Text file busy

Je n'explique pas la différence entre tar et cp… tar est aussi lancé par bash et il utilise aussi la libld-2.19 située dans le même répertoire…

La Commission européenne ne fait pas que travailler sur la réglementation européenne. Les ingénieurs de l’exécutif bruxellois sont prêts à fournir des audits de sécurité sur des projets Open Source. Pour choisir le projet qui bénéficierait de cet audit gratuit, la Commission européenne a mené un sondage public entre les 17 juin et le 8 juillet et a obtenu 3282 réponses.

Cette initiative s’inscrit dans un programme EU-FOSSA (EU-Free and Open Source Software Auditing) qui bénéficie d’un budget de 1 million d’euros jusqu’en décembre 2016. C’est Julia Reda, membre du Parlement européen pour le Parti pirate allemand qui a proposé ce projet en 2014. Elle souhaitait améliorer la sécurité des solutions Open Source utilisées par les institutions européennes.

Dans le sondage mené, deux projets Open Source se sont détachés. Le premier est KeePass (23,1%) un gestionnaire de mot de passe et le second est HTTP Apache (18,7%).

[...] les représentants du projet UE-FOSSA ont expliqué qu’ils travailleraient en collaboration avec les deux projets retenus en produisant des rapports utilisables.

Bonne nouvelle, ça même si je préfère largement l'idée d'audits de sécurité réalisés ou conduits/financés par une association totalement financée par des dons. Et, àmha, la priorité est plutôt d'auditer les grosses libs utilisées par tout le monde comme openssl/libressl) que des logiciels complets.

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.