La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: stylou08 le 29 juin 2019 à 15:47:50
-
Bonjour, quelqu'un a lu cette news et a d'autres infos ?
Internet : bientôt un mouchard pour mesurer le débit de votre box
Après une charte pour uniformiser les méthodes de mesure de débit des box, l’Arcep veut les équiper d’une application pour obtenir des résultats très précis.
[...]
Source : Le Parisien (http://www.leparisien.fr/high-tech/internet-bientot-un-mouchard-pour-mesurer-le-debit-de-votre-box-27-06-2019-8104383.php) le 27 juin 2019
-
Bonjour,
Cela fait un petit moment que l'ARCEP parle de cet api, on en avait aussi parler sur lafibre.info.
Le but c'est que les logiciels de test de débit puisse savoir le type de connexion (aussi bien entre la box et le pc qu'entre la box et internet) ce qui permettra de bien mieux catégoriser les différents tests. Par exemple actuellement Nperf pour séparer les tests de débit câble des tests FTTH exclus tous les tests ayant réalisé moins de 100 mbps en UP, ce qui exclus aussi les tests FTTH "mauvais" et fausse les comparaisons. Avec cet API plus de problème, on peut savoir le type de connexion.
Il y aura aussi moyen de savoir si du débit est utilisé par un autre service, afin d'exclure les tests invalides des stats (ou informer l'utilisateur qu'il est mieux de couper les autres appareils pour avoir un test fiable).
Ça va dans le bon sens, les dev de chez Nperf, 4Gmark et autres vont être heureux (de mémoire ils ont participé à la création des specs de cet api).
Par contre ... Je viens de voir les actus ces derniers temps et je ne comprends pas du tout pourquoi sur la presse cet api est souvent qualifié de mouchard.
-
Par contre ... Je viens de voir les actus ces derniers temps et je ne comprends pas du tout pourquoi sur la presse cet api est souvent qualifié de mouchard.
ça vient enrichir le moulin à connerie qui tourne déjà à plein régime avec les complots chemtrails et autres sujets parano.
-
Il y a effectivement beaucoup de journaux qui n'ont rien compris à cette API. >:(
On va jouer au jeu du VRAI / FAUX sur l'API :
- L'API fait un test de débit : FAUX. L'API se contente de caractériser la ligne et ne fait aucun test. C'est l'outil habituel que vous utilisez qui fait le test (nPerf par exemple)
- L'API remonte des données personnelles : FAUX. Aucune donnée personnelle n'est remontée par l'API : ni localisation, ni identifiant unique, ni adresse mac: l'API indiquer le débit souscrit, le type de connexion entre le PC qui réalise le test et la box et savoir si il y a du crooss-trafic : du trafic autre que le test de débit, ce qui biaise le résultat du test (exemple: Box TV allumée)
- L'API permet "de réaliser des tests extrêmement précis en moins de 7 secondes" : FAUX, le code de conduite 2018 de l'Arcep (https://www.arcep.fr/uploads/tx_gspublication/code-de-conduite-qs-internet-2018_FR.pdf) précise que le test de débit doit avoir une durée minimum de 7 secondes ou 100 Mo.
- "Ce code sera bientôt applicable aux mesures de débit sur les réseaux mobiles." : FAUX, des outils mobile sont déjà conforme au code de conduite. Le rapport Arcep sur l'état de l'Internet 2019 en liste 3 : "Les outils de test de qualité de service mobile qui se sont déclarés conformes le Code de conduite de la qualité de service internet : nPerf, développé par nPerf ; DébiTest 60 : le testeur de connexion de 60 millions de consom-mateurs, développé par QoSi ; 4GMark, développé par QoSi"
-
Pour le coup, l'article cité parait plutôt correct, avec de bonnes informations. Tout ce que l'on peut lui reprocher est l'usage du terme "mouchard" pour l'API. Par exemple, il dit bien :
Pour la robustesse, le site de mesure s'engage à ce que le test dure au moins 7 secondes et télécharge plus de 100 Mo de données.
-
En fait, au delà du débat mouchards/données, personnellement, j'ai envie de dire : de quoi je me mêle.
Je ne vois pas trop l'intérêt de cette API.
A la limite, j'aurais préféré que l'on trouve le moyen que ça soit la box qui fasse le test afin de s'affranchir des limites des PC.
-
L'objectif est de fiabiliser les tests de débit, afin de s'appuyer sur du crowdsourcing pour comparer les opérateurs.
Sur le mobile, il y a https://www.monreseaumobile.fr/
Sur le fixe, il y a eu des tests en environnements contrôlés, mais c'était coûteux et peu représentatif, d'où l'idée de fiabiliser les tests de débit.
Certains régulateurs développent leur propre outil de test, le choix de l'Arcep est d’accompagner tous l'ecosystème à monter en qualité et fiabilité.
Les tests en environnement contrôlés et la communication de Bouygues Telecom :
Communiqué de presse
Bouygues Telecom 1er ou 1er ex-aequo sur 15 des 16 critères ADSL mesurés dans l’enquête « Qualité du service fixe d’accès à l’Internet » de l’ARCEP
Paris, le 26 novembre 2014 – Bouygues Telecom est 1er ou 1er ex-aequo sur 15 des 16 critères d’usage ADSL mesurés par l’ARCEP dans le cadre de l’enquête « Qualité des Services des réseaux fixes » parue le 25 novembre 2014, et qui présente des mesures de la qualité du service fixe d’accès à l’Internet * .
En particulier, le réseau ADSL de Bouygues Telecom est noté 1 er ou 1 er ex-aequo sur tous les critères liés au streaming vidéo et au téléchargement en mode P2P (peer-to-peer), sur la moyenne des performances.
« Bouygues Telecom a investi constamment ces dernières années pour rénover intégralement son réseau fixe. Grâce à ces équipements de dernière génération, et au travail formidable de nos équipes, nos clients bénéficient d’une excellente qualité de service. C’est un motif de satisfaction et de grande fierté pour toute notre entreprise » déclare Olivier Roussat, président-directeur général de Bouygues Telecom.
* Les mesures de qualité du service fixe d’accès à l’Internet contenues dans le rapport de l’ARCEP ont eu lieu du 26 mai au 30 juin 2014 (à l’exception du surf web, mesuré du 26 juin au 10 juillet 2014) dans 8 villes Françaises métropolitaines, selon une méthodologie arrêtée par l’ARCEP et validée par un comité technique rassemblant les acteurs du secteur (régulateur, opérateurs, associations de consommateurs et d’utilisateurs, experts indépendants).
Pour plus de détails, voir rapport et précisions méthodologiques sur arcep.fr
Le rapport (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/barometre/201411_arcep_rapport_qos_internet.png) (https://lafibre.info/images/barometre/201411_arcep_rapport_qos_internet.pdf)
Les données agrégées => https://lafibre.info/images/barometre/201411_arcep_rapport_qos_internet.zip
-
le type de connexion entre le PC qui réalise le test et la box
Si c'est une API côté box, on est d'accord que ça ne marchera pas si un switch est inséré ?
4GMark, développé par QoSi
Ne pas réussir à détecter l'opérateur mobile du test est "conformes au Code de conduite de la qualité de service internet" ? C'est étonnant.
-
Moi je trouve ça abusé. Je ne veux pas une merde de l’etat chez moi.
A la limite si c’est desactivable, pourquoi pas. Et encore...
-
Je suis sceptique aussi en cas de switch, de routeur ou de point d'accès perso branché, ça ne fonctionnera pas. En plus, pourquoi installer ça dans la box alors que les opérateurs disposent dans leurs bases de données des infos de synchronisation DSL ou d'abonnement fibre ?
-
Si c'est une API côté box, on est d'accord que ça ne marchera pas si un switch est inséré ?
Oui, il y a des cas à la marge où cela ne fonctionnera pas, comme un point d’accès WiFi connecté en Ethernet à la box.
Pour les CPL, certains opérateurs sont en mesure de détecter plus de 90% des CPL, mais pas tous.
En France, 99% des clients grand public utilisent uniquement le matériel de leur opérateur pour l’accès à Internet / Wi-FI. C'est moins le cas dans d'autres pays.
Ne pas réussir à détecter l'opérateur mobile du test est "conformes au Code de conduite de la qualité de service internet" ? C'est étonnant.
Je ne vois pas du tout à quoi tu fais référence, tu peut donner du contexte.
Pour le code de conduite, c'est aujourd'hui principalement de la transparence. Le code de conduite évolue régulièrement et il faudra attendre l'arrivée de l'API pour qu'il soit plus stricts sur de nombreux points comme le post-traitement / publication des données.
-
Oui, il y a des cas à la marge où cela ne fonctionnera pas, comme un point d’accès WiFi connecté en Ethernet à la box.
Merci :). Je chipote sur ce point et on est en phase que c'est à la marge.
Je ne vois pas du tout à quoi tu fais référence, tu peut donner du contexte.
Soucis de détection des eSIM, l'application prend en compte l'opérateur de la SIM physique. C'est un peu dommage.
(et je ne sais pas si il n'y a pas de soucis sur les double SIM aussi)
-
J'imagine que le bug de l'eSIM sera corrigé. C'est quel outil de test de débit qui est impacté ?
J’espère que cela peut se faire sans Apple.
Au passage, pendant longtemps sur iOS il était impossible de remonter le type de réseau (GPRS / Edge / 3G / 4G / 4G+) utilisé, c'était une limitation Apple, levée avec une nouvelle version iOS.
-
J'imagine que le bug de l'eSIM sera corrigé.
En attendant, c'est gênant.
C'est quel outil de test de débit qui est impacté ?
4GMark et Nperf à minima. #frenchteche
-
Merci Vivien pour ces précisions.
-
L'objectif est de fiabiliser les tests de débit, afin de s'appuyer sur du crowdsourcing pour comparer les opérateurs.
Sur le mobile, il y a https://www.monreseaumobile.fr/
Sur le fixe, il y a eu des tests en environnements contrôlés, mais c'était coûteux et peu représentatif, d'où l'idée de fiabiliser les tests de débit.
Certains régulateurs développent leur propre outil de test, le choix de l'Arcep est d’accompagner tous l'ecosystème à monter en qualité et fiabilité.
Les tests en environnement contrôlés et la communication de Bouygues Telecom :
Mouais, je ne suis toujours pas convaincu.
Je préférerais nettement qu'il y ait un formulaire où les testeurs puissent rentrer un certains nombre d'informations.
En ce qui concerne l'api, à l'heure du RGPD, j'estime qu'il est important que le user puisse refuser et désactiver l'api sur sa box.
Bref un mode opt-in plutôt que opt-out ...
D'autant que l'idée arrive (presque) trop tard, faisons en sorte d'implèmenter correctement l'api NetworkInformation des navigateurs et cela devrait suffire.
Vivement l'arrivée de l'API NetworkInformation pour classer les tests RJ des tests wifi !
https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation/type (https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation/type)
-
L'api NetworkInformation ne peut pas indiquer le débit souscrit auprès de ton opérateur.
Elle n'est pas en mesure de savoir si tu es en Ethernet ou en WiFi et quelles sont les capacité de la box en matière de WiFi / Ethernet et que les la connexion actuelle.
Il est impossible de savoir si il y a un usage en parallèle pendant ton test de débit ou si tu es seul à utiliser la ligne quand tu réalise ton test de débit.
Bref, c'est bien différent.
Concernant le RGPD, oui, il faut que les outils améliorent leur conformité au RGPD, c'est pré-requis pour avoir un accès à l'API.
-
L'api permet(era) justement de savoir si le périphérique est en Ethernet ou Wifi.
Certes elle ne permet pas de savoir tout le reste.
Mais à mon sens savoir si il y a un usage parallèle est une goutte d'eau à côté de :
- un ordinateur un peu vieillot
- une box supportant le wifi6 mais l'ordinateur n'ayant pas ces capacités
- des CPL vus comme des câbles RJ
- un câble RJ avec une paire manquante et négociant à 100 Mbps
etc.
Je n'arrive vraiment pas à voir en quoi l'API d'une box apporte des éléments pertinents au crowdsourcing.
Un simple questionnaire avec qqs questions n'est-il pas suffisant ?
Je préférerais nettement qu'ils développent des applis lourdes capables de remonter toutes ces infos et même plus (charge CPU par ex.) plutôt que de faire appel à une API donnant un semblant de fiabilité à ces données.
-
- une box supportant le wifi6 mais l'ordinateur n'ayant pas ces capacités
- un câble RJ avec une paire manquante et négociant à 100 Mbps
L'API permet de remonter ces deux cas là.
Elle permet de connaître les capacité de la box vs ce qui a été négocié (donc limité par le PC)
En Ethernet elle permet de connaître la capacité du port Ethernet vs ce qui a été négocié et donc d’alerter sur une limitation lié à un câble Ethernet avec seulement 2 paires ou un PC avec une carte réseau limité en 100 Mb/s.
-
En attendant, c'est gênant.
4GMark et Nperf à minima. #frenchteche
Ca n'a rien à voir avec le thread, du coup désolé pour le HS.
Sur iOS 12 il n'y a pas d'API officielle pour savoir quelle est la SIM utilisée pour Internet. Ça vous paraîtra peut-être hallucinant, on a eu la même réaction, mais hélas c'est bien le cas.
Du coup on a trouvé une autre technique pour avoir l'info (pas simple à mettre en place donc ça a pris un peu de temps mais ça fonctionne) ce sera déployé dans la prochaine release dans les jours qui viennent.
Sur iOS 13 une nouvelle API permet d'avoir l'info.
Pour SpeedTest, on pense qu'ils se basent uniquement sur l'adresse IP, du coup ça ne marche pas quand t'es en VPN et ça peut poser probablement aussi d'autres problèmes.
-
Salut,
pas convaincu non plus au dire ce cet article:
https://www.journaldugeek.com/2019/06/28/arcep-mouchard-operateurs-francais/
extrait "..., le type de connexion entre la box et l’ordinateur, quelle génération de WiFi est utilisée, la connexion de la box à d’autres appareils…"
1. "connexion de la box à d’autres appareils" ???
a quoi ca pourrait bien leur servir dans un speedtest, ca sent pas bon...
2. les 3 petits points a la fin, ca veut dire que la liste n'est pas complete ?
tant que le code de cette API ne sera pas publique alors ce sentirait le pompage de données perso...
bye Fred
-
On est d'accord que le RIPE propose ça depuis des années maintenant, avec ses sondes ATLAS ?
-
1. "connexion de la box à d’autres appareils" ???
a quoi ca pourrait bien leur servir dans un speedtest, ca sent pas bon...
2. les 3 petits points a la fin, ca veut dire que la liste n'est pas complete ?
tant que le code de cette API ne sera pas publique alors ce sentirait le pompage de données perso...
https://www.arcep.fr/uploads/tx_gspublication/rapport-etat-internet-2019-270619.pdf
Page 71 annexe 1.
Si je n'ai rien raté, je ne vois rien en rapport avec l'identification des autres terminaux, juste le débit vers internet et local au moment du test.
Sinon de manière générale attention au journal du geek qui représente les bas-fond du "journalisme" depuis des années déjà, toujours en retard sur l'actu et se trompe très (trop) souvent.
-
https://www.arcep.fr/uploads/tx_gspublication/rapport-etat-internet-2019-270619.pdf
Page 71 annexe 1.
Si je n'ai rien raté, je ne vois rien en rapport avec l'identification des autres terminaux, juste le débit vers internet et local au moment du test.
Sinon de manière générale attention au journal du geek qui représente les bas-fond du "journalisme" depuis des années déjà, toujours en retard sur l'actu et se trompe très (trop) souvent.
en fait il n'y a pas pléthore d'articles sur cet API pour le moment...
néanmoins, je reste tres mefiant tant que je ne vois pas le source de l'API.
-
en fait il n'y a pas pléthore d'articles sur cet API pour le moment...
néanmoins, je reste tres mefiant tant que je ne vois pas le source de l'API.
Une API n'est pas du code mais une abstraction que le code doit suivre, tu ne verras pas le "code de l'api" tout simplement parce qu'il y aura autant d'implantations de cette api qu'il y a de box/version_d'une_meme_box et que sfr, orange et les autres ne fournissent pas le code qu'ils n'ont aucune obligation légale de montrer (gpl, etc).
-
Une API n'est pas du code mais une abstraction que le code doit suivre, tu ne verras pas le "code de l'api" tout simplement parce qu'il y aura autant d'implantations de cette api qu'il y a de box/version_d'une_meme_box et que sfr, orange et les autres ne fournissent pas le code qu'ils n'ont aucune obligation légale de montrer (gpl, etc).
ah ouai ?
relit le lien sur le pdf que tu as envoyé (https://www.arcep.fr/uploads/tx_gspublication/rapport-etat-internet-2019-270619.pdf, annexe 1), tu verras qu'ils parlent d'API, 1ere ligne:
"ApiVersion" -> "Version de l’API"
etc...
donc, le module/script/API/ce-que-vous-voulez devrait etre rendu public du coté des box/routers afin que tout cela soit 100% transparent vis-a-vis du client, sinon on va voir apparaitre des outils pour bloquer les remontées des infos (ce qui ne serait pas + mal si y a embrouille)
bye Fred
-
juste pour rappel de la nature d'une API:
https://en.wikipedia.org/wiki/Application_programming_interface
-
On est d'accord que le RIPE propose ça depuis des années maintenant, avec ses sondes ATLAS ?
Pas du tout, c'est complèmentaire : L'API permet de caractériser la box, la sonde ATLAS permet de faire des tests.
L'API ne fait aucun test, c'est le logiciel qui appelle l'API qui fait des tests : nPerf par exemple mais cela pourrait être la sonde Atlas.
extrait "..., le type de connexion entre la box et l’ordinateur, quelle génération de WiFi est utilisée, la connexion de la box à d’autres appareils…"
1. "connexion de la box à d’autres appareils" ???
a quoi ca pourrait bien leur servir dans un speedtest, ca sent pas bon...
2. les 3 petits points a la fin, ca veut dire que la liste n'est pas complete ?
tant que le code de cette API ne sera pas publique alors ce sentirait le pompage de données perso...
Tout est publique, je t'invite à voir que les journalistes se sont trompés.
La dernière documentation : https://www.arcep.fr/uploads/tx_gspublication/consult-projdec-api-box-avril2019.pdf
-
Faut admettre que les termes "mouchard" et "ARCEP" dans le même titre ça crée le buzz.
Tout ça pour une API qui va juste dire que la co utilisée est en ADSL ou FTTH et permet d'atteindre X Mb/s sans même savoir à qui elle appartient. Ils sont forts ces journalistes 8)
-
juste pour rappel de la nature d'une API:
https://en.wikipedia.org/wiki/Application_programming_interface
Oui, ici on parle de la seconde proposition dans la première phrase de l'article (des protocoles de communication). Une interface de programmation est une interface qui permet de s'interfacer avec quelque chose par la programmation, les informaticiens utilisent ce terme aussi bien pour parler de protocoles (le plus souvent basés sur HTTP aujourd'hui) que de bibliothèques ou de modules logiciels, c'est un terme à l'emploi très vaste. Ici il est question d'un ensemble de terminaisons HTTP (c'est bien ce qui est défini dans le document de l'ARCEP). La notion d'interface est quand même dissociée de la notion d'implèmentation dans le langage courant (on va utiliser le terme API pour parler d'un ensemble de prototypes de fonctions utilisables par un composant externe, mais pas nécessairement de l'implèmentation associée).
-
juste pour rappel de la nature d'une API:
https://en.wikipedia.org/wiki/Application_programming_interface
Exactement ce que je dis donc...
ah ouai ?
relit le lien sur le pdf que tu as envoyé (https://www.arcep.fr/uploads/tx_gspublication/rapport-etat-internet-2019-270619.pdf, annexe 1), tu verras qu'ils parlent d'API, 1ere ligne:
"ApiVersion" -> "Version de l’API"
etc...
donc, le module/script/API/ce-que-vous-voulez devrait etre rendu public du coté des box/routers afin que tout cela soit 100% transparent vis-a-vis du client, sinon on va voir apparaitre des outils pour bloquer les remontées des infos (ce qui ne serait pas + mal si y a embrouille)
bye Fred
Quel est le rapport ? Il est possible d'implèmenter une même version d'une api de différentes façons, à partir du moment où les conventions de nommage et le reste sont respectés...
-
et le corollaire de cette api obligatoire dans les box c'est qu'elle soit aussi obligatoire dans tous les equipement qui peuvent remplacer la box ?
Ou tant qu'a faire on interdit d'avoir un acces a internet sans utiliser la box du fai ?
Et pourquoi pas faire la meme API sur les telephones ?
non mais quel truc de merde ils sont en train de preparer, franchement....
-
Je pense - j'espère - que ces gens qui n'ont pas la box FAI ne sont pas un soucis en terme de représentativité vu de l'ARCEP.
-
ah sisi, c'est un probleme
un anneau pour les gouverner tous !
-
bref, API ou pas API, ce n'est pas le + important...
questions que je me pose:
1. quel est l'objectif de l'ARCEP avec cet outil ?
je sous entend, a quoi ca va leur servir ? n'ont-ils pas d'autres chats a fouetter ?
2. est ce une demande des clients (nous) ? des sites de speedtest ? du gouv. ? de la CNIL ? autres ?
3. ou vont etre stocke les info et par qui ?
car il y a + d'info qui vont sortir grace a cet outil/methode/solution/... (choisir le bon terme a votyre convenance ;))
4. est ce la face immergé de l'iceberg pour obtenir + d'infos ?
5. cet solution (API) pourrait donc etre utiliser aussi par d'autres sites qui ne sont pas des speedtest...
nan, je ne suis pas partisan du complot global, je me pose simplement quelques questions...
bye
-
http://www.leparisien.fr/high-tech/internet-bientot-un-mouchard-pour-mesurer-le-debit-de-votre-box-27-06-2019-8104383.php
extrait: "modèle de la box, version du logiciel intégré, mais aussi débit souscrit par l'utilisateur, type de connexion (ADSL, fibre…), type de connexion entre la box et le PC, génération du wi-fi, connexion de la box à d'autres appareils…"
meme si generation-pc n'est pas fiable, leparisien.fr n'est peut etre un peu + ;)
bye Fred
-
http://www.leparisien.fr/high-tech/internet-bientot-un-mouchard-pour-mesurer-le-debit-de-votre-box-27-06-2019-8104383.php
extrait: "modèle de la box, version du logiciel intégré, mais aussi débit souscrit par l'utilisateur, type de connexion (ADSL, fibre…), type de connexion entre la box et le PC, génération du wi-fi, connexion de la box à d'autres appareils…"
meme si generation-pc n'est pas fiable, leparisien.fr n'est peut etre un peu + ;)
bye Fred
Vivien a donné le lien vers les specs : https://www.arcep.fr/uploads/tx_gspublication/consult-projdec-api-box-avril2019.pdf
C'est toujours mieux de se renseigner à la source.
Je suppose que par "connexion de la box à d'autres appareils" ils font référence à la possibilité de mesurer le cross-traffic.
L'intérêt c'est de savoir si la connexion a été sollicitée par d'autres appareils durant les quelques secondes de la mesure. C'est un simple compteur d'octets à un instant T, l'API ne renvoie aucune autre info.
Tout ce projet a pour objectif de mieux qualifier les mesures pour les post-traiter plus finement, et exclure éventuellement des mesures qui seraient prises dans de mauvaises conditions (mauvais wifi, cross traffic, etc.). Tout ça dans le but de faire des analyses plus précises et plus pertinentes pour le consommateur.
-
L'API vise à avoir des études fiables publiées par les acteurs spécialisés dans ces mesures (nPerf, QoSi, Ookla,...) dans le but de remplacer le dispositif fixe dans l’information des consommateurs.
On avait parlé du dispositif fixe, notamment le seul semestre où il y a a eu des données brutes de publiées, permettant de faire des graphes (j'avais représenté toutes les données sous forme de graphes).
L'ARCEP (le gendarme des Telecom français) a publié sont second observatoire de la QoS Internet, portant sur s2 2014
(https://lafibre.info/images/logo/logo_arcep_450.png)
Les mesures ARCEP (Autorité de régulation des communications électroniques et des postes) sont été effectuées sur 8 sites répartie en France métropolitaine, dans des conditions "permettant de s’affranchir d’un grand nombre de biais". Ces mesures officielles permettent à l'ARCEP d'assurer la mission, prévue par la loi, de supervision du niveau général de qualité du service d'accès à l'internet. La mise en œuvre de ce dispositif a été confiée, à la société ip-label (entreprise française spécialisée dans la mesure et le suivi de la qualité de service d’accès à l’internet).
(https://lafibre.info/images/logo/logo_ip-label.png)
C'est encore une version bêta et l'ARCEP insiste pour faire figurer cet avertissement pour chaque publication : "Cette deuxième publication est le fruit d’un très important travail visant à définir un protocole de mesure robuste garantissant une bonne comparabilité entre opérateurs. La mise en œuvre d’un tel protocole comporte un certain nombre de difficultés techniques qui ne peuvent être que progressivement résolues. Compte tenu du recul limité et des risques inhérents au lancement de tout dispositif de ce type, l’ARCEP invite le lecteur à la prudence quant à l’interprétation des données publiées dans le présent rapport de synthèse, qui correspond à un exercice test (version bêta)."
Afin de comparer ce qui est comparable, les données sont classées sous forme de 6 catégories d’accès (par la suite une catégorie = un graphique) :
- Lignes xDSL courtes : Lignes avec un affaiblissement théorique à 300 kHz est inférieure à 21 dB.
- Lignes xDSL moyennes : Lignes avec un affaiblissement théorique à 300 kHz est comprise entre 21 dB et 43 dB.
- Lignes ADSL longues : Lignes avec un affaiblissement théorique à 300 kHz est supérieure à 43 dB.
- Lignes HFC 30 Mb/s (Zones 30 Mb/s du réseau Numericable) : Lignes en fibre optique à terminaison coaxiale ou « hybrides fibre câble coaxial » (HFC) sur lesquelles sont proposées des offres avec des débits théoriques de 30 Mbit/s.
- Lignes FTTLA 100 Mb/s et + : Lignes en fibre optique à terminaison coaxiale sur lesquelles sont proposées des offres avec des débits théoriques de 100 Mbit/s ou plus. L'ARCEP à mesuré des box 100 et 200 Mb/s.
- Lignes FTTH : Lignes en fibre optique de bout-en-bout sur lesquelles sont proposées des offres avec des débits théoriques de 100 Mbit/s ou plus. Pour Orange c'est l'offre Livebox Jet haut de gamme qui est retenue (débit de 500 Mb/s ou 1 Gb/s suivant la zone). SFR est à 300 ou 1 Gb/s en fonction de la zone. Free et Bouygues Telecom ne sont pas mesurés en FTTH car ils ont moins de 100 000 clients FTTH (Free devrait l'être le semestre prochain, vu qu'ils ont dépassé en décembre 2014 les 100 000 clients).
L'ARCEP mesure le débit de 6 façons :
- http depuis Paris (hébergeur Mediactive)
- http depuis Lyon (hébergeur Adeli)
- http depuis Londres (hébergeur Akamai)
- http depuis Francfort (hébergeur Akamai)
- http depuis New-York (hébergeur Akamai)
- P2P en téléchargeant une ISO d'Ubuntu LTS
Les débits des 5 premiers sites ne sont "pas publiés in extenso, la phase de rodage du dispositif s’étant poursuivie au second semestre.". Il ne reste donc que les débits en P2P :
-
L'API est enfin adoptée par l’Arcep. La décision Arcep va être transmise pour homologation au ministre chargé des communications électroniques puis, sous réserve d’homologation, publiée au Journal officiel.
La décision n°2019-1410 : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/barometre/201910_arcep_decision_api_box.png) (https://lafibre.info/images/barometre/201910_arcep_decision_api_box.pdf)
Un communiqué de presse bien détaillé accompagne la décision, afin d'éviter des articles de presse qui se trompent. Non l'API ne réalise aucun test de débit.
Le communiqué de presse de l'Arcep :
L’Arcep adopte la décision visant à fiabiliser la mesure de qualité de service de l’internet fixe à travers la mise en place d’une API dans les box
Paris, le 25 octobre 2019
Sur les réseaux fixes, la mesure de la qualité de service est particulièrement complexe : il est à ce jour quasi-impossible techniquement pour un outil de mesure (souvent appelé « speed test ») de connaître avec certitude la technologie d’accès (cuivre, câble, fibre, etc.) sur laquelle a été réalisé un test. Ce manque de caractérisation de la mesure, qui ne permet pas d’isoler des facteurs susceptibles de modifier fortement les résultats, rend les données difficilement exploitables, voire, dans certains cas, induit en erreur le consommateur.
L’API « carte d’identité de l’accès » dans les box : caractériser l’environnement de la mesure, une démarche pionnière à l’échelle mondiale
De nombreux utilisateurs utilisent aujourd’hui des outils de mesure en crowdsourcing pour évaluer le débit ou plus généralement la qualité de service de leurs accès internet. L’API « carte d’identité de l’accès », à laquelle ces outils de mesure auront accès, a pour objectif de caractériser l’environnement de la mesure. Sollicitée uniquement lorsque l'utilisateur initie un test de débit, et sous son contrôle, l'API renseignera l’outil de mesure sur une série d’indicateurs techniques, tels que la technologie d’accès à internet, les débits montant ou descendant contractuels, la qualité du Wi-Fi, etc.
Les résultats obtenus, désormais qualifiés, sont un nouveau pas dans l’amélioration de la mesure de la qualité de service des réseaux fixes.
La décision de l’Arcep précise le cadre de mise en place de l’API, dans le respect et la protection de la vie privée des utilisateurs
Opérateurs et box concernés, paramètres techniques remontés, calendrier de mise en place, spécifications techniques d’implèmentation sont précisés dans la décision. Les données recueillies par l’API ne sont pas transmises à l’Arcep. Aucune donnée liée à l’identification de l’utilisateur (identifiant, nom, localisation etc.) ne sera par ailleurs transmise par l’API aux outils de mesure, dans un objectif de protection de la vie privée des utilisateurs. L’API est sollicitée lors d’un test de débit initié par l’utilisateur lui-même et ne répond pas aux sollicitations depuis internet. Questionnée dans le cadre de cette démarche, la CNIL a pu s’assurer que le dispositif répondait dans son principe aux exigences en matière de protection des données personnelles tout en insistant sur l’importance du rôle de conseil de l’Arcep, notamment au travers du « Code de conduite de la qualité de service internet » vis-à-vis des outils de mesure exploitant l’API.
L’API « carte d’identité de l’accès » : une démarche de co-construction avec les acteurs de l’écosystème
L’Arcep a lancé en début d’année 2018 un vaste chantier sollicitant toutes les parties prenantes afin de résoudre les difficultés de mesure de la qualité de service des réseaux fixes. Cette démarche de co-construction initiée par l’Arcep implique une vingtaine d’acteurs dont des outils de mesure en crowdsourcing, des opérateurs et des acteurs académiques. L’écosystème a convergé vers la mise en place d’une Application Programming Interface (API) implèmentée directement dans les box des opérateurs et accessible aux outils de mesure qui respectent le Code de conduite publié par l’Arcep .
Une consultation publique a été menée au printemps dernier sur ce projet ; les dix-sept réponses reçues par l’Arcep sont publiées ce jour (cf. annexe). Ces contributions ont permis d’ajuster, en concertation avec les acteurs de l’écosystème, les modalités de mise en œuvre de l’API.
La décision adoptée par l’Arcep va être transmise pour homologation au ministre chargé des communications électroniques puis, sous réserve d’homologation, publiée au Journal officiel.
Document associé : Décision n°2019-1410 (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/barometre/201910_arcep_decision_api_box.png) (https://lafibre.info/images/barometre/201910_arcep_decision_api_box.pdf)
-
Pour en savoir plus sur l’API « Carte d’identité de l’accès »
Comment fonctionne l’API ?
(https://lafibre.info/images/barometre/201910_arcep_decision_api_box_1.png)
(1) L’outil de mesure utilisé par le client envoie une requête à l’API située dans la box.
(2) L’API répond à l’outil de mesure en lui transmettant les spécifications techniques qui caractérisent l’environnement de l’utilisateur.
La plupart des informations transmises sont disponibles nativement dans la box. Les autres spécifications non disponibles nativement, comme le débit souscrit par l’utilisateur, sont transférées du système d’information des opérateurs à la box (3).
Quels sont les outils de mesure qui ont accès à l’API ?
L’API sera accessible aux outils de mesure qui se sont déclarés conformes au « Code de conduite de la qualité de service internet » publié par l’Arcep.
A ce jour, cinq outils de test de qualité de service d’internet fixe se sont déclarés conformes à ce Code de conduite :
• nPerf (https://www.nperf.com/) ;
• SpeedTest UFC-Que Choisir (https://www.quechoisir.org/outil-speedtest-n64483) ;
• DébitTest 60 (https://www.60millions-mag.com/debitest-60-le-testeur-de-connexion-de-60-millions-de-consommateurs) ;
• 4GMark (https://www.4gmark.com/test) ;
• IPv6-test (https://ipv6-test.com/).
Le Code de conduite de la qualité de service internet, version 2018, qui fixe un niveau minimum de transparence et de robustesse, sera amené à évoluer périodiquement.
Quelles sont les box concernées par l’API ?
Les opérateurs qui ont plus d’un million de clients et qui remplissent les conditions décrites dans la décision de l’Arcep auront l’obligation d’implèmenter l’API dans la majorité des modèles de box xDSL, câble, FTTH et 5G fixe proposées aux clients à l’issue d’un délai de 18 mois à compter de la publication, après homologation, de la décision de l’Arcep au Journal officiel.
L’Arcep encourage également à implèmenter l’API dans les autres modèles de box.
L’API est-elle accessible depuis Internet ?
Non, l’API est accessible uniquement depuis le réseau local de l’utilisateur final et ne répond pas aux requêtes provenant d’internet. De plus, un système de restriction d’accès est mis en place, afin que seuls les outils autorisés puissent accéder à l’API.
Quand l’API sera-t-elle disponible ?
Le déploiement de l’API sera progressif :
• 22 mois après la publication de la décision, l’API sera implèmentée dans 5% des box du parc concerné par la mise en place de l’API ;
• 26 mois après la publication de la décision, l’API sera implèmentée dans 40% des box du parc concerné ;
• 30 mois après la publication de la décision, l’API sera implèmentée dans 95% des box du parc concerné et 100% des box du parc concerné proposées aux nouveaux clients.
-
Les délais sont annoncés en mois "après la publication de la décision".
La publication n'est pas celle de l'Arcep mais celle du Journal officiel, après homologation au ministre chargé des communications électroniques. Si tout se passe bien, cela devrait se faire début 2020.
Donc l'API arrivera concrètement en 2022, le temps de laisser le temps aux opérateurs de la mettre en place.
Si vous regardez la décision, vous pouvez voir que contrairement aux décisions habituelles de l'Arcep, on rentre dans les détails techniques. TLS apparaît une dizaine de fois dans la décision par exemple.
Exemple avec l'annexe 3 qui détaille la sécurisation minimum des SpeedTest / nPerf / ... pour avoir accès à l'API :
Afin de mieux fiabiliser la restriction définie en annexe 2, les outils de mesure devraient mettre en
place les mesures de sécurité suivantes :
- le nom de domaine de l’outil de mesure doit être signé par DNSSEC, afin de protéger contre
le cache poisoning ;
- le champ DNS Certification Authority Authorization (CAA) doit être déclaré pour limiter les
autorités de certification (CA) qui sont autorisées à délivrer des certificats pour le nom de
domaine ;
- un appel au site en HTTP doit contenir uniquement une redirection vers le même site en
HTTPS ;
- les échanges HTTPS ne doivent pas gérer des versions inférieures à TLS 1.2 ;
- les en-têtes HTTP Strict Transport Security (HSTS) doivent être envoyés sur le domaine
principal.
Rien de révolutionnaire, ce sont les bonnes pratiques pour sécuriser un site.
-
Pour des raisons de sécurité et de confidentialité des échanges, l’API ne répond pas sur une
connexion HTTP sans couche de chiffrement TLS. L’API n’est accessible que depuis le réseau local
(LAN) de l’utilisateur final et ne répond pas aux requêtes qui pourraient provenir d’Internet
....
Afin de sécuriser l’API et réduire le périmètre d’attaque, un système de restriction d’accès doit être
mis en place. La restriction d’accès retenue en concertation avec les différents acteurs impliqués est :
CORS + OAuth 2.0 (https://oauth.net/2/) avec un token à validité de 15 minutes.
Chaque outil de mesure autorisé dispose d’un jeton OAuth dédié et peut en demander un second
pour effectuer des vérifications avant une mise en production.
euh pourquoi CORS/OAuth si on ne peut y accéder que de l’intérieur ?!
donc je ne pourrais pas creer mon propre outil pour faire mes propres speedtest ?
"en concertation avec les différents acteurs impliqués" ->
. a croire qu'ils veulent pas que de nouveaux concurrents viennent ? du moins pas facilement ?
. et/ou a croire que les opérateurs veulent limiter/controller quel outils utilisent l'api ?
franchement c'est étonnant que l'ARCEP laisse faire cela.
(je n'ai pas encore tout lu donc y'a peut-etre quelque chose que j'ai loupé).
-
Probablement pour une question de vie privé.
Laisser l'api ouvert, c'est permettre à des scripts d'accéder à ces informations (même si l'accès ne se fait qu'en local, via du javascript dans le navigateur tu peux récupérer les données) et ces informations pourraient être utilisé pour faire du profilage publicitaire.
Après c'est effectivement dommage dans le sens où cela limiterai les acteurs, j'aurai bien aimé faire quelque test avec l'api une fois déployé perso.
Sinon j'ai regardé les spécifications rapidement, ça semble bien pensé.
-
Probablement pour une question de vie privé.
Laisser l'api ouvert, c'est permettre à des scripts d'accéder à ces informations (même si l'accès ne se fait qu'en local, via du javascript dans le navigateur tu peux récupérer les données) et ces informations pourraient être utilisé pour faire du profilage publicitaire.
Après c'est effectivement dommage dans le sens où cela limiterai les acteurs, j'aurai bien aimé faire quelque test avec l'api une fois déployé perso.
Sinon j'ai regardé les spécifications rapidement, ça semble bien pensé.
Franchement je doute que ce soit pour cela. Un simple mot de passe définissable par l'utilisateur suffit pour contrer ce genre de chose.
Tout le truc me semble fait 'dans un coin, entre amis' au lieu d'une approche dans l'esprit d'Internet avec RFC et un depot de source commun sur github ou autre et contrôlé par l'ARCEP. Cet problématique n'est pas franco-française après tout. Il y déjà une base, UPnP-IDG, que toutes les box supportent déjà, et que tous les routeurs SOHO supportent. Il suffisait de partir la dessus et d'amender des nouvelles fonctionnalités par RFC dont une api web.
En plus rendre le truc 'IPv6 only' (ie l'API ne fonctionne qu'en IPv6 par exemple) aurait été un plus.
-
La sécurisation est une demande des FAI et non pas une demande des outils de mesure de la QoS (les SpeedTest / nPerf / ...).
L'idée est d'éviter que Facebook ou des régies publicitaires se servent de l'API pour faire de la publicité ciblée. Abonnement à 10 Gb/s => personne aisée => produits de luxe. Abonnements à 2 Mb/s, ADSL mauvais, pub pour un abonnement satellite...
Avec la puissance du Wi-Fi, je suis sur que certains pourraient faire des choses...
Rien empercherait un site web ou une application d'appeler l'API sans le consentement de l'utilisateur.
Bref, pour éviter tout usage abusif, seul les outils de test de débit conforme a un code de conduite peuvent accéder à l'API et pour éviter tout usage frauduleux, la sécurisation est réalisée selon les règles de l'art.
C'est tout le contraire d'un mouchard (terme repris par la presse qui n'avait probablement pas lu les 17 pages)
-
Pour un site, ça aurait été bloqué via CORS (hors DNS poisoning, mais dans ce cas la box verrait un champ Host qui ne correspondrait pas).
Mais une application (notamment mobile) aurait pu faire les requêtes.
Là effectivement c'est bloqué, mais ça empêche donc l'utilisateur ou tout programme opensource d'exploiter l'API.
Il aurait été possible d'autoriser le mot de passe de la box (il permet déjà accéder à l'interface web en local, donc ça n'aurait pas ajouté de risque supplèmentaire côté sécurité) en plus du système à base OAuth qui a l'avantage de ne rien devoir demander à l'utilisateur.
-
L'idée est d'éviter que Facebook ou des régies publicitaires se servent de l'API pour faire de la publicité ciblée. Abonnement à 10 Gb/s => personne aisée => produits de luxe. Abonnements à 2 Mb/s, ADSL mauvais, pub pour un abonnement satellite...
Avec la puissance du Wi-Fi, je suis sur que certains pourraient faire des choses...
Je me demande bien qui a pu imaginer un scenario pareil et chez quel(s) FAI...c'est juste pas crédible une seconde. Les régies pubs ont de bien meilleurs moyens d'obtenir ces infos sans aller utiliser une api franco-française ...
Et franchement avoir un abo a 10Gbps chez Free n'indique en rien de la CSP d'une personne.
Le plus inquiétant dans cette solution c'est qu’apparemment les opérateurs ont le contrôle total de qui peut utiliser l'API. Il n'est fait mention nulle part des règles qui régissent la liste ' Access-Control-Allow-Origin' (CORS).
Et l'OAuth retenue court-circuite complètement l'utilisateur : ce n'est pas lui qui a le contrôle final de qui peut utiliser l'API.
Une approche 'neutre' et sous le contrôle de l'utilisateur, devrait être comme les OAuth que tout les utilisateurs connaissent et pratiquent déja quand ils se connectent avec un compte Google, FaceBook, Twitter, etc sur un site tiers (ou comme avec FranceConnect).
Dans le cas présent il suffit d'une sorte de serveur oauth 'neutre' géré directement par et que par l'ARCEP.
En détail:
- N'importe qui peut créer un compte d'outil de mesure sur le site (géré par l'ARCEP donc) en donnant un email valide et l'url CORS qui sera utilisée.
- Un process auto ou manuel permet de valider l'email et l'url (notamment vérifier que la personne a bien le contrôle de l'url comme fait LetsEncrypt). D'autres infos peuvent éventuellement être demandés & validés comme l'identité, le but du test, etc, usage perso ou pro (avec kbis) etc. Une fois validé l'url est dans une base globale chez l'ARCEP (éventuellement pour une durée limité comme 1 mois , a renouveler régulièrement donc).
- Ensuite ce sont les box qui iront directement interroger cette base globale pour valider ou pas une requête sur l'api lan. Si l'url est autorisée par la base de l'ARCEP, la box présente ensuite une demande d'autorisation a l'utilisateur ('autorisez vous <url> de <email ou nom de société> a accéder a vos informations technique d’abonnement Internet (cette presentation se fait via une page web avec une URL fixe sans CORS que les sites de test pourront intégré dans un popup comme font Google,Facebook, etc quand ils permettent une oauth sauf que la il n'y a pas besoin de compte utilisateur/mot de passe, la box autorisant cette demande que si ca vient du lan et avec la bonne url).
- si l'utilisateur autorise la demande, l'url est ajouté a la liste 'Access-Control-Allow-Origin' (CORS) de la box (durée limitée a 15 minutes par exemple).
- en option, l'interface de la box permet aussi d'ajouter manuellement des URLs dans la CORS de la box pour les utilisateurs avancées ou ceux souhaitant automatiser les mesures chez eux.
- En aucun cas les FAI n'ont a gérer de backoffice spécifique a cela ou peuvent bloquer qui que ce soit. Ils n'ont pas la liste des url des outils de mesure enregistrés a l'ARCEP dans la base globale (personne d'autre que l'ARCEP n'a cette liste) et n'ont pas a la connaitre. Ils peuvent par un process de signalement d'abus justifié a l'ARCEP faire éventuellement retirer de la base globale une url qui ferait trop de demande sur l'API (mais ils peuvent de toute façon 'throttler' l'API s'ils le souhaitent et ils le devraient de toute façon et cela suffit largement comme protection).
Bref y'a quasi zero coût en backoffice, support, etc (OPEX) pour les FAI que du code a ajouter et valider dans les box, code qui peut et devrait être fournit par l'ARCEP dans le cadre d'un projet open-source accessible a tous. Le coût pour les FAI est minimal , juste les tests d'intégration/validation/stabilité de leur box avec le code commun et il ne faut pas 2 ans pour ca...
l'ARCEP peut éventuellement demandé une participation financière aux outils de mesure si c'est pour un usage pro (l'ARCEP aura de toute facon pour chaque outil (url) le taux d'usage puisque toutes les box de France viendront interroger le serveur de l'ARCEP. Si besoin des quotas/limites peuvent donc être prévus avec des options payantes).
-
Beau cadeau que fait l'ARCEP à cette liste d'outils de mesure, ils ont du ouvrir le champagne !
Y a-t-il une contrepartie pour s'assurer de la qualité des tests qu'ils réalisent ou c'est un chèque en blanc ? Je lis "se sont déclarés conformes" au code de bonne conduite, c'est vérifié ou déclaratif ?
-
Je me demande bien qui a pu imaginer un scenario pareil et chez quel(s) FAI...c'est juste pas crédible une seconde. Les régies pubs ont de bien meilleurs moyens d'obtenir ces infos sans aller utiliser une api franco-française ...
Plusieurs pays suivent cette initiative et si c'est une réussite, cela pourrait arriver dans d'autres pays.
Si l'API est généralisée dans plusieurs pays les sociétés vont être intéressé pour l'utiliser. CORS ne protège que des sites web et pas d'applications ou des système d'exploitation. CORS a été proposé, mais cette méthode plus simple a été rejeté par les opérateurs.
Beau cadeau que fait l'ARCEP à cette liste d'outils de mesure, ils ont du ouvrir le champagne !
Y a-t-il une contrepartie pour s'assurer de la qualité des tests qu'ils réalisent ou c'est un chèque en blanc ? Je lis "se sont déclarés conformes" au code de bonne conduite, c'est vérifié ou déclaratif ?
Le but de l'Arcep est d'avoir des baromètres fiables, pour faire de la "régulation par la data".
Aujourd'hui les baromètres mixent toutes les technologies (xDSL, câble, FTTH, ...) ou tentent de séparer les tests par technologies en filtrant sur le débit montant. Les offres FTTH a des débits commerciaux sont toutes mélangées, bref cela ne permet pas d'en déduire si un FAI est bon ou non. Un opérateur peut être premier juste par-ce-qu'il a un pourcentage de clients plus important qui ont souscrit a des offre avec un grands débit.
N'importe quel outil peut se mettre en conformité avec le code de conduite et avoir accès à l'API.
Le code de conduite qui est aujourd'hui essentiellement de la transparence va évoluer pour garantir un minimum de qualité et de représentativité.
Maintenant c'est un sujet complexe. Je prend l'exemple des mire de tests (les serveurs) : Certains souhaitent pousser pour que les mires soit au minimum à 10 Gb/s tandis que d'autres pour que les mires ne soient pas chez les FAI de façon a être plus représentatif d'Internet.
Or les grande majorité des mires à 10 Gb/s sont des mires fournies par les opérateurs il est donc impossible de demander les deux.
-
Si l'API est généralisée dans plusieurs pays les sociétés vont être intéressé pour l'utiliser. CORS ne protège que des sites web et pas d'applications ou des système d'exploitation. CORS a été proposé, mais cette méthode plus simple a été rejeté par les opérateurs.
Le but de l'Arcep est d'avoir des baromètres fiables, pour faire de la "régulation par la data".
Je ne comprend pas cette logique de l'ARCEP. Pour moi, ce n'est pas aux opérateurs de décider qui peut ou pas utiliser l'API et dans tous les cas c'est a l'utilisateur d'autoriser cela ou pas. A ma connaissance mon contrat de box avec mon FAI ne l'autorise pas a communiquer mon type d'abo a Nperf ou 4GMark ou etc meme si je vais moi-meme sur le site de Nperf ou 4GMark: il faut que je l'autorise.
En plus la solution retenue va forcement dévier vers une connivance entre opérateurs et ses sociétés de mesure. Deja qu'ils sont en dépendance économique directe quand on connait le business model des 'speed-testeurs'. C'est a ce demander si ce business model a été étudier et compris par l'ARCEP avant de lancer ce chantier...
Franchement je veux pas être méchant mais tout ce projet me semble être complètement mal conduit par l'ARCEP. On croit revivre ce que la HADOPI a produit...
Et meme si c'est pour faire un truc 'entre amis agrées' il suffit de faire du B2B direct entre les FAI et les testeurs: une simple API entre eux qui prend l'@IP en parametre et renvoi les info du type d'abo, etc. Ca ne passe par les box. C'est simple et y'a pas de complexité inutile (pki, token etc) dans les box.
- je fais un test sur Nperf, Nperf voit mon IP et connait mon FAI, demande a mon FAI en direct les caractéristiques de mon abo.
Pour les données techniques, il suffit juste d'exposer les compteurs de la box sur le LAN sans aucune sécurité ,avec un simple throttling a une seconde par exemple. un peu comme du simple SNMP exposé en HTTP, y'a pas a ce prendre plus la tete que ca. Il n'y a rien de sensible ou d'exploitable par un tiers. D'ailleurs,pour le volume upload/download on peut déjà le faire en UPnP, il suffit de télécharger/install upnpc (http://miniupnp.free.fr/index_fr.html)et faire 'upnpc -S' depuis n'importe quelle machine du LAN...
-
Et meme si c'est pour faire un truc 'entre amis agrées' il suffit de faire du B2B direct entre les FAI et les testeurs: une simple API entre eux qui prend l'@IP en parametre et renvoi les info du type d'abo, etc. Ca ne passe par les box. C'est simple et y'a pas de complexité inutile (pki, token etc) dans les box.
Cette solution a été évoquée. Elle ne plaît ni aux opérateurs car il y a un risque de sécurité (surtout DDOS mais pas que) en ouvrant une porte sur leur SI, ni aux outils : la plupart des indicateurs sont absents : comment savoir si on est en WiFi ou en Ethernet (cas d'un test lancé depuis le navigateur) ? Si Ethernet, comment connaître le débit du lien ? Comment connaître le débit maximal du port ? (Si le débit commercial et la débit du port maximal est supérieur au débit du port utilisé pour faire le test, alors le test est en mesure de savoir que c'est la carte Ethenret ou le cêble du PC qui limite le débit)
Si c'est un test réalisé en Wi-Fi, comment connaître la technologie du PC connecté ? la bande de fréquence utilisée ? Le RSSI ?
Tous ces indicateurs nécessitent une API sur la box.
-
Parfois, on est obligé de dire des choses désagréables à nos amis.
Et sur cet aspect, je suis assez d'accord avec l'analyse de kgersen.
Que diable allait faire l'ARCEP dans cette galère ?
On comprends que l'ARCEP souhaite se doter d'un instrument de mesure pour ses propres statistiques.
La question est, est-ce du domaine de compétences de l'ARCEP d'imposer aux opérateurs de mettre en oeuvre des outils à disposition de tiers allant à l'encontre des autorisations personnelles à donner au préalable ?
La question "Oauth" est actuellement importante et passée sous silence, on DONNE l'accès au système d'authentification personnelle aux GAFA en toute connaissance de cause, pour "simplifier" la vie des utilisateurs (c'est en soi une bonne chose) mais plutôt pervers.
Un exemple personnel qui m'énerve bien comme il faut : J'avais depuis de nombreuses année accès à mon compte GDF avec mon adresse mail d'identifiant personnel et ma messagerie personnelle.
Et bien ce organisme pseudo-étatique a décidé que mon adresse mail ne lui plais pas, et m'oblige à utiliser "Oauth" d'un tiers ( Google ). Une adresse mail google a donc plus de légitimité auprès de GDF que la mienne. Pas de bol, l'auth se fais avec mon système de messagerie en partie chez google ( le chat se mords la queue ).
Tout ceci pour dire quoi ?
Est-ce légitime de donner accès à des informations personnelles à des tiers sans accord de la personne intéressée ?
On peux inverser le raisonnement, si des acteurs souhaitent utiliser des informations me concernant, via la box de mon opérateur, si ils rémunèrent mon opérateur pour que mon accès soit gratuit, il y a matière à y réfléchir.
-
Parfois, on est obligé de dire des choses désagréables à nos amis.
Pas de souci, si tu te pose ces questions, d'autres vont se les poser. C'est peut-être pas assez clair.
Est-ce légitime de donner accès à des informations personnelles à des tiers sans accord de la personne intéressée ?
Il n'y pas de données personnelles dans l'API elle ne remonte ni adresse IP, ni adresse mac, ni aucune autre donnée personnelle.
Bien sur plusieurs acteurs ont demandé qu'on rajoute la localisation du test, mais c'est une donnée personnelle et cela a été supprimé pour cette raison (avec d'autres comme un identifiant unique de lute contre le fraude).
Le communiqué de presse Arcep précise : Questionnée dans le cadre de cette démarche, la CNIL a pu s’assurer que le dispositif répondait dans son principe aux exigences en matière de protection des données personnelles
La question "Oauth" est actuellement importante et passée sous silence, on DONNE l'accès au système d'authentification personnelle aux GAFA en toute connaissance de cause, pour "simplifier" la vie des utilisateurs (c'est en soi une bonne chose) mais plutôt pervers.
L'utilisateur n'a pas besoin de s'identifier, ce sont les outils (nPerf, SpeedTest,...) qui s'identifient.
Les GAFA ne sont pas du tout dans la boucle, le serveur Oauth est chez les opérateurs pas chez les GAFA.
La question est, est-ce du domaine de compétences de l'ARCEP d'imposer aux opérateurs de mettre en oeuvre des outils à disposition de tiers
La première page de la décision liste les textes qui permettent à l'Arcep de le faire. Le plus important, c'est le L. 32-1,L. 36-6et D. 98-4 du CPCE.
Que diable allait faire l'ARCEP dans cette galère ?
Ces tests en crowdsourcing prennent la suite du dispositif contrôlé fixe dont on a parlé ici qui est arrêté depuis quelques années.
Les opérateurs ont préféré sortir de l'ancien système coûteux et pas suffisamment représentatif.
J'avais en 2015 analysé les données OpenData pour en sortir des indicateurs supplèmentaires :
L'ARCEP (le gendarme des Telecom français) a publié sont second observatoire de la QoS Internet, portant sur s2 2014
(https://lafibre.info/images/logo/logo_arcep_450.png)
Les mesures ARCEP (Autorité de régulation des communications électroniques et des postes) sont été effectuées sur 8 sites répartie en France métropolitaine, dans des conditions "permettant de s’affranchir d’un grand nombre de biais". Ces mesures officielles permettent à l'ARCEP d'assurer la mission, prévue par la loi, de supervision du niveau général de qualité du service d'accès à l'internet. La mise en œuvre de ce dispositif a été confiée, à la société ip-label (entreprise française spécialisée dans la mesure et le suivi de la qualité de service d’accès à l’internet).
(https://lafibre.info/images/logo/logo_ip-label.png)
C'est encore une version bêta et l'ARCEP insiste pour faire figurer cet avertissement pour chaque publication : "Cette deuxième publication est le fruit d’un très important travail visant à définir un protocole de mesure robuste garantissant une bonne comparabilité entre opérateurs. La mise en œuvre d’un tel protocole comporte un certain nombre de difficultés techniques qui ne peuvent être que progressivement résolues. Compte tenu du recul limité et des risques inhérents au lancement de tout dispositif de ce type, l’ARCEP invite le lecteur à la prudence quant à l’interprétation des données publiées dans le présent rapport de synthèse, qui correspond à un exercice test (version bêta)."
Afin de comparer ce qui est comparable, les données sont classées sous forme de 6 catégories d’accès (par la suite une catégorie = un graphique) :
- Lignes xDSL courtes : Lignes avec un affaiblissement théorique à 300 kHz est inférieure à 21 dB.
- Lignes xDSL moyennes : Lignes avec un affaiblissement théorique à 300 kHz est comprise entre 21 dB et 43 dB.
- Lignes ADSL longues : Lignes avec un affaiblissement théorique à 300 kHz est supérieure à 43 dB.
- Lignes HFC 30 Mb/s (Zones 30 Mb/s du réseau Numericable) : Lignes en fibre optique à terminaison coaxiale ou « hybrides fibre câble coaxial » (HFC) sur lesquelles sont proposées des offres avec des débits théoriques de 30 Mbit/s.
- Lignes FTTLA 100 Mb/s et + : Lignes en fibre optique à terminaison coaxiale sur lesquelles sont proposées des offres avec des débits théoriques de 100 Mbit/s ou plus. L'ARCEP à mesuré des box 100 et 200 Mb/s.
- Lignes FTTH : Lignes en fibre optique de bout-en-bout sur lesquelles sont proposées des offres avec des débits théoriques de 100 Mbit/s ou plus. Pour Orange c'est l'offre Livebox Jet haut de gamme qui est retenue (débit de 500 Mb/s ou 1 Gb/s suivant la zone). SFR est à 300 ou 1 Gb/s en fonction de la zone. Free et Bouygues Telecom ne sont pas mesurés en FTTH car ils ont moins de 100 000 clients FTTH (Free devrait l'être le semestre prochain, vu qu'ils ont dépassé en décembre 2014 les 100 000 clients).
L'ARCEP mesure le débit de 6 façons :
- http depuis Paris (hébergeur Mediactive)
- http depuis Lyon (hébergeur Adeli)
- http depuis Londres (hébergeur Akamai)
- http depuis Francfort (hébergeur Akamai)
- http depuis New-York (hébergeur Akamai)
- P2P en téléchargeant une ISO d'Ubuntu LTS
Les débits des 5 premiers sites ne sont "pas publiés in extenso, la phase de rodage du dispositif s’étant poursuivie au second semestre.". Il ne reste donc que les débits en P2P :
Débit médian en téléchargement P2P :
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_1.png)
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_2.png)
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_3.png)
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_4.png)
FTTH : Les données d'Orange ne sont pas publiées
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_5.png)
(https://lafibre.info/images/barometre/201505_arcep_qos_internet_p2p_median_6.png)
-
Du coup si on a pas de box, c'est tout bon ?
C'est un nouveau use case intéressant du remplacement de la box !
-
Si un client n'a pas de box, si un client a une box pas éligible, si un client a désactivé l'API (certains opérateurs vont le proposer),...
Bref le test de débit se fait sans l'API, comme c'est le cas aujourd’hui. Les données ne seront probablement pas utilisées pour un baromètre.
-
Le plus dommage c'est qu'un site comme testdebit.info qui si un jour décide enfin de se passer de nperf pour utiliser un truc 100% open source comme Librespeed (source: https://github.com/librespeed/speedtest ,demo: http://speedtest.fdossena.com/) ne pourra profiter de l'API ou sera a la merci des opérateurs pour le pouvoir.
Ca va tuer tout innovation de développement ce qui est clairement le but quand on fait un 'truc en amis' ("club" de sociétés ayant des intérêts communs a défendre) plutôt qu'un truc 'public open data' destinée a promouvoir l'innovation, la transparence et donner une vraie raison a l’existence et au coût de fonctionnement (nos taxes & impôts) d'un régulateur.
-
comment savoir si on est en WiFi ou en Ethernet (cas d'un test lancé depuis le navigateur) ? Si Ethernet, comment connaître le débit du lien ? Comment connaître le débit maximal du port ? (Si le débit commercial et la débit du port maximal est supérieur au débit du port utilisé pour faire le test, alors le test est en mesure de savoir que c'est la carte Ethenret ou le cêble du PC qui limite le débit)
Si c'est un test réalisé en Wi-Fi, comment connaître la technologie du PC connecté ? la bande de fréquence utilisée ? Le RSSI ?
Tous ces indicateurs nécessitent une API sur la box.
Pour ça, est-ce qu'il ne faudrait pas plutôt imposer un serveur dans la box pour pouvoir faire un speedtest local ?
Dans le cas d'un AP wifi externe, ou de CPL, l'API répondra Ethernet, ce qui ne sera pas bon.
Si l'utilisateur a un switch, la box verra 1Gbps pour un PC connecté en 100Mbps.
En wifi, s'il y a un répéteur, la box donnera les caractéristiques du premier lien, à part si le répéteur est fourni par le FAI et la box peut l'interroger.
-
Je vais évoqué la problématique différemment.
Imaginons que le ministère des transports souhaite se doter d'un outil de mesure sur le traffic routier pour évaluer les besoins de mise en oeuvre de nouvelles autoroutes et encadre les concessions d'autoroutes fonction du traffic (ce qui reviens à ce que l'Arcep veux faire en pilotant avec la data).
Quelques sociétés d'autoroute se proposent de mettre en oeuvre cet outils de mesure,facturable à l'état et aux collectivités locales,à chaque péage elle peuvent identifier et comptabiliser les véhicules.
Mais ce qui est envisagé est de mettre en oeuvre sur chaque véhicule un outil pour identifier les déplacements en accord avec tous les constructeurs automobiles français (les allemands et autres pays pour l'instant ne sont pas concernés).Et on dit aux automobilistes, ne vous inquiétez pas, il n'y a rien de personnel on ne recueille que vos déplacements pour identifier si les concessionnaires d'autoroute font bien leur travail.
C'est à peu pret cela ( comme je ne veux pas froisser certains amis je reste approximatif).
Quand le grand public va apprendre qu'il est cobaye de mesures prises sans concertations et accords ne les impliquant pas, à l"l'insu de leur plein grés", il va y avoir un retour de bâton conséquent.
L'ARCEP n'a pas besoin de cela,c'est donner un bâton pour se faire battre.
-
Comment connaître le débit maximal du port ? (Si le débit commercial et la débit du port maximal est supérieur au débit du port utilisé pour faire le test, alors le test est en mesure de savoir que c'est la carte Ethenret ou le cêble du PC qui limite le débit)
Si c'est un test réalisé en Wi-Fi, comment connaître la technologie du PC connecté ? la bande de fréquence utilisée ? Le RSSI ?
Tous ces indicateurs nécessitent une API sur la box.
oui une api simple, en http, sans contrôle d'accès,sans gestion de pki et token à faire.
Permettre a n'importe quel site web ou app locale d'obtenir via XHR/REST a un url local (http://cpe.local par exemple - ou pour éviter les disparités de config dns via une URL sur un domaine public vérifié style http://openapi-cpe.arcep.fr (l'ip retournée étant intercepté par les box a la facon d'une anycast)):
- la techno de connexion du port lan d'ou la demande émane (Ethernet 10M/100M/1G/2.5G/5G/,wifi-x@yGHz, 5G )
- http://openapi-cpe.arcep.fr/v1/lan/type
- les debits max in/out du port lan d'ou la demande émane :
- http://openapi-cpe.arcep.fr/v1/lan/rx/max
- http://openapi-cpe.arcep.fr/v1/lan/tx/max
- les compteurs actuels in/out du port lan d'ou la demande émane
- http://openapi-cpe.arcep.fr/v1/lan/rx/counter
- http://openapi-cpe.arcep.fr/v1/lan/tx/counter
- la techno de connexion du port wan (adsl, vdsl, gpon, xgs-pon,etc)
- http://openapi-cpe.arcep.fr/v1/wan/type
- les debits max possible in/out du port wan
- http://openapi-cpe.arcep.fr/v1/wan/rx/max
- http://openapi-cpe.arcep.fr/v1/wan/tx/max
- les compteurs actuels in/out du port wan
- http://openapi-cpe.arcep.fr/v1/wan/rx/max
- http://openapi-cpe.arcep.fr/v1/wan/tx/max
ca fait quoi 10 méthodes REST à mettre en oeuvre dans les box. un truc ultra simple qui prendra pas 2 ans de tests et validation. Donner ces infos a tout monde permettra plein de chose d'autres dont optimiser les jeux vidéos en réseau, les visio confs par exemple ou diagnostiquer des problèmes de fonctionnement.
Apres les opérateurs peuvent penser qu'ils ne veulent pas qu'on cible leur clients ADSL avec des pubs pour de la fibre... mais bof franchement a y réfléchir plus d'une minute ca changera absolument rien sur leur part de marché ils ont déjà ces infos 'entre eux'.
Pour finir, cette API peut-être activée par défaut dans les box mais doit être désactivable par l'abonné qui le souhaite dans l'interface de gestion de sa box (mode opt-out donc).
-
Pour finir, cette API peut-être activée par défaut dans les box mais doit être désactivable par l'abonné qui le souhaite dans l'interface de gestion de sa box (mode opt-out donc).
Non, au nom de quoi ?
Si le consommateur souhaite participer, c'est son droit de le faire, ou pas, il peux choisir de le faire, ou pas.
Par défaut c'est au consommateur de choisir.
-
Non, au nom de quoi ?
Si le consommateur souhaite participer, c'est son droit de le faire, ou pas, il peux choisir de le faire, ou pas.
Par défaut c'est au consommateur de choisir.
Participation a quoi ? les tests de débits ne sont pas automatiques ou fait a son insu mais fait par l'utilisateur lui meme quand il va sur les sites en question ou utilise les apps en question.
-
Je comprends pas, je veux faire un test de débit sur mon smartphone, elle se trouve ou cette "API" ?
Par défaut dans l'OS ?
Si j'ai bien compris, il y a une volonté de généraliser aux différentes Box opérateurs,uniquement et pour l'instant, c'est bien cela ?
-
Je comprends pas, je veux faire un test de débit sur mon smartphone, elle se trouve ou cette "API" ?
Par défaut dans l'OS ?
Si j'ai bien compris, il y a une volonté de généraliser aux différentes Box opérateurs,uniquement et pour l'instant, c'est bien cela ?
non l'API est dans la box.
le sujet de la décision de l'ARCEP c'est: "caractérisation de l’environnement utilisateur dans les mesures de qualité de service
d’internet fixe via la mise en place d’une interface de programmation applicative (API) dans les box"
Ca ne concerne que les box internet. Ca ne permet que la "caractérisation l’environnement utilisateur" pas de le connaitre ou de collecter des infos perso sur lui.
En pratique:
Si tu install NPerf ou 4GMark ou etc dans ton smartphone et le connecte en wifi a ta box alors et alors seulement NPerf ou 4GMark pourront utiliser l'API de la box. Idem depuis un PC en filaire ou wifi avec les sites web de NPerf, 4GMark, etc.
En l'état la décision de l'ARCEP limite sévèrement les apps ou sites web qui peuvent utiliser l'API et ce sont les FAI qui décident et gardent la main. Donc facebook ou Google ou lafibre.info ne pourront accéder a ses informations meme si toi tu le veux. Et NPerf ou 4GMark ou etc le pourront meme si toi tu ne le veux pas (il faut quand meme que tu utilises leur apps ou site webs pour qu'ils accèdent a ces infos).
La ou je ne suis pas d'accord c'est sur cette restriction de qui peut utiliser l'API, au bon vouloir des FAI et ce avec un gestion complexe et inutile a base de CORS , tokens et infra pki. Bref un truc qui aurait du être simple et ouvert a tous devient compliqué et réservé a un club fermé.
Franchement que Google ou Facebook ou n'importe qui au monde puissent obtenir la "caractérisation l’environnement utilisateur" ca présente aucun probleme, c'est comme savoir ton navigateur ou ton OS ce qui est le cas aujourd'hui.
Au contraire ca permet éventuellement d'optimiser les services et contenus en fonction des informations fournit par l'API ou d'aider l'utilisateur en cas de problème.
Exemple: tu regarde une video sur Youtube, si ca commence a temporiser, Youtube pourrait interroger l'API de ta box pour savoir si ton lien WAN est saturé ou pas (cross-traffic) et du coup t'afficher une information a ce sujet (exemple : "Votre video a du mal a s'afficher car d’après votre Box votre accès a Internet est apparemment saturée localement. Vérifier si des téléchargements lourds sont en cours sur votre appareil ou d'autres appareils du réseau local et wifi").
-
Pour ça, est-ce qu'il ne faudrait pas plutôt imposer un serveur dans la box pour pouvoir faire un speedtest local ?
Le test de débit intégré dans une box, ce n'est possible que si tu as un processeur puissant. Aucun opérateur excepté Free n’intègre deux CPU dans la box. Free intègre le Broadcom habituel pour l’accès xDSL, très limité en CPU (le routage/NAT se fait en hardware), mais intègre en plus un processeur puissant (utilisé habituellement dans des NAS) à partir de ses Freebox Révolution.
Dans le cas d'un AP wifi externe, ou de CPL, l'API répondra Ethernet, ce qui ne sera pas bon.
Si l'utilisateur a un switch, la box verra 1Gbps pour un PC connecté en 100Mbps.
En wifi, s'il y a un répéteur, la box donnera les caractéristiques du premier lien, à part si le répéteur est fourni par le FAI et la box peut l'interroger.
Plus de 90% des CPL sont détectable par la box qui est même en mesure de récupérer le débit.
Dans le cas d'un répéteur, comme celui fourni avec la Livebox 5, la box sera en mesure d'avoir l'information :
L’application ma Livebox permet d'avoir également des informations détaillées sur le fonctionnement du Wi-Fi intelligent et du répéteur Wi-Fi, qui est représenté sur la carte :
(https://lafibre.info/images/orange/201910_orange_repeteurwifi_4.jpg)
Cet outil de cartographie permet d’optimiser l'installation Wifi à la maison, ou encore le contrôle de la durée de connexion de chaque appareil.
Pour le cas d'un point d’accès externe indépendant de la box ou l'utilisation d'un switch externe l'API retournera des résultats erronés, mais ce sont des cas rares.
-
Beau cadeau que fait l'ARCEP à cette liste d'outils de mesure, ils ont du ouvrir le champagne !
Y a-t-il une contrepartie pour s'assurer de la qualité des tests qu'ils réalisent ou c'est un chèque en blanc ? Je lis "se sont déclarés conformes" au code de bonne conduite, c'est vérifié ou déclaratif ?
Le but est d'enrichir les données pour les rendre plus complètes et donc mieux exploitables. Tout cela avec deux objectifs:
- Mieux ventiler nos publications pour des chiffres et classements encore plus précis
- Permettre aux opérateurs une analyse plus approfondie des données à des fins techniques pour améliorer leur réseau
Côté nPerf, il n'est pas prévu d'augmenter la valeur de la donnée suite à ces ajouts, c'est la moindre des choses vu les frais engagés par les opérateurs pour la mise en place de l'API. Côté opérateur, lorsqu'ils achètent des données nPerf, ils s'engagent contractuellement à ne les utiliser que dans un but de supervision et diagnostic technique. Ils ne peuvent en aucun cas les utiliser commercialement, pour de la prospection par exemple.
On n'a pas réclamé toutes les sécurités mises en place, comme le dit Vivien, ce sont les opérateurs qui en voulaient tjs plus. Cela dit, l'API est ouverte à tous les outils de mesure qui sont conformes au code de conduite. La liste pourra être enrichie par l'ARCEP, il suffit de demander !
-
En l'état la décision de l'ARCEP limite sévèrement les apps ou sites web qui peuvent utiliser l'API et ce sont les FAI qui décident et gardent la main. Donc facebook ou Google ou lafibre.info ne pourront accéder a ses informations meme si toi tu le veux. Et NPerf ou 4GMark ou etc le pourront meme si toi tu ne le veux pas (il faut quand meme que tu utilises leur apps ou site webs pour qu'ils accèdent a ces infos).
La ou je ne suis pas d'accord c'est sur cette restriction de qui peut utiliser l'API, au bon vouloir des FAI et ce avec un gestion complexe et inutile a base de CORS , tokens et infra pki. Bref un truc qui aurait du être simple et ouvert a tous devient compliqué et réservé a un club fermé.
L'API est mise en place dans un but précis, l'idée de l'ARCEP c'est de limiter son utilisation à cet objectif uniquement.
Rien empêche un nouvel outil de faire une demande d'ajout à l'ARCEP... les opérateurs n'auront pas la possibilité de refuser si l'ARCEP valide la demande et la conformité de l 'outil demandeur.
Dans un premier temps c'est défini comme ça mais à long terme peut être que l'ARCEP décidera d'étendre le domaine d'application...
-
Bien sur plusieurs acteurs ont demandé qu'on rajoute la localisation du test, mais c'est une donnée personnelle et cela a été supprimé pour cette raison (avec d'autres comme un identifiant unique de lute contre le fraude).
A notre grand désespoir, nous aurions bien aimé avoir au moins le département ou le code insee pour être en mesure de faire des baromètres locaux...
-
L'API est mise en place dans un but précis, l'idée de l'ARCEP c'est de limiter son utilisation à cet objectif uniquement.
oui mais pourquoi limité a cet objectif ? pourquoi limité aux personnes présentes lors des réunions ? pourquoi ce club entre amis ? pourquoi tout va dépendre des opérateurs alors qu'ils sont l'objectif eux-meme.
C'est comme demander a des sportifs de financer et mettre en oeuvre eux-meme leur contrôle anti-dopage avec des docteurs qu'ils paient eux-meme ...
Et en plus c'est pour accoucher d'un truc si compliqué et alambiqué qu'il va falloir, dans les faits, au moins 3 ans pour que ce soit en place partout... et si d'ici la un opérateur ne jette pas l'éponge et finalement ne fait rien. Ca sera quoi la sanction ?
-
L'API est mise en place dans un but précis, l'idée de l'ARCEP c'est de limiter son utilisation à cet objectif uniquement.
Rien empêche un nouvel outil de faire une demande d'ajout à l'ARCEP... les opérateurs n'auront pas la possibilité de refuser si l'ARCEP valide la demande et la conformité de l 'outil demandeur.
Dans un premier temps c'est défini comme ça mais à long terme peut être que l'ARCEP décidera d'étendre le domaine d'application...
C'est bien ce qui m'ennuie, l'utilisation de l'ARCEP pour obtenir des opérateurs, des modalités non sollicitées.
On comprends que Nperf souhaite poursuivre son activité ( soit dit en passant, j'aime bien mettre les pieds dans le plats, ces tests de mesures font transiter un traffic totalement inutile sur les réseaux, en somme j'envoi un fichier d'un endroit à un autre puis le récupère en faisant transiter ce volume dans le réseau juste pour mesurer la taille du tuyau, cela va une fois ou deux, allez voire trois au grand maximum, mais il ya des adeptes du speed test, passant leur temps à savoir si leur lien est bien gros, comme ils voudraient avoir ce qui leur a été vendu. Intéret ? )
L'ARCEP n'a pas à privilégier quelques acteurs que ce soit, si un marché pour dotation d'un instrument de mesure à l'ARCEP doit être ouvert, il doit être public. (Il n' y a rien de personnel sn@ke, pas plus envers nperf, mais ce sont des basiques d'un régulateur).
-
Il n'y a pas que les FAI qui souhaitent sécuriser l'API :
(commentaire suite à l'article de NetxINpact (https://www.nextinpact.com/news/108344-qualite-service-arcep-enterine-mise-en-place-dune-api-dans-box-fai.htm) - pas sur qu'il ait lu la décision)
C'est une blague ??? Non sérieusement on est déjà le 1er Avril ???
Dans 6 mois l'accès sera ouvert au FISC (comme d'hab)
Dans 1 an ce sera ouvert à Hadopi/CSA
Dans 1 an et demi il y aura une énorme fuite.
Sérieusement un simple test de débit justifie le déploiement généralisé d'une backdoor potentielle sur toutes les box françaises ???
-
Il n'y a pas que les FAI qui souhaitent sécuriser l'API :
(commentaire suite à l'article de NetxINpact (https://www.nextinpact.com/news/108344-qualite-service-arcep-enterine-mise-en-place-dune-api-dans-box-fai.htm) - pas sur qu'il ait lu la décision)
C'est une blague ??? Non sérieusement on est déjà le 1er Avril ???
Dans 6 mois l'accès sera ouvert au FISC (comme d'hab)
Dans 1 an ce sera ouvert à Hadopi/CSA
Dans 1 an et demi il y aura une énorme fuite.
Sérieusement un simple test de débit justifie le déploiement généralisé d'une backdoor potentielle sur toutes les box françaises ???
Parce qu'un random inconnu sur un forum spécialisé donne son avis alors il faut mettre en oeuvre une sécurité complete ?! Qui représente l'opinion majoritaire des français ? l'ARCEP a t'il mené une enquête/étude la dessus ? ou c'est full pifometre / celui qui crie le plus fort pour imposer son point de vue ? Qui a en charge de défendre l’intérêt des consommateurs ?
Les navigateurs fournissent l'OS et sa version, leur version, la résolution de l'écran, etc. Personne ne bronche la dessus. Que n'importe qui sache que j'ai un Mac a plus d'impact que de savoir si ma ligne est en ADSL ou en fibre non ?
Qu'une box fournisse le type de connexion et sa vitesse max, je ne vois vraiment pas ou le souci en terme de sécurité et vie privée. On ne demande le nom de la personne, ni la durée du contrat ou quoique ce soit d'autre. De simples infos techniques basiques pour permettre a quiconque , et pas seulement a un club de copains, de mesurer correctement des débits.
En plus ceux qui sont contre trouve normal qu'on file ces infos a Nperf,4GMark&go sans meme demander l'avis de l'utilisateur ?!
Car comme le mentionne le 1er commentaire sur NI et comme je l'ai déja mentionné ici ,la seule solution acceptable par tout le monde est de laisser l'utilisateur autoriser lui-meme ou pas l'accès a ces infos et a qui.
-
Je vois que je n'avais pas répondu.
Au premier semestre 2018 il a été décidé de partir sur une API et on espérait une API simple en http, sans contrôle d'accès,sans gestion de pki et token à faire.
Au second semestre les opérateurs ont demander d'étudier plusieurs pistes pour sécuriser l'API
En janvier 2019, une multilatérale, réunion dans les locaux de l'Arcep qui regroupe tous les opérateurs et les principaux outils de test de débit, il a fallu choisir entre les différentes méthodes de sécurisation :
- CORS uniquement
- CORS + mot de passe (mot de passe sans limite de validité)
- CORS + mot de passe (durée de validité du mot de passe : 24h)
- OAuth uniquement (durée de validité du token : 60min)
- CORS + OAuth (token sans limite de validité)
- CORS + OAuth (durée de validité du token : 60min)
Et le consensus s'est fait pour CORS + OAuth avec un token qui a une durée de validité de 15 minutes.
Ensuite il y a eu une consultation publique. Les réponses à cette consultation publique sont publique => https://www.arcep.fr/uploads/tx_gspublication/reponses_consultation_publique_api_box-oct2019.zip
On peut voir que la solution de sécurisation fait plutôt consensus.
Réponse de Bouygues Telecom :
La restriction d’accès via CORS/O.Auth2.0 et l’implémentation technique proposées semblent adaptées aux objectifs de sécurité et sont compatibles avec les choix techniques de Bouygues Telecom.
Bouygues Telecom attire l’attention de l’Autorité sur la nécessité que chaque outil de mesure autorisé dispose de 2 jetons O.Auth dédiés : un pour les tests, l’autre pour la production.
Réponse d'Orange :
Les restrictions d’accès retenues par l’Arcep dans l’annexe 2 sont conformes aux échanges qui ont eu lieu lors du chantier qui s’est déroulé en 2018.
Toutefois, comme échangé lors des multilatérales, Orange n’a pas encore lancé les études approfondies indispensables autour de l’accès au serveur d’authentification ou bien encore de la mise en place de certificats publics. Ainsi, à ce stade, Orange ne peut s’engager sur une proposition de modifications.
Réponse de SFR :
Si les choix techniques opérés par l’Arcep en matière de restriction d’accès semblent conformes à l’état de l’art, il n’en demeure pas moins que leur mise en œuvre serait lourde pour les opérateurs.
Réponse de Free :
Free remercie l’Autorité pour les progrès accomplis depuis la précédente version en matière de protection des réseaux, de protection de la qualité de service du client final et de protection des données confidentielles de l’utilisateur.
L’API de Free sera activée par défaut mais elle ne sera accessible qu’aux domaines autorisés par l’opérateur (whitelist) et elle pourra être désactivée par le client s’il le souhaite.
-
Au second semestre les opérateurs ont demander d'étudier plusieurs pistes pour sécuriser l'API
Avec quels arguments ? cette demande était-elle public ?
On imagine qu'ils ont avancé des arguments recevables pour sécurisé l'API ?
ou c'est juste les opérateurs ont 'demander', l'ARCEP doit exécuter ?
Ensuite il y a eu une consultation publique. Les réponses à cette consultation publique sont publique => https://www.arcep.fr/uploads/tx_gspublication/reponses_consultation_publique_api_box-oct2019.zip
On peut voir que la solution de sécurisation fait plutôt consensus.
"consensus" ... vu les réponses j’appelle pas ca 'publique' mais bon...
Réponse de Bouygues Telecom :
Réponse d'Orange :
Réponse de SFR :
Réponse de Free :
C'est ou je ne comprend pas du tout le process, en quoi l'avis des ces opérateurs a autant de poids? Le but est d'aller mesurer s'ils font correctement leur boulot, évidemment qu'ils font tout faire pour limiter ce qui peut être fait.
Je comprend pas trop les relations opérateurs-ARCEP sur ce sujet, pour moi c'est l'ARCEP est sensé être une 'autorité' pas un laquais. Qu'on leur demande les contraintes et impacts purement techniques ok mais pour le reste (confidentialité, etc) ce n'est pas de leur ressort.
Est-ce qu'un avis a été demandé a d'autres organismes comme l'Autorité de la concurrence , les assos de défenses des consommateurs, etc
As t'on contacter et consulter speedtest.net ? (ok ils ne sont pas francais mais ils sont les plus utilisés en France non ? un peu comme faire une consultation sur les moteurs de recherche et pas inviter Google a participer)
Qu'a t'il été répondu a la question du CNES ? :
- Question 6 :
- Est-il prévu une procédure pour vérifier la véracité des informations (paramètres de performance)
retournées par l’API ? Ou chaque équipementier va développer son API uniquement à partir des
spécifications et de sa compréhension de celles-ci ?
-
Et M-Lab ?
M-Lab provides the largest collection of open Internet performance data on the planet. As a consortium of research, industry, and public-interest partners, M-Lab is dedicated to providing an ecosystem for the open, verifiable measurement of global network performance.
Leurs outils sont open-source,ils n'ont semble t'il pas la même vocation ?
https://www.measurementlab.net/
-
L'API ne fait pas de test de débit.
L'API est utilisée par les outils de test de débit. M-Lab pourrait utiliser l'API afin d'avoir plus d'informations sur l’environnement de test, pour les tests réalisés depuis un navigateur web.
-
Est-ce que c'est sûr que M-Lab (ou d'autres organisations qui font des tests de débit) auront bien accès à l'API ? Vu les conditions d'authentification, il faudra avoir les bons certificats, être dans les bons domaines IP autorisés etc... Qui décidera de qui aura accès ou pas à l'API ?
Je suppose que l'on va dire que c'est l'ARCEP, mais il faudra que les FAIs suivent... Et sur quelle base l'ARCEP décidera-telle qu'untel a droit à l'accès et pas un autre. Je suppose là encore que ce sera sur la notoriété, et suite à des engagements sur l’utilisation des données. Mais est-ce qu'il n'y a pas un risque qu'un nouvel entrant, libre par exemple, ne puisse rentrer sur le "marché" des tests, ou avec un gros handicap ?
-
M-Lab pourrait utiliser l'API
Comment faire pour que les gens n'utilisent pas un truc, en faire une usine a gaz trop complexe a utiliser.
Pour moi les FAI ont habillement "noyauté puis enterré le sujet" comme on dit.
Le truc ne sera quasi pas utilisé , meme pas sur que la mise en oeuvre soit prolongée au delà du premier bilan.
Y'a absolument rien de 'service public' la dedans et j’ose espérer que tout les autres sujets traités par l'ARCEP en rapport avec les FAI ne sont pas manipulés de la meme façon...car sinon on est proche d'HADOPI en terme de gâchis d'argent public.
https://www.arcep.fr/larcep/nos-missions.html :
s'assurer que les dynamiques et intérêts des opérateurs privés se concilient avec les objectifs de connectivité du territoire, de compétitivité et de concurrence effective et loyale entre les opérateurs, au bénéfice des utilisateurs finals
Dommage.
-
au bénéfice des utilisateurs finals
Ahhh je saigne des yeux !!! Ils se sont pas relus ? :o :o
-
Ahhh je saigne des yeux !!! Ils se sont pas relus ? :o :o
Tes yeux ne devraient pas saigner, mais relire le dictionnaire. ;)
-
Bah, on m'a appris qu'au masculin pluriel on disait "finaux" et "finales" pour le féminin pluriel.
Mais tu as absolument raison :
Néanmoins, on préférera utiliser « finals » quand l’adjectif qualifie des personnes, cela afin d’éviter l’homophonie avec « finauds ». Exemples : « les candidats finals »
Au moins j'aurais appris un truc.
-
Pareil, merci. ;)
-
Pour moi les FAI ont habillement "noyauté puis enterré le sujet" comme on dit.
Le truc ne sera quasi pas utilisé , meme pas sur que la mise en oeuvre soit prolongée au delà du premier bilan.
A mon avis speedtest et nperf comptent bien s'en servir.
-
Je suis persuadé que le test de 60millions de consommateurs et celui de l'UFC Que choisir utilisera aussi l'API.
-
La décision pour une API dans les box est homologuée par le ministre chargé des communications électroniques et est publiée dans le journal officiel du 16 janvier 2020.
=> https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000041405914&categorieLien=id
Le 16 janvier 2020 est le "T0" dans La décision n°2019-1410 : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/barometre/201910_arcep_decision_api_box.png) (https://lafibre.info/images/barometre/201910_arcep_decision_api_box.pdf)
Les modèles de box concernés par la mise en place de l’API sont ceux mis à disposition sur le marché de détail grand public fixe haut débit et très haut débit à l’issue d’un délai de 18 mois à compter de la publication de la présente décision au Journal officiel (date «T0»)
=> 17 juillet 2021
[..]
Ainsi, dans un délai de 18 mois suivant la publication de la présente décision, les opérateurs effectuent la démonstration auprès de l’Arcep d’une box de développement avec l’API implémentée conformément aux dispositions de la présente décision.
=> 17 juillet 2021
Dans un délai de 22 mois suivant la publication de la présente décision, les opérateurs implémentent et activent par défaut l’API sur au minimum 5% des box du parc concerné par la mise en place de l’API.
=> 17 novembre 2021
Dans un délai de 26 mois suivant la publication de la présente décision, les opérateurs implémentent et activent par défaut l’API sur au minimum 40% des box du parc concerné par la mise en place de l’API.
=> 17 mars 2022
Dans un délai de 30 mois suivant la publication de la décision:
- les opérateurs implémentent et activent par défaut l’API sur au minimum 95% des box du parc concerné par la mise en place de l’API. Un maximum de 5% de ces box sans API est toléré notamment afin de ne pas imposer aux opérateurs de remplacer le cas échéant,la totalité des box qui ne pourraient plus être mises à jour à distance;
- les opérateurs implémentent et activent par défaut l’API sur 100% des box concernées par la mise en place de l’API et mises à disposition sur le marché de détail grand public fixe haut débit et très haut débit auprès de nouveaux clients de l’opérateur à l’issue de ce délai.
=> 17 juillet 2022
-
Top, si le calendrier est tenu, on pourra faire une première publication en 2024 sur les données 2023 :) RDV dans 4 ans !
-
C'est clair que vu les délais ce n'est pas pour tout de suite ! On n'est pas prêts d'avoir des tests de débit fiables, et nombreux, permettant de remplacer les tests de l'ARCEP. J'espère que certains opérateurs vont le mettre en place avant cela.
-
Ce sont des délais maximaux.
Ils ont été reculés à la suite de demande (cf réponse des opérateur à la consultation publique)
On a un opérateur qui semble bien motivé pour faire ça rapidement.
-
Ainsi, dans un délai de 18 mois suivant la publication de la présente décision, les opérateurs effectuent la démonstration auprès de l’Arcep d’une box de développement avec l’API implémentée conformément aux dispositions de la présente décision.
Les démonstrations de l'API se sont déroulées cette semaine et les opérateurs ont tous bien travaillés.
Lundi, j'étais au Technopole de Bouygues à Meudon (Hauts-de-Seine) :
(https://lafibre.info/images/bytel/202109_locaux_bouygues_meudon.jpg)
Mardi, j'étais chez Orange Village à Arceuil (Val-de-Marne) :
(https://lafibre.info/images/orange/202109_locaux_orange_arceuil.jpg)
Mercredi, j'étais chez Free à Paris 8ème :
(https://lafibre.info/images/free/202109_locaux_free_paris8.jpg)
Jeudi, j'étais chez SFR à l'Altice Campus de Paris 15ème :
(https://lafibre.info/images/altice/202109_locaux_sfr_paris15.jpg)
-
Les démonstrations de l'API se sont déroulées cette semaine et les opérateurs ont tous bien travaillés.
Il y en a qui sont plus volontaires que d'autres ou même pas ?
-
Il semblait y avoir un opérateur motivé pour l'implanter rapidement. C'est toujours le cas ? Est-ce que l'on peut espérer le voir mis en service chez cet opérateur dans les mois à venir sur un nombre significatif de box ? Au moins sur des volontaires ?
-
Il y a un calendrier précis pour la mise en place.
L'opérateur qui a la plus permis d'avancer dans la phase avant que cela devienne une décision a ensuite peu participé une fois la décision adoptée.
Deux autres opérateurs ont vraiment pris en charge la spécification de l'API, la réalisation d'un bouchon de test,...
Un quatrième opérateur a été très discret.
Mais ils ont tous fait l'implémentation de l'API.
Après on jugera surtout au moment où nPerf sortira un outil de test de débit qui intègre l'API : Si il manque un opérateur ou si les 4 sont là au lancement.
Rendez-vous dans quelques mois...
-
Dans un délai de 22 mois suivant la publication de la présente décision, les opérateurs implémentent et activent par défaut l’API sur au minimum 5% des box du parc concerné par la mise en place de l’API.
=> 17 novembre 2021
Bonsoir, si je comprend bien, on arrive bientôt à la date de mise en place à petite échelle de cet API. Sait-on si il sera possible d'activer manuellement l'API dans notre box si elle ne l'est pas déjà ?
-
Il y a d'une place la mise en place de l'API par les opérateurs et d'autre part la mise en place d'outil qui vont utiliser cette API.
Le fait que L'API soit disponible ne sert à rien si il n'est pas possible de l'utiliser.
Le schéma d'implémentation est partiellement dans les box : Le gros est sur des serveurs chez le FAI. Ces serveurs mis en place par les FAI vont assurer l'authentification, la terminaison TLS, mais aussi une partie des données et interroger les box pour la partie des données détenues par les box.
Un premier outil est bien avancé dans la mise en place de l'API, mais ce sont les contraintes RGPD et surtout le futur règlement « e-privacy » qui retarde la signature des contrats entre cet premier outil de mesure et les FAI. Un consentement de l'utilisateur est a priori nécessaire.
J'aimerais bien que tout soit fonctionnel de bout en bout les box compatibles des 4 FAI avec ce premier outil d'ici la fin de l'année, toutefois je ne sais pas si cela sera possible, l'aspect contractualisation avec des contrats qui échappe au contrôle de l'Arcep pourrait retarder bien les choses.
-
L'Arcep a communiqué sur la liste des box compatible avec l'API : https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29547
A partir de juillet 2022, l’API sera implémentée et activée dans les box suivantes :
Bouygues Telecom
- Bbox Wi-Fi 6 (Bbox F@st 5688b)
- Bbox Wi-Fi 5 (Bbox F@st 5330b-r1)
Free
- Freebox Pop
- Freebox Delta
- Freebox One
- Freebox mini 4K
- Freebox Révolution
Orange
- Livebox v5
- Livebox v4
SFR
- SFR Box 8
- SFR Box 7 (NB6VAC)
- Neufbox 6 (NB6)
- Modem THD Wi-Fi AC (F@st 3686)
- La Box THD 4K (V3)
- La Box THD V2 (La Box by Numericable V2)
Autres opérateurs
L’Arcep encourage les opérateurs non soumis à la décision (opérateurs ayant moins d'un million de clients, opérateurs fournissant des offres entreprises, etc.) à implémenter l’API dans leur box.
-
Belle effort de SFR :P
-
Je vois aussi que toutes les box Free sont concernées, tant mieux ! C'est peut-être plus facile pour Free qui développe lui-même ses firmwares.
-
Pour ma part, je regrette que la Bbox F@st 5330b (sans la r1 qui lui donne du Wi-Fi 5) ne soit pas éligible à l'API, mais comme elle n'est plus commercialisée, il n'y a pas d'obligation.
Mais oui, toutes les box récents seront compatible avec l'API et de nouvelles box le seront dans le futur (5G Box, Livebox 6,...)
-
Possible de refuser la MAJ de la Box pour ne pas avoir de mouchard ?
-
Ce n'est pas censé être désactivable (sur al box ou sur le site de test) ?
-
Il y a eu quelques modifications, elle n'est plus sur la box, mais chez l'opérateur. C'est l'opérateur qui ira chercher les éléments qu'il faut pour répondre à la demande.
L'API, même si elle ne donne aucune information personnelle n'est activée qu’après votre consentement.
Le recueil du consentement sera fait directement sur l'outil de test de débit, avant de démarrer un test.
Sans consentement le test de débit se fera comme aujourd'hui.
-
Le recueil du consentement sera fait directement sur l'outil de test de débit, avant de démarrer un test.
Sans consentement le test de débit se fera comme aujourd'hui.
En opt-in on est d'accord ?
-
Un consentement, par définition, ce n'est pas coché par défaut (sinon cela ne respecte pas les règles de la CNIL).
Un consentement doit être « libre, spécifique, éclairé et univoque ». L'internaute doit, de la sorte, poser un acte positif clair pour marquer son consentement. Toutes ces conditions s'opposent ainsi au recours à l'utilisation d'une case cochée par défaut pour recueillir le consentement.
Ici la CNIL est venu a deux réunions avec les opérateurs donc les choses seront faites en respectant strictement la loi.
-
Possible de refuser la MAJ de la Box pour ne pas avoir de mouchard ?
De quel mouchard tu parle? tu veux bloquer la MAJ de ta box pour ne plus aller sur FB, Insta et 100% des autres sites qui collectent allègrement tes donnés perso?! :D
Le mieux pour toi, débranche la :o
-
Mise à jour des box compatible avec l'API :
A partir de juillet 2022, l’API sera implémentée et activée dans les box suivantes :
Bouygues Telecom
- Bbox Wi-Fi 6E FttH (Bbox F@st 5688b-v2) à partir de septembre 2022
- Bbox Wi-Fi 6 FttH (Bbox F@st 5688b)
- Bbox Wi-Fi 5 FttH / xDSL (Bbox F@st 5330b-r1)
- Bbox Wi-Fi 4 FttH / xDSL (Bbox F@st 5330b)
Free
- Freebox Pop FttH / xDSL (Wi-Fi 5)
- Freebox Delta FttH / xDSL (Wi-Fi 5)
- Freebox One FttH / xDSL (Wi-Fi 5)
- Freebox mini 4K FttH / xDSL (Wi-Fi 5)
- Freebox Révolution r3 FttH / xDSL (Wi-Fi 5)
- Freebox Révolution r2 FttH / xDSL (Wi-Fi 4)
- Freebox Révolution r1 FttH / xDSL (Wi-Fi 4)
Orange
- Livebox v6 FttH (Wi-Fi 6E)
- Livebox v5 FttH (Wi-Fi 5)
- Livebox v4 FttH / xDSL (Wi-Fi 5)
SFR
- SFR Box 8X Wi-Fi 6 FttH XGS-Pon (NB8 XGSPON)
- SFR Box 8 Wi-Fi 6 FttH Gpon (NB8 FTTH)
- SFR Box 8 Wi-Fi 6 Docsis (NB8 Docsis)
- SFR Box 8 Wi-Fi 6 xDSL (NB8 xDSL)
- Box Plus de SFR ou "SFR Box 7" Wi-Fi 5 FttH / xDSL (NB6VAC)
- Modem THD AC Wi-Fi 5 Docsis (F@st 3686)
- La Box THD 4K ou "La Box Fibre Zive" Wi-Fi 5 Docsis (La Box V3)
- La Box THD V2 ou "La Box by Numericable V2" Wi-Fi 5 Docsis (La Box V2)
- Box Évolution VDSL ou "Neufbox 6V" Wi-Fi 4 FttH / xDSL (NB6V et NB6V2)
- Box Évolution ou "Neufbox 6" Wi-Fi 4 FttH / ADSL (NB6)
Autres opérateurs
L’Arcep encourage les opérateurs non soumis à la décision (opérateurs ayant moins d'un million de clients, opérateurs fournissant des offres entreprises, etc.) à implémenter l’API dans leur box.
Source : Arcep (https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29547), le 22/04/2022
-
(https://pic.nperf.com/r/3380706253694828-JmFJcgLL.png)
Curieux cette mention "xDSL" en dessous de Free. Est-ce que c'est lié à l'API ?
Si oui, il y a un petit soucis du coup...
Chez moi ça donne ceci (logique, je n'ai pas de box) :
Opérateur : MilkyWan
Type de connexion : inconnu
-
L'APi commence à être disponible chez les opérateurs, mais aujourd'hui aucun outil n'a encore signé : l'API n'est donc pas exploitée.
nPerf, faute d'API, a tagué à la main des plages IP en xDSL ou FttH. Là Manu2 est sur une plage qui est rament passé de xDSL à FttH et nPerf n'a pas fait la mise à jour (c'est manuel).
Les opérateurs, notamment Free et Bouygues ont fait de grosse migrations de plages IP ces dernières années dans le but d'économiser les IPv4 (Chez Free cela s'est accompagné par la passage en IPv4 partagée t chez Bouygues par l'IP porté par le BSR à la place du DSLAM de façon a limiter les pertes d'IPv4).
-
Curieux cette mention "xDSL" en dessous de Free. Est-ce que c'est lié à l'API ?
Si oui, il y a un petit soucis du coup...
En revoyant le sujet, je vois que la personne vient d'être migrée en fibre, mais avait un vieux PC affichant des débits très faibles. Et il a beaucoup mieux avec un PC récent, normal. Ce n'est donc pas l'API qui lui dit que c'est de l'xDSL, ou alors elle est à revoir...
-
nPerf, faute d'API, a tagué à la main des plages IP en xDSL ou FttH. Là Manu2 est sur une plage qui est rament passé de xDSL à FttH et nPerf n'a pas fait la mise à jour (c'est manuel).
Si les plages d'IP ne mélangent jamais xDSL et FTTH, alors le simple résultat du test pourrait déclencher la mise à jour (ou au moins modifier le type de connexion détecté).
-
Mise à jour des box compatible avec l'API :
A partir de juillet 2022, l’API sera implémentée et activée dans les box suivantes :
Bouygues Telecom
- Bbox Wi-Fi 6E FttH (Bbox F@st 5688b-v2) à partir de septembre 2022
- Bbox Wi-Fi 6 FttH (Bbox F@st 5688b)
- Bbox Wi-Fi 5 FttH / xDSL (Bbox F@st 5330b-r1)
- Bbox Wi-Fi 4 FttH / xDSL (Bbox F@st 5330b)
Free
- Freebox Pop FttH / xDSL (Wi-Fi 5)
- Freebox Delta FttH / xDSL (Wi-Fi 5)
- Freebox One FttH / xDSL (Wi-Fi 5)
- Freebox mini 4K FttH / xDSL (Wi-Fi 5)
- Freebox Révolution r3 FttH / xDSL (Wi-Fi 5)
- Freebox Révolution r2 FttH / xDSL (Wi-Fi 4)
- Freebox Révolution r1 FttH / xDSL (Wi-Fi 4)
Orange
- Livebox v6 FttH (Wi-Fi 6E)
- Livebox v5 FttH (Wi-Fi 5)
- Livebox v4 FttH / xDSL (Wi-Fi 5)
SFR
- SFR Box 8X Wi-Fi 6 FttH XGS-Pon (NB8 XGSPON)
- SFR Box 8 Wi-Fi 6 FttH Gpon (NB8 FTTH)
- SFR Box 8 Wi-Fi 6 Docsis (NB8 Docsis)
- SFR Box 8 Wi-Fi 6 xDSL (NB8 xDSL)
- Box Plus de SFR ou "SFR Box 7" Wi-Fi 5 FttH / xDSL (NB6VAC)
- Modem THD AC Wi-Fi 5 Docsis (F@st 3686)
- La Box THD 4K ou "La Box Fibre Zive" Wi-Fi 5 Docsis (La Box V3)
- La Box THD V2 ou "La Box by Numericable V2" Wi-Fi 5 Docsis (La Box V2)
- Box Évolution VDSL ou "Neufbox 6V" Wi-Fi 4 FttH / xDSL (NB6V et NB6V2)
- Box Évolution ou "Neufbox 6" Wi-Fi 4 FttH / ADSL (NB6)
Autres opérateurs
L’Arcep encourage les opérateurs non soumis à la décision (opérateurs ayant moins d'un million de clients, opérateurs fournissant des offres entreprises, etc.) à implémenter l’API dans leur box.
Source : Arcep (https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29547), le 22/04/2022
La révolution R2 est aussi WiFi 5.
-
L'APi commence à être disponible chez les opérateurs, mais aujourd'hui aucun outil n'a encore signé : l'API n'est donc pas exploitée.
Merci pour ce retour clair :).
-
La révolution R2 est aussi WiFi 5.
Tu es sur ?
Univers Freebox se serait trompé ?
Il y a un sujet dédié à ça : https://www.universfreebox.com/article/25430/MaJ-Confirmation-les-Freebox-Server-sont-compatibles-WiFi-802-11ac-seulement-pour-les-versions-r3
-
Le sujet date de 2014. Il me semble que depuis, les revolution r2 (et même r1...) qui sont repassées par chez Free ont été mises à jour avec un chipset wifi compatible 802.11ac. Il y en a eu pas mal avec les migration à la Delta (ou les changements d'opérateur).
-
La révision en change pas lors de cette opération ?
Chez Bouygues Telecom la référence des box change après passage dans en reconditionnement avec changement de la puce Wi-Fi.
- Une Bbox F@st 5330b devient une Bbox F@st 5330b-r1
- Une Bbox F@st 5688b devient une Bbox F@st 5688b-v2
-
Tu es sur ?
Univers Freebox se serait trompé ?
Il y a un sujet dédié à ça : https://www.universfreebox.com/article/25430/MaJ-Confirmation-les-Freebox-Server-sont-compatibles-WiFi-802-11ac-seulement-pour-les-versions-r3
Ma mère a une R2, et il y a bien le wifi 5.
C'était dans le cas d'un sav, R1 remplacé par une R2.
-
Tu ne confonds pas d'avoir du WiFi 5 Ghz avec du WiFi 5 (802.11ac) ?
Le WiFi 4 (802.11n) peut être disponible en 5 Ghz
Les premières Freebox révolution proposait un Wi-Fi 4 2,4 Ghz only (débit réel de 20 à 30 Mb/s).
Ta mère n'aurais pas un Wi-Fi 4 double-bande (2,4 GHz ou 5 GHz) ?
-
R2 wifi AC.
-
Merci, j'ai fait la demande de modification de la liste des box compatible avec l'API, ce sera en ligne sur le site de l'Arcep demain :
A partir de juillet 2022, l’API sera implémentée et activée dans les box suivantes :
Bouygues Telecom
- Bbox Wi-Fi 6E FttH (Bbox F@st 5688b-v2) à partir de septembre 2022
- Bbox Wi-Fi 6 FttH (Bbox F@st 5688b)
- Bbox Wi-Fi 5 FttH / xDSL (Bbox F@st 5330b-r1)
- Bbox Wi-Fi 4 FttH / xDSL (Bbox F@st 5330b)
Free
- Freebox Pop FttH / xDSL (Wi-Fi 5)
- Freebox Delta FttH / xDSL (Wi-Fi 5)
- Freebox One FttH / xDSL (Wi-Fi 5)
- Freebox mini 4K FttH / xDSL (Wi-Fi 5)
- Freebox Révolution Wi-Fi 5 FttH / xDSL
- Freebox Révolution Wi-Fi 4 FttH / xDSL
Orange
- Livebox v6 FttH (Wi-Fi 6E)
- Livebox v5 FttH (Wi-Fi 5)
- Livebox v4 FttH / xDSL (Wi-Fi 5)
SFR
- SFR Box 8X Wi-Fi 6 FttH XGS-Pon (NB8 XGSPON)
- SFR Box 8 Wi-Fi 6 FttH Gpon (NB8 FTTH)
- SFR Box 8 Wi-Fi 6 Docsis (NB8 Docsis)
- SFR Box 8 Wi-Fi 6 xDSL (NB8 xDSL)
- Box Plus de SFR ou "SFR Box 7" Wi-Fi 5 FttH / xDSL (NB6VAC)
- Modem THD AC Wi-Fi 5 Docsis (F@st 3686)
- La Box THD 4K ou "La Box Fibre Zive" Wi-Fi 5 Docsis (La Box V3)
- La Box THD V2 ou "La Box by Numericable V2" Wi-Fi 5 Docsis (La Box V2)
- Box Évolution VDSL ou "Neufbox 6V" Wi-Fi 4 FttH / xDSL (NB6V et NB6V2)
- Box Évolution ou "Neufbox 6" Wi-Fi 4 FttH / ADSL (NB6)
Autres opérateurs
L’Arcep encourage les opérateurs non soumis à la décision (opérateurs ayant moins d'un million de clients, opérateurs fournissant des offres entreprises, etc.) à implémenter l’API dans leur box.
-
L'Arcep a publié un schéma de fonctionnement de l'API pour mieux caractériser l'environnement des tests de débit et la réponse à quelques questions fréquentes :
L’API est accessible à des outils de mesure en crowdsourcing utilisés par les usagers pour évaluer le débit ou, plus généralement, la qualité de service de leurs accès à internet. Sollicitée uniquement lorsque l’utilisateur initie un test de débit, et sous son contrôle, l’API renseigne l’outil de mesure sur une série d’indicateurs techniques, tels que le type de box, la technologie d’accès à internet, les débits montants ou descendants contractuels.
Les modalités de fonctionnement de l’API prennent pleinement en compte les questions de respect et de protection de la vie privée des utilisateurs. D’abord, les données recueillies par l’API ne sont évidemment pas transmises à l’Arcep. Ensuite, aucune donnée liée à l’identification de l’utilisateur (identifiant, nom, localisation, etc.) n’est transmise par l’API aux outils de mesure. Enfin, l’API n’est sollicitée que lors d’un test de débit initié par l’utilisateur lui-même et ne répond pas aux sollicitations depuis internet.
Questionnée dans le cadre de cette démarche, la CNIL a pu s’assurer que le dispositif répondait dans son principe aux exigences en matière de protection des données personnelles tout en insistant sur l’importance du rôle de conseil de l’Arcep, notamment au travers du « Code de conduite de la qualité de service internet », vis-à-vis des outils de mesure exploitant l’API.
Les résultats obtenus, désormais enrichis grâce à l’API, seront un nouveau pas dans l’amélioration de la mesure de la qualité de service des réseaux fixes.
Comment fonctionne l’API ?
Le schéma ci-dessus décrit le fonctionnement de l’API lorsqu’un client initie un test de QoS avec un outil de test ayant accès à l’API. Deux appels à l’API sont réalisés : le premier juste avant le test de débit et le second juste après. Ces appels permettent de récupérer les différents indicateurs pour caractériser le lien entre le terminal de l’utilisateur et internet tout en s’assurant qu’il n’y a pas eu de cross-trafic, c’est-à-dire un trafic autre que celui mesuré (trafic d’un autre PC ou smartphone, box TV ou trafic lié à un autre programme sur le PC de test). Pour ce faire, l’outil de mesure va comparer la quantité de données qu’il a envoyée et reçue sur internet à la quantité de données qui a été transmise sur internet par la box entre le premier et le second appel de l’API.
(https://lafibre.info/images/doc/202206_arcep_fonctionnement_de_api_carte_identite_de_acces.webp)
L’API est-elle accessible depuis internet ?
Non, l’API est accessible uniquement depuis le réseau local de l’utilisateur final. L’appel de l’API doit être réalisé sur les serveurs du fournisseur d’accès à internet depuis l’adresse IP du client. Les requêtes provenant d’autres adresses IP sont rejetées afin de sécuriser le dispositif. C’est donc uniquement l’outil de test exécuté sur le terminal du client qui peut appeler l’API. De plus, un système de restriction d’accès est mis en place, afin que seuls les outils autorisés puissent accéder à l’API.
-
On est le 2 Juillet, l'API est activée ?
-
Oui, la majorité des box intègrent l'API (cf la liste donnée dans les messages précédents).
Pour le moment il n'y a pas d'outil qui propose l'API donc l'API n'est pas utilisable, vu qu'il faut consentir à l'API sur un outil compatible. Cela ne devrait pas tarder ;)
Pour en savoir plus, voici le rapport 2022 sur l'état de d'internet en France de l'Arcep :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/202206_arcep_rapport_etat_internet_2022.webp) (https://lafibre.info/images/doc/202206_arcep_rapport_etat_internet_2022.pdf)
Présentation de la partie qualité de service en vidéo :
https://lafibre.info/videos/arcep/202206_arcep_rapport_etat_internet_2_qos.mp4
-
Même si on parle d'un très faible nombre d'utilisateurs, comment ça se passe quand on n'utilise pas la box opérateur ? (exemple le sujet mikrotik pour profiter des 2Gbps)
-
Bah, l'API ne sera pas implémentée, donc pas détectée ? J'attends avec impatience les premiers tests qui vont l'utiliser.
-
L'outil de mesure va proposer l'API dès que l'opérateur l'intègre.
Si la box du client n'a pas l'API, l'opérateur renverra uniquement les informations accessibles sans la box (par exemple le débit souscrit et la technologie d'accès)
Si vous avez vu le schéma de fonctionnement, l'outil ne contacte pas la box, mais l'opérateur. C'est l'opérateur qui va renvoyer les informations et faire appel à la box pour les informations qu'il n'a pas dans son SI, comme par exemple savoir comment est connecté le PC qui fait la mesure à la box.
Avoir une box comme un routeur mikrotik permettra à l'outil d'avoir une partie des informations.
-
Un autre inconvénient de passer par un serveur d'API du FAI, c'est qu'elle indique quand l'utilisateur fait un test de débit.
Elle pourrait donc théoriquement être utilisée pour tricher sur la QoS en cas de saturation (et ce sans DPI ni atteinte à la neutralité du net si c'est toute le trafic de l'abonné qui se retrouve priorisé).
-
On arrive bientôt à la fin du calendrier de déploiement de l'API et les opérateurs sont bien au rendez-vous.
Pour utiliser l'API, il faut un outil de test qui l'implémente et un premier outil devrait être compatible dans quelques mois.
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_1_qos_3.png)
-
L'appli RED & Moi demande d'autoriser l'accès à la SIM et à la position pour faire un test de débit depuis quelques jours.
-
Cela n'a rien à voir, l'API ne transmet pas de données géographiques.
Cela avait été évoqué, mais avec le RGPD c'est compliqué et on a préféré supprimer cet aspect.
-
Ça doit être pour SFR en interne quand le test est en 4/5G RED/SFR.
-
Pour votre information, NPerf l'a intégré sur les tests effectués depuis un navigateur
Pour le problème NPerf, j'ai remarqué que depuis peu, le site fait une requête vers une URL "partner" liée à l'opérateur afin de récupérer les caractéristiques de l'accès et de la box, par exemple si
IP Orange :
https://api-infoacces.orange.fr/res/v1/tca/prec
IP SFR :
https://apibox.sfr.net/v1/tca/prec (dont le reverse de l'IP correspondante est front.arcep.diag.sfr.net)
Le test NPerf ne démarre plus chez SFR dans certains cas (remplacement de la box par un routeur perso par exemple) et bloque sur "interrogation du serveur".
Cette requête "partner" n'est pas implémentée sur l'application NPerf Windows, possible que ce soit de même dans l'appli iOS/Android, ce qui expliquerait l'échec sur un navigateur mais le bon fonctionnement sur le téléphone.
-
Intéressant, je vérifierais pour Free ce soir quand je serai rentré.
-
Pour votre information, NPerf l'a intégré sur les tests effectués depuis un navigateur
Intéressant, pour information. Il faut autoriser le traitement des données. Pour que API soit appelé.
(https://pix.milkywan.fr/IFsOdMxg.png)
-
En effet, j’ai bien FTTH qui s’affiche. En revanche quelques étonnements, le moyen de connexion détecté n’est pas ajouté sur la vignette de partage, alors que maintenant que c’est déterminé à coup sûr, ça pourrait être intéressant.
N’était-il pas prévu que le type de connexion du terminal au routeur soit détecté ? Il me semblait que ça devait être le cas, pour déterminer quelle crédibilité on peut accorder au résultat.
-
En effet, j’ai bien FTTH qui s’affiche. En revanche quelques étonnements, le moyen de connexion détecté n’est pas ajouté sur la vignette de partage, alors que maintenant que c’est déterminé à coup sûr, ça pourrait être intéressant.
N’était-il pas prévu que le type de connexion du terminal au routeur soit détecté ? Il me semblait que ça devait être le cas, pour déterminer quelle crédibilité on peut accorder au résultat.
Dans le JSON. Tu as
{
"gateway": {
"model": "NB6",
"softwareVersion": "R4.0.45d.0"
},
"wan": {
"mode": "ExternalNT",
"speedNT": {
"download": ,
"upload": ,
"duplex": "full"
},
"aggregation": "no",
"technology": "ftth",
"byteCounter": {
"download": ,
"upload":
}
},
"lan": {
"speedLan": {
"download": 1000000,
"downloadMax": 1000000,
"upload": 1000000,
"duplex": "Full",
"uploadMax": 1000000
},
"connectionType": "ethernet"
},
"timestamp": {
"lastUpdate": ,
"apiCallTime":
},
"id": "",
"apiVersion":
}
-
Dans le JSON. Tu as
{
"gateway": {
"model": "NB6",
"softwareVersion": "R4.0.45d.0"
},
"wan": {
"mode": "ExternalNT",
"speedNT": {
"download": ,
"upload": ,
"duplex": "full"
},
"aggregation": "no",
"technology": "ftth",
"byteCounter": {
"download": ,
"upload":
}
},
"lan": {
"speedLan": {
"download": 1000000,
"downloadMax": 1000000,
"upload": 1000000,
"duplex": "Full",
"uploadMax": 1000000
},
"connectionType": "ethernet"
},
"timestamp": {
"lastUpdate": ,
"apiCallTime":
},
"id": "",
"apiVersion":
}
Si le client utilise un ONT externe même avec la box fournis, l'API peut pas détecté le débit WAN ?
-
Si le client utilise un ONT externe même avec la box fournis, l'API peut pas détecté le débit WAN ?
Le cas de l'ONT externe est bien traité. Met un câble avec 4 fils entre l'ONT et la box, tu vas voir que le débit Wan passe à 100 Mb/s.
Le débit souscrit est lui donné par l'opérateur via son système d'information.
En effet, j’ai bien FTTH qui s’affiche. En revanche quelques étonnements, le moyen de connexion détecté n’est pas ajouté sur la vignette de partage, alors que maintenant que c’est déterminé à coup sûr, ça pourrait être intéressant.
L'API vient d'être activée par nPerf, pour le moment les données sont juste archivées pour la publication du baromètre, mais il est bien prévu dans quelques mois (probablement au second semestre 2023) de donner des information à l'utilisateur qui réalise le test.
-
Si le client utilise un ONT externe même avec la box fournis, l'API peut pas détecté le débit WAN ?
Je vois 4 types de limitation de débit :
- l'OLT pour le profil lié à l'abonnement : l'opérateur doit remonter l'information, quel que soit l'ONT
- le lien Ethernet dans le cas d'un ONT externe (par exemple un problème de câble qui limiterait à 100Mbps) : la box a nécessairement l'information
- l'architecture de la box (par exemple la NB6V qui a LAN et WAN sur un switch relié au SoC via un lien 1Gbps) : l'API ne semble pas prévoir ce cas (limite download + upload à 1Gbps, qui pourrait être émulée en déclarant le lien avec l'ONT comme étant half duplex)
- un bug ou une mauvaise configuration de l'ONT (ce qui peut arriver avec les ONT non officiels par exemple) : ce n'est pas une limitation franche, et on ne s'attend pas à ce que l'API en tienne compte
-
J'ai réussi à avoir la réponse pour l'API via curl :
curl -s "https://api-infoacces.orange.fr/res/v1/tca/prec" --header "Authorization : Bearer {bearer}"
(Le bearer est trouvable dans une des deux requêtes en cherchant dans inspecté l’élément section réseau)
Il y a un cota max d'utilisation, en tout cas je crois que si on arrive a choper le bearer avant la fin du speedtest il est visiblement utilisable plusieurs fois (à confirmer)
Chez Orange l'adresse api-infoacces.orange.fr (au passage elle est visiblement IPv6 Only, il n'y a pas de réponse DNS A )
"id": "xxxxxxx-xxxxxxxx-xxxxxxxxxxx",
"apiVersion": 4312662016,
"gateway": {},
"subscriptionSpeed": {
"downloadMax": 0,
"uploadMax": 0
},
"wan": {
"technology": "ftth",
"mode": "IntegratedNT",
"aggregation": "no",
"byteCounter": {
"download": 4008684651,
"upload": 2333043527
}
},
"lan": {
"connectionType": "ethernet",
"complexity": "Undefined",
"speedLan": {
"downloadMax": 1000000.0,
"uploadMax": 1000000.0,
"download": 0,
"upload": 0
}
},
"timestamp": {
"apiCallTime": 1672246529,
"lastUpdate": 1672246529
}
}
visiblement les vitesses sont exprimés en kilobits/s (par rapport à la vitesse LAN) mais si on regarde par rapport a la vitesse WAN je pense qu'il y a un problème car ça me ferait 4 Tb/s en WAN mais je pense que c'est normal vu que j'utilise pas vraiment l'API de façon conventionnel
-
visiblement les vitesses sont exprimés en kilobits/s (par rapport à la vitesse LAN) mais si on regarde par rapport a la vitesse WAN je pense qu'il y a un problème car ça me ferait 4 Tb/s en WAN mais je pense que c'est normal vu que j'utilise pas vraiment l'API de façon conventionnel
Là tu n'as pas de vitesse WAN, et même 0 comme vitesse souscrite.
byteCounter correspond au volume de données reçue et envoyé, ça permet de détecter l'activité en parallèle du test de débit (si l'accroissement est supérieur à ce qui est attendu).
-
Là tu n'as pas de vitesse WAN, et même 0 comme vitesse souscrite.
byteCounter correspond au volume de données reçue et envoyé, ça permet de détecter l'activité en parallèle du test de débit (si l'accroissement est supérieur à ce qui est attendu).
ah d'accord, ok oui c'est vrai que c'est plus logique
EDIT : du coup la partie WAN est en octet ?
-
Je confirme c'est bien en place chez Free. Ça pointe sur https://api-arcep.proxad.net/api/v1/tca/prec
-
- l'architecture de la box (par exemple la NB6V qui a LAN et WAN sur un switch relié au SoC via un lien 1Gbps) : l'API ne semble pas prévoir ce cas (limite download + upload à 1Gbps, qui pourrait être émulée en déclarant le lien avec l'ONT comme étant half duplex)
La NB6V n'a pas l'API (par contre la NB6VAC, également appelée NB7 l'a).
La liste des box compatible est indiquée sur ce site de l'Arep (https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29547).
Les différents cas sont pris en compte. Il y a un indicateur LAN complexe / WAN complexe qui est remonté en cas de détection de situation inhabituelle.
-
La NB6V n'a pas l'API (par contre la NB6VAC, également appelée NB7 l'a).
La liste des box compatible est indiquée sur ce site de l'Arep (https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29547).
Les différents cas sont pris en compte. Il y a un indicateur LAN complexe / WAN complexe qui est remonté en cas de détection de situation inhabituelle.
Sur la liste, je vois bien NB6 et NB6V.
Comment est-ce que la limitation à 1Gbps cumulés download + upload est-elle prise en compte ?
Certes en pratique la quasi totalité des tests de débit doivent tester le download et l'upload de manière séparée (c'est le cas de nPerf), donc tant qu'il n'y a pas d'utilisation en même temps ça ne se voit pas.
-
J'avais oublié pour les veilles NB6 (pourtant, c'est moi qui ai mis en ligne la page).
Les tests réalisés par nPerf font le débit descendant et montant successivement, mais s'il y a une limite de 1 Gb/s, cela signifie que le client ne pourra pas obtenir les 940 Mb/s, car il ne faut pas oublier qu'à 1 Gb/s, il y a 20 Mb/s d'acquittements dans le sens opposé.
-
Chez Orange, l'API semble être sur le nom api-infoacces.orange.fr (qui a seulement une IPv6 d'ailleurs).
-
Chez Orange, l'API semble être sur le nom api-infoacces.orange.fr (qui a seulement une IPv6 d'ailleurs).
Oui :
J'ai réussi à avoir la réponse pour l'API via curl :
curl -s "https://api-infoacces.orange.fr/res/v1/tca/prec" --header "Authorization : Bearer {bearer}"
(Le bearer est trouvable dans une des deux requêtes en cherchant dans inspecté l’élément section réseau)
Il y a un cota max d'utilisation, en tout cas je crois que si on arrive a choper le bearer avant la fin du speedtest il est visiblement utilisable plusieurs fois (à confirmer)
Chez Orange l'adresse api-infoacces.orange.fr (au passage elle est visiblement IPv6 Only, il n'y a pas de réponse DNS A )
"id": "xxxxxxx-xxxxxxxx-xxxxxxxxxxx",
"apiVersion": 4312662016,
"gateway": {},
"subscriptionSpeed": {
"downloadMax": 0,
"uploadMax": 0
},
"wan": {
"technology": "ftth",
"mode": "IntegratedNT",
"aggregation": "no",
"byteCounter": {
"download": 4008684651,
"upload": 2333043527
}
},
"lan": {
"connectionType": "ethernet",
"complexity": "Undefined",
"speedLan": {
"downloadMax": 1000000.0,
"uploadMax": 1000000.0,
"download": 0,
"upload": 0
}
},
"timestamp": {
"apiCallTime": 1672246529,
"lastUpdate": 1672246529
}
}
visiblement les vitesses sont exprimés en kilobits/s (par rapport à la vitesse LAN) mais si on regarde par rapport a la vitesse WAN je pense qu'il y a un problème car ça me ferait 4 Tb/s en WAN mais je pense que c'est normal vu que j'utilise pas vraiment l'API de façon conventionnel
-
Chez Orange, l'API semble être sur le nom api-infoacces.orange.fr (qui a seulement une IPv6 d'ailleurs).
Oui, chez Orange pas de compatibilité IPv4.
L'IPv4 complique le développement, car les différents PC sur la box se présentent avec la même IPv4 et donc ce n'est pas suffisant pour l'identifier afin de savoir s'il est connecté en Wi-Fi ou en Ethernet et à quel débit.
Orange à 100% des clients compatible API activé par défaut en IPv6. Le support d'IPv4 n'était donc pas obligatoire.
Bouygues et SFR n'ont pas 100% d'IPv6 et ont dû développer une gestion de l'IPv4 (et de l'IPv6, car avec du CG-Nat, on ne peut plus utiliser l'IPv4, l'IPv6 est obligatoire).
-
Avec ma Freebox Révolution j'ai une jolie erreur 500 "Internal Server Error" sur la requête vers https://api-arcep.proxad.net/api/v1/tca/prec et on dirait bien que ça bloque le test sur nPerf.
-
Quand tu lances un test nPerf sur le navigateur web, il y a un problème ?
L'échec de l'API ne devrait pas impacter le test nPerf.
-
Quand tu lances un test nPerf sur le navigateur web, il y a un problème ?
Oui, je faisais le test sur Firefox. Je réessayerai ce soir.
-
N'éhsites pas à ouvrir un sujet dans la section nPerf : https://lafibre.info/nperf/
-
Avec la Livebox, l'appel de l'API a pris 17s, et si je refais la requête manuellement elle prend 6,5s >:(
Ca retarde le début du test, actuellement si c'est juste pour afficher FTTH, c'est dommage.
Mais s'ils veulent plus tard se servir des compteurs d'octets reçus et envoyés côté WAN (byteCounter), il faut effectivement attendre avant de débuter le test de download.
Actuellement ce n'est pas le cas, puisqu'il n'y a qu'un seul appel à l'API, pour vérifier qu'il n'y a pas de trafic à côté du test de débit il faudrait au moins un appel à la fin (et donc une autre attente de 7s...).
Le test de latence génère peu de trafic, donc il pourrait être fait en parallèle de l'appel à l'API (soit en le déplaçant au début, soit pour l'éventuel futur second appel à la fin).
Ca implique aussi que si l'API n'échoue pas immédiatement pour les abonnés ayant soit une ancienne box non supportée, soit remplacé la box, alors il faut attendre le timeout, qui doit nécessairement être assez long.
-
C’est vrai. Je ne l’avais pas précisé, mais il y a une bonne latence supplémentaire au début du test, du moins chez Orange. Je suis étonné que ce ne soit pas imperceptible.
-
L'API vient être mise en service, Orange va travailler pour améliorer le temps de réponse de l'API, le point leur a été remonté juste avant les vacances.
-
Je ne sais pas si c'est à cause de la mise à jour de la Livebox 5 en 4.66.0, mais maintenant l'API Orange échoue systématiquement sur le PC qui fonctionnait ce matin, alors qu'elle fonctionne sur un autre PC !
Le serveur Orange retourne une erreur 500 avec comme contenu {"error":"internal_server_error","errorDescription":"304"}.
La première tentative a échoué en 11s, les suivantes en environ 4,5s.
Et dans ce cas, nPerf reste bloqué :-[
Pourtant les deux PC sont sur le même port de la Livebox (derrière un switch), et la Livebox les voit dans les équipements connectés (mais il n'y a que les IPv6 dans cette interface).
-
N'éhsites pas à ouvrir un sujet dans la section nPerf : https://lafibre.info/nperf/
Fait !
-
C'est le bêta test si je comprends bien :
{"error":"unauthorized","errorDescription":"invalid request"}
-
y'a t'il un moyen légal de saisir l'ARCEP ou l'autorité de la concurrence ou le parlement pour contester la mise en œuvre cette API ?
-
y'a t'il un moyen légal de saisir l'ARCEP ou l'autorité de la concurrence ou le parlement pour contester la mise en œuvre cette API ?
Contester quoi exactement ? ???
-
Contester quoi exactement ? ???
plein de choses. déjà c'est anti-concurrentiel, l'utilisateur lui-même ne peut créer son propre outil de mesure et avoir les infos de sa box. Plus plein d'autres points notamment sur le tracking et le fait que les FAI savent qui et quand et avec qui un utilisateur fait un test de débit et peuvent donc influer sur le résultat.
Bref je peux rédiger un doc détaillé mais je ne veux pas perdre mon temp si c'est pour que ce ne serve a rien, parce que le petit comité de complices qui a pondu cette horreur est bien trop doué pour manipuler l'ARCEP ou les autorités en général... ;)
-
Bref je peux rédiger un doc détaillé mais je ne veux pas perdre mon temp si c'est pour que ce ne serve a rien, parce que le petit comité de complices qui a pondu cette horreur est bien trop doué pour manipuler l'ARCEP ou les autorités en général... ;)
Je crois que tu peux t'arrêter tout de suite...
Il me semble que l'API n'est pas utilisée si tu ne valides pas l'étape sur le consentement, à moins que ça ne bloque le test complètement.
Sur le fait de ne pas pouvoir utiliser l'API, on va te dire que c'est pour des raisons de sécurité et que tu peux te faire certifier si tu veux y avoir accès (ou une réponse du genre).
-
c'est pour des raisons de sécurité
ou de confidentialité ou respect de la vie privée etc
C'est l'argument toujours utilisé pour dissimuler l'intention véritable.
C'est malheureux mais ca fonctionne super bien quand on a en face des politiques ou des décideurs/managers techniquement incompétents. J'avoue que j'ai moi-même par le passé abusé de cela quand je voulais placer un produit ou un service...
Pourtant depuis des années les bbox de Bouygues ont une API simple et qui fait le job mais curieusement cela n'a jamais posé de problème de sécurité / confidentialité / respect de la vie privée
C'est juste exaspérant cette exploitation de l'administration française par des intérêts privés.
-
Pour l'aspect sécurité, ça me semble difficile d'obtenir l'ouverture complète de l'API depuis le web.
En revanche, si tu as en tête l'utilisation dans nspeed, pourquoi pas demander des modifications à l'ARCEP .
L'API pourrait être accessible sans authentification (le client étant identifié par son IP) à condition de mettre un entête qui ne puisse pas être positionné par un site web.
Par exemple, "Sec-LocalAPIUsage: true" (ou sinon une valeur particulière de "Origin" ou "Referer").
Ce serait le signe d'un usage local (par un programme), car ce sont des entêtes qui ne peuvent pas être positionnés par une page web (https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name) .
-
Arcep -> THD = 30Mbits
C'est l'Europe qui définit le THD ≥ 30 Mb/s.
Il y a eu une époque où le THD était défini en France comme ≥ 50 Mb/s, mais l'Arcep s'est ensuite aligné sur la définition européenne.
y'a t'il un moyen légal de saisir l'ARCEP ou l'autorité de la concurrence ou le parlement pour contester la mise en œuvre cette API ?
Bien sûr que tu peux attaquer l'Arcep, les opérateurs ou des associations le font régulièrement.
L'API est sécurisée pour plusieurs raisons :
- Des raisons de sécurité, tu fais un appel au SI des opérateurs qui sont probablement des OIV, donc il y a de nombreuses précautions prises
- Éviter l'utilisation de l'API par des tiers (je pense que beaucoup de sociétés qui collectent des données aimeraient récupérer dans le navigateur web ton offre internet pour mieux cibler tes publicités ou savoir si tu es connecté en Ethernet ou en Wi-Fi).
Je vais être constructif : Si tu souhaites utiliser l'API pour ton outil de test de débit, je propose de voir avec toi comment faire.
Deux pré-requis :
- être conforme au code de conduite, cf https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29507
- être en mesure d'avoir une volumétrie prévisionnelle
Voici un code open source proposé par nPerf pour l'accès à l'API côté client : https://github.com/renaudk/arcep-api-box-tester
(merci à nPerf pour tout le travail fait sur l'API au passage).
L'API pourrait être accessible sans authentification (le client étant identifié par son IP) à condition de mettre un entête qui ne puisse pas être positionné par un site web.
Par exemple, "Sec-LocalAPIUsage: true" (ou sinon une valeur particulière de "Origin" ou "Referer").
Ce serait le signe d'un usage local (par un programme), car ce sont des entêtes qui ne peuvent pas être positionnés par une page web (https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name).
On pensait au départ que cela serait suffisant comme sécurité, mais non. Là, tu sécurises par rapport à un site web, mais n'importe quel application sur le PC ou téléphone pourrait faire un appel à l'API (ou même le système d'exploitation).
Vraiment la sécurité en place n'a pas été mise en place pour le plaisir. C'est le fruit de longs échanges avec l'écosystème.
-
Pourquoi une sécurisation toute bête basée sur des clés d'API autorisées ou non par l'utilisateur dans son interface client n'était pas suffisante ? (comme ce que fait Free depuis bien longtemps avec son API d'envoi de SMS vers les mobiles Free par exemple, bien pratique)
C'est franchement dommage ce workflow obligeant l'utilisateur à passer par une tierce partie uniquement pour accéder à des données sur sa box et à des données le concernant chez son FAI, je rejoins complètement kgersen...
-
- Des raisons de sécurité, tu fais un appel au SI des opérateurs qui sont probablement des OIV, donc il y a de nombreuses précautions prises
L'appel est uniquement réellement nécessaire pour récupérer le débit souscrit, les autres valeurs viennent de la box (et donc même si elles sont relayées par l'opérateur, ça peut être sur un système séparé donc l'attaque ne nuirait pas à d'autres services).
Deux pré-requis :
- être conforme au code de conduite, cf https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/la-mesure-de-la-qualite-de-service-dinternet.html#c29507
- être en mesure d'avoir une volumétrie prévisionnelle
Je ne vois pas trop comment ça pourrait être compatible avec une appli locale, qui plus est si elle passe opensource.
N'importe qui pourrait utiliser les mêmes identifiants.
On pensait au départ que cela serait suffisant comme sécurité, mais non. Là, tu sécurises par rapport à un site web, mais n'importe quel application sur le PC ou téléphone pourrait faire un appel à l'API (ou même le système d'exploitation).
Vraiment la sécurité en place n'a pas été mise en place pour le plaisir. C'est le fruit de longs échanges avec l'écosystème.
Si on part du principe que l'utilisateur peut installer des applis douteuses, alors effectivement c'est un problème.
Mais celles-ci ont déjà accès à une partie des informations ; type de connexion locale, volume des échanges de la machine (au moins sur PC).
Pour le système d'exploitation, ça pourrait servir à détecter des problèmes et les signaler à l'utilisateur.
La question est de savoir si les vendeurs iraient se mettre hors la loi (si l'utilisation de l'API en local est conditionnée à l'absence de remontée d'informations).
-
Pourquoi une sécurisation toute bête basée sur des clés d'API autorisées ou non par l'utilisateur dans son interface client n'était pas suffisante ? (comme ce que fait Free depuis bien longtemps avec son API d'envoi de SMS vers les mobiles Free par exemple, bien pratique)
C'est franchement dommage ce workflow obligeant l'utilisateur à passer par une tierce partie uniquement pour accéder à des données sur sa box et à des données le concernant chez son FAI, je rejoins complètement kgersen...
Sur ce point, je pense que ça a dû être écarté compte tenu :
- de la complexité du dev nécessaire : la clé d'API devrait authentifier l'utilisateur auprès du SI pour récupérer le débit souscrit, ou alors la box doivrait le récupérer pour le donner dans une réponse locale
- du faible nombre d'utilisateurs potentiels : ce serait réservé aux utilisateurs avancés (dont une partie remplace déjà la box), et ça viendrait en plus de la solution actuelle pour nPerf et autres (qui doit fonctionner sans intervention utilisateur)
-
L'API est sécurisée pour plusieurs raisons :
- Des raisons de sécurité, tu fais un appel au SI des opérateurs qui sont probablement des OIV, donc il y a de nombreuses précautions prises
- Éviter l'utilisation de l'API par des tiers (je pense que beaucoup de sociétés qui collectent des données aimeraient récupérer dans le navigateur web ton offre internet pour mieux cibler tes publicités ou savoir si tu es connecté en Ethernet ou en Wi-Fi).
l'API n'avait pas besoin de passer par le SI des opérateurs. Un simple endpoint web sur la box comme y'a deja l'interface web suffisait largement. ca prend 1 journée a dev, ca n'impacte en rien le SI des FAI, ca reste local aux box (cf ce que fait Bytel).
Pour ce qui est de la collecte de données c'est de la parano pure et simple des opérateurs. Ils ne veulent pas que leur concurrents proposent des pubs fibre sur les clients adsl ? ridicule. Ile ne veulent pas qu'un site sans dépendance économique avec eux fasse un rapport taux fibre/adsl/débit moyen par zone ? ridicule.
Le navigateur informe déja n'importe qui de la résolution de l'écran, de l'OS, de sa version , etc. Rendre dispo le type de connexion Internet, son débit max up/max down et le crosstalk ne pose aucun problème aux utilisateurs eux-mêmes. On demande meme pas le modele de box ou sa version. Et juste une option pour désactiver cela dans l'interface de la box (donc opt-in par défaut avec opt-out possible).
Mais non, sous des prétextes fallacieux , ce "comité" en arrive a devoir passer par le SI des FAI donc OVI ,machin truc, sortie de parapluie a tous les étages de la hiérarchie des FAI.
Des dévelopements complexes s'en suit (combien de mois/années ? qui a payé pour ca ? qui s'en est mis dans les poches pour ca ? )
Tout ca pour une usine a gaz qui sera peu utilisée et sans doute fermée dans quelques années après le bilan d'évaluation. ce qui était le but sans doute du "comité".
-
Je vais être constructif : Si tu souhaites utiliser l'API pour ton outil de test de débit, je propose de voir avec toi comment faire.
non ce n'est pas spécifique a NSpeed. J'estime que n'importe qui doit avoir accès a ses infos. Netflix par exemple pourrait s'en servir pour améliorer son fonctionnement et/ou détecter les FAI 'merdiques' au heures de pointes (faible débit sur une connexion fibre par exemple).
C'est clairement un truc que les FAI ne voulaient pas, que l'ARCEP a voulu leur imposer et qu'ils ont habilement manœuvré pour faire une usine a gaz qu'ils contrôlent et qui va finir a la poubelle. Je ne vois pas d'autres explications cohérentes et sensées.
Alors qu'il suffisait a un petit comité de pondre une RFC tout simple (après tout pourquoi rester franco-francais), de l'imposer aux FAI et de la proposer un niveau européen aussi.
-
Pour l'aspect sécurité, ça me semble difficile d'obtenir l'ouverture complète de l'API depuis le web.
pourquoi ? j'aimerai bien un cas d'exemple qui "pose problème".
-
Il y a l'API "Network Information API" actuellement en phase de test qui est dispo sur plusieurs navigateur -> https://caniuse.com/netinfo
il permet notamment de connaitre le type de connexion Wifi / Ethernet / 3G / 4G / 5G, le RTT estimé/réel ect... voir le rapport du W3C https://wicg.github.io/netinfo/
Donc même sans être API de l'Arcep, un jour ou l'autre ça arrivera
-
pourquoi ? j'aimerai bien un cas d'exemple qui "pose problème".
C'est du tracking / fingerprinting supplémentaire, c'est vrai qu'en soi ce n'est pas forcément critique pour les abonnés (mais les opérateurs considèrent probablement les données comme importantes, ou préfèrent les monétiser eux-mêmes).
En revanche, pour une implémentation locale sans restriction, il faudrait que ce soit implémenté proprement, je ne sais pas si c'est réaliste...
-
l'API n'avait pas besoin de passer par le SI des opérateurs. Un simple endpoint web sur la box comme y'a deja l'interface web suffisait largement. ca prend 1 journée a dev, ca n'impacte en rien le SI des FAI, ca reste local aux box (cf ce que fait Bytel).
On pensait au départ que seule certaines informations avaient besoin de venir du SI (d'où le nom API dans la box).
L'implémentation réalisée est différente : le nom de domaine ne pointe pas vers la box pour une problématique de certificat TLS valide. Un site https ne peut pas charger une ressource en http. Les certificats TLS ont une durée maximale de 13 mois, la mise à jour de ce certificat régulièrement, même sur des veilles box est problématiques.
C'est du tracking / fingerprinting supplémentaire, c'est vrai qu'en soi ce n'est pas forcément critique pour les abonnés (mais les opérateurs considèrent probablement les données comme importantes, ou préfèrent les monétiser eux-mêmes).
Oui, un accès par d'autres outils que les tests de débit entrainait d'autres risques que le fingerprinting pour les clients et pour le SI des opérateurs.
-
Les certificats TLS ont une durée maximale de 13 mois, la mise à jour de ce certificat régulièrement, même sur des veilles box est problématiques.
On pourrait très bien avoir un firmware fixe avec l'implémentation et la clé privée, qui télécharge régulièrement un certificat mis à disposition par l'opérateur (cette mise à jour dynamique ne nécessiterait aucune sécurité supplémentaire du côté de la box, car seul un certificat associé avec la clé privée fonctionnerait).
Mais ça aurait nécessité un développement côté box, avec la solution actuelle il est possible que certains opérateurs aient tout fait côté SI (si les accès de gestion de la box permettaient déjà de récupérer les différentes informations).
-
On parle d'un unique nom de domaine qui aurait pointé vers la box, donc une unique clé privée.
L'aspect sécurisation a été étudié. Je ne dis pas que c'est impossible, mais cela a posé plusieurs problèmes. Il y a toujours un appel du SI et les opérateurs souhaitent éviter tout dérapage en nombre de requêtes par seconde.
Un aspect qui semble avoir convaincu les opérateurs, c'est le fait d'avoir cette API sur du matériel très hétérogène (y compris les 5G box) une réponse identique.
Enfin, il faut penser que s'il faut mettre à jour le certificat, d'(autres choses peuvent évoluer comme la version de TLS (des veilles box ne gèrent pas TLS 1.2)...
-
Il me semble que les box 4G/5G en France sont toutes des modèles génériques, contrairement aux box xDSL/Câble/FTTH des gros opérateurs.
Je peux comprendre que dans ce cas faire implémenter une API à un tiers (comme Huawei par exemple) et la maintenir ne soit pas facile.
-
non ce n'est pas spécifique a NSpeed. J'estime que n'importe qui doit avoir accès a ses infos. Netflix par exemple pourrait s'en servir pour améliorer son fonctionnement et/ou détecter les FAI 'merdiques' au heures de pointes (faible débit sur une connexion fibre par exemple).
La demande de l'ARCEP était de permettre une meilleure analyse des résultats des tests réalisés en crowdsourcing et une meilleure info pour l'utilisateur de ces tests, l'API a été conçue en ce sens, et les règles de sécurité également. Dans ce contexte, je pense sincèrement que tout le monde a travaillé ensemble pour trouver une solution technique qui convienne à tous les intervenants. Les FAI n'avaient aucun intérêt à rajouter de la complexité inutilement car ils ont pris à leur charge tous les coûts de développement de l'API.
Si dès le départ le projet avait été d'être ouvert à tous, ça aurait effectivement simplifié beaucoup le process, mais ce serait aussi certainement bcp plus problématique pour garantir la sécurité côté FAI. Néanmoins, cela n'était pas l'objectif de cette décision de l'ARCEP, je doute donc que ça puisse être remis en cause pour cela.
-
Si l'API est massivement ouverte, cela signifie que tous les acteurs pourraient récupérer les informations, avec le risque que certains acteurs ne soient pas conformes au RGPD.
Comme vous pouvez l'imaginer, c'est inacceptable pour les fournisseurs d'accès à internet de diffuser comme cela leurs données, avec un risque que cela retombe sur eux.
Il ne faut pas me dire que tous les sites respectent le RGPD, on sait tous que de nombreux sites sont soit carrément hors des clous ou du mauvais côté de la ligne jaune. Même le site de la CNIL a été épinglé pour une non-conformité de certaines régles : https://twitter.com/aeris22/status/1612833612478529541
Là l'API est contrôlée acteurs par acteurs et si son arrivée sur nPerf ne se fait que maintenant, c'est que le consentement proposé ne convenait pas aux experts RGPD des opérateurs. L'API était prête depuis de nombreux mois chez les opérateurs.
-
désolé mais j'ai l'impression d'un dialogue de sourds.
on n'est clairement pas d'accord sur "l'importance" de ces données. postulat de base a tout ce qui suit.
"fingerprinting" ? on parle du type de la connexion et des débits max ... franco/francais en plus.. qui va s'amuser a utiliser cela pour du fingerprinting ?
"pas conformes au RGPD" - j'aimerai bien lire le rapport la dessus...
quid de la CNIL sur le pertinence de rendre disponible 'type de connexion, débit max/min, crosstalk' ? y'a t'il un avis officiel et rapport la dessus ?
"Comme vous pouvez l'imaginer, c'est inacceptable pour les fournisseurs d'accès à internet de diffuser comme cela leurs données" - quoi ?! c'est pas plus leur donnée que celles de leurs clients... et mon adresse IP qui informe qui est mon FAI et ma géoloc ils disent quoi les FAI a ce sujet ? c'est bien plus fingerprinting et sensible que le type et le débit max de ma connexion... non désolé je n'imagine pas cela un instant. C'est non seulement complétement acceptable et ils auraient du le faire d'eux-mêmes depuis longtemps.
tout le monde a travaillé ensemble pour trouver une solution technique qui convienne à tous les intervenants.
...
ce serait aussi certainement bcp plus problématique pour garantir la sécurité côté FAI
C'est bien le problème: le but était "qui convienne à tous les intervenants" et pas plus. aucun esprit RFC et ouverture aux futures intervenants ou une extension a l'Europe voir au monde. Et open source la dedans ? rien
Et désolé mais c'est prendre les gens pour des 'ignorants technique' (a défaut d'autre mot) que de dire : "garantir la sécurité côté FAI" . On parle d'un solution qui remonte pas au delà de la box. Bytel l'a déja mise en œuvre (cf https://api.bbox.fr/doc/apirouter/index.html#api-Device-GetDevice). Toutes les box ont déjà un serveur web embarqué accessible en https. Ca ne pose problème a personne. ni a la CNIL d'ailleurs.
"On parle d'un unique nom de domaine qui aurait pointé vers la box, donc une unique clé privée.": c'est très faisable avec un unicast comme fait free avec mafreebox.free.fr (et y'a surement d'autres solutions, surtout si on fait qu'en IPv6).
Un rate limiting est trivial à faire aussi si on éviter qu'une site DoS une box depuis le lan (ce qui est déjà possible d'ailleurs vu que toutes les box ont un serveur web coté lan voir meme coté wan parfois).
Bref quand on prend le temps de réfléchir plus de 5 minutes a ce sujet, qu'on regarde ce qui existe déja et ce qui arrive bientot dans les navigateurs, qu'on pèse tout les aspects, qu'on a 30 ans+ d'expérience en info dont 10 ans en sécurité , désolé de vous le dire mais l'existence et la complexité de cette 'API' n'est juste pas compréhensible et justifiable...
Et pas bonne pour l'image de l'ARCEP et de l'IT française, vraiment.
Apres j'ai peut-être aussi une vue trop technique et idéalisée de l'ARCEP, je pensais qu'elle avait de la compétence technique interne, des gens avec de la bouteille, pas influençables et aptes a pondre des RFC de haute tenue et ensuite a les imposer aux FAI (genre IANA, IETF, etc). C'est clairement pas le cas, la on dirait que y'a vraiment principalement de la politique et peu de technique. J'aurais du me renseigner mieux sur l'ARCEP avant de me lancer dans cette critique.
Sur ce je retourne coder et j'attendrai la RFC d'un GAFA et les évolutions des navigateurs qui feront sans doute la même chose, en plus simple et plus universel. En l'état cette API n'est compatible avec de l'open source ou chacun peut compiler son programme de test ou faire son site web de test.
-
on parle du type de la connexion et des débits max ... franco/francais en plus.. qui va s'amuser a utiliser cela pour du fingerprinting ?
Si le débit max de ton ip devient public, ça veut dire que ton abonnement devient public. Donc en gros n'importe que peut voir la répartition des abonnements d'un FAI quelconque.
Si on était parti là-dessus, autant demander à n'importe quel commerçant de rendre public le détail de ce qu'il vend.
En tout cas en l'état, moi, je trouve que ce n'est pas si mal cette api.
-
"fingerprinting" ? on parle du type de la connexion et des débits max ... franco/francais en plus.. qui va s'amuser a utiliser cela pour du fingerprinting ?
On donne accès à des informations qui permet d'estimer la distance du PC à la box. Cela permet d'aider à séparer les différents PC d'un foyer. C'est pour cette même raison qu'Apple ne met plus à jour le user-agent de Safari, de façon que tous les Mac d'un même foyer se présentent avec le même user-agent, même si ce sont différentes versions. C'est par contre galère pour savoir s'il y a ou pas un support de VP9+Oppus du Safari utilisé.
SUr PC, on peut citer aussi le retrait de l'information 32bits / 64bits dans le user-agent pour limiter le fingerprinting. Le retrait de l'API Battery Status dans les navigateurs suit la même logique : limiter les données qui permettent à un site web de savoir qui est qui => https://developer.mozilla.org/fr/docs/Web/API/Battery_Status_API
quid de la CNIL sur la pertinence de rendre disponible 'type de connexion, débit max/min, crosstalk' ? y'a t'il un avis officiel et rapport la dessus ?
La Cnil a participé à deux réunions. Les FAI souhaitaient ceinture et bretelle.
La Cnil ne permet pas que l'API soit ouvert à tous et le consentement de l'utilisateur est nécessaire.
"On parle d'un unique nom de domaine qui aurait pointé vers la box, donc une unique clé privée.": c'est très faisable avec un unicast comme fait free avec mafreebox.free.fr (et y'a surement d'autres solutions, surtout si on fait qu'en IPv6).
C'est bien l'idée de faire comme avec mafreebox.free.fr, mais avec un certificat : on a donc un même certificat pour toutes les box. La problématique étant de bien sécuriser la chose pour que la clé privée ne puisse être récupérée.
-
Si le débit max de ton ip devient public, ça veut dire que ton abonnement devient public. Donc en gros n'importe que peut voir la répartition des abonnements d'un FAI quelconque.
Précision : Le busness de nPerf, c'est de vendre les résultats des tests de débit (leur base de donnée) et l'autorisation de faire des publicités citant nPerf.
Les données de l'API ont un régime particulier : elles ne peuvent être vendues qu'à l'opérateur du client. Les autres clients qui achètent les données nPerf n'ont pas accès aux données détaillées de l'API.
-
Comment sont gérés les abonnements 500mb/s mais provisionnés à 1gb/s pour orange par exemple ?
-
Ah tiens une bonne question ! Moi j'ai une offre qui n'existe pas officiellement chez Bouygues ... (erreur de provisioning je pense)
-
Il suffit de regarder, mais Bouygues Telecom a tous les débits possibles en offre : ils proposent régulièrement aux clients d'augmenter de 100 ou 200 Mb/s le débit contre quelques euros de plus, donc tu as plein d'offre.
Pour voir le débit commercial, tu as le tutoriel ici (https://lafibre.info/tester-son-debit/api-arcep/msg995951/#msg995951).
Dans mon cas RED me propose 1 Gb/s symétrique, mais mon offre commerciale est de 1 Gb/s descendant et 500 Mb/s montant (logique vu que je n'ai jamais vu d'offre 1 Gb/s symétrique chez RED) :
(https://lafibre.info/images/barometre/202301_api_arcep_box_sfr_1.webp)
-
En fait, je pense à une erreur parce que mes augmentations de débit ont été faites successivement sans notification (et sans augmentation) et à quelques mois d'intervalle. Je suis passé en quelques mois de 300 > 400 > 500 (mais toujours avec un UP bloqué à 200).
J'ai essayé de recup le call API mais comme je n'utilise pas la box de l'opérateur.
-
Si le débit max de ton ip devient public, ça veut dire que ton abonnement devient public. Donc en gros n'importe que peut voir la répartition des abonnements d'un FAI quelconque.
Si on était parti là-dessus, autant demander à n'importe quel commerçant de rendre public le détail de ce qu'il vend.
En tout cas en l'état, moi, je trouve que ce n'est pas si mal cette api.
on quoi c'est un problème de savoir que telle IP c'est une connexion fibre plutôt qu'une ADSL ?
De plus c'est une info disponible que de facon "active" = il faut un site web ou une app, que l'utilisateur consulte/utilise, qui fait une requête a la box et qui remonte le résultat ...y'a guerre que Google et Facebook qui peuvent utiliser cela pour faire une carto global de la fibre en France...infos qu'ils ont déjà autrement de toute facon.
Et pourquoi un site quelconque ne pourrait pas avoir cette répartition ?
"n'importe que peut voir la répartition des abonnements d'un FAI quelconque": oui et tant mieux. Ca devrait être public , tout comme la carte fibre/adsl est public ( https://maconnexioninternet.arcep.fr/ ) et l'éligibilité par opérateur devrait être public et accessible via une API (ce qui manque).
Je ne compare pas les FAI a des commerçants quelconques. Mais plus a des marques de voitures. On a les chiffres précis de chaque marques/modèles qui circulent.
Le problème de cette API est que sous de faux prétexte de protéger le consommateur (nous) ,elle protège juste les FAI et les speedtesteurs qui sont leur fournisseurs et surtout limite l'innovation. Dans ce cas pourquoi une API ? les speedtesteurs n'ont qu'a envoyer chaque jour une liste d'IPs a chaque FAI et les FAI les leur renvoient qualifiées. Pas besoin d'API complexe, de serveurs a maintenir et à faire évoluer, de procédure administrative (couts CAPEX et OPEX important). C'est un deal entre chaque speedtesteurs et FAI, en quoi l'ARCEP devrait intervenir dans ce cas ?
Je ne comprend pas d'ailleurs non plus le "code de conduite". Ca nuit a toute innovation et utilisation non prévues. Tout ce cadre et ces processus n'ont qu'un but: surtout ne pas permettre d'autres usages que ce qu'on a prévu. Tout innovation est bannie d'office.
Par exemple ,si je créer un jeu en ligne, je ne peux interroger la box pour savoir le débit max de la ligne, le type de connexion avec le PC, le cross-talk. Infos pourtants super utiles pour de l'autodiagnostique donc diminuer le cout de support. D'ailleurs ceci est applicable aux FAI eux-mêmes pour diminuer leur couts de diag et support...
On donne accès à des informations qui permet d'estimer la distance du PC à la box. Cela permet d'aider à séparer les différents PC d'un foyer. C'est pour cette même raison qu'Apple ne met plus à jour le user-agent de Safari, de façon que tous les Mac d'un même foyer se présentent avec le même user-agent, même si ce sont différentes versions. C'est par contre galère pour savoir s'il y a ou pas un support de VP9+Oppus du Safari utilisé.
SUr PC, on peut citer aussi le retrait de l'information 32bits / 64bits dans le user-agent pour limiter le fingerprinting. Le retrait de l'API Battery Status dans les navigateurs suit la même logique : limiter les données qui permettent à un site web de savoir qui est qui => https://developer.mozilla.org/fr/docs/Web/API/Battery_Status_API
La Cnil a participé à deux réunions. Les FAI souhaitaient ceinture et bretelle.
La Cnil ne permet pas que l'API soit ouvert à tous et le consentement de l'utilisateur est nécessaire.
hum y'a des grosses confusions entre ce qui est fait pour de la sécurité et du fingerprinting... je ne vais pas m'étendre la dessus a priori on n'a pas du tout la même vision des choses la (mais pour sur l'agent safari ,l'api battery status et 32/64 bits c'est plus pour des raisons de sécurité/exploit que de fingerprinting d'autant que y'a pas consensus sur tout les navigateurs).
> La Cnil ne permet pas que l'API soit ouvert à tous : c'est cela qui n'est pas normal dans ce dossier. y'a t'il un recours possible contre cela ? (sans passer des heures à faire des rapports et/ou payer des avocats). Je pense que c'est le point clé pour
C'est bien l'idée de faire comme avec mafreebox.free.fr, mais avec un certificat : on a donc un même certificat pour toutes les box. La problématique étant de bien sécuriser la chose pour que la clé privée ne puisse être récupérée.
la clé privée peut être public dans ce cas...car c'est une unicast qui ne répond qu'en local. ca permet a ceux qui mettent leur propre routeur de répondre a l'API.
pour illustrer usine a gaz vs "ce que ca aurait du etre":
(https://www.arcep.fr/fileadmin/cru-1671101953/user_upload/grands_dossiers/qualite-service-internet/202206_arcep_fonctionnement_de_api_carte_identite_de_acces.png)
- serveurs chez les FAI: capex et opex
- procédures a l'arcep: cout RH et opex
- limité a quelques élus sectionnés.
- pas d'innovation
- mon FAI sait quand et avec qui je fais un speedtest
- latence et scalabilité problématique
vs
(https://i.imgur.com/l1D0Rls.png)
- ouvert a tout le monde, tout usage et innovation possible
- aucun cout coté FAI si ce n'est le capex initial pour l'ajout du code dans la box et l'opex du certificat
- aucun cout arcep
- aucun info vers le FAI sauf si mouchard dans la box
- zéro latence, scalable a l'infini
les infos renvoyées par la box:
- débit max up et down (vu que y'a des paranos, on ne demande meme pas le type ftth/cable/adsl, juste les débits max possibles).
- crosstraffic (2 valeurs: up & down)
- débit max up et down entre la box et qui fait la requête (meme pas besoin du type wifi/ethernet en fait)
si on se limite au minimum utile: en gros juste "6 valeurs numériques" suffisent. c'est tout.
Tout cette complexité (réunions/consultations arcep, cnil, reunions groupe , rédac documents, serveurs, processus et opex derriere, formations de gens en interne etc) pour ne pas donner a tout le monde juste 6 valeurs numériques qu'un dev par box peut ajouter en quelques jours !!! quelle efficacité !
-
Même avec les données que tu voudrais donner tu peux créer une empreinte qui permet de mieux cibler les différents périphériques derrière une même IP par exemple ou de faire des suppositions sur le niveau de vie en supposant que plus ton débit est max est gros plus tu as un forfait cher/des équipements récents.
Il y a forcément un risque à laisser ce genre d'infos accessibles. La seule solution ça serait une API où l'utilisateur doit valider tout demande mais là il faut un tiers de confiance (par exemple le navigateur ou l'OS dont on considère qu'il respectera bien le consentement de l'utilisateur). Et là on retombe dans quelque chose compliqué à mettre en place.
-
"n'importe que peut voir la répartition des abonnements d'un FAI quelconque": oui et tant mieux. Ca devrait être public , tout comme la carte fibre/adsl est public ( https://maconnexioninternet.arcep.fr/ ) et l'éligibilité par opérateur devrait être public et accessible via une API (ce qui manque).
Je ne parle pas de distinction adsl/fibre, je parle de savoir exactement quel abonnement tu as. Pour Free, avec le debit wan tu peux distinguer si le gars a une pop ou une delta ou soit une mini soit une revolution. Donc avec un simple scan j'ai la repartition exacte des abonnements, et donc des revenus de Free, reste plus qu'a faire un scan par jour et de belles courbes. Ce genre d'info releve du droit des affaires et n'a pas a etre public.
Je maintiens : si jamais ce genre de truc deviens public, alors je veux aussi la liste des ventes du Franprix en bas de chez moi, ou du club de sport, d'Amazon, etc.
-
#MonDebitWanNestPasUneInfoPublique !
brdl de m !
;)
-
Ben pourquoi tu l'affiches dans ton avatar alors ? ;D
-
ahah !
bien vu :)
-
Les données de l'API ont un régime particulier : elles ne peuvent être vendues qu'à l'opérateur du client. Les autres clients qui achètent les données nPerf n'ont pas accès aux données détaillées de l'API.
J'ajouterai que nPerf ne fait pas de business sur ces données car aucun surcoût n'est appliqué pour l'opérateur qui les récupère, le tarif est le même avec ou sans les données API.