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

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.

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)...

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.

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.

"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.