[OUTDATED] Zestawy źródeł własnych i atrybut SameParty

Ostrzeżenie: oferta pakietowa zestawów źródeł własnych została zaktualizowana, a ten artykuł nie jest już aktualny. Najnowsze informacje znajdziesz w wyjaśnieniu i instrukcjach testowania.

Wiele organizacji ma powiązane witryny z różnymi nazwami domen, np. brandx.site i fly-brandx.site, lub domeny przeznaczone dla różnych krajów, np. example.com, example.rs, example.co.uk itd.

Przeglądarki zmierzają do sprawiania, że pliki cookie innych firm stają się nieaktualne, aby poprawić ochronę prywatności w internecie. Jednak w witrynach takich jak te pliki cookie są często wykorzystywane w funkcjach, które wymagają utrzymania stanu i dostępu do nich w różnych domenach (np. logowania jednokrotnego i zarządzania zgodą użytkowników).

Zestawy źródeł własnych mogą zezwolić na traktowanie powiązanych nazw domen należących do tego samego podmiotu i przez niego zarządzanych jako „własne” w sytuacjach, gdy nazwa „własna” i „zewnętrzna” są traktowane inaczej. Nazwy domen w zestawie własnych są uważane za same i mogą oznaczać, które pliki cookie mają być ustawiane lub wysyłane w kontekście tej samej strony. Chodzi o to, aby znaleźć równowagę między zapobieganiem śledzeniu w witrynach przez osoby trzecie, a jednocześnie zachować ścieżkę, która nie narusza prawidłowych przypadków użycia.

Propozycja zestawów źródeł własnych jest obecnie w fazie testowania. Czytaj dalej, aby dowiedzieć się, jak ona działa i jak możesz ją wypróbować.

Jaka jest różnica między własnymi plikami cookie a plikami cookie innych firm?

Pliki cookie nie są z natury własne ani innych firm, ale zależą od kontekstu, w którym się on znajduje. Dzieje się tak w żądaniu w nagłówku cookie lub przez document.cookie w JavaScript.

Jeśli np. video.site ma plik cookie theme=dark, to podczas przeglądania video.site i wysyłanie żądania do video.site jest to kontekst tej samej witryny, a zawarty plik cookie jest własnym.

Jeśli jednak używasz przeglądarki my-blog.site, która zawiera odtwarzacz iframe dla witryny video.site, to żądanie wysyłane z adresu my-blog.site do video.site jest wysyłane z innych witryn, a plik cookie theme jest zewnętrznie.

O uwzględnieniu plików cookie decyduje ich atrybut SameSite:

• Kontekst tej samej witryny z elementami SameSite=Lax, Strict lub None sprawia, że plik cookie jest własny.
• Kontekst z różnych witryn o wartości SameSite=None sprawia, że plik cookie jest firmy zewnętrznej.

Jednak nie zawsze jest to tak oczywiste. Załóżmy, że brandx.site to strona służąca do rezerwacji podróży, a także fly-brandx.site i drive-brandx.site do oddzielania lotów i wynajmu samochodów. W trakcie rezerwacji jednej ścieżki użytkownicy przechodzą między tymi witrynami, aby wybrać różne opcje. Oczekują, że opcje wyboru w „koszyku na zakupy” pozostaną w tych witrynach. brandx.site zarządza sesją użytkownika za pomocą pliku cookie SameSite=None, który umożliwia korzystanie z niego w różnych witrynach. Wadą jest jednak to, że plik cookie nie jest objęty ochroną przed oszustwem w ramach żądania z innej witryny (CSRF). Jeśli evil.site uwzględnia żądanie do brandx.site, będzie zawierać ten plik cookie.

Plik cookie znajduje się w innej witrynie, ale wszystkie witryny należą do tej samej organizacji i są przez nią zarządzane. Użytkownicy rozumieją też, że chodzi o tę samą organizację, i oczekują tej samej sesji, czyli wspólnej tożsamości.

Uwaga: zestawy źródeł własnych pozwalają wskazywać sytuacje, w których kontekst z różnych witryn jest wciąż własnym. Plik cookie może zostać uwzględniony w zestawie własnym i wykluczony w kontekście innych firm.

Zasady dotyczące zestawów źródeł własnych

Zestawy źródeł własnych oferują metodę dokładnego definiowania relacji między wieloma witrynami należącymi do tej samej strony i przez nią zarządzanym. Umożliwi to brandx.site zdefiniowanie własnej relacji z elementami fly-brandx.site, drive-brandx.site itd.

Model prywatności, który tworzy różne oferty Piaskownicy prywatności, opiera się na koncepcji partycjonowania tożsamości w celu uniemożliwienia śledzenia w witrynach. Jest to granica między witrynami, która ogranicza dostęp do informacji umożliwiających identyfikację użytkowników.

Domyślna opcja to partycjonowanie według witryny, co sprawdza się w wielu przypadkach własnych. Z kolei przykład brandx.site pokazuje, że dane własne mogą być większe niż tylko jedna witryna.

Ważną częścią oferty zestawów źródeł własnych jest zapewnienie, aby zasady obowiązujące w różnych przeglądarkach zapobiegały nadużyciom i niewłaściwym użyciu. Zestawy źródeł własnych nie mogą np. umożliwiać wymiany informacji o użytkownikach między niepowiązanymi witrynami ani grupowaniem witryn, które nie należą do tego samego podmiotu. Chodzi o to, aby zestaw źródeł własnych był powiązany z czymś, co użytkownik uważa za własne, i nie był używany do dzielenia się tożsamością między różnymi podmiotami.

Jednym z możliwych sposobów na zarejestrowanie własnego zestawu przez witrynę może być przesłanie przez witrynę proponowanej grupy domen do publicznego narzędzia do śledzenia (na przykład w specjalnym repozytorium GitHub) wraz z informacjami potrzebnymi do spełnienia zasad przeglądarki.

Uwaga: proces akceptacji nowego zestawu danych własnych konsultuje się z W3C. Jedną z rozważanych opcji jest przeprowadzenie weryfikacji przez podmiot niezależny, a nie przez firmę zajmującą się przeglądarką.

Po zweryfikowaniu zgodności zestawu danych własnych zgodnie z zasadami przeglądarki mogą pobierać listy zbiorów za pomocą procesu aktualizacji.

Testowanie origin ma zdefiniowaną zasadę, która nie jest ostateczna, ale zasady prawdopodobnie pozostaną takie same:

• Domeny należące do zbioru danych własnych muszą należeć do tej samej organizacji i nią zarządzać.
• Domeny powinny być rozpoznawalne dla użytkowników jako grupa.
• Domeny powinny mieć wspólną politykę prywatności.

Uwaga: dowiedz się więcej o proponowanych zasadach dotyczących zestawów źródeł własnych.

Jak zdefiniować zestaw danych własnych

Po określeniu członków i właściciela zestawu własnego organizacji musisz przesłać proponowany zestaw do zatwierdzenia. Dokładna procedura nadal jest nadal omawiana.

Uwaga: zestaw danych własnych nie stanowi pełnej listy witryn należących do tej samej organizacji. Musisz utworzyć zestaw między witrynami tylko wtedy, gdy potrzebujesz zezwolić na stosowanie w nich plików cookie pochodzących z różnych witryn. Zapoznaj się z sekcją Które przypadki użycia są odpowiednie w przypadku wersji próbnej origin zestawów źródeł własnych? poniżej.

Aby zadeklarować własny zestaw, statyczne zasoby JSON zawierające listę użytkowników i właścicieli powinny być hostowane w /.well-known/first-party-set na najwyższym poziomie każdej uwzględnionej domeny.

W przykładzie zbioru danych własnych brandx domena właściciela hostuje następujące elementy pod adresem https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Każdy element zestawu hostuje też statyczny zasób JSON wskazujący właściciela zestawu. W firmie https://fly-brandx.site/.well-known/first-party-set dostępne są:

{ "owner": "brandx.site" }

O https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Istnieje kilka ograniczeń dotyczących zbiorów danych własnych:

• Zestaw może mieć tylko jednego właściciela.
• Jeden członek może należeć tylko do jednego zestawu – nie można się na niego nakładać ani łączyć go ze sobą.
• Lista członków powinna pozostać stosunkowo czytelna dla człowieka i nie może być nadmiernie długa.

Uwaga: możliwe, że hostujesz podobny plik, jeśli używasz linków do zasobów cyfrowych do łączenia witryn, które korzystają z tego samego systemu zarządzania kontem. Ma to na celu umożliwienie Menedżerowi haseł Chrome sugerowania tych samych danych logowania na wszystkich powiązanych stronach.

Jak zestawy źródeł własnych wpływają na pliki cookie?

Pasujący składnik plików cookie to proponowany atrybut SameParty. Jeśli określisz SameParty, przeglądarka będzie uwzględniać plik cookie, gdy jego kontekst należy do tego samego zestawu własnego co kontekst najwyższego poziomu.

Oznacza to, że jeśli brandx.site ustawi ten plik cookie:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Następnie, gdy użytkownik korzysta z fly-brandx.site i wysyła żądanie do brandx.site, do tego żądania zostanie dołączony plik cookie session. Jeśli inna witryna, która nie należy do zbioru danych własnych, np. hotel.xyz, wyśle żądanie do brandx.site, plik cookie nie zostanie uwzględniony.

Dopóki standard SameParty nie będzie powszechnie obsługiwany, używaj wraz z nim atrybutu SameSite do definiowania zachowania zastępczego w przypadku plików cookie. Atrybut SameParty przypomina ustawienie od SameSite=Lax do SameSite=None.

• SameSite=Lax; SameParty rozszerzy funkcję Lax, aby uwzględniała konteksty z tych samych firm tam, gdzie jest to obsługiwane. W razie potrzeby wraca do ograniczeń Lax.
• Tam, gdzie jest to możliwe, SameSite=None; SameParty ogranicza funkcję None tylko do kontekstów tej samej strony, ale w razie potrzeby powraca do szerszych uprawnień None.

Obowiązują dodatkowe wymagania:

• Pliki cookie SameParty muszą zawierać Secure.
• Pliki cookie SameParty nie mogą zawierać SameSite=Strict.

Polecenie Secure jest nadal wymagane, ponieważ nadal odbywa się z innej witryny. W związku z tym należy ograniczyć to ryzyko, upewniając się, że połączenia są bezpieczne (HTTPS). Podobnie, ponieważ jest to relacja między witrynami, atrybut SameSite=Strict jest nieprawidłowy, ponieważ nadal pozwala na ścisłą ochronę CSRF opartą na witrynie w ramach zestawu.

Ważne: atrybut SameParty ma wpływ tylko na konteksty, w których może zostać wysłany plik cookie. Nie tworzy udostępnionego kontenera plików cookie. Plik cookie z domeny brandx.site jest dostępny tylko w przypadku żądań lub dokumentów związanych z elementem brandx.site. Ten plik nigdy nie jest dostępny bezpośrednio dla usługi fly-brandx.site. Może to być mylące, ponieważ może się to nazywać współdzieloną tożsamością. Oznacza to jednak, że łagodna granica między witrynami umożliwia im ustawianie lub wysyłanie plików cookie w kontekście tej samej strony w różnych witrynach – a nie bezpośrednie udostępnianie plików cookie.

Jakie przypadki użycia są odpowiednie w przypadku zestawów źródeł własnych?

Zestawy źródeł własnych dobrze sprawdzają się w przypadkach, gdy organizacja potrzebuje formy wspólnej tożsamości w różnych witrynach najwyższego poziomu. Współdzielona tożsamość w tym przypadku oznacza wszystko, od rozwiązania do pełnego logowania jednokrotnego po potrzebę korzystania ze wspólnych ustawień w różnych witrynach.

Uwaga: w takich przypadkach możesz zidentyfikować potencjalne przypadki użycia, w których plik cookie został już przez Ciebie oznaczony jako SameSite=None, mimo że dotyczy on tylko kontekstu w różnych witrynach, w którym wszystkie witryny należą do Ciebie.

Organizacja może mieć różne domeny najwyższego poziomu dla:

• Domeny aplikacji: office.com,live.com, microsoft.com
• Domeny marki: amazon.com, audible.com / disney.com, pixar.com
• Domeny krajowe, w których chcesz włączyć lokalizację: google.co.in, google.co.uk
• Domeny usług, z którymi użytkownicy nigdy nie wchodzą w bezpośrednią interakcję, ale udostępniają usługi w witrynach tej samej organizacji: gstatic.com, githubassets.com, fbcdn.net
• Domeny piaskownicy, z którymi użytkownicy nigdy nie wchodzą w bezpośrednią interakcję, ale istnieją ze względów bezpieczeństwa: googleusercontent.com, githubusercontent.com

W jaki sposób się zaangażujesz?

Jeśli masz zbiór witryn, który spełnia powyższe kryteria, możesz się zaangażować na kilka sposobów. Najprostszą inwestycją jest przeczytanie i dołączenie do dyskusji na temat 2 propozycji:

• First-Party Sets Privacy Community Group – dyskusja w grupie dyskusyjnej
• Dyskusja na temat atrybutów plików cookie SameParty

Na etapie testowania możesz wypróbować tę funkcję, używając flagi wiersza poleceń --use-first-party-set i podając listę witryn rozdzielonych przecinkami.

Możesz wypróbować tę funkcję w witrynie demonstracyjnej pod adresem https://fps-member1.glitch.me/ po uruchomieniu Chrome z tą flagą:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Jest to przydatne, jeśli chcesz przetestować środowisko programistyczne lub chcesz spróbować dodać atrybut SameParty w aktywnym środowisku, aby sprawdzić, jak zestaw własny wpłynie na pliki cookie.

Jeśli masz wystarczającą przepustowość do eksperymentowania i przekazywania opinii, możesz też zarejestrować się w wersji próbnej origin dla zestawów własnych i SameParty, która jest dostępna w Chrome od wersji 89 do 93.

Kluczowy termin: wersje próbne to sposób, w jaki Chrome umożliwia deweloperom zewnętrznym testowanie wczesnych propozycji w rzeczywistych scenariuszach w celu przekazywania opinii niezbędnych do ewolucji i powielania rozwiązań, które spełniają potrzeby platformy internetowej. Więcej informacji znajdziesz w artykule Pierwsze kroki z testami origin Chrome.

Jak aktualizować pliki cookie na potrzeby testowania origin

Jeśli dołączasz do testowania origin i testujesz atrybut SameParty w plikach cookie, weź pod uwagę 2 wzorce.

Opcja 1

Po pierwsze, jeśli masz pliki cookie oznaczone jako SameSite=None, ale chcesz ograniczyć je do własnych kontekstów, możesz dodać do nich atrybut SameParty. W przeglądarkach, w których włączona jest wersja próbna origin, plik cookie nie będzie wysyłany poza zestawem plików cookie w kontekście innych witryn.

W przypadku większości przeglądarek poza okresem próbnym plik cookie będzie nadal wysyłany między witrynami. Potraktuj to jako progresywne podejście do ulepszania.

Przed: set-cookie: cname=cval; SameSite=None; Secure

Po: set-cookie: cname=cval; SameSite=None; Secure; SameParty

Opcja 2

Druga opcja jest bardziej pracochłonna, ale umożliwia pełne oddzielenie wersji próbnej origin od istniejących funkcji i szczególnie umożliwia testowanie kombinacji SameSite=Lax; SameParty.

Przed: set-cookie: cname=cval; SameSite=None; Secure

Po:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Podczas sprawdzania pliku cookie w żądaniach przychodzących plik cname-fps powinien pojawić się w żądaniu z innej witryny tylko wtedy, gdy odpowiednie witryny wchodzą w skład zestawu, a przeglądarka jest w trakcie testowania origin. Potraktuj to podejście jak równoczesne wprowadzenie zaktualizowanej funkcji przed wycofaniem poprzedniej wersji.

Dlaczego własny zestaw może nie być potrzebny?

W przypadku większości witryn granica witryny stanowi dopuszczalne miejsce do określenia granicy partycji lub prywatności. To jest proponowana trasa z elementem CHIPS (Pliki cookie bez niezależnego państwa partycji), który za pomocą atrybutu Partitioned zapewni witrynom możliwość dopuszczania się takich elementów, jak najistotniejsze elementy umieszczone w innych witrynach, zasoby, interfejsy API i usługi, a jednocześnie zapobiega wyciekom informacji umożliwiających identyfikację w różnych witrynach.

Oto kilka innych kwestii, które warto wziąć pod uwagę, że witryna może działać bez zestawu:

• Korzystasz z różnych źródeł, a nie z różnych witryn. W powyższym przykładzie, jeśli dyrektywa brandx.site miała uprawnienia fly.brandx.site i drive.brandx.site, są to różne subdomeny w tej samej witrynie. Pliki cookie mogą używać znaczników SameSite=Lax i nie są potrzebne żadne ustawienia.
• Dostarczasz umieszczone przez inne firmy elementy umieszczone w innych witrynach. We wstępie pokazujemy przykład filmu z kanału video.site umieszczonego na stronie my-blog.site, który stanowi oczywiste podział treści od osób trzecich. Witryny te są obsługiwane przez różne organizacje, a użytkownicy postrzegają je jako oddzielne podmioty. Te 2 witryny nie powinny znajdować się w jednym zestawie.
• Korzystasz z usług logowania społecznościowego innych firm. Dostawcy tożsamości, którzy używają takich funkcji jak OAuth czy OpenId Connect, często używają plików cookie innych firm, aby usprawnić logowanie się użytkowników. To prawidłowy przypadek użycia, ale nie nadaje się on do stosowania w zestawach źródeł własnych, ponieważ w ich organizacjach występują pewne różnice. We wcześniejszych wersjach usługi, w tym WebID, znajdują się nowe sposoby pozwalające na włączenie tych funkcji.