SharedArrayBuffer fonctionne enfin à nouveau dans le navigateur, mais seulement lorsque la page est isolée en cross-origin – un état qui nécessite deux en-têtes de réponse. L'ajout de ces en-têtes m'a contraint à supprimer tous les scripts tiers de mon site, une décision qui a remodelé toute la structure du front-end et la nature des données qui y sont exposées.

Pourquoi les en-têtes sont importants

SharedArrayBuffer permet un véritable multithreading en JavaScript, une condition préalable pour exécuter ffmpeg dans un onglet. Les navigateurs modernes ont réactivé cette fonctionnalité après les mesures d'atténuation de type Spectre, mais ils l'ont liée à l'isolation cross-origin. Pour parvenir à cette isolation, un serveur doit envoyer :

  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp

Le second en-tête, require-corp, indique au navigateur que toute ressource externe doit soit porter un en-tête Cross-Origin-Resource-Policy, soit être récupérée via CORS (Cross-Origin Resource Sharing). La plupart des services tiers ne configurent pas ces en-têtes, de sorte que leurs scripts, polices et iframes sont purement et simplement bloqués.

Ce qui a disparu lors de l'activation de l'isolation

Au moment où les en-têtes sont devenus actifs, une cascade d'échecs est apparue :

  • Analytics – la plupart des fournisseurs chargent leur code de suivi avec un simple <script> qui effectue une requête sans CORS. Sans en-tête CORP, la requête est rejetée, et le tracker ne s'exécute jamais.
  • Google Fonts – la feuille de style est récupérée depuis fonts.googleapis.com sans CORS. Le navigateur la rejette, laissant la page sans sa typographie personnalisée.
  • Médias intégrés – les iframes YouTube et les scripts de widgets n'ont pas de CORP, ils cessent donc de s'afficher.
  • Fenêtres contextuelles OAuth – la relation window.opener est rompue par la politique stricte de même origine (same-origin), ce qui casse le flux de connexion habituel basé sur les pop-ups.

En résumé, tout actif dépendant d'un domaine tiers a disparu, à moins que ce domaine n'ait opté pour le nouveau régime d'en-têtes.

Reconstruire sans intermédiaires

Face à un site défaillant, j'ai réécrit la pile front-end autour d'actifs auto-hébergés :

  • Les polices et les images sont désormais servies depuis ma propre origine, éliminant le besoin de feuilles de style externes.
  • Les API de données reposent sur un backend privé que je contrôle, de sorte que chaque requête reste dans mon domaine.
  • L'Analytics est devenu un minuscule Cloudflare Worker qui accepte des événements POST et les stocke dans un bucket privé. Le côté client ne se résume qu'à une douzaine de lignes de code fetch.
  • Les outils de signalement d'erreurs et de relecture de session tels que Sentry ont été totalement abandonnés ; chaque crash est désormais enregistré sur mon propre point de terminaison.

Si une ressource externe est toujours nécessaire, la seule voie viable est de la passer par un proxy via un serveur que vous possédez, en ajoutant l'en-tête CORP nécessaire avant que le navigateur ne la voie.

Gains de confidentialité contre coût opérationnel

Le bénéfice immédiat est clair : le site ne fuit plus de données d'utilisation vers les réseaux publicitaires, les fournisseurs de polices ou les plateformes vidéo. Toute la télémétrie reste sous mon contrôle, et je peux la supprimer quand je le souhaite. Ce niveau de confidentialité est difficile à atteindre avec une pile tierce classique.

Le revers de la médaille est la charge de maintenance supplémentaire. Héberger des polices, gérer le stockage des analyses et maintenir un proxy à jour sont des tâches que la plupart des développeurs sous-traitent à des services spécialisés. Cette approche signifie également renoncer à des fonctionnalités offertes par ces services – par exemple, l'agrégation d'erreurs en temps réel ou les visualisations détaillées de tunnels de conversion.

Contre-argument : l'écosystème va-t-il s'adapter ?

Certains soutiennent que les fournisseurs tiers finiront par ajouter les en-têtes requis, rendant l'adoption de l'isolation cross-origin indolore. Quelques-uns le font déjà, mais la majorité des services largement utilisés ne le font toujours pas. En attendant que l'écosystème rattrape son retard, les développeurs doivent décider si le gain de confidentialité l'emporte sur l'effort d'ingénierie requis pour l'auto-hébergement.

Comment vérifier que vous êtes réellement isolé

Avant de commencer à réécrire, confirmez que le navigateur voit votre page comme isolée :

crossOriginIsolated   // should be true
typeof SharedArrayBuffer   // should be "function"

Si l'un des deux tests échoue, les en-têtes ne sont pas appliqués correctement, et SharedArrayBuffer restera indisponible.

Quelle est la suite pour les développeurs ?

À mesure que davantage d'applications web recherchent le gain de performance du JavaScript multithreadé, la pression sur les fournisseurs tiers pour adopter CORP augmentera. En attendant, tout projet nécessitant SharedArrayBuffer devrait prévoir une stratégie d'actifs auto-hébergés ou une couche de proxy légère. Surveiller les notes de version des navigateurs pour d'éventuels changements dans les exigences d'isolation sera également essentiel.

À retenir : L'activation de l'isolation cross-origin pour débloquer SharedArrayBuffer impose un choix difficile : conserver la commodité des scripts tiers ou l'échanger contre un modèle de confidentialité plus strict et maîtrisé. Cette décision remodèle à la fois l'architecture technique et l'empreinte des flux de données des sites web modernes.