[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 i example.co.uk.

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 zwykłe źródła własne i zewnętrzne są traktowane 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 powoduje nieprawidłowego działania przypadków użycia.

Propozycja dotycząca zestawów własnych jest w fazie testów. Czytaj dalej, aby dowiedzieć się, jak to działa i jak możesz to 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 np. 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 witryny my-blog.site do witryny video.site będzie żądaniem w kontekście witryny, a plik cookie theme będzie plikiem cookie zewnętrznym.

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

  • Kontekst w ramach tej samej witryny z użyciem 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 rezerwacji podróży, 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 widoczny 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 chroniony przed atakami polegającymi na fałszowaniu żądań z innej witryny (CSRF). Jeśli evil.site zawiera żądanie wysłane do brandx.site, zawiera ono też ten 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ść.

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

Zestawy źródeł własnych to metoda określania tych relacji w wielu witrynach, które należą do tej samej strony i są przez nią zarządzane. Umożliwiłoby to brandx.site zdefiniowanie relacji z usługami fly-brandx.site i drive-brandx.site.

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.

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ę.

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 dotyczącego zestawu źródeł własnych zgodnie z zasadami przeglądarki mogą pobierać listy zestawó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 swojej 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 inne elementy.
  • 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 ustawia ten plik cookie:

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

Gdy użytkownik znajduje się na stronie fly-brandx.site, a żądanie trafia do brandx.site`, then thesession`cookie will be included on that request. If some other site which is not a part of the first-party set, for examplehotel.xyz, sends a request tobrandx.site`, plik cookie nie jest uwzględniany.

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

  • SameSite=Lax; SameParty rozszerzy funkcjonalność Lax o konteksty własne, jeśli jest to możliwe, ale w przeciwnym razie użyje ograniczeń Lax.
  • SameSite=None; SameParty ograniczy funkcjonalność 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
  • domeny piaskownicy, z którymi użytkownicy nigdy nie mają bezpośredniej interakcji, ale istnieją ze względów bezpieczeństwa: googleusercontent.com, githubusercontent.com

Jak możesz się zaangażować?

Jeśli masz zestaw witryn, które spełniają te 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ę, używając 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 chcesz 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 czas na eksperymentowanie i przesyłanie 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.

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 z oznaczeniem SameSite=None, ale chcesz ograniczyć ich użycie do kontekstów własnych, możesz dodać do nich atrybut SameParty. W przeglądarkach, w których aktywny jest okres próbny pochodzenia, plik cookie nie będzie wysyłany w kontekście witryn spoza zestawu.

Jednak w przypadku większości przeglądarek spoza próby dotyczącej pochodzenia plików cookie nadal będą one wysyłane w ramach witryny tak jak do tej pory. 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 ramach testu pochodzenia. Rozwiązanie to można porównać z jednoczesnym uruchomieniem nowej funkcji przed wyłączeniem poprzedniej wersji.

Dlaczego nie potrzebujesz zestawu własnego?

W przypadku większości witryn ich granica jest odpowiednim miejscem do wyznaczenia granicy podziału lub granicy prywatności. Ta metoda jest proponowana w ramach CHIPS (Cookies Having Independent Partitioned State), która umożliwi witrynom korzystanie z atrybutu Partitioned, aby nadal korzystać z kluczowych wbudowanych elementów, zasobów, interfejsów API i usług w wielu witrynach, a jednocześnie zapobiegać wyciekom informacji identyfikujących.

Oto kilka innych kwestii, które mogą oznaczać, że Twoja witryna jest w porządku i nie wymaga konfiguracji:

  • Hostujesz różne źródła, a nie różne witryny. W tym przykładzie brandx.site ma wartości fly.brandx.site i drive.brandx.site, więc 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 usług takich jak OAuth czy OpenId, 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 danych własnych, ponieważ występuje wyraźna różnica w organizacjach. Wczesne propozycje, takie jak WebID, badają sposoby na wdrożenie tych przypadków użycia.