Signed HTTP Exchange (ou "SXG") est un sous-ensemble de la technologie émergente appelé packages Web, qui permet aux éditeurs de rendre leur contenu portable en toute sécurité, c'est-à-dire de le distribuer par d'autres parties, tout en préservant son intégrité et son attribution. Le contenu portable présente de nombreux avantages, qu'il s'agisse d'une diffusion plus rapide du contenu, d'un partage de contenu entre utilisateurs ou d'une expérience hors connexion plus simple.
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é, l'URL de l'éditeur peut s'afficher en toute sécurité dans la barre d'adresse, car la signature dans l'échange est une preuve suffisante que le contenu provient à l'origine de l'éditeur.
Cela permet de dissocier l'origine du contenu de celui qui le distribue. Vous pouvez publier votre contenu sur le Web sans passer par un serveur, une connexion ou un service d'hébergement spécifique. Nous sommes ravis des utilisations possibles de l'échange signé, par exemple:
Préchargement respectueux de la confidentialité:bien que le préchargement des ressources (par exemple, by link 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 des ressources pour les navigations multi-origines révèle au site de destination qu'un utilisateur est potentiellement intéressé par une information, même s'il n'a finalement pas consulté le site. D'autre part, l'échange signé permet de précharger les ressources multi-origines à partir d'un cache rapide sans jamais accéder au site de destination. Cela permet de ne communiquer l'intérêt des utilisateurs que si et quand la navigation se produit. Nous pensons que cela peut être utile pour les sites dont le but est de rediriger les utilisateurs vers d'autres sites Web. En particulier, 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 le nombre de clics sur les résultats de recherche.
Avantages d'un CDN sans céder le contrôle de la clé privée de votre certificat:un contenu qui est soudainement devenu populaire (par exemple, un lien depuis la première page de reddit.com) surcharge souvent le site où le contenu est diffusé. Si le site est relativement petit, il a tendance à ralentir, voire à devenir temporairement indisponible. Cette situation peut être évitée si le contenu est partagé à l'aide de serveurs de cache rapides et puissants, et si l'échange signé permet cela sans partager vos clés TLS.
Essayer les échanges signés
Les échanges signés sont disponibles dans Chrome 73 et les versions ultérieures et étaient auparavant disponibles en tant qu'évaluation d'origine.
Créer un échange signé
Afin de créer des échanges signés pour votre origine (en tant qu'éditeur), vous devez disposer d'une clé de certificat pour signer la signature et le certificat doit comporter une extension "CanSignHttpExchanges" spéciale pour être considéré comme un échange signé valide. Depuis novembre 2018, DigiCert est la seule autorité de certification compatible avec cette extension. Vous pouvez demander un certificat compatible avec SXG sur cette page.
Une fois que vous avez obtenu un certificat pour un échange signé, vous pouvez créer vos propres échanges à l'aide des outils de génération de référence publiés sur GitHub.
Vous pouvez également consulter les fichiers d'exemple 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 des tests en local. Ne vous attendez pas à ce qu'ils contiennent des certificats et des codes temporels valides dans leur signature.
Tester la fonctionnalité en local
Pour créer des échanges signés à 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 échanges signés avec le certificat, sans l'extension spéciale.
Un code de ce type devrait fonctionner si le serveur, le certificat et les 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 l'échange signé n'est compatible 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. Par conséquent, votre contenu signé expire assez rapidement.
Fournir des commentaires
Nous aimerions connaître votre avis sur cette expérience à l'adresse webpackage-dev@chromium.org. Vous pouvez également participer à la discussion sur les spécifications ou signaler un bug de Chrome à l'équipe. Vos commentaires nous seront très utiles pour le processus de normalisation et nous aideront aussi à résoudre les problèmes d'implémentation.