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.