Podpisana wymiana HTTP (lub „SXG”) to podzbiór nowej technologii o nazwie Web Packages, która umożliwia wydawcom bezpieczne przenoszenie treści, czyli udostępnianie ich do rozpowszechniania przez inne osoby przy jednoczesnym zachowaniu ich integralności i informacji o źródle. Przenośne treści mają wiele zalet, m.in. umożliwiają szybsze dostarczanie treści, ułatwiają ich udostępnianie innym użytkownikom i ułatwiają korzystanie z treści offline.
Jak działają podpisane wymiany HTTP? Ta technologia umożliwia wydawcy podpisanie pojedynczej wymiany HTTP (czyli pary żądanie/odpowiedź) w taki sposób, aby można było ją wyświetlić z dowolnego serwera pamięci podręcznej. Gdy przeglądarka wczyta ten element Signed Exchange, może bezpiecznie wyświetlić adres URL wydawcy na pasku adresu, ponieważ podpis w wymianie jest wystarczającym dowodem, że treści pochodzą z domeny wydawcy.
Dzięki temu źródło treści jest odseparowane od osoby, która je rozpowszechnia. Twoje treści mogą być publikowane w internecie bez konieczności korzystania z konkretnego serwera, połączenia lub usługi hostingowej. Cieszymy się, że możliwe zastosowania SXG obejmują:
Przedwstępna analiza z zachowanymi informacjami o prywatności: chociaż wstępna analiza zasobów (np. za pomocą linku rel=prefetch) w celu późniejszego przekierowania może sprawić, że przekierowanie będzie wydawać się znacznie szybsze, ma też wady związane z prywatnością. Na przykład wstępne pobieranie zasobów w przypadku nawigacji między domenami spowoduje, że witryna docelowa dowie się, że użytkownik jest potencjalnie zainteresowany pewną informacją, nawet jeśli ostatecznie nie odwiedzi tej witryny. Z drugiej strony SXG umożliwia wstępne pobieranie zasobów z różnych źródeł z szybkiej pamięci podręcznej bez korzystania z witryny docelowej, dzięki czemu zainteresowanie użytkownika jest przekazywane tylko wtedy, gdy nastąpi nawigacja. Uważamy, że może to być przydatne w przypadku witryn, których celem jest odsyłanie użytkowników do innych stron. W szczególności planujemy stosować tę funkcję na stronach z wynikami wyszukiwania Google, aby ulepszać adresy URL AMP i przyspieszać kliknięcia wyników wyszukiwania.
Zalety CDN bez utraty kontroli nad kluczem prywatnym certyfikatu: treści, które nagle stają się popularne (np.linki z pierwszej strony reddit.com), często przeciążają witrynę, w której są dostarczane.Jeśli witryna jest stosunkowo mała, może się ona spowolnić lub nawet czasowo stać się niedostępna. Można tego uniknąć, udostępniając treści za pomocą szybkich i wydajnych serwerów pamięci podręcznej. SXG umożliwia to bez udostępniania kluczy TLS.
Wypróbuj Signed Exchange
Umowy podpisane cyfrowo są dostępne w Chrome 73 i nowszych wersjach. Wcześniej były dostępne jako próbna wersja na serwerze.
Tworzenie SXG
Aby utworzyć SXG dla swojej usługi (jako wydawca), musisz mieć klucz certyfikatu, który posłuży do podpisania podpisu. Certyfikat musi mieć specjalne rozszerzenie „CanSignHttpExchanges”, aby można było go przetworzyć jako prawidłowy SXG. Od listopada 2018 r. DigiCert jest jedynym urzędem certyfikacji, który obsługuje to rozszerzenie. Możesz poprosić o certyfikat, który działa w przypadku SXG, na tej stronie.
Po uzyskaniu certyfikatu SXG możesz tworzyć własne SXG, korzystając z narzędzi do generowania referencji opublikowanych na GitHub.
Możesz też zapoznać się z przykładowymi plikami SXG w repozytorium kodu Chrome (np. ten jest najprostszym plikiem tekstowym). Pamiętaj, że są one generowane głównie na potrzeby testów lokalnych, więc nie oczekuj, że będą zawierać prawidłowe certyfikaty i stemplę czasu w podpisie.
Testowanie funkcji lokalnie
Aby tworzyć SXG do celów testowych, możesz utworzyć certyfikat podpisany samodzielnie i włączyć chrome://flags/#allow-sxg-certs-without-extension, aby Chrome przetwarzało SXG utworzone za pomocą certyfikatu bez specjalnego rozszerzenia.
Jeśli serwer, certyfikat i SXG są prawidłowo skonfigurowane, powinien działać kod podobny do tego:
<!-- 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>
Pamiętaj, że SXG jest obsługiwane tylko przez tag kotwicy (<a>) i link rel=prefetch w Chrome 73 lub nowszej. Pamiętaj też, że zgodnie ze specyfikacją ważność podpisu jest ograniczona do 7 dni, więc podpisane treści wygasną stosunkowo szybko.
Przekazywanie opinii
Chętnie poznamy Twoją opinię na temat tego eksperymentu. Wyślij ją na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji lub zgłosić błąd w Chrome zespołowi. Twoja opinia znacznie ułatwi nam proces standaryzacji i pomoże nam rozwiązać problemy z wdrażaniem.