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

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

Aby zwiększyć prywatność w internecie, przeglądarki wycofaja pliki cookie innych firm, ale takie witryny często korzystają z plików cookie w funkcjach, które wymagają utrzymywania stanu i dostępu do niego w różnych domenach (np. jednokrotne logowanie i zarządzanie zgodą).

Zestawy źródeł własnych mogą umożliwiać traktowanie powiązanych nazw domen należących do tego samego podmiotu i przez niego zarządzanych jako źródeł własnych w sytuacjach, gdy zwyczajowo źródeł własnych i zewnętrznych traktuje się inaczej. Nazwy domen w zestawie plików cookie własnych są uważane za własne i mogą oznaczać, które pliki cookie mają być ustawiane lub wysyłane w kontekście plików cookie własnych. Celem jest znalezienie równowagi między zapobieganiem śledzenia w witrynach przez osoby trzecie a zachowaniem ścieżki, która nie łamie prawidłowych przypadków użycia.

Propozycja dotycząca własnych zestawów jest obecnie w fazie testów. Czytaj dalej, aby dowiedzieć się, jak działa i jak możesz ją wypróbować.

Czym różnią się pliki cookie własne i pliki cookie innych firm?

Pliki cookie nie są z zasady plikami własnymi ani innych firm – zależy to od bieżącego kontekstu, w którym są używane. Możesz to zrobić w żądaniu w nagłówku cookie lub za pomocą funkcji document.cookie w JavaScript.

Jeśli na przykład video.site ma plik cookie theme=dark, a podczas przeglądania witryny video.site wysyłasz żądanie do witryny video.site, jest to kontekst tej samej witryny, a uwzględniony plik cookie jest własnym.

Jeśli jednak korzystasz z witryny my-blog.site, która zawiera wbudowany odtwarzacz iframe dla witryny video.site, żądanie wysłane z my-blog.site do video.site będzie żądaniem w kontekście witryny, a plik cookie theme będzie plikiem cookie zewnętrznym.

Diagram pokazujący plik cookie z witryny video.site w 2 kontekstach Plik cookie jest pochodzący z tej samej witryny, gdy kontekst najwyższego poziomu to również video.site. Plik cookie jest międzywitrynowym, gdy kontekst najwyższego poziomu to my-blog.site z elementem iframe witryny video.site.

Obecność pliku cookie jest określana przez jego atrybut SameSite:

  • Kontekst w ramach tej samej witryny z użyciem wartości SameSite=Lax, Strict lub None powoduje, że plik cookie jest własny.
  • Kontekst międzywitrynowy z SameSite=None powoduje, że plik cookie jest plikiem cookie innej firmy.

Nie zawsze jest to jednak takie oczywiste. Wyobraź sobie, że brandx.site to witryna turystyczna, która używa również fly-brandx.site i drive-brandx.site do oddzielania lotów i wynajmu samochodów. Podczas rezerwacji podróży użytkownicy przechodzą między tymi witrynami, aby wybrać różne opcje. Oczekują, że „koszyk” z wyborami będzie zachowany w tych witrynach. brandx.site zarządza sesją użytkownika za pomocą pliku cookie SameSite=None, aby umożliwić mu działanie w kontekście międzywitrynowym. Minusem jest to, że plik cookie nie jest już chroniony przed atakami CSRF (Cross Site Request Forgery). Jeśli evil.site zawiera żądanie do brandx.site, to zawiera też plik cookie.

Plik cookie jest używany w wielu witrynach, ale wszystkie te witryny należą do tej samej organizacji i są przez nią zarządzane. Odwiedzający wiedzą też, że jest to ta sama organizacja i chcą mieć tę samą sesję, czyli wspólną tożsamość.

Diagram pokazujący, że plik cookie może być nadal uwzględniany w kontekście obejmującym wiele witryn, jeśli witryny należą do tego samego zestawu źródeł własnych, ale zostanie odrzucony w kontekście obejmującym wiele witryn spoza tego zestawu.

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

Zestawy źródeł własnych to metoda określania tych relacji w wielu witrynach należących do tej samej strony i przez nią zarządzanych. Umożliwiłoby to aplikacji brandx.site zdefiniowanie relacji z aplikacją fly-brandx.site, drive-brandx.site itd.

Model prywatności, który jest podstawą różnych propozycji dotyczących piaskownicy prywatności, opiera się na koncepcji podziału tożsamości na części, aby zapobiec śledzeniu w wielu witrynach. Polega ona na wyznaczeniu granicy między witrynami, która ogranicza dostęp do wszelkich informacji, które mogą służyć do identyfikacji użytkowników.

Diagram pokazujący stan bez partycjonowania, w którym ten sam plik cookie osoby trzeciej jest dostępny w różnych kontekstach między witrynami, w przeciwieństwie do modelu partycjonowania, w którym każdy kontekst najwyższego poziomu ma osobny plik cookie między witrynami, co uniemożliwia łączenie aktywności w tych witrynach.

Domyślną opcją jest podział według witryny, który rozwiązuje wiele przypadków użycia danych własnych, ale przykład brandx.site pokazuje, że dane własne mogą obejmować więcej niż jedną witrynę.

Diagram pokazujący, jak ta sama instancja pliku cookie w ramach jednego zbioru może być uwzględniona w kontekstach obejmujących wiele witryn, gdy wszystkie te witryny należą do tego samego zbioru.

Ważnym elementem propozycji zestawów źródeł własnych jest zapewnienie, aby zasady w różnych przeglądarkach zapobiegały nadużyciom i niewłaściwemu używaniu. Na przykład zestawy danych własnych nie mogą umożliwiać wymiany informacji o użytkownikach między niepowiązanymi witrynami ani grupowania witryn, które nie należą do tego samego podmiotu. Chodzi o to, aby zestaw źródeł własnych był mapowany na coś, co użytkownik rozumie jako własne, i nie był używany do udostępniania tożsamości innym stronom.

Jedną z możliwości rejestracji zestawu danych własnych jest przesłanie proponowanej grupy domen do publicznego śledzenia (np. do specjalnego repozytorium GitHub) wraz z informacjami potrzebnymi do spełnienia zasad przeglądarki.

Po zweryfikowaniu oświadczenia o zbiorze źródeł własnych zgodnie z zasadami przeglądarki mogą pobierać listy zbiorów za pomocą procesu aktualizacji.

W przypadku próbnego udostępniania treści z pierwotnego źródła obowiązują zasady, które nie są ostateczne, ale zasady te prawdopodobnie pozostaną takie same:

  • Domeny w zestawie źródeł własnych muszą należeć do tej samej organizacji i być przez nią zarządzane.
  • Domeny powinny być rozpoznawalne przez użytkowników jako grupa.
  • Domeny powinny mieć wspólną politykę prywatności.

Jak zdefiniować zestaw źródeł własnych

Po zidentyfikowaniu członków i właściciela zestawu danych własnych organizacji musisz przesłać proponowany zestaw do zatwierdzenia. Dokładny proces jest nadal omawiany.

Aby zadeklarować własny zbiór, statyczne zasoby JSON z listą członków i właścicieli powinny być hostowane w pliku /.well-known/first-party-set na najwyższym poziomie każdej domeny uwzględnionej w zbiorze.

W przykładzie zestawu danych własnych brandx domena właściciela hostuje te adresy:https://brandx.site/.well-known/first-party-set

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

Każdy element zbioru zawiera też statyczny zasób JSON, który wskazuje właściciela zbioru. W https://fly-brandx.site/.well-known/first-party-set mamy:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

W przypadku zestawów źródeł własnych obowiązuje kilka ograniczeń:

  • Zestaw może mieć tylko jednego właściciela.
  • Element może należeć tylko do jednego zbioru. Nie można go łączyć z innymi elementami ani nakładać na siebie.
  • Lista członków powinna być zrozumiała dla człowieka i niezbyt duża.

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

Odpowiadający składnik w przypadku plików cookie to proponowany atrybut SameParty. Podanie wartości SamePartymówi przeglądarce, aby uwzględniła plik cookie, gdy jego kontekst należy do tego samego zestawu plików cookie 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

Gdy użytkownik znajduje się na stronie fly-brandx.site i wysyła żądanie do strony brandx.site, w tym żądaniu uwzględniany jest plik cookie session. Jeśli inna witryna, która nie należy do zestawu własnych plików cookie, np. hotel.xyz, wysyła żądanie do brandx.site, plik cookie nie zostanie uwzględniony.

Diagram pokazujący plik cookie brandx.site zezwolony lub zablokowany w kontekstach między witrynami zgodnie z opisem.

Dopóki atrybuty SameParty nie będą obsługiwane powszechnie, używaj atrybutu SameSite, aby zdefiniować zachowanie zastępcze plików cookie. Atrybuty SameParty pozwalają na ustawienie wartości od SameSite=Lax do SameSite=None.

  • SameSite=Lax; SameParty rozszerzy funkcjonalność Lax o konteksty własnego wydawcy, jeśli jest to możliwe, ale w przeciwnym razie użyje ograniczeń Lax.
  • SameSite=None; SameParty ograniczy funkcję None tylko do kontekstów tej samej firmy, w których jest to obsługiwane, ale w przeciwnym razie użyje szerszych uprawnień None.

Istnieją dodatkowe wymagania:

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

Secure jest wymagany, ponieważ nadal występuje w różnych witrynach. Należy minimalizować te zagrożenia, zapewniając bezpieczne połączenia (HTTPS). Ponieważ jest to relacja między witrynami, SameSite=Strict jest nieprawidłowy, ponieważ nadal umożliwia ścisłą ochronę przed atakami CSRF w ramach zestawu.

Jakie zastosowania są odpowiednie dla zestawów źródeł własnych?

Zestawy źródeł własnych są dobrym rozwiązaniem w przypadku, gdy organizacja potrzebuje wspólnej tożsamości w różnych witrynach najwyższego poziomu. W tym przypadku wspólna tożsamość może oznaczać wszystko, od pełnego rozwiązania logowania jednokrotnego po udostępnianie preferencji w różnych witrynach.

Twoja organizacja może mieć różne domeny najwyższego poziomu w przypadku:

  • Domeny aplikacji: office.com,live.com, microsoft.com
  • Domena z nazwą marki: amazon.com, audible.com / disney.com, pixar.com
  • Domena krajowa, aby 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 które zapewniają usługi w witrynach tej samej organizacji: gstatic.com, githubassets.com, fbcdn.net
  • Domena piaskownicy, z którą użytkownicy nigdy bezpośrednio nie wchodzą w interakcję, ale która istnieje ze względów bezpieczeństwa: googleusercontent.com, githubusercontent.com

Jak się zaangażować?

Jeśli masz zestaw witryn, które spełniają powyższe kryteria, możesz skorzystać z kilku opcji. Najmniejszym nakładem pracy jest przeczytanie i dołączenie do dyskusji na temat 2 propozycji:

W trakcie testowania możesz wypróbować tę funkcję, korzystając z flagi wiersza poleceń --use-first-party-set i podając listę witryn rozdzieloną przecinkami.

Możesz to wypróbować na stronie demonstracyjnej 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ć atrybuty w środowisku programistycznym lub dodać atrybut SameParty w środowisku produkcyjnym, aby sprawdzić, jak zestaw plików cookie należących do firmy wpłynie na pliki cookie.

Jeśli masz możliwość eksperymentowania i przesyłania opinii, możesz też zarejestrować się w testach wersji próbnej Origin dla zestawów własnych i SameParty, które są dostępne w Chrome od wersji 89 do 93.

Jak zaktualizować pliki cookie w przypadku wersji próbnej pochodzenia

Jeśli chcesz wziąć udział w testach wersji próbnej i testować atrybut SameParty w plikach cookie, możesz wziąć pod uwagę 2 wzorce.

Opcja 1

Po pierwsze, jeśli masz pliki cookie oznaczone etykietą SameSite=None, ale chcesz ograniczyć ich użycie do kontekstów własnych, możesz dodać do nich atrybut SameParty. W przypadku przeglądarek, w których aktywny jest okres próbny pochodzenia, plik cookie nie będzie wysyłany w kontekstach między witrynami poza zestawem.

Jednak w przypadku większości przeglądarek spoza próby dotyczącej pochodzenia plików cookie, pliki cookie będą nadal wysyłane w innych witrynach jak zwykle. Jest to podejście polegające na stopniowym ulepszaniu.

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

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

Opcja 2

Druga opcja wymaga więcej pracy, ale pozwala całkowicie oddzielić próbną wersję pochodzenia od dotychczasowej funkcjonalności 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 przychodzących żądaniach plik cname-fps powinien być widoczny tylko w przypadku żądań między witrynami, jeśli odpowiednie witryny znajdują się w zestawie, a przeglądarka jest w okresie próbnym. Możesz traktować to podejście jak jednoczesne wdrożenie zaktualizowanej funkcji przed wyłączeniem poprzedniej wersji.

Dlaczego zestawu własnych danych może nie być Ci potrzebny?

W przypadku większości witryn granica witryny jest odpowiednim miejscem do wyznaczenia granicy podziału lub granicy prywatności. Ta ścieżka jest proponowana w ramach CHIPS (Cookies Having Independent Partitioned State), która umożliwi witrynom korzystanie z atrybutu Partitioned, aby nadal móc korzystać z ważnych wstawień, zasobów, interfejsów API i usług w różnych witrynach, a jednocześnie zapobiegać wyciekom informacji umożliwiających identyfikację.

Oto kilka innych kwestii, które mogą oznaczać, że Twoja witryna jest w porządku bez konieczności zmiany ustawień:

  • Hostujesz różne źródła, a nie różne witryny. W przypadku przykładu powyżej, jeśli brandx.site ma wartości fly.brandx.site i drive.brandx.site, to są to różne subdomeny w tej samej witrynie. Pliki cookie mogą używać SameSite=Lax i nie trzeba ich ustawiać.
  • udostępniasz w innych witrynach elementy embedowane pochodzące od innych firm; W wstępie przykład filmu z video.site umieszczonego na stronie my-blog.site wyraźnie pokazuje podział na treści własne i treści innych firm. Witryny są obsługiwane przez różne organizacje, a użytkownicy postrzegają je jako osobne podmioty. Te 2 witryny nie powinny znajdować się w jednym zestawie.
  • Usługa zewnętrzna umożliwia logowanie się w mediach społecznościowych. Dostawcy tożsamości, którzy korzystają z protokołów takich jak OAuth czy OpenId Connect, często polegają na plikach cookie innych firm, aby zapewnić użytkownikom płynniejsze logowanie. Jest to ważny przypadek użycia, ale nie nadaje się do zestawów źródeł własnych, ponieważ występuje wyraźna różnica w organizacjach. Wczesne propozycje, takie jak WebID, badają sposoby na wdrożenie tych zastosowań.