Network Information API : confidentialité et replis
Découvrez comment des indications de connexion grossières peuvent aider les interfaces adaptatives sans devenir un identifiant stable du navigateur.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
La Network Information API expose des indications grossières comme effectiveType et saveData. Ces valeurs peuvent changer avec le réseau et la politique du navigateur ; elles ne constituent ni une recherche d'opérateur, ni une mesure exacte du débit, ni une preuve de localisation ou d'identité. BotBrowser peut rejouer une fixture de compatibilité autorisée et consigner les changements visibles, mais ne peut pas fabriquer un réseau, garantir la prise en charge de l'API ni déduire une personne d'une indication.
TL;DR
- Traitez les indications de connexion comme des entrées grossières et volatiles pour l'expérience utilisateur.
- Ne les utilisez pas comme preuves d'authentification, de localisation, d'opérateur, de débit ou d'identité.
- Détectez la capacité de l'API et fournissez un repli utile lorsqu'elle est absente ou change.
Sommaire
- Ce que l'API signale
- Limites de confidentialité et de cohérence
- Concevoir un repli sûr
- Le rôle borné de BotBrowser
- Conclusion
Ce que l'API signale
La spécification Network Information du WICG et MDN décrivent un objet de connexion avec des valeurs grossières comme effectiveType, downlink, rtt et saveData, ainsi qu'un événement change dans les implémentations qui l'exposent. Ce sont des indications d'adaptation, pas une mesure complète. Le navigateur peut les arrondir, les omettre ou les actualiser lorsque les conditions changent.
Utilisez la détection de capacité et lisez seulement la valeur nécessaire à une décision visible. Une page peut différer un grand aperçu lorsque saveData vaut true, tout en gardant un contrôle pour le charger. Ne réduisez pas silencieusement un contenu essentiel parce qu'une indication semble lente.
Limites de confidentialité et de cohérence
Les indications de connexion peuvent contribuer à une empreinte plus large lorsqu'elles sont combinées à d'autres signaux, surtout si l'application les conserve comme identifiant durable. Minimisez la collecte, n'associez pas ces indications aux comptes sans objectif clair et gardez une télémétrie grossière. Un événement de changement indique qu'une valeur a changé ; il n'explique ni pourquoi, ni le réseau, ni une nouvelle localisation.
Le même navigateur peut signaler des valeurs différentes sur deux réseaux, et deux navigateurs d'un même réseau peuvent différer. Ne prenez pas de décision de sécurité avec effectiveType, rtt ou downlink. Les principes de confidentialité du W3C soutiennent la limitation des finalités, tandis que la documentation MDN de l'API décrit ses limites de disponibilité et de comportement.
Concevoir un repli sûr
Commencez par une base fonctionnelle lorsque navigator.connection est absent. Utilisez ensuite l'indication minimale pour adapter une ressource facultative et exposez un contrôle visible de reprise ou de préférence. Si un événement de changement existe, débouncez le travail d'interface et conservez l'état précédent jusqu'à validation de la nouvelle valeur. Une API absente ne doit jamais être traitée comme un utilisateur défaillant ou un compte bloqué.
Testez les états lent, rapide, hors ligne, saveData, API absente et réseau changeant. Consignez la version du navigateur, la plateforme et le résultat visible, sans collecter d'identifiants réseau bruts ni de données de compte. Évaluez un repli selon l'utilisabilité et la correction, pas selon l'identité de l'objet exposé par chaque navigateur.
Le rôle borné de BotBrowser
BotBrowser permet d'exécuter une fixture Network Information autorisée dans un BrowserContext isolé, de comparer la détection de capacité entre versions déclarées et de consigner les décisions visibles avec des données synthétiques. Il ne peut pas contrôler un opérateur, garantir un effectiveType précis, contourner la médiation du navigateur ni transformer des indications en preuves d'identité ou de géolocalisation.
Liste de contrôle pratique
- Détectez l'API et gardez l'expérience par défaut utilisable sans elle.
- Réservez les indications grossières à l'adaptation facultative, jamais à l'autorisation ou l'identité.
- Débouncez les changements et exposez une reprise ou une préférence contrôlée par l'utilisateur.
- Testez les états absent, changeant, lent, rapide, hors ligne et
saveData. - Limitez la télémétrie à sa finalité et séparez-la des données de compte et de localisation.
Conclusion
La Network Information API est un signal pratique pour une livraison adaptative, pas une promesse sur un réseau ou une personne. Utilisez-la avec parcimonie, gardez les replis au premier plan et validez le comportement visible entre versions du navigateur. BotBrowser rend cette comparaison autorisée répétable, tandis que la politique réseau, les décisions de confidentialité et la responsabilité applicative restent aux systèmes qui les contrôlent.
À lire aussi
- Recherche sur la confidentialité des navigateurs avec des spécifications publiques
- Prise en charge des fonctions et qualité des fonctions du navigateur
- Qualité du réseau et performances du navigateur
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.