Français

Vidéo et sous-titres · Téléchargeur de vignettes YouTube et visionneuse de métadonnées

Pourquoi "contacts i.ytimg.com et youtube.com" est indiqué avant de coller

· Pourquoi c'est important

youtube confidentialité outils de développement du navigateur

Un panneau réseau affichant les demandes de vignettes et une demande de métadonnées
Illustration vectorielle originale de ToolAcre

La plupart des outils décrivent leur confidentialité dans une page de politique ; celui-ci nomme ses hôtes sur l'outil lui-même. Cet article explique pourquoi la nomination des hôtes dès le départ est importante, comment cela s'adapte à la configuration sans analyse de ToolAcre et comment tenir la promesse de l'outil.

Une promesse de réseau sur une seule ligne : pourquoi les "contacts i.ytimg.com et youtube.com" sont inhabituels

Nommer i.ytimg.com et www.youtube.com avant Fetch donne à un évaluateur informatique une attente concrète au lieu d'une vague promesse en matière de confidentialité. Le premier hôte propose des candidats miniatures ; le second sert l'enregistrement oEmbed. Étant donné que la divulgation apparaît avant le clic, un testeur peut observer la page inactive, coller un lien et décider si les demandes tierces documentées sont acceptables avant le début de toute recherche.

Lisez la déclaration dans sa portée réelle. Il décrit les requêtes initiées par l’opération Fetch de cet outil, et non toutes les polices, scripts, requêtes d’analyse ou fonctionnalités de déploiement qui pourraient exister ailleurs sur une page de production. Un audit utile isole l'action testée et compare son trafic avec les hôtes documentés. Cela ne transforme pas une trace propre en une affirmation à l'échelle d'une page que l'implémentation limitée ne peut pas établir.

Politiques et déclarations que vous pouvez tester : la différence entre une page de confidentialité et un hôte nommé

La source et le manifeste décrivent le comportement prévu ; un enregistrement sur le panneau réseau montre ce qu'un navigateur a réellement envoyé. Utilisez les deux formes de preuves. Le code identifie les URL attendues, les options de requête et les déclencheurs, tandis qu'une trace en direct révèle les extensions, les techniciens de service, les proxys gérés ou la politique du navigateur susceptibles de modifier l'exécution. S’ils ne sont pas d’accord, la différence devient une enquête spécifique plutôt qu’un débat sur des étiquettes générales telles que « local » ou « privé ».

Ouvrez DevTools avant d'interagir, sélectionnez Réseau, effacez les lignes existantes et désactivez la préservation des requêtes afin qu'une navigation antérieure ne contamine pas le décompte. Collez un lien pris en charge et vérifiez que l'analyse locale ne crée aucune recherche Google. Appuyez ensuite une fois sur Récupérer, filtrez par ID vidéo extrait et regroupez ou analysez par nom d'hôte. Capturez les horodatages et les colonnes d’état si la trace prend en charge une révision ou une modification de la liste verte.

Vérifiez les requêtes directes de l'outil sans réclamer un CSP strict à l'échelle de la page ni aucun actif externe.

Ne déduisez pas une politique stricte de sécurité du contenu à l'échelle de la page ou l'absence d'analyses, de publicités, de polices et de scripts externes de ce module. Ces assertions nécessitent des preuves provenant de la page déployée et de ses en-têtes, et non d'un assistant réseau spécifique à l'outil. L'affirmation défendable est plus restreinte : le code de recherche émet des GET publics anonymes à deux hôtes Google nommés après une action explicite de l'utilisateur.

L'itinéraire est direct. Aucun point de terminaison de l'API ToolAcre ne transmet l'ID collé à un serveur, ne récupère la réponse de Google ou ne stocke un historique de recherche. Cela réduit un intermédiaire mais ne supprime pas le tiers : Google reçoit toujours les demandes de vignettes et de métadonnées. Enregistrez ensemble le clic, la destination, le nombre de demandes et la classe de réponse afin que « direct » ne puisse pas être interprété à tort comme « hors ligne » ou « invisible pour Google ».

Pourquoi deux hôtes et non un seul : les images et les métadonnées proviennent de différents services YouTube

Pour une recherche réussie, attendez-vous à huit requêtes i.ytimg.com : maxresdefault, sddefault, hqdefault, mqdefault, default, hq1, hq2 et hq3. ToolAcre lit chaque corps JPEG et décode les dimensions afin qu'un statut réussi portant un espace réservé 120×90 ne soit pas confondu avec l'illustration plus grande demandée. Cinq adresses d'affiche WebP facultatives sont générées sous forme de liens, mais ne sont pas récupérées sous forme de corps de téléchargement lisibles.

Attendez-vous à une requête www.youtube.com/oembed distincte dont la requête contient l'URL de montre canonique et format=json. Son résultat fournit des métadonnées publiques normalisées plutôt que la disponibilité des images. Toutes les demandes omettent les informations d'identification et le référent, demandent le non-stockage et suivent les redirections ; Google les voit ainsi que l'en-tête Origin du navigateur. Ces options décrivent le comportement du client, et non les garanties d'anonymat ou la politique de rétention côté serveur.

Exemple concret : une requête par vignette JPEG plus une recherche oEmbed

Une exécution propre contient donc neuf requêtes de recherche : huit sondes JPEG et un appel oEmbed. Ouvrez une ligne JPEG disponible et vérifiez ses dimensions de réponse par rapport au résultat de l'outil. Cliquez ensuite sur le contrôle de téléchargement de cette ligne. La sauvegarde doit réutiliser le Blob retenu lors du sondage, donc aucune deuxième demande d’image ne doit apparaître. Une demande en double à ce moment-là contredirait le comportement prévu de réutilisation du Blob et mériterait une enquête.

Gardez les liens distincts des demandes lors du comptage. Copier une URL WebP ou l'afficher sous forme de texte ne signifie pas que ToolAcre a récupéré ses octets, et le chemin vi_webp ne dispose pas de l'en-tête de réponse multi-origine nécessaire pour un téléchargement de blob JavaScript. Le rendu de l'iframe généré avec protection de la vie privée est également en dehors de cette trace de recherche : il contacte youtube-nocookie.com plus tard, lorsqu'une autre page ou un autre aperçu charge l'intégration copiée.

Ce que ceci ne couvre pas : l'outil ne peut pas parler au nom des propres règles ou politiques de YouTube en matière de journalisation.

Classez les échecs plutôt que de les aplatir. En mode hors ligne, une extension ou un proxy peut arrêter le transport avant qu'une réponse HTTP n'existe. Une image peut renvoyer 404, un autre état d'erreur, un espace réservé 200 ou des octets qui ne parviennent pas à décoder. Les métadonnées peuvent échouer en raison d'une interruption du réseau, d'un refus HTTP ou d'un JSON invalide. Conservez ces distinctions dans les captures d'écran ou les notes HAR, car chacune suggère une explication et un suivi différents.

La trace ne peut pas révéler la politique interne de Google en matière de journalisation, de conservation ou de corrélation. Il ne peut pas non plus rendre disponible du matériel privé, supprimé ou soumis à une limite d'âge. Un échec de recherche restreinte est un comportement de déconnexion attendu, tandis qu'une recherche publique réussie ne prouve que ce que cet environnement a reçu à ce moment-là. Aucun des deux résultats ne valide les droits de réutilisation, ne prédit la disponibilité future ou n'établit un comportement universel pour d'autres classes de vidéo.

À retenir : moins de promesses, toutes vérifiables – comment le téléchargeur de vignettes et la visionneuse de métadonnées YouTube indique et conserve son comportement réseau

La transparence du réseau fonctionne lorsque la promesse est suffisamment petite pour être falsifiée : l'analyse est locale avant Fetch, puis un clic explicite démarre la vignette directe et les requêtes oEmbed vers les hôtes divulgués. Si DevTools affiche une requête API ToolAcre contenant des données de recherche, le comportement observé est en conflit avec la revendication d'implémentation. Si le nombre de demandes diffère, inspectez les tentatives, les techniciens de service, les redirections et les actions des utilisateurs avant de décider si le produit ou la configuration de test en est responsable.

Lorsque le panneau affiche les neuf requêtes attendues et aucun proxy de recherche, conservez la trace en tant que preuve datée et spécifique à l'environnement. Incluez la version du navigateur, les extensions ou le contexte du réseau géré si le résultat éclaire la politique. Répétez après un déploiement significatif ou des modifications de dépendances plutôt que de traiter une ancienne capture comme une preuve permanente. La conclusion la plus forte reste exacte : ce navigateur a effectué la recherche documentée sur cette exécution, avec ces hôtes, options et réponses.