Podpisana wymiana HTTP (inaczej „SXG”) to podzbiór nowej technologii zwanej pakietami internetowymi, która umożliwia wydawcom bezpieczne przenoszenie treści, tj. udostępnianie ich innym stronom do dalszej dystrybucji, przy zachowaniu integralności i autorstwa treści. Przenośne treści mają wiele zalet: od szybszego dostarczania po ułatwianie udostępniania treści użytkownikom po łatwiejsze korzystanie z trybu offline.
Jak działają podpisane wymiany HTTP? Ta technologia umożliwia wydawcy podpisanie pojedynczej wymiany HTTP (tj. pary żądanie/odpowiedź) w taki sposób, że podpisana komunikacja może być udostępniana z dowolnego serwera buforowania. Gdy przeglądarka wczyta tę Signed Exchange, może bezpiecznie wyświetlić adres URL wydawcy na pasku adresu, ponieważ podpis na giełdzie stanowi wystarczający dowód na to, że treść pochodzi z źródła wydawcy.
Dzięki temu pochodzenie treści jest oddzielone od tego, kto je rozpowszechnia. Twoje treści mogą być publikowane w internecie, bez korzystania z konkretnego serwera, połączenia czy usługi hostingowej. Jesteśmy ciekawi, jak można wykorzystać SXG, na przykład:
Pobieranie z wyprzedzeniem chroniące prywatność: chociaż z wyprzedzeniem pobieranie zasobów (np. przez link rel=prefetch) na potrzeby późniejszej nawigacji może przyspieszyć nawigację, ma to też zalety związane z ochroną prywatności. Na przykład pobieranie zasobów z wyprzedzeniem na potrzeby nawigacji między domenami ujawnia stronie docelowej, że użytkownik jest potencjalnie zainteresowany daną informacją, nawet jeśli w ogóle jej nie odwiedził. Z drugiej strony SXG umożliwia wstępne pobieranie zasobów z innych domen z szybkiej pamięci podręcznej bez konieczności otwierania strony docelowej. Pozwala to przekazywać informacje o zainteresowaniach użytkownika tylko wtedy, gdy użytkownik nawiguje w jego witrynie. Uważamy, że może to być przydatne dla witryn, których celem jest odsyłanie użytkowników do innych witryn. Konkretnie Google planuje używać tego adresu na stronach wyników wyszukiwania Google do ulepszania adresów URL AMP i przyspieszania kliknięć w wynikach wyszukiwania.
Zalety korzystania z sieci CDN bez wymuszania kontroli nad kluczem prywatnym certyfikatu: treści, które nagle stały się popularne (np.linki na pierwszej stronie reddit.com), często przeciążają witrynę, w której są wyświetlane.Jeśli witryna jest względnie mała, wolniej, a nawet tymczasowo staje się niedostępna. Tej sytuacji można uniknąć, jeśli treści są udostępniane przy użyciu szybkich i wydajnych serwerów pamięci podręcznej, a SXG umożliwia to bez udostępniania kluczy TLS.
Korzystanie z technologii Signed Exchange
Platformy Signed Exchange są dostępne w Chrome 73 i nowszych wersjach. Wcześniej były dostępne w ramach wersji próbnej origin.
Tworzenie SXG
Aby utworzyć mechanizmy SXG dla swojego źródła (jako wydawca), potrzebujesz klucza certyfikatu do podpisania podpisu, a certyfikat musi mieć specjalne rozszerzenie „CanSignHttpExchanges”, aby można było przetworzyć go jako prawidłowy kod SXG. Od listopada 2018 roku DigiCert jest jedynym urzędem certyfikacji, który obsługuje to rozszerzenie. O certyfikat zgodny z SXG możesz poprosić na tej stronie.
Po uzyskaniu certyfikatu SXG możesz utworzyć własne komponenty SXG za pomocą narzędzi do generatora plików referencyjnych opublikowanych na githubie.
Możesz też zobaczyć rzeczywiste przykładowe pliki SXG w repozytorium kodu Chrome (np. ten najprostszy plik utworzony dla prostego pliku tekstowego). Pamiętaj, że są one generowane głównie na potrzeby testów lokalnych i nie oczekuj, że mają w podpisie prawidłowe certyfikaty i sygnatury czasowe.
Lokalne testowanie funkcji
Aby utworzyć komponenty SXG do celów testowych, możesz utworzyć certyfikat podpisany samodzielnie i umożliwić chrome://flags/#allow-sxg-certs-without-extension, aby przeglądarka Chrome przetwarzała komponenty SXG utworzone z tym certyfikatem bez specjalnego rozszerzenia.
Jeśli serwer, certyfikat i SXG są skonfigurowane prawidłowo, kod podobny do tego powinien działać:
<!-- 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 protokół SXG jest obsługiwany tylko przez tag kotwicy (<a>) i zasadę link rel=prefetch w Chrome 73 i nowszych wersjach. Pamiętaj też, że zgodnie ze specyfikacją podpis jest ograniczony do 7 dni, więc podpisana treść wygasa stosunkowo szybko.
Przekazywanie opinii
Chcielibyśmy poznać Twoją opinię na temat tego eksperymentu, wysyłając ją na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji lub zgłosić do zespołu błąd w Chrome. Twoja opinia bardzo pomoże nam w procesie standaryzacji, a także w rozwiązaniu problemów z implementacją.