Comment les opérateurs mobiles connaissent-ils la résolution vidéo sur les connexions HTTPS?
Verizon modifie ses plans de données "illimités". Aux États-Unis, les clients peuvent diffuser des vidéos à 480p - ou - pour déverrouiller des résolutions plus élevées (720p et + 1080p). Ils ne sont pas le seul opérateur mobile à mettre en œuvre des règles telles que this .
Si je suis sur un site qui implémente HTTPS pour le streaming vidéo, disons YouTube ou Facebook, comment les opérateurs savent-ils quelle résolution je regarde? Si les opérateurs limitent la bande passante pour toutes les données, parler de résolutions vidéo semble être une mauvaise direction. S'il ne s'agit que de vidéo, cela semble soulever des problèmes de confidentialité.
Il s'agit d'un domaine de recherche actif. Il se trouve que j'ai fait du travail dans ce domaine, je vais donc partager ce que je peux sur l'idée de base (ce travail était avec des partenaires de l'industrie et je ne peux pas partager les détails secrets :)).
Le tl; dr est qu'il est souvent possible d'identifier un flux de trafic crypté comme transportant de la vidéo, et il est souvent possible d'estimer sa résolution - mais c'est compliqué et pas toujours précis. Il y a beaucoup de gens qui travaillent sur des façons de le faire de manière plus cohérente et plus précise.
Le trafic vidéo a des caractéristiques spécifiques qui peuvent le distinguer des autres types de trafic. Ici, je me réfère spécifiquement à la vidéo à la demande - pas à la vidéo en direct. La vidéo à la demande n'a pas souvent ces balises prioritaires mentionnées dans cette réponse . Je me réfère également spécifiquement à la vidéo adaptative, ce qui signifie que la vidéo est divisée en segments (chacun d'environ 2 à 10 secondes), et chaque segment de vidéo est codé à plusieurs niveaux de qualité (niveau de qualité signifiant: débit binaire vidéo à long terme, codec, résolution). Lorsque vous lisez la vidéo, le niveau de qualité auquel le segment suivant est téléchargé dépend du débit de données que l'application pense que votre réseau peut prendre en charge. (C'est le protocole DASH mentionné dans cette réponse .)
Si votre téléphone lit une vidéo et que vous regardez le débit de données (moyenne mobile pondérée) du trafic allant vers votre téléphone au fil du temps, cela pourrait ressembler à ceci:
(Ceci est capturé à partir d'une session YouTube sur Verizon. Il y a la moyenne mobile sur 15 secondes et également la moyenne à court terme.)
Cette session comprend plusieurs parties:
Tout d'abord, l'application vidéo (lecteur YouTube) essaie de remplir le tampon jusqu'à la capacité du tampon. Pendant ce temps, il extrait des données à n'importe quel débit que le réseau peut prendre en charge. À ce stade, il est fondamentalement impossible de le distinguer d'un téléchargement de fichiers volumineux, sauf si vous pouvez déduire qu'il s'agit du trafic vidéo de l'adresse distante (comme mentionné dans cette réponse ).
Une fois que le tampon est plein, vous obtenez des "rafales" à intervalles réguliers. Supposons que votre tampon puisse contenir 200 secondes de vidéo. Lorsque le tampon contient 200 secondes de vidéo, l'application arrête le téléchargement. Ensuite, après la lecture d'un segment de vidéo (disons 5 secondes), il y a de la place dans le tampon, donc il téléchargera le segment suivant, puis s'arrêtera à nouveau. C'est ce qui cause ce motif éclaté.
Ce modèle est très caractéristique de la vidéo - le trafic provenant d'autres applications n'a pas ce modèle - donc un fournisseur de services réseau peut assez facilement sélectionner les flux qui transportent le trafic vidéo. Dans certains cas, vous pourriez ne jamais observer ce modèle - par exemple, si la vidéo est si courte que la chose entière est chargée dans le tampon à la fois puis le client arrête le téléchargement. Dans ces circonstances, il est très difficile de distinguer le trafic vidéo d'un téléchargement de fichier (sauf si vous pouvez le déterminer par adresse distante).
Quoi qu'il en soit, une fois que vous avez identifié le flux comme transportant du trafic vidéo - soit par l'adresse distante (pas toujours possible, car les principaux fournisseurs de vidéo utilisent des réseaux de distribution de contenu qui ne sont pas exclusifs à la vidéo) ou par son modèle de trafic (possible si la session vidéo est longue, beaucoup plus difficile si elle est si courte que la vidéo entière est chargée dans le tampon d'un coup) ...
Maintenant, comme Hector a dit , vous pouvez essayer de deviner la résolution à partir du débit binaire en regardant la taille (en octets) de chaque "rafale" de données:
À partir de la taille par durée, vous pouvez faire une estimation raisonnable de la résolution - surtout si vous gardez une moyenne mobile.
Mais cela peut être difficile. Prenez la session YouTube dans mon exemple:
- Tous les segments n'ont pas la même durée - la durée de la vidéo demandée à la fois dépend de plusieurs facteurs (le niveau de qualité, l'état du réseau, le type d'appareil sur lequel vous lisez la vidéo et d'autres). Donc, vous ne pouvez pas nécessairement regarder une "rafale" et dire: "OK, c'était X octets représentant 5 secondes de vidéo, donc je connais le débit de données vidéo". Parfois, vous pouvez déterminer la durée probable du segment, mais d'autres fois, c'est difficile.
- Pour un niveau de qualité vidéo et une durée de segment donnés, différents segments auront des tailles différentes (en fonction de choses comme la quantité de mouvement qui se produit dans cette partie de la vidéo).
- Même pour la même résolution vidéo, le débit de données à long terme peut varier - une vidéo 1080p encodée avec VP9 n'aura pas le même débit de données à long terme que celle encodée avec H.264.
- Le niveau de qualité vidéo change en fonction de la qualité du réseau perçue (qui est visible par le fournisseur de services réseau) et de l'état du tampon (qui ne l'est pas). Vous pouvez donc regarder les débits de données à long terme sur 30 secondes, mais il est possible que le niveau de qualité vidéo réel ait changé plusieurs fois au cours de ces 30 secondes.
- Pendant les périodes où le tampon se vide ou se remplit le plus rapidement possible (lorsque vous n'avez pas ces "rafales"), il est beaucoup plus difficile d'estimer ce qui se passe dans la vidéo.
- Pour compliquer encore les choses: parfois, un flux vidéo est "réparti" sur plusieurs flux de couche inférieure. Parfois, une partie de la vidéo sera récupérée à partir d'une seule adresse, puis elle passera à la récupération de la vidéo à partir d'une adresse différente.
Ce graphique du débit de données que je vous ai montré juste au-dessus? Voici la résolution vidéo sur cet intervalle de temps:
Ici, la couleur indique la résolution vidéo. Donc ... vous pouvez sorte de estimer ce qui se passe uniquement à partir des modèles de trafic. Mais c'est un problème difficile! Il existe d'autres marqueurs dans le trafic que vous pouvez consulter. Je ne peux pas dire définitivement comment un fournisseur de services le fait. Mais au moins en ce qui concerne l'état de l'art universitaire, il n'y a aucun moyen de le faire avec une précision parfaite, tout le temps (sauf si vous avez la coopération des fournisseurs de vidéos ...)
Si vous souhaitez en savoir plus sur les techniques utilisées pour ce type de problème, il existe de nombreux ouvrages universitaires - voir par exemple BUFFEST: Predicting Buffer Conditions and Real-time Requirements of HTTP (S) Adaptive Streaming Clients comme point de départ. (Ce n'est pas mon article - je l'ai lu récemment.)
Rien ne maximise la bande passante à un taux constant autre que le streaming vidéo.
De plus, afin de s'assurer que le flux est géré en priorité (et non comme un téléchargement de gros fichiers, par exemple), les sources de streaming marquent les paquets de manière à indiquer aux opérateurs qu'ils diffusent de la vidéo. Le reste du paquet est crypté, mais les métadonnées qui indiquent au FAI comment le router parviennent à voir cette partie. S'ils ne le faisaient pas, il y aurait de fortes chances que le flux soit interrompu ou dégradé alors que le FAI tentait d'équilibrer tous les besoins du trafic réseau à ce moment-là.
Et voici comment Verizon a dit ils le feront:
Verizon ne convertira apparemment pas les vidéos à des résolutions plus basses. Au lieu de cela, il fixera une limite de bande passante à laquelle les applications vidéo devront s'adapter. " Nous gérons le débit vidéo HD en fixant des vitesses à pas plus de 10 Mbps , ce qui fournit une vidéo HD jusqu'à 1080p", a déclaré Verizon à Ars. Le Mbps sera probablement inférieur à celui dans les cas où Verizon limite la vidéo à 480p ou 720p.
Cela signifie que l'abonné et le fait que le trafic est en forme d'une certaine manière parce que c'est un certain type de vidéo signifie qu'il est étiqueté.
Comment? Verizon a un système d'optimisation vidéo qui a été montré pour limiter Netflix et YouTube à 10 Mbps avant même l'annonce en août 2017 des nouveaux plafonds.
Verizon a reconnu avoir utilisé un nouveau système d'optimisation vidéo , mais a déclaré qu'il faisait partie d'un test temporaire et qu'il n'affectait pas la qualité réelle de la vidéo. L'optimisation vidéo semble s'appliquer à la fois aux plans mobiles illimités et limités.
Mais certains utilisateurs de YouTube signalent une vidéo dégradée, affirmant que l'utilisation d'un service VPN peut contourner la limitation de Verizon .
Cela indique la capacité de Verizon à identifier les flux vidéo et à limiter la bande passante en conséquence, même si le contenu est fourni via HTTPS (mais pas les VPN).
Schroeder a presque certainement raison en ce que c'est juste une façon marketing de dire qu'ils restreignent la bande passante à certaines adresses IP de sites ou recherchent des marqueurs de priorité sur les paquets.
Il convient toutefois de noter qu'en théorie, il existe des moyens d'améliorer le fonctionnement si le seul objectif était de forcer les utilisateurs à une certaine résolution lors de la diffusion vidéo et rien d'autre.
De nos jours, une grande partie du streaming Internet utilise un processus appelé DASH (Dynamic Adaptive Streaming over HTTP). La façon dont cela fonctionne est de demander un petit morceau de vidéo, de mesurer la bande passante pendant le téléchargement et de sélectionner le prochain morceau de vidéo selon un schéma de résolution/compression qui lui permettrait d'être reçu à temps pour la fin du premier morceau. en jouant.
Cela signifie qu'il y a des indices dans les demandes quant à ce que fait l'utilisateur. Si votre appareil envoie une demande à un site Web toutes les 3 secondes pour demander un fichier qui prend un peu moins de 3 secondes à télécharger, il y a de fortes chances que ce site diffuse de la vidéo. À partir de la taille par durée, vous pouvez faire une estimation raisonnable de la résolution - surtout si vous gardez une moyenne mobile. Vous pouvez alors simplement restreindre la bande passante à cette adresse IP.
En utilisant des adresses IP connues pour les principaux fournisseurs de vidéos (googlevideo (youtube), Netflix, etc.) dans la pondération des décisions, vous pourriez rendre l'algorithme plus agressif sans trop de faux positifs.
La plus grande chose est l'adresse à laquelle vous vous connectez. HTTPS protège les données en vol, mais ne protège pas l'adresse à laquelle vous parlez. Si Verizon connaît les adresses IP des serveurs Netflix, ils peuvent imposer des restrictions sur les flux de données provenant des adresses IP situées dans une certaine plage. Netflix ajustera alors automatiquement sa lecture en fonction de la bande passante disponible.
Il est également largement possible de remarquer en se basant sur des taux de trafic constants inférieurs au maximum possible. Cela signifie probablement un flux multimédia d'un certain type, bien qu'il puisse également s'agir d'un transfert de fichiers à bande passante limitée, il y aurait donc des faux positifs.
Je crois que dans les détails techniques qu'ils ont mentionnés lors de l'annonce des changements, ils prévoyaient simplement d'utiliser les adresses IP pour configurer les limites, mais je ne suis pas sûr si cela changera avec le temps ou si je me souviens même correctement, comme il l'a fait. Cela fait un petit moment depuis l'annonce et je n'ai pas pris de notes sur mes recherches originales à ce sujet.
Si vous utilisez un VPN (approprié) qui valorise la sécurité/la confidentialité plutôt que les performances, il emploiera un tas d'astuces pour tromper toutes les tentatives de votre FAI de vous identifier positivement en tant que vidéo en streaming:
- Le FAI vous verra vous connecter à une adresse IP qui n'est pas reconnue dans le cadre d'un CDN vidéo (par exemple Youtube, etc.) - en supposant que votre VPN n'est pas hébergé par Youtube ou tout autre fournisseur vidéo majeur. Donc, au moins, ils ne pourront pas identifier positivement votre point de terminaison IP distant comme faisant partie d'un CDN vidéo. Note: Bien sûr, ils pourraient décider de le limiter parce que c'est un VPN, mais les principaux fournisseurs ne le font pas, en date du maintenant, déclarez explicitement qu'ils limitent les VPN (ainsi, cela serait extrêmement sournois et classerait les FAI américains dans leur suppression de la liberté d'expression de la même manière que le grand pare-feu de Chine).
- Un bon VPN ne soumet aucune métadonnée en clair (par exemple, QoS) qui indiquerait la nature de votre trafic. Cela peut entraîner des inversions de priorité étranges (comme un téléchargement entraînant un retard dans la VoIP en temps réel ou la vidéo en streaming), mais c'est le prix à payer pour la confidentialité.
- Selon le protocole vidéo de couche application que vous utilisez, il serait difficile, voire impossible, que le FAI identifie positivement le trafic en tant que vidéo à l'aide de l'analyse de la forme du trafic. Par exemple, si le protocole spécifie que le serveur doit envoyer en rafale la vidéo à la bande passante maximale disponible (vitesse de ligne) pour télécharger la plupart/la totalité de la vidéo à la fois au lieu de la pousser progressivement au débit binaire de la vidéo, le FAI n'a aucune idée si vous télécharge un ISO Linux, une vidéo en streaming à partir d'un fournisseur de contenu bien connu comme Youtube ou CBS, ou un gros document Excel pour votre travail.
- Bien que le volume total du trafic VPN reflète à peu près les données réelles envoyées/reçues, de bons VPN jettent des données indésirables (et même introduisent une petite latence dans le trafic légitime) dans le tunnel crypté afin de rendre l'analyse du trafic plus difficile. Plus votre VPN introduit de données indésirables et de latence intentionnelle, plus votre VPN sera lent, mais d'un autre côté, cela améliorera la sécurité si le trafic de votre VPN est très résistant à l'analyse de la forme du trafic.
Cependant, il existe certaines limitations:
- Le type de vidéo en streaming le plus simple à analyser via l'analyse de la forme du trafic est un protocole qui limite le téléchargement de votre vidéo au débit de la vidéo. Sur la base du débit binaire, ils peuvent estimer votre résolution probable.
- La vidéo "en direct" (où le spectateur apprécie de visualiser le contenu très peu de temps après sa génération) est plus difficile à masquer, car vous devez transmettre à proximité du débit vidéo pour garantir une bonne réactivité; la mise en mémoire tampon et l'éclatement des données imposent un retard inhérent au flux que l'utilisateur peut ne pas trouver acceptable (par exemple pour la vidéoconférence, Twitch.TV, etc.)
Bien sûr, afin de garantir que les vidéos ne peuvent pas être diffusées à des qualités supérieures, le FAI pourrait choisir de limiter tout ce que vous téléchargez à un arbitraire débit binaire inférieur à la vitesse de ligne - mais il y a beaucoup de problèmes avec cela:
- Il n'y a pas de débit binaire "typique" bien établi à une résolution particulière, donc ils pourraient faire des hypothèses, mais ce ne serait que cela: des hypothèses. Selon le codec et les paramètres d'encodage, une vidéo 1080p peut varier d'un faible Mbit/s à un chiffre à 50 Mbps et plus.
- Cela deviendrait un "accélérateur de tout" efficace et vous ne renifleriez jamais les vitesses maximales annoncées, conduisant à une fausse responsabilité potentielle en matière de publicité si vous obtenez bien moins que leurs vitesses min/max annoncées et que vous n'avez pas marché sur des mines terrestres dont elles font la publicité comme le déclenchement d'un accélérateur (par exemple le plafond de données haute vitesse typique de 22 Go/mois sur LTE).
- S'ils étranglent tout le monde, ils recevraient beaucoup de réactions de la part d'utilisateurs légitimes qui ne diffusent jamais de vidéo mais qui, comme mentionné précédemment, téléchargent simplement un gros fichier Excel à partir d'un travail via un VPN ou autre.
- En déduisant que le trafic peut être vidéo et en décidant de le limiter sur cette base (même si leurs inférences s'avèrent incorrectes), les utilisateurs sont plus susceptibles de perçoivent leur service comme lent et annulent/migrent vers un autre fournisseur, car le FAI n'annonce pas qu'il limite d'autres types de trafic en plus de la vidéo (sauf si vous dépassez un plafond donné par mois ou si vous vous trouvez sur une tour saturée; les deux ces situations sont cependant assez faciles à exclure en tant que client).
Donc, dans l'ensemble, dans la course aux armements des FAI essayant de détecter le contenu spécifique des utilisateurs et discriminant en fonction de ce que vous téléchargez, l'utilisateur finira par gagner si vous utilisez un bon VPN (et en supposant que le FAI n'a aucun moyen de casser votre cryptographie) . Le FAI ne sera pas en mesure de détecter ce que votre contenu est avec certitude, et les suppositions ne viendront pas avec une très grande probabilité d'être précis.
Je pense que lorsque les utilisateurs commencent à comprendre cela et prennent des mesures pour empêcher les FAI de détecter leur contenu, les FAI répondront en diminuant leurs vitesses annoncées pour tout le monde (pour permettre à plus d'abonnés de partager le même spectre disponible); l'augmentation des prix; éliminer (encore une fois) les forfaits de données illimités; aggravation des pénalités de limitation pour ceux qui dépassent un plafond de données arbitraire (assez faible) par mois; ou ralentir intentionnellement tout trafic qu'ils ne peuvent pas identifier positivement (par exemple, le trafic VPN) et le justifier comme étant du trafic "suspect".
Ils pourraient faire valoir, et de manière convaincante pour les régulateurs, les politiciens et le public ignorant, que la plupart/tout le trafic VPN est des téléchargements illégaux, du commerce illicite (drogues, etc.), et des personnes qui tentent de "briser les règles" et de contourner les restrictions fixées par le FAI. Alors que les experts techniques crieraient au scandale, nous avons tendance à être noyés par ceux qui sont complices du système et heureux de se venger du consommateur pour faire de l'argent rapidement.
Ils pourraient également faire toutes toutes ces choses simultanément. D'après mon expérience avec l'industrie du sans fil aux États-Unis, aussi mauvais que vous le pensez, il est pire. Et plutôt que de choisir uniquement les remèdes les plus bénins à un problème, ils ont tendance à privilégier ceux qui sont au maximum hostiles aux clients, ce qui supprime la liberté d'expression et viole les principes de neutralité du net.
Ils ont également tendance à opposer les utilisateurs les uns aux autres. Ils adoptent des politiques qui incitent les utilisateurs à blâmer et à appeler les autres utilisateurs comme des "porcs de données", plutôt que de travailler ensemble en tant que groupe pour faire pression sur leur fournisseur afin d'étendre l'infrastructure pour répondre à la demande plutôt que d'essayer d'amincir le troupeau pour qu'il corresponde aux ressources actuellement disponibles.
C'est juste la nature humaine, je suppose - c'est pourquoi l'industrie du sans fil doit être réglementée si nous voulons qu'elle soit un élément constitutif cohérent et précieux de la société, semblable à l'électricité et à l'eau courante. Jusque-là, ce n'est qu'une autre variante du PSTN propriétaire byzantin des jours Ma Bell.
Verizon ne reconnaît ni ne bloque LITTÉRALEMENT la vidéo HD cryptée ... mais il a des accords avec des services comme Netflix et Youtube qui les obligent à reconnaître les plages d'adresses IP de Verizon et à respecter les limites imposées par Verizon.
Pour les petits services, je crois que Verizon a une deuxième arme à sa disposition ... Je suis à peu près sûr que quelque part dans le contrat de service client pour les plans "illimités" est une clause qui permet à Verizon de compter le trafic crypté "opaque" contre l'utilisateur limite mensuelle de "partage de connexion". Verizon peut donc ne pas savoir (ou se soucier) que vous diffusez des vidéos HD sur votre téléphone toute la journée à partir de vos caméras de sécurité à la maison, mais ils PEUVENT compter le trafic par rapport à votre limite mensuelle de 5 ou 10 Go (ou le limiter à 150 kbit/s si votre plan n'inclut pas le partage de connexion).