Gestion sûre des URL externes pour les profils

Les systèmes d'exploitation permettent aux applications d'enregistrer des schémas d'URL personnalisés, et une page peut parcourir une liste comme slack://, vscode:// ou zoommtg:// pour découvrir quel logiciel de bureau l'internaute a installé. BotBrowser configure ce traitement selon le profil retenu, mais il ne peut pas inventorier les applications de l'hôte et ne transforme pas un schéma non documenté en schéma pris en charge.

Résumé

• Une page parcourt une liste de schémas en pointant un iframe masqué vers chacun et en lisant la suite : le délai de chargement, un événement blur quand un gestionnaire prend le focus, ou la fenêtre vide que laisse window.open().
• Ces écarts décrivent le poste de travail et non le réseau, donc ni le VPN ni la navigation privée ne changent le résultat, car l'enregistrement du protocole se trouve dans le système d'exploitation.
• BotBrowser maintient le traitement des URL externes sur le profil sélectionné : dans un contexte ciblant Android, un schéma non pris en charge comme vscode:// ne passe pas à une application installée sur le worker.
• La validation tient à deux résultats dans le même contexte : un lien https:// ordinaire aboutit dans le navigateur et le schéma non pris en charge ne produit pas d'inventaire logiciel du worker.

Sommaire

• Pourquoi les URL externes exigent une politique
• URL externes et vie privée
• Limites des contrôles du profil
• Gestion alignée sur le profil
• Attribuer la politique du profil
• Valider, déployer et accompagner le déploiement
• Conclusion pratique

Pourquoi les URL externes exigent une politique

Lorsqu'une application comme Slack, VS Code, Zoom ou Steam est installée, elle enregistre un protocole (comme slack://, vscode://, zoommtg:// ou steam://) qui permet à d'autres applications et sites web de la lancer directement via une URL. Ce système alimente les liens profonds, permettant à un site web d'ouvrir une vue spécifique d'une application, de rejoindre une réunion ou de lancer un jeu via un simple clic sur un lien. Une navigation explicitement approuvée par l'utilisateur ou par un flux de travail reste également hors du périmètre de BotBrowser, qui ne la bloque pas.

Cependant, le mécanisme qui rend les gestionnaires de protocole utiles en fait aussi une surface de fingerprinting. Les sites web peuvent tenter de naviguer vers des URL de protocole personnalisé et observer la réponse du navigateur. Le comportement diffère selon que l'application associée au protocole est installée : le navigateur peut afficher une invite pour ouvrir l'application, rediriger silencieusement, afficher une erreur, ou simplement ne rien faire. En testant une liste de schémas de protocole connus, un site web peut construire un profil des applications installées sur l'appareil du visiteur, créant une empreinte hautement distinctive.

Impact sur la vie privée

La détection d'applications basée sur les protocoles est l'une des techniques de fingerprinting les plus invasives pour la vie privée car elle révèle des informations sur l'environnement logiciel de l'utilisateur plutôt que sur son matériel. Alors que les empreintes matérielles identifient l'appareil, les empreintes d'applications identifient la personne et ses activités. Les polices sont un autre signal de l’environnement logiciel : pour savoir comment la disponibilité des polices, le comportement de repli et les métriques de texte révèlent les traits d’une plateforme, consultez Qu'est-ce que l'empreinte des polices ? Cohérence du texte, qui explique comment garder un texte cohérent d’un hôte à l’autre.

Les implications pour la vie privée sont significatives :

• Inventaire logiciel : en testant les gestionnaires de protocole courants (Spotify, Discord, Telegram, WhatsApp, Steam, Epic Games, Zoom, Teams, VS Code, Sublime Text, et des dizaines d'autres), un site web peut déterminer quelles applications sont installées.
• Profilage comportemental : les applications installées révèlent les intérêts, la profession et les schémas de comportement. Un développeur avec vscode://, iterm2:// et docker:// présente un profil différent d'un joueur avec steam://, epicgames:// et discord://.
• Unicité de l'appareil : la combinaison spécifique d'applications installées est hautement unique. Même parmi les appareils avec un matériel identique, l'ensemble logiciel installé varie dramatiquement entre les utilisateurs.
• Pistage inter-navigateurs : les gestionnaires de protocole sont enregistrés au niveau du système d'exploitation, pas au niveau du navigateur. Cela signifie que la même empreinte d'application persiste à travers tous les navigateurs sur l'appareil.

Une étude marquante de 2021 par FingerprintJS a démontré que le fingerprinting basé sur les protocoles pouvait tester 32 applications populaires en quelques secondes, produisant une empreinte qui identifiait uniquement 95% des sujets de test.

La technique est particulièrement préoccupante car elle ne nécessite aucune permission et peut être effectuée silencieusement. Il n'y a aucune notification à l'utilisateur que ses applications installées sont sondées.

URL externes et vie privée

Comment fonctionne la détection de protocole

La détection de protocole exploite le comportement du navigateur lors de la navigation vers une URL avec un schéma personnalisé inconnu ou enregistré. Plusieurs techniques ont été développées :

Méthode de navigation par iframe : un site web crée un iframe caché et définit son src vers une URL de protocole personnalisé (par ex. slack://open). Si Slack est installé, le navigateur tente de gérer la navigation. Sinon, l'iframe reçoit une erreur.

Méthode de fenêtre popup : ouvrir un window.open() vers une URL de protocole personnalisé produit un comportement différent selon l'enregistrement du gestionnaire.

Détection focus/blur : lorsqu'un gestionnaire de protocole lance une application externe, la fenêtre du navigateur perd le focus. En surveillant les événements blur et focus, un site web peut détecter si une application a été lancée avec succès.

Détection basée sur le timing : le temps pris par le navigateur pour traiter une navigation de protocole varie selon qu'un gestionnaire existe. Les gestionnaires installés produisent une réponse plus rapide ou plus lente (selon le navigateur) que les protocoles non enregistrés, et cette différence de timing est mesurable.

Comportement propre à chaque navigateur

Les navigateurs ne traitent pas les schémas inconnus de la même façon :

• Chrome : affiche une boîte de dialogue qui demande si l'utilisateur veut ouvrir l'application pour un gestionnaire connu, et n'affiche rien ou une erreur minimale pour un schéma inconnu. La présence de cette boîte se détecte par programme.
• Firefox : affiche sa propre boîte de dialogue pour les protocoles enregistrés et une page d'erreur pour les autres.
• Safari : a mis en place des mesures qui limitent le sondage, mais la détection par le timing fonctionne encore dans certains cas.
• Edge : comportement proche de Chrome, avec des invites de protocole supplémentaires.

Le problème de l'inondation de schémas

En 2021, des chercheurs ont démontré une technique appelée "scheme flooding" qui exploitait les gestionnaires de protocole pour identifier de manière fiable les utilisateurs à travers plusieurs navigateurs sur le même appareil. La technique impliquait de tester des dizaines de schémas de protocole en succession rapide et de mesurer le motif de réponse.

Défis de normalisation du timing

Le cœur du problème est le temps de traitement. Quand le navigateur traite une navigation vers un schéma personnalisé, il consulte d'abord le registre de l'OS, puis prépare le lancement de l'application ou l'affichage d'une invite si un gestionnaire existe, et bascule sinon vers un état d'erreur. Ces deux derniers chemins n'ont pas la même durée, et cet écart constitue le signal principal. Même lorsque l'interface visible est unifiée, le temps de traitement sous-jacent reste souvent différent.

Listes d'applications testées

Les scripts de fingerprinting testent couramment des familles entières de schémas : communication (slack://, discord://, telegram://, whatsapp://), développement (vscode://, sublime://, docker://), jeu (steam://, epicgames://), productivité (notion://, evernote://), média (spotify://, vlc://, figma://) et réunion (zoommtg://, msteams://, webex://). Chaque schéma supplémentaire ajoute de l'entropie, et 30 à 40 schémas suffisent à produire une combinaison suffisamment distincte.

Limites des contrôles du profil

VPN et serveurs proxy

Les VPN n'ont aucun effet sur la détection des gestionnaires de protocole. L'enregistrement de protocole est une propriété locale du système d'exploitation, et la détection se produit entièrement dans le navigateur. Le routage est une question distincte : pour la politique de routes au niveau du navigateur, consultez PAC Request Policy pour un routage cohérent, qui couvre la politique PAC, les garde-fous et la validation.

Navigation privée et mode incognito

Les modes de navigation privée n'altèrent pas l'enregistrement des gestionnaires de protocole. Les mêmes applications sont installées en mode privé qu'en fenêtre normale, car les gestionnaires de protocole sont enregistrés au niveau du système d'exploitation. Pour d’autres signaux d’environnement que BotBrowser aligne sur le profil choisi, consultez Signaux de mémoire et de stockage des profils, qui couvre le quota de stockage, les limites du tas JavaScript et la mémoire de l’appareil.

Extensions de navigateur

Les extensions peuvent tenter d'intercepter la navigation de protocole, mais bloquer la navigation crée un comportement lui-même observable, et le délai de l'interception de l'extension est lui-même détectable.

Mitigations des navigateurs

Les navigateurs modernes ont implémenté certaines protections : Chrome a ajouté la limitation du taux pour les vérifications de gestionnaires de protocole, Safari a implémenté des politiques de même origine plus strictes, et Firefox a ajouté des exigences de geste utilisateur.

Gestion alignée sur le profil

BotBrowser aligne le comportement des URL externes sur le profil sélectionné afin que les applications locales ne modifient pas le comportement attendu.

Normalisation du timing

BotBrowser normalise le timing du traitement de la navigation de protocole de sorte que les protocoles enregistrés et non enregistrés produisent des signatures de timing indistinguables :

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Réponse comportementale uniforme

Au-delà du timing, BotBrowser garantit que le comportement observable (états d'erreur, événements focus/blur, statut de l'iframe) est cohérent pour toutes les tentatives de navigation de protocole. Le navigateur ne révèle pas si un gestionnaire existe par un canal comportemental quelconque.

Liens de protocole légitimes

La protection ne bloque pas toute navigation de protocole. Lorsqu'un utilisateur ou un script d'automatisation suit explicitement un lien de protocole dans un flux de travail normal, la navigation aboutit. Seul le comportement de sondage, c'est-à-dire l'énumération rapide de gestionnaires par le timing et le comportement, est neutralisé.

Intégration au profil

La protection des gestionnaires de protocole fait partie du profil d'empreinte plus large. Elle fonctionne avec l'identification de l'OS, les signaux de version du navigateur et les autres comportements propres à la plateforme pour maintenir une identité cohérente :

chrome --bot-profile="path/to/profile.enc" \
       --bot-noise-seed=42 \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --user-data-dir="$(mktemp -d)"

Pas de fuite de l'environnement hôte

La garantie clé est que les applications installées de la machine hôte ne fuient pas à travers les requêtes de gestionnaires de protocole. Que l'hôte ait Slack, Steam, VS Code, ou aucune application personnalisée installée, le comportement des gestionnaires de protocole est contrôlé par le profil, pas par l'environnement hôte.

URL externes dans la version actuelle

Les contextes ciblant Android gardent les URL externes non prises en charge isolées des applications du bureau. La navigation web standard continue dans le contexte. Les applications installées sur un worker de bureau ne déterminent donc pas le comportement du profil mobile.

Cette politique appartient au contexte. Après un changement de plateforme ou de profil, créez un nouveau contexte. Validez le parcours web approuvé et confirmez qu'une URL externe non prise en charge n'ouvre pas une application du bureau.

Attribuer la politique du profil

Utilisation CLI de base

La protection des gestionnaires de protocole est automatique lors du chargement d'un profil :

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Intégration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: ['--bot-profile=path/to/profile.enc'],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  await page.goto('https://example.com');
  // Les requêtes de gestionnaires de protocole produiront des réponses uniformes
  // indépendamment des applications installées de la machine hôte
  await browser.close();
})();

Intégration Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: ['--bot-profile=path/to/profile.enc'],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  // Les signaux de gestionnaires de protocole sont contrôlés par le profil
  await browser.close();
})();

Combiné à la protection de l'identité applicative

Un lien externe n'est qu'une surface parmi d'autres. Combinez la politique de protocole avec les signaux d'identité de l'application pour que le contexte reste cohérent : un profil Android sur un worker Linux doit garder les schémas non pris en charge dans le contexte alors que l'en-tête User-Agent, la locale et le fuseau horaire décrivent le même appareil mobile.

chrome --bot-profile="path/to/profile.enc" \
       --bot-timezone="Europe/London" \
       --bot-locale="en-GB" \
       --user-data-dir="$(mktemp -d)"

Valider, déployer et accompagner le déploiement

Valider le comportement de l'application

Après le lancement de BotBrowser avec un profil, vérifiez la protection des gestionnaires de protocole :

// Test protocol handler timing consistency
async function testProtocolTiming(protocol) {
  const start = performance.now();
  const iframe = document.createElement('iframe');
  iframe.style.display = 'none';
  document.body.appendChild(iframe);

  return new Promise(resolve => {
    iframe.onload = () => {
      resolve(performance.now() - start);
      document.body.removeChild(iframe);
    };
    iframe.onerror = () => {
      resolve(performance.now() - start);
      document.body.removeChild(iframe);
    };
    iframe.src = `${protocol}://test`;
    setTimeout(() => {
      resolve(performance.now() - start);
      if (iframe.parentNode) document.body.removeChild(iframe);
    }, 500);
  });
}

// Both registered and unregistered protocols should
// produce similar timing
const timing1 = await testProtocolTiming('slack');
const timing2 = await testProtocolTiming('nonexistentprotocol12345');
console.log('Slack timing:', timing1);
console.log('Unknown protocol timing:', timing2);
console.log('Difference:', Math.abs(timing1 - timing2));

Points de vérification :

1. Les différences de timing entre les protocoles connus et inconnus sont minimales (dans la plage de bruit)
2. Aucun événement focus/blur n'est déclenché par les sondes de protocole
3. Les pages de test de détection de protocole (comme SchemeFlood.com) montrent des résultats uniformes
4. Les applications installées de la machine hôte ne sont pas détectables via les requêtes de protocole

Mesures de déploiement

1. Utilisez des profils complets. La protection des gestionnaires de protocole fonctionne mieux dans le cadre d'un profil complet qui contrôle toutes les surfaces d'empreinte de manière cohérente.

2. Testez contre les méthodes de détection connues. Visitez les pages de test de fingerprinting par protocole pour vérifier que votre configuration ne divulgue pas d'informations sur les applications installées.

3. Combinez avec d'autres protections. La détection de gestionnaires de protocole est souvent utilisée aux côtés du fingerprinting Canvas, WebGL et polices. Utilisez un profil complet pour garantir que tous les vecteurs sont couverts.

4. Gardez les profils à jour. À mesure que les navigateurs implémentent de nouvelles mitigations et que les techniques de détection évoluent, des profils mis à jour garantissent une protection continue.

Questions sur les URL externes

La détection de protocole peut-elle identifier des versions spécifiques d'application ?

Généralement non. La détection de gestionnaires de protocole révèle si une application est installée, pas quelle version. Cependant, certaines applications enregistrent des schémas de protocole spécifiques à la version.

La détection de protocole fonctionne-t-elle sur tous les systèmes d'exploitation ?

La technique fonctionne sous Windows, macOS et Linux, mais le comportement spécifique varie par système d'exploitation. Les gestionnaires de protocole Windows sont enregistrés dans le Registre Windows. macOS utilise les déclarations Info.plist dans les bundles d'applications. Linux utilise les fichiers .desktop. BotBrowser normalise le comportement indépendamment du système d'exploitation hôte.

Les sites web peuvent-ils détecter la protection des gestionnaires de protocole ?

Une interception JavaScript peut ajouter un comportement propre à la page. BotBrowser applique la politique choisie de manière cohérente dans le contexte.

Cela casse-t-il les liens de protocole légitimes ?

Non. La protection de BotBrowser cible le comportement de sondage utilisé pour le fingerprinting, pas la navigation de protocole légitime. Lorsqu'un utilisateur ou un script suit explicitement un lien de protocole dans le cadre d'un workflow normal, la navigation fonctionne normalement.

Combien de protocoles peuvent être testés dans un script de fingerprinting ?

La quantité varie selon le site et ne constitue pas une cible utile de déploiement. Validez le résultat de l'application et conservez l'attribution du profil pendant la version.

Est-ce la même chose que l'attaque « scheme flooding » ?

Le scheme flooding est une technique publiée en 2021 pour relier un même appareil à travers plusieurs navigateurs. Le problème est plus large : tout écart observable dans le traitement des URL externes peut servir de signal. La politique de profil agit sur le comportement de traitement, pas sur une seule technique nommée.

Les navigateurs mobiles prennent-ils en charge la détection de protocole ?

Sur mobile, les schémas non pris en charge restent généralement dans le contexte et n'ouvrent pas d'application de bureau, ce qui limite le sondage au niveau du poste. La navigation web standard continue de fonctionner.

Quel rôle joue registerProtocolHandler() ?

L'API registerProtocolHandler() permet à un site de s'enregistrer comme gestionnaire d'un schéma. C'est une question distincte de la détection des applications installées. BotBrowser contrôle les deux surfaces dans le cadre du profil.

Accompagner le déploiement

Élargissez le déploiement par groupe une fois les deux chemins conformes. Gardez la révision --bot-profile et la version de navigateur précédentes disponibles tant que tous les groupes n'ont pas rapporté le même résultat. Les enregistrements de support doivent contenir la version du navigateur, la famille de profil, la plateforme cible, l'affectation de contexte, le chemin applicatif et le résultat ; ni l'historique de navigation complet ni l'inventaire des applications du poste ne sont nécessaires.

Maintenir la cohérence de la plateforme

Les URL externes peuvent révéler des informations sur l'environnement de bureau. BotBrowser aligne leur traitement sur la plateforme sélectionnée. Les contextes Android séparent les URL non prises en charge des applications du bureau tout en conservant la navigation web. Consultez la documentation Android.

Conclusion pratique

Commencez par la frontière de plateforme, car elle change l'aspect d'une vérification réussie. Sur un worker Linux, un contexte ciblant Android doit garder slack:// à l'intérieur du contexte du navigateur pendant que https:// continue de charger, et un contexte de bureau peut conserver sa propre voie de gestionnaire approuvée. Inscrivez ce couple à côté de la révision --bot-profile et de la plateforme cible déclarée, afin que la revue suivante compare des données comparables.

Ensuite, testez le couple et non l'inventaire logiciel. L'exemple d'iframe ci-dessus mesure le temps écoulé jusqu'à load, error ou le rappel de délai d'attente, et comparer un schéma connu à nonexistentprotocol12345 indique si les deux chemins diffèrent encore sur le worker. Un résultat uniforme accompagné d'une navigation https:// qui fonctionne constitue la preuve attendue pour une sortie ; la liste des applications installées sur le worker ne l'est pas et n'a pas sa place dans le registre de déploiement.

Gardez une unité de retour arrière réduite. Si une actualisation de profil laisse un schéma non pris en charge atteindre une application de bureau depuis un contexte ciblant Android, restaurez ensemble la version de navigateur et la révision de profil déjà revues, rejouez les deux vérifications, puis élargissez le déploiement seulement après.

Sources

• Documentation BotBrowser : émulation Android
• MDN : Navigator.registerProtocolHandler()
• Chromium : gestionnaires de protocoles externes