Signed HTTP Exchange (ou "SXG") est un sous-ensemble de la technologie émergente appelée Web Packages, qui permet aux éditeurs de rendre leur contenu portable, c'est-à-dire redistribuable par d'autres parties, en toute sécurité, tout en préservant son intégrité et son attribution. Le contenu portable présente de nombreux avantages, par exemple pour accélérer la diffusion du contenu, faciliter le partage de contenu entre les utilisateurs et simplifier les expériences hors connexion.
Comment fonctionnent les échanges HTTP signés ? Cette technologie permet à un éditeur de signer un seul échange HTTP (c'est-à-dire une paire requête/réponse), de sorte que l'échange signé puisse être diffusé à partir de n'importe quel serveur de mise en cache. Lorsque le navigateur charge cet échange signé, il peut afficher en toute sécurité l'URL de l'éditeur dans la barre d'adresse, car la signature de l'échange est une preuve suffisante que le contenu provient à l'origine de l'éditeur.
Cela dissocie l'origine du contenu de celui qui le distribue. Vos contenus peuvent être publiés sur le Web, sans dépendre d'un serveur, d'une connexion ou d'un service d'hébergement spécifiques. Nous sommes ravis des utilisations possibles des SXG, par exemple:
Préchargement respectueux de la confidentialité:bien que le préchargement de ressources (par exemple, par lien rel=prefetch) pour une navigation ultérieure puisse rendre la navigation beaucoup plus rapide, il présente également des inconvénients en termes de confidentialité. Par exemple, le préchargement de ressources pour les navigations inter-origines indique au site de destination que l'utilisateur est potentiellement intéressé par une information, même s'il ne l'a finalement pas consultée. D'autre part, SXG permet de précharger des ressources multi-origines à partir d'un cache rapide sans jamais contacter le site de destination, ne communiquant ainsi l'intérêt de l'utilisateur que si et quand la navigation se produit. Nous pensons que cela peut être utile pour les sites dont l'objectif est de rediriger leurs utilisateurs vers d'autres sites Web. Plus précisément, Google prévoit de l'utiliser sur les pages de résultats de recherche Google pour améliorer les URL AMP et accélérer les clics sur les résultats de recherche.
Avantages d'un CDN sans céder le contrôle de votre clé privée de certificat:les contenus qui deviennent soudainement populaires (par exemple, ceux qui sont mis en lien sur la première page de reddit.com) surchargent souvent le site sur lequel ils sont diffusés. Si le site est relativement petit, il a tendance à ralentir ou même à être temporairement indisponible. Cette situation peut être évitée si le contenu est partagé à l'aide de serveurs de cache rapides et puissants. SXG permet de le faire sans partager vos clés TLS.
Essayer les échanges signés
Les échanges signés sont disponibles dans Chrome 73 et versions ultérieures. Ils étaient auparavant disponibles en phase d'évaluation de l'origine.
Créer votre SXG
Pour créer des SXG pour votre origine (en tant qu'éditeur), vous avez besoin d'une clé de certificat pour signer la signature. Le certificat doit également disposer d'une extension "CanSignHttpExchanges" spéciale pour être traité en tant que SXG valide. Depuis novembre 2018, DigiCert est la seule autorité de certification compatible avec cette extension. Vous pouvez demander le certificat compatible avec les SXG sur cette page.
Une fois que vous avez obtenu un certificat pour SXG, vous pouvez créer vos propres SXG à l'aide des outils de générateur de références publiés sur GitHub.
Vous pouvez également consulter les exemples de fichiers SXG dans le dépôt de code de Chrome (par exemple, celui-ci est le plus simple créé pour un fichier texte simple). Notez qu'ils sont générés principalement pour les tests en local. Ne vous attendez pas à ce qu'ils contiennent des certificats et des codes temporels valides dans la signature.
Tester la fonctionnalité en local
Pour créer des fichiers SXG à des fins de test, vous pouvez créer un certificat autosigné et activer chrome://flags/#allow-sxg-certs-without-extension pour que Chrome traite les fichiers SXG créés avec le certificat sans l'extension spéciale.
Un code comme celui-ci devrait fonctionner si votre serveur, votre certificat et vos SXG sont correctement configurés:
<!-- prefetch the sample.sxg -->
<link rel="prefetch" href="https://your-site.com/sample.sxg" />
<!-- clicking the link below should make Chrome navigate to the inner
response of sample.sxg (and the prefetched SXG is used) -->
<a href="https://your-site.com/sample.sxg">Sample</a>
Notez que les balises SXG ne sont compatibles qu'avec la balise d'ancrage (<a>) et link rel=prefetch dans Chrome 73 et versions ultérieures. Notez également que la validité de la signature est limitée à sept jours par spécification. Vos contenus signés expireront donc relativement rapidement.
Envoyer des commentaires
Nous aimerions connaître votre avis sur ce test à l'adresse webpackage-dev@chromium.org. Vous pouvez également participer à la discussion sur les spécifications ou signaler à l'équipe un bug Chrome. Vos commentaires nous aideront grandement à standardiser le processus et à résoudre les problèmes d'implémentation.