Maintenir Clearcote à jour

Sans clé de licence, chaque version du SDK est épinglée sur un build ouvert dont le SHA-256 est vérifié, et la mise à jour se fait par une simple montée de version du package. Avec une clé, le SDK récupère le build sous licence actuel à chaque lancement — aucune montée de version nécessaire.

Builds disponibles

Les versions majeures de Chromium que nous livrons actuellement ou sur lesquelles nous travaillons, et quand chaque offre les reçoit :

Utilisateurs du SDK (recommandé)

Mettez le package à jour comme n’importe quelle autre dépendance :

npm i clearcote@latest          # Node
pip install -U clearcote        # Python
dotnet add package Clearcote    # .NET (adds or updates to the newest version)

Au prochain launch(), le SDK constate que le build dont il a besoin n’est pas en cache, le télécharge — le build ouvert depuis GitHub Releases, le build sous licence depuis clearcotelabs.com — et vérifie son SHA-256 avant de l’utiliser. Rien ne s’exécute sans vérification. Chaque build est mis en cache séparément dans le répertoire de cache de votre utilisateur — %LOCALAPPDATA%\clearcote\Cache sous Windows, ~/.cache/clearcote sous Linux (définissez CLEARCOTE_CACHE pour le déplacer) — si bien que chacun n’est téléchargé qu’une seule fois. Les anciens builds sont conservés jusqu’à ce que vous lanciez clearcote clear-cache.

Plusieurs programmes, un seul cache

Les programmes qui partagent le cache installent un build à tour de rôle (SDK 0.41.0+, en Python, Node comme en .NET) : le premier le télécharge, les autres attendent puis l’utilisent, et un build qu’exécute un autre programme n’est jamais remplacé sous ses pieds. Un programme qui attend abandonne au bout de 30 minutes avec un message qui nomme le processus détenant l’installation (le verrou est le fichier .install-lock du dossier de cache de ce build ; le message indique quand il peut être supprimé sans risque). Un verrou laissé par un programme qui a planté est repris automatiquement.

Un build en cache dont les fichiers ont été endommagés ou supprimés (une mise en quarantaine par un antivirus, un dossier supprimé) est réparé au lancement suivant par un seul téléchargement. Si ses fichiers sont encore utilisés, le lancement s’arrête immédiatement et vous demande de fermer tous les programmes qui utilisent ce navigateur, puis de réessayer. Le verrou exige que chaque processus partageant le cache utilise le SDK 0.41.0 ou plus récent ; les versions plus anciennes ne l’attendent pas.

Windows : certaines configurations ne peuvent pas démarrer un build téléchargé là où il se trouve, par exemple un programme exécuté dans une application empaquetée (MSIX), dont Windows redirige les écritures dans %LOCALAPPDATA% (le lancement échoue avec spawn UNKNOWN ou "the side-by-side configuration is incorrect"). Dans ce cas, le SDK crée une copie du build dans ~/.clearcote/recovered, et chaque lancement ultérieur depuis Python, Node ou .NET l’utilise : rien ne reste dans le dossier temporaire, et les lancements suivants démarrent en quelques secondes (Python et Node à partir de la 0.40.1, .NET à partir de la 0.41.0). clearcote clear-cache supprime aussi ces copies ; le SDK .NET n’a pas de ligne de commande, appelez-y donc WinLaunch.ClearRecovered().

Mettre à jour le build ouvert sans mettre à jour le SDK

Sans clé, activez la mise à jour automatique pour prendre le build ouvert le plus récent publié sur GitHub au lieu de celui qu’épingle le SDK. Il est vérifié avec le SHA256SUMS.txt de cette version (et avec la clé de signature si gpg est installé) ; si GitHub est injoignable, le SDK se rabat sur le build épinglé. Depuis un shell, clearcote update fait la même chose. Avec une clé, cela ne change rien — vous obtenez déjà le build sous licence actuel.

import { launch } from "clearcote";
await launch({ autoUpdate: true });   // or set env CLEARCOTE_AUTO_UPDATE=1

Le navigateur lui-même ne contacte jamais son éditeur et ne se met jamais à jour tout seul. Sans clé, le navigateur ne change que lorsque vous montez la version du SDK ou activez autoUpdate. Avec une clé, le SDK récupère chaque nouveau build sous licence au lancement suivant ; avec Pro, vous pouvez conserver un build donné grâce à version.

Choisir un build

Passez version (ou définissez CLEARCOTE_BROWSER_VERSION) : "latest", une version majeure comme "154", une version exacte "154.0.8037.57" ou une révision sous licence "r36" / "154.0.8037.57-r36". Avant tout téléchargement, une version ou une majeure est vérifiée auprès du catalogue publié, et une révision auprès du serveur de licences. releaseChannel: "preview" (release_channel en Python, ou CLEARCOTE_RELEASE_CHANNEL=preview) prend un build preview lorsqu’il en existe un. Sur le build sous licence, les anciens builds, l’épinglage et le canal preview sont des fonctionnalités Pro — les clés gratuites obtiennent toujours la dernière version.

clearcote install --version 154        # fetch + verify a build ahead of time
clearcote install --channel preview     # the newest preview build (Pro)
clearcote info                          # what's installed and cached, and your key
clearcote clear-cache                   # delete cached builds

Utilisation directe / Docker

• Binaire direct (build ouvert uniquement — le build sous licence s’exécute via le SDK, clearcote serve ou l’image Docker) : téléchargez la nouvelle archive depuis la page Releases, vérifiez la somme de contrôle + la signature (voir Vérification), puis faites pointer executable_path / executablePath (ou CLEARCOTE_BINARY) vers le nouveau chrome.
• Docker : docker pull teamflatearth/clearcote pour obtenir la dernière image, puis recréez votre conteneur. Les clés gratuites nécessitent une image construite à partir du SDK 0.30.0 ou plus récent. Avec une clé, montez -v clearcote-cache:/opt/xdg-cache pour que le build sous licence ne soit téléchargé qu’une fois, et non dans chaque nouveau conteneur. Voir Déploiement.

Le build sous licence — toujours à jour, et en premier

Le build sous licence suit le dernier Chromium et les patchs les plus récents : vous recevez les mises à jour sans recompiler vous-même. Définissez CLEARCOTE_LICENSE_KEY, passez licenseKey ou lancez clearcote login (Python/Node ; npx clearcote login pour une installation npm locale) — la commande vérifie la clé et l’enregistre dans ~/.clearcote/license.key, que lisent tous les SDK, .NET compris. Il existe deux façons d’obtenir une clé :

• Gratuit avec GitHub — un navigateur à la fois, sans frais. Connectez-vous avec un compte GitHub qui existe depuis au moins 30 jours, ouvrez « Licenses » dans votre tableau de bord, cliquez sur « Connect GitHub and get it free », puis sur « Claim my free key » (une par compte GitHub). La clé est valable 30 jours ; renouvelez-la gratuitement depuis la même page avant son expiration.
• Pro — le même build avec jusqu’à 250 navigateurs à la fois, les anciens builds, l’épinglage de version et le canal preview, plus un support par e-mail assuré par le propriétaire du projet.

Les nouvelles versions majeures arrivent d’abord sur le build sous licence. Dès qu’une nouvelle majeure de Chromium est compilée, elle est disponible immédiatement sur Gratuit avec GitHub et Pro ; le build ouvert la reçoit plus tard — avec pour objectif environ 2 mois après la sortie (il est aujourd’hui sur Chromium 150). Le build ouvert reste toujours entièrement ouvert et reproductible ; le build sous licence reçoit la plus récente plus tôt.

Comment les navigateurs sous licence sont comptés

Chaque navigateur démarré avec une clé prend un slot auprès du serveur de licences et le rend à sa fermeture. Votre tableau de bord indique combien de slots sont utilisés, et clearcote info affiche le même décompte.

• Gratuit avec GitHub compte chaque navigateur. Un seul slot : un deuxième navigateur — dans le même programme, dans un autre programme ou sur une autre machine — est refusé avec The free tier runs one browser at a time, and one is already running tant que le premier n’est pas fermé. Un navigateur qui a planté sans se fermer libère son slot dans un délai de 6 minutes.
• Pro compte les machines et couvre jusqu’à 250 navigateurs à la fois. Tous les navigateurs d’une même machine partagent le slot de cette machine. Les abonnements souscrits avant le 26 septembre 2026 conservent leurs conditions précédentes, sans plafond ; s’il vous en faut plus de 250, demandez-le et nous relèverons la limite.
• Les clés gratuites nécessitent le SDK 0.30.0 ou plus récent (Python, Node et .NET), car pour compter chaque navigateur, le SDK doit signaler chaque lancement et maintenir la licence à jour tant que ce navigateur tourne. Un SDK plus ancien reçoit SDK_UPGRADE_REQUIRED avec la commande de mise à jour, et un SDK plus ancien qui atteint malgré tout le moteur y est refusé. Les clés Pro fonctionnent avec les anciens SDK, comme avant.
• Un navigateur gratuit s’arrête quand son slot disparaît. La vérification est continue, pas seulement au démarrage : si la clé est révoquée, si le slot est restitué ailleurs ou si la licence dépasse sa limite, un navigateur gratuit déjà ouvert s’arrête en 2 à 3 minutes environ. Les courtes coupures réseau (un ou deux heartbeats manqués) sont absorbées ; une panne de plus de 2 à 3 minutes environ arrête un navigateur gratuit de la même façon.
• L’offre gratuite exécute toujours le dernier build. Demander un ancien build sous licence ou le canal preview renvoie FREE_LATEST_ONLY ; l’épinglage d’un build est une fonctionnalité Pro.
• Téléchargements avec une clé gratuite : jusqu’à 10 builds différents par période de 24 heures. Un même build ne compte qu’une fois, quel que soit le nombre de lancements.

pip install -U clearcote          # Python 0.30.0+
npm i clearcote@latest            # Node 0.30.0+
dotnet add package Clearcote      # .NET 0.30.0+

Ce qui change lors d’une mise à jour

La plupart des versions du SDK ne changent rien qui demande une action de votre part. Celles-ci modifient le comportement d’une configuration existante ; chaque version est listée sous « Releases » dans votre tableau de bord.

• Build sous licence 154 r36, une seed existante : une seed tire désormais sa carte graphique d’un éventail de modèles réels du fabricant de GPU de la machine elle-même, et non plus d’un seul modèle par fabricant ; la plupart des seeds annoncent donc une autre carte que sur la r35. Sur une machine équipée d’une carte NVIDIA, une seed qui annonçait du matériel d’entrée de gamme (4 à 6 threads de processeur, 4 à 8 Go de mémoire, un petit écran) annonce désormais du milieu de gamme ou mieux, et aucune seed n’y annonce d’écran tactile. Pour conserver les identités qu’avaient vos seeds avant la r36, définissez persona_schema=2 / personaSchema: 2. Voir la même seed sur des machines différentes.
• Build sous licence 154 r36, cookies tiers : le navigateur les autorise désormais par défaut, comme le fait Chrome, y compris lorsqu’un SDK plus ancien ou votre propre lanceur ne passe aucune option de cookies. --block-third-party-cookies les bloque.
• 0.42.0, hôtes Linux : le WebGL d’une persona Linux est désormais rendu par Mesa via EGL en mode headed comme en headless (l’hôte a besoin de libegl1), si bien que la chaîne renderer, la liste d’extensions et les limites WebGL d’une persona Linux en headed changent une fois, pour prendre la forme que montraient déjà les lancements headless et que rapportent la plupart des vraies machines Linux. Un lancement headed sous Xvfb sans gestionnaire de fenêtres s’ouvre ajusté à l’écran. Les lancements headless conservent un affichage réaliste même lorsqu’une persona ne prend pas effet, et serve() le conserve quand vous ne passez que --window-position. Voir Playwright & Puppeteer.
• Build sous licence 154 r34 et plus récent, disableGpuFingerprint : il ne change désormais que ce que rapporte le GPU. La relecture des pixels WebGL conserve le bruit par site de la seed, si bien que readPixels et les exports d’un canvas WebGL concordent. Auparavant, il supprimait uniquement le bruit de readPixels. Voir Flags d’empreinte.
• 0.41.1, entrées humanisées : avec humanize, le défilement avance par crans entiers de molette, comme une vraie molette : 100 px par cran pour une identité Windows, 120 sous Linux et 40 sous macOS. Une distance demandée est arrondie au cran le plus proche (au moins un), si bien que mouse.wheel(0, 800) fait défiler de 800 px sous Windows et de 840 sous Linux. Sur les paires rapides, la frappe enfonce désormais parfois la touche suivante avant de relâcher la précédente. En .NET, un humanizer initialisé avec un nombre se déplace désormais avec la même identité motrice qu’en Python et Node ; auparavant, toutes les seeds numériques non nulles partageaient la même. Voir Entrées humanisées.
• 0.41.0 sur le build sous licence à partir de la r32 : la persona parvient au navigateur par son environnement plutôt que par sa ligne de commande, si bien qu’un outil qui lisait la seed dans la liste des processus ne la trouve plus (persona_env=False conserve l’ancien fonctionnement). Les contextes créés par un lancement local n’émulent plus un thème de couleurs clair, si bien qu’une persona sombre se déclare sombre partout (passez color_scheme pour en épingler un). Un lancement Linux headless avec une persona obtient un écran de la taille qu’annonce la persona. Voir Options de lancement.
• 0.41.0, .NET sous Linux : les lancements utilisent désormais les polices du bundle du navigateur, comme l’ont toujours fait Python et Node, au lieu de celles de l’hôte. Une persona Windows y mesure donc différemment, désormais comme avec les deux autres SDK. Voir vos propres polices sous Linux.
• 0.41.0, une persona Linux sur un ordinateur Windows : le SDK avertit une fois par processus. Windows pilote le GPU via Direct3D, qui plafonne les limites WebGL et WebGPU, et une persona peut abaisser une limite mais jamais la relever au-delà de celle du pilote : une persona Linux y annonce donc des limites qu’aucune machine Linux n’a. Annoncez Windows sous Windows, ou exécutez les personas Linux sous Linux ou dans Docker. quiet ou CLEARCOTE_NO_WARN font taire cet avertissement.
• Image Docker sdk-0.41.0 : Chrome peut tourner avec sa sandbox si vous démarrez le conteneur avec le profil seccomp de l’image ; sans lui, le conteneur fonctionne comme avant. Les polices d’écritures sont intégrées. Voir Déploiement.
• 0.40.0 : sous macOS, launch() exécute l’image Docker de Clearcote (Docker Desktop requis ; docker=False le désactive). Voir macOS.

Après une mise à jour, revérifiez

Un nouveau build peut modifier un signal. Relancez vos tests d’empreinte (par exemple CreepJS) et, si vous utilisez un profil importé, vérifiez qu’il se charge toujours de façon cohérente — voir Vérification. Le build ouvert actuel est v0.1.0-pre.23 (Chromium 150.0.7871.114) ; le build sous licence actuel est 154.0.8037.57-r36. La feuille de route indique ce qui arrive ensuite.