Screen Capture API : contrôle utilisateur et vie privée

BotBrowser peut répéter un parcours getDisplayMedia() autorisé dans un profil déclaré, mais il ne peut pas choisir l'écran d'une personne, masquer les indicateurs du navigateur ni rendre les pixels capturés privés pour la page qui les reçoit. Cet article traite des limites de contrôle et de confidentialité, distinctes de la caméra virtuelle et des limites de permission de Document Picture-in-Picture.

TL;DR

L'accès à Screen Capture API dépend d'un choix de l'utilisateur. Lancez-le depuis une action visible, expliquez ce qui sera partagé, arrêtez chaque piste à la fin et traitez le flux comme des données sensibles. getDisplayMedia() n'est ni une capture d'écran silencieuse, ni une permission éternelle, ni la preuve que la surface capturée est privée.

Contents

• Le contrat de capture
• Une matrice de test respectueuse de la vie privée
• Révocation et arrêt sûr
• Différences avec les API média voisines
• Ce que BotBrowser peut contrôler
• Conclusion pratique

Le contrat de capture

L'application doit appeler navigator.mediaDevices.getDisplayMedia() après une action utilisateur, par exemple un clic, tant que l'activation utilisateur transitoire est encore valide. Un appel depuis un minuteur ou un message en arrière-plan peut renvoyer InvalidStateError. Le navigateur affiche un sélecteur de moniteur, fenêtre ou onglet ; le code ne peut pas choisir une surface en silence. Le MediaStream renvoyé contient des pistes dont le cycle de vie doit rester visible.

Le sélecteur est une limite de contrôle, pas un signal d'identité. NotAllowedError peut signifier annulation, politique ou décision du navigateur. Enregistrez seulement le résultat nécessaire à la récupération de l'interface, pas l'objet complet de capacités, le nom d'écran, le texte du document ou un identifiant persistant.

Les pixels capturés restent des données applicatives. Ne téléversez pas le flux simplement parce que la capture a réussi. Appliquez les contrôles d'accès, la conservation, la rédaction et le consentement comme pour la caméra ou le microphone. L'indicateur du navigateur signale le partage ; il ne rend pas la destination fiable.

Une matrice de test respectueuse de la vie privée

Utilisez un contenu synthétique et un profil neuf par ligne. Gardez explicites l'action, l'origine, les contraintes et l'arrêt.

Ligne	Parcours	Observation attendue	Sens vie privée
A	Cliquer Partager puis annuler	La promesse rejette une erreur bornée	Le choix est refusé ; aucune surface n'est accordée
B	Sélectionner un onglet synthétique	Une piste vidéo et l'UI de partage apparaissent	Les pixels de l'onglet deviennent des données de page
C	Appeler track.stop() depuis Arrêter	La piste finit et l'UI revient au repos	L'application termine volontairement la capture
D	Fermer l'onglet ou révoquer dans le navigateur	ended arrive ou le flux devient inactif	L'utilisateur ou le navigateur a révoqué
E	Demander sans activation	La demande est rejetée	Un script arrière-plan ne peut pas capturer en silence

Un résultat compact peut être {"browser":"Chrome 155","mode":"headed","surface":"synthetic-tab","result":"started","stopped":true,"capturedBytes":null}. Gardez capturedBytes à null sauf mesure privée gouvernée. L'artefact public doit montrer le cycle de vie, pas conserver l'écran.

Révocation et arrêt sûr

Ajoutez des écouteurs ended à chaque piste et un bouton Arrêter visible. L'UI du navigateur, la navigation, la fermeture de l'onglet ou la politique peuvent aussi terminer le flux. Nettoyez les références, retirez l'aperçu et rendez le focus au contrôle initial. Masquer l'aperçu ne stoppe pas la source.

Si vous utilisez un enregistreur, fermez-le avant de libérer le flux et traitez dataavailable comme une sortie sensible. Préférez des fragments courts, une conservation documentée et des fixtures synthétiques. Ne journalisez jamais les images brutes, l'OCR, les données de compte ou les noms d'écran complets.

Différences avec les API média voisines

Les périphériques média et la confidentialité de la caméra virtuelle concernent enumerateDevices(), les permissions caméra/micro et la limite de la liste de périphériques virtuels. Screen Capture n'énumère pas un écran comme périphérique stable et ne le choisit pas en silence : il présente un choix nouveau et renvoie un flux d'affichage.

Les limites de permission de Document Picture-in-Picture créent une fenêtre same-origin gérée par le navigateur. Elles n'exposent pas les pixels d'une autre surface. Screen Capture transfère les pixels choisis dans un MediaStream, donc la minimisation et la révocation sont essentielles.

Ne regroupez pas ces APIs sous une permission média générale. Chacune possède son geste, sa médiation, ses erreurs et sa revue de confidentialité. Une fenêtre Picture-in-Picture ouverte ne prouve pas la capture d'écran, et une caméra virtuelle ne prouve pas le choix du moniteur.

Ce que BotBrowser peut contrôler

BotBrowser peut répéter le bouton visible avec des pages synthétiques, une version déclarée et un profil neuf. Il peut vérifier l'annulation, un onglet de test, track.stop() et l'événement ended. Il ne peut pas choisir l'écran réel d'une personne, contourner le sélecteur, cacher les indicateurs ou garantir le même comportement sur chaque système.

Conclusion pratique

Traitez Screen Capture API comme un flux révocable, contrôlé par l'utilisateur et contenant des données sensibles. Commencez par une action visible, décrivez la surface, utilisez des tests synthétiques, arrêtez chaque piste et ne conservez que des résultats bornés. La limite de confidentialité combine médiation du navigateur, arrêt applicatif et gestion disciplinée des pixels.

Cycle de vie pour le support

Le contrat possède quatre ancrages observables : getDisplayMedia(), MediaStreamTrack.readyState, ended et track.stop(). Notez displaySurface, la valeur Permissions-Policy d'une iframe et la version du navigateur. Un refus ne renvoie aucun MediaStream; une demande démarrée garde une piste live jusqu'à stop() ou ended.

Un test intégré doit séparer les branches de politique. La liste par défaut de display-capture est self, une iframe de même origine peut donc être éligible ; une iframe d'une autre origine a besoin d'une délégation explicite qui nomme le partenaire, par exemple display-capture=(self) example.test. Ne supposez pas qu'une délégation absente entraîne toujours un refus : notez séparément l'origine, la politique déclarée, l'activation et l'état de piste.

Un cycle de vie exploitable par le support.

Le rapport commence avant l'ouverture du sélecteur. Notez le contrôle visible, l'origine de la page, la version du navigateur, la famille du système et le caractère temporaire du profil. Décrivez le résultat attendu simplement : la personne choisit un onglet synthétique, la page reçoit une piste vidéo, l'indicateur reste visible et le bouton Arrêter termine la piste. Le support peut ainsi traiter un signalement « le partage d'écran échoue » sans demander le contenu partagé.

La première issue négative est l'annulation. La personne peut ouvrir le sélecteur puis décider de ne rien partager. Traitez ce choix comme normal, conservez la tâche initiale et donnez une brève explication ; ne rouvrez pas automatiquement le sélecteur. Les relances risquent de transformer un refus délibéré en sollicitations répétées. Un résultat borné tel que cancelled suffit aux métriques agrégées dont la finalité est documentée.

La deuxième issue est l'absence d'activation. Une page ouverte depuis un favori, une minuterie ou un message en arrière-plan ne doit pas lancer le sélecteur sans geste utilisateur actuel. Testez ce cas sur une page synthétique et notez la catégorie du refus. Ne le « corrigez » pas en simulant un clic ou en demandant une permission plus large : proposez un contrôle visible qui explique l'action.

Le chemin positif doit aussi avoir un état final. L'aperçu peut rester visible pendant le flux, mais le masquer n'arrête pas la capture. Regroupez les pistes dans un objet responsable, appelez stop() sur chaque piste audio ou vidéo créée intentionnellement et actualisez le contrôle au changement d'état. Si le navigateur termine une piste en premier, le gestionnaire ended doit exécuter le même nettoyage afin que l'application ne prétende pas que le partage continue.

Réduire les données qui franchissent la limite.

La capture peut inclure des messages privés, des pages de compte, des notifications ou des fenêtres étrangères à la tâche. Le fixture le plus sûr est une page synthétique simple portant une grande mention « surface de test », sans données de compte. Dans un produit réel, expliquez la surface juste avant le sélecteur et limitez le récepteur à la tâche. Ne rognez, masquez ou floutez que si la personne en comprend l'effet : cacher l'aperçu ne retire pas les pixels du flux.

N'envoyez à l'analytique ni MediaStream sérialisé, ni titre d'écran, ni objet complet de capacités, ni images brutes. Un vocabulaire court, requested, cancelled, started, stopped, ended, répond à la plupart des questions de fiabilité. Si un enregistrement est nécessaire, séparez son chemin de données, avec contrôle d'accès, durée de conservation et responsable de suppression. La documentation publique doit employer des exemples synthétiques et laisser nuls les champs contenant du contenu.

Comparer les changements du navigateur avec prudence.

Si une version change le résultat, répétez le même fixture synthétique avant de modifier le code applicatif. Gardez constants l'origine, le mode d'activation, la surface demandée, le cycle du profil et l'arrêt. Comparez le premier champ différent : affichage du sélecteur, création du flux, état de piste, indicateur ou nettoyage. Un simple verdict réussite/échec ne localise pas la limite qui a changé.

Les exécutions avec interface visible et automatisées peuvent différer selon l'affichage, la politique ou le moment de l'activation. Indiquez ces variables dans l'en-tête du résultat ; une observation d'un seul runner ne vaut pas affirmation universelle sur les systèmes. BotBrowser aide à répéter le contexte déclaré, mais le navigateur garde la maîtrise du sélecteur et la personne celle du choix.

Une revue concise de confidentialité.

Avant publication, posez cinq questions : le contrôle est-il visible et accessible au clavier ? Le texte précise-t-il s'il s'agit d'un onglet, d'une fenêtre ou d'un moniteur ? L'annulation préserve-t-elle la tâche ? Chaque sortie arrête-t-elle les pistes et retire-t-elle les aperçus ? Les journaux excluent-ils images, noms d'écran, identifiants de compte et champs de profil sans rapport ? Cette revue tient dans une demande de changement et évite la conservation accidentelle.

La même revue s'applique au support. Demandez la version du navigateur, le résultat visible, la première étape du cycle de vie en échec et si la personne a annulé ou si le navigateur a terminé la piste. Ne réclamez pas l'enregistrement de l'écran d'un client si une reproduction synthétique suffit. Si une preuve privée est indispensable, recueillez le minimum par un canal restreint et supprimez-le selon le calendrier documenté.

Détails d'implémentation qui protègent les personnes.

Conservez le rapport sous forme d'une ligne bornée avec displaySurface, la version du navigateur, la source d'activation et le premier état terminal. Séparez le résultat de la requête de sa cause : un refus de politique ne prouve pas que le navigateur ne prend pas en charge la capture ; une piste live ne prouve pas que conserver ses pixels est sûr.

Placez la requête près du contrôle qui l'explique. « Partager un onglet de test » est plus parlant que « Démarrer », surtout si le produit propose aussi caméra ou micro. Expliquez les cibles possibles et l'ouverture du sélecteur par le navigateur ; ne promettez pas que l'application peut limiter tout ce qui apparaît dans l'onglet choisi. La personne reste responsable du contenu de la surface, l'application du MediaStream reçu.

L'aperçu doit afficher un état clair et un bouton Arrêter utilisable au clavier. « Partage de l'onglet de test sélectionné » vaut mieux qu'un badge uniquement coloré. À la fin de la piste, annoncez le changement et restaurez la tâche. Séparez l'état d'enregistrement de celui du partage : un flux peut être affiché sans être enregistré, ou l'enregistrement s'arrêter alors que l'aperçu reste actif. L'événement ended fournit l'ancrage concret du cycle.

La politique de permissions peut modifier le parcours d'une page intégrée. Une iframe peut ne pas pouvoir demander la capture alors que la page supérieure le peut. Testez les deux cas comme lignes distinctes, notez la politique déclarée et expliquez le refus dans la page. Ne demandez pas d'assouplir une politique globale uniquement pour faire passer un fixture : c'est une décision produit et sécurité avec son propre responsable ; notez la valeur de la politique avec la date.

Le récepteur a lui aussi besoin d'un contrat borné. Si le flux passe par une connexion pair à pair, documentez les pistes envoyées, leur retrait et la notification de fin à l'autre extrémité. Pour un rendu local, placez l'élément d'aperçu sous la même responsabilité que les pistes. Une connexion distante ne justifie pas de conserver des images après Arrêter : ce bouton doit libérer les références locales et terminer la tâche.

Pour la validation automatisée, utilisez une page qui dessine un motif connu et une étiquette de test, pas un bureau ni un compte client. Le runner peut vérifier l'existence d'une piste vidéo, des dimensions non nulles pour l'onglet synthétique et sa fin après Arrêter. Il n'a pas besoin d'inspecter les pixels pour vérifier le cycle. Notez readyState, track.kind et l'heure d'arrêt ; éviter de stocker des images simplifie la gouvernance des artefacts de test.

En cas de refus du navigateur, préservez l'action initiale et proposez une solution compatible : téléversement, export statique ou explication dans la page. Le recours ne doit jamais basculer en silence vers la caméra ou le micro ; chaque source implique une attente distincte et un changement non expliqué dégrade la confidentialité.

Réexaminez la matrice quand le sélecteur change, que la politique évolue ou que l'application ajoute un enregistreur ou un transport distant. Notez date et version du navigateur avec le résultat ; s'il change, indiquez la première ligne touchée et le prochain responsable. Ne généralisez pas d'un onglet synthétique à tous les écrans, fenêtres, comptes ou systèmes.

Lire le résultat sans extrapoler.

Le contrat MediaStream est l'ancrage concret de cette décision de support. Un flux démarré prouve que le navigateur déclaré et le parcours utilisateur ont produit un flux pour cette surface synthétique ; il ne prouve ni la disponibilité d'une autre surface, ni le même résultat pour une autre origine, ni la sûreté de conservation du contenu. Une piste arrêtée prouve le nettoyage de cette piste, pas l'effacement de copies déjà stockées ailleurs. ended prouve que l'application a observé la fin, pas sa cause.

Gardez ces affirmations ensemble dans les notes de version et les traductions : action, résultat observable et limite. Cela évite aussi de confondre les API voisines : la caméra virtuelle décrit un périphérique média, Document Picture-in-Picture une fenêtre de présentation auxiliaire, et Screen Capture un flux d'affichage choisi par la personne. Chacune a son propre contrat de contrôle et de confidentialité.

Sources publiques

• Screen Capture (W3C)
• MediaDevices.getDisplayMedia() (MDN)
• Media Capture and Streams (W3C)
• Documentation des périphériques média BotBrowser