L'échange HTTP signé (ou "SXG") est un sous-ensemble de la technologie émergente appelé packages Web, qui permet aux éditeurs de transférer leur contenu en toute sécurité, c'est-à-dire qu'il peut être redistribué par d'autres parties, tout en préservant l'intégrité et l'attribution du contenu. Le contenu portable présente de nombreux avantages, qu'il s'agisse d'accélérer la diffusion de contenu, de faciliter le partage de contenu entre les utilisateurs et de simplifier l'expérience hors connexion.
Comment fonctionnent les Signed HTTP Exchanges ? Cette technologie permet à un éditeur de signer un seul échange HTTP (c'est-à-dire une paire requête/réponse) de la manière dont l'échange signé peut ê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 dans l'échange est une preuve suffisante que le contenu provient initialement de l'origine de l'éditeur.
Cette opération permet de dissocier l'origine du contenu de la personne qui le diffuse. Vous pouvez publier votre contenu sur le Web sans dépendre d'un serveur, d'une connexion ou d'un service d'hébergement spécifique. Nous sommes impatients de proposer l'échange signé:
Préchargement protégeant la confidentialité:bien que le préchargement des ressources (par exemple, via 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 indique au site de destination que l'utilisateur est potentiellement intéressé par une information, même s'il n'a finalement pas visité le site. D'un autre côté, l'échange signé permet de précharger des ressources multi-origines à partir d'un cache rapide sans jamais accéder au site de destination, ce qui permet de ne communiquer 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 les internautes vers d'autres sites Web. Google prévoit en particulier d'utiliser cette fonctionnalité sur les pages de résultats de recherche Google afin d'améliorer les URL AMP et d'accélérer le nombre de clics dans les résultats de recherche.
Avantages d'un CDN sans céder le contrôle de la clé privée de votre certificat:le contenu devenu soudainement populaire (par exemple, lié à 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 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.
Créer un échange signé
Afin de créer des échanges signés pour votre origine (en tant qu'éditeur), vous avez besoin d'une clé de certificat afin de signer la signature. Le certificat doit avoir une extension "CanSignHttpExchanges" spéciale pour être traité comme un échange signé valide. Depuis novembre 2018, DigiCert est la seule autorité de certification compatible avec cette extension. Vous pouvez demander le certificat compatible avec l'échange signé depuis cette page.
Une fois que vous avez obtenu un certificat pour l'échange signé, vous pouvez créer vos propres échanges signés à l'aide des outils de générateur de référence publiés sur GitHub.
Vous pouvez également consulter les exemples de fichiers SXG réels dans le dépôt de code Chrome (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 comportent des certificats et des codes temporels valides dans la 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 votre Chrome traite les échanges signés avec le certificat, sans extension spéciale.
Le code suivant devrait fonctionner si votre serveur, votre certificat et vos échanges signés 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 le tag 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. Votre contenu signé expirera donc relativement rapidement.
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 Chrome à l'équipe. Vos commentaires nous seront d'une aide précieuse pour le processus de normalisation, mais aussi pour résoudre les problèmes de mise en œuvre.