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":
- 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
- 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é !