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

Wiele organizacji ma powiązane witryny w różnych nazwach domen, np. brandx.site i fly-brandx.site – lub domeny w przypadku innych krajów, takich jak example.com, example.rs, example.co.uk itd.

Przeglądarki zmierzają w kierunku tworzenia plików cookie innych firm nieaktualny dla większej prywatności w internecie, ale witryny takie jak te często korzystają z plików cookie funkcje, które wymagają utrzymywania i utrzymywania stanu w wielu domenach; (np. logowanie jednokrotne i zarządzanie zgodą użytkowników).

Zestawy źródeł własnych mogą zezwalać na powiązane nazwy domen, które należą do Ciebie i są przez nie obsługiwane ten sam podmiot jest traktowany jako własny w sytuacjach, gdy są traktowane inaczej. Nazwy domen w tagu są uznawane za pliki tej samej strony i mogą oznaczać, które pliki cookie są które mają być ustawione lub wysyłane w kontekście tej samej strony. Celem jest znalezienie aby zachować równowagę pomiędzy zapobieganiem śledzeniu w witrynach przez osoby trzecie, utrzymywania ścieżki, która nie narusza prawidłowych przypadków użycia.

Propozycja zestawów źródeł własnych jest obecnie testowana etapie, dowiesz się, jak to działa. i sposoby jej wypróbowania.

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

Pliki cookie nie są z założenia własne ani pliki cookie innych firm, zależą od w którym znajduje się plik cookie. To albo na żądanie w cookie lub przez document.cookie w JavaScripcie.

Jeśli na przykład video.site ma plik cookie theme=dark, podczas przeglądania Żądanie video.site jest wysyłane do video.site, czyli ta sama strona kontekstu oraz uwzględniony plik cookie to własny plik cookie.

Jeśli jednak korzystasz z my-blog.site, który osadza odtwarzacz iframe dla video.site, gdy żądanie jest wysyłane z my-blog.site do video.site , czyli kontekst pochodzący z innej witryny, a plik cookie theme to plik innej firmy.

Uwzględnienie plików cookie jest określane na podstawie jego atrybutu SameSite:

• Ta sama witryna kontekstu za pomocą Dzięki SameSite=Lax, Strict lub None plik cookie jest własny.
• Kontekst w wielu witrynach z ustawieniem SameSite=None sprawia, że plik cookie jest innym dostawcą.

Nie zawsze jest to jednak oczywiste. Wyobraź sobie, że brandx.site to podróż witryny rezerwacji. Korzysta on też z usług fly-brandx.site i drive-brandx.site, oddzielne loty i wynajem samochodów. W trakcie rezerwacji jednej podróży użytkownicy między nimi wybrać różne opcje – oczekują, „koszyk na zakupy” wybranych elementów, które pozostaną niezmienione w tych witrynach. brandx.site zarządza sesją użytkownika za pomocą pliku cookie SameSite=None, aby zezwolić na w różnych witrynach. Wadą jest jednak to, że teraz plik cookie nie zawiera już wielu witryn. Poproś o ochronę przed oszustwami (CSRF). Jeśli evil.site zawiera prośbę do brandx.site, wówczas uwzględnia on ten plik cookie.

Plik cookie pochodzi z innej witryny, ale wszystkie te witryny należą do tej samej witryny i są przez nią zarządzane Twojej organizacji. Użytkownicy wiedzą też, że jest to ta sama organizacja i chcą oni, w tej samej sesji, czyli w ramach wspólnej tożsamości.

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

Zestawy źródeł własnych zawierają metody jednoznacznego definiowania tej relacji między wieloma witrynami, które należą do tej samej strony i są przez nią zarządzane. Dzięki temu brandx.site będzie mogła: zdefiniować własną relację z platformą fly-brandx.site, drive-brandx.site itd.

model prywatności, różne propozycje Piaskownicy prywatności opierają się na koncepcji partycjonowania, tożsamości w celu zapobiegania śledzeniu w witrynach, czyli rysowania granic między witrynami, ogranicza dostęp do informacji, które mogą posłużyć do identyfikacji użytkowników.

Choć opcja domyślna to partycjonowanie według witryny, co rozwiązuje wiele problemów przypadków użycia, przykład brandx.site pokazuje, że własne dane mogą być większe niż tylko jedną witrynę.

Ważną częścią propozycji zestawów źródeł własnych jest zagwarantowanie, że zasady w różnych przeglądarkach zapobiega nadużyciom i niewłaściwemu używaniu. Na przykład zestawy źródeł własnych nie mogą umożliwiać wymianę informacji o użytkownikach w niepowiązanych witrynach lub które nie należą do tego samego podmiotu. Chodzi o to, aby Zestaw źródeł własnych mapuje się na coś, co użytkownik rozumie jako własne, nie służą do dzielenia się tożsamością między różnymi stronami.

Jednym z możliwych sposobów zarejestrowania własnego zestawu przez witrynę może być mogą przesłać proponowaną grupę domen do publicznego narzędzia do śledzenia (np. dedykowanego repozytorium GitHub) oraz informacji potrzebnych do obsługi przeglądarki .

Gdy potwierdzenie zestawu własnych zostanie zweryfikowane zgodnie z zasadami, przeglądarki mogą a następnie pobierać listy zbiorów w ramach procesu aktualizacji.

Testowanie origin ma określoną zasadę, która nie jest ostateczna. prawdopodobnie pozostaną takie same:

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

.

Jak zdefiniować zbiór własnych

Gdy określisz członków i właściciela zasobów własnych organizacji istotnym krokiem będzie przesłanie proponowanego zestawu do zatwierdzenia. Dokładny jest nadal w trakcie dyskusji.

Aby zadeklarować zbiór własny, statyczne zasoby JSON zawierające listę członków i właścicieli powinien być hostowany w /.well-known/first-party-set na najwyższym poziomie każdego .

W przykładzie ze zbioru danych własnych brandx domena-właściciela hostuje zasób obserwuję na 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 klucz właściciela zestawu zdjęć. Firma https://fly-brandx.site/.well-known/first-party-set zapewnia:

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

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

• Zestaw może mieć tylko jednego właściciela.
• Jeden użytkownik może należeć tylko do jednego zestawu. Treści nie mogą się nakładać ani mieszać.
• Lista członków powinna być względnie czytelna dla człowieka. zbyt duże.

.

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

Składnikiem pasującym do plików cookie jest proponowany SameParty . Określanie: SameParty informuje przeglądarkę, że ma uwzględnić plik cookie, jeśli jego kontekst jest częścią tego samego jako kontekstu 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 otworzy stronę fly-brandx.site i prześle żądanie do brandx.site, do tego żądania zostanie dołączony plik cookie session. Jeśli jakaś inna witryna, która nie wchodzi w skład zestawu danych własnych, na przykład hotel.xyz, wysyła żądanie do brandx.site, plik cookie nie zostanie uwzględniony.

Dopóki SameParty nie stanie się powszechnie obsługiwany, używaj razem z nim atrybutu SameSite, aby określić zachowanie zastępcze dla plików cookie. Czas na SameParty jako dający ustawienie od SameSite=Lax do SameSite=None

• SameSite=Lax; SameParty rozszerza funkcję Lax na uwzględniają konteksty tej samej strony, jeśli są obsługiwane, ale wracają do Lax ograniczenia, jeśli nie są.
• SameSite=None; SameParty ograniczy funkcję None do tylko konteksty tej samej strony, jeśli są obsługiwane, ale wracają do szerszego None, jeśli nie.

Istnieją dodatkowe wymagania:

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

Działanie Secure jest obowiązkowe, ponieważ nadal działa ona w innej witrynie i musisz wyeliminować te problemy związanych z bezpieczeństwem, zapewniając bezpieczne połączenia (HTTPS). Podobnie, ponieważ jest to relacji między witrynami, atrybut SameSite=Strict jest nieprawidłowy, ponieważ nadal zezwala na ściśle związanych z witryną zabezpieczeń CSRF.

Jakie przypadki użycia sprawdzają się w przypadku zestawów źródeł własnych?

Zestawy źródeł własnych dobrze sprawdzają się w przypadkach, gdy organizacja potrzebuje formy tę samą tożsamość w różnych witrynach najwyższego poziomu. W tym przypadku wspólna tożsamość oznacza wszystko, od rozwiązania w pełni z logowaniem jednokrotnym po po prostu potrzebę wspólnego w różnych witrynach.

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

• Domeny aplikacji: office.com,live.com, microsoft.com
• Domeny oznaczone marką: amazon.com, audible.com / disney.com, pixar.com
• Domeny krajowe, które umożliwiają 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 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średnie interakcje, ale istnieją przyczyny bezpieczeństwa: googleusercontent.com, githubusercontent.com

Jak się zaangażować?

Jeśli masz zbiór witryn spełniających powyższe kryteria, jest ogromna liczba opcji. Najprostsze inwestowanie w czytanie i dołączanie dyskusję na temat obu propozycji:

• Dyskusja w grupie społeczności związanej z prywatnością zestawów źródeł własnych
• Omówienie atrybutów pliku cookie SameParty

Na etapie testowania możesz wypróbować tę funkcję za pomocą flagę wiersza poleceń --use-first-party-set i podaj listę oddzieloną przecinkami witryn.

Możesz go wypróbować w witrynie demonstracyjnej pod adresem https://fps-member1.glitch.me/ po rozpoczęciu 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 przeprowadzać testy w środowisku programistycznym lub spróbuj dodać atrybut SameParty w aktywnym środowisku, aby sprawdzić, jak własny zestaw będzie miał wpływ na pliki cookie.

Jeśli masz wystarczającą przepustowość do eksperymentów i opinii, możesz też się zarejestrować dla testu origin dla zestawów użytkowników SameParty który jest dostępny w Chrome od wersji 89 do 93.

Jak aktualizować pliki cookie na potrzeby testowania origin

Jeśli dołączasz do wersji próbnej origin i testujesz atrybut SameParty na plików cookie, warto wziąć pod uwagę 2 wzorce.

Opcja 1

Po pierwsze, jeśli masz pliki cookie oznaczone jako SameSite=None, ale chcesz ograniczyć się do własnych kontekstów, możesz dodać SameParty i jaką rolę odgrywają. W przeglądarkach, w których aktywna jest wersja testowa origin, plik cookie będzie nie mogą być wysyłane poza witryną.

Jednak dla większości przeglądarek nieobjętych testem origin, plik cookie będzie nadal wysyłany między witrynami. Potraktuj to jako metodę stopniowego 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 pozwala w pełni oddzielić źródło wersji testowej istniejącej funkcji, a w szczególności umożliwia testowanie Kombinacja: 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 dla przychodzących żądań należy spodziewać się wyświetlenia pliku cookie cname-fps w żądaniu z innej witryny, jeśli odpowiednie witryny są a przeglądarka jest w fazie testowania origin. Rozważ to podejście jednoczesne uruchomienie zaktualizowanej funkcji przed wyłączeniem poprzedniej wersji.

Dlaczego własny zestaw może być niepotrzebny?

W przypadku większości witryn ich granice stanowią akceptowalny punkt do granicy partycji czy prywatności. To jest trasa, która jest proponowana CHIPS (pliki cookie z niezależnymi partycjami) stan), który umożliwia wyrażenie zgody na wykorzystanie danych. przez atrybut Partitioned, aby nadal mieć te krytyczne umieszczone zasoby, zasoby, interfejsy API i usługi, jednocześnie zapobiegając wyciekowi danych identyfikujących informacji z różnych witryn.

Kilka innych kwestii, o których warto pamiętać, że Twoja witryna może działać poprawnie bez konieczności zestaw:

• Hostujesz w różnych źródłach, a nie w różnych witrynach. W przykładzie powyżej jeśli brandx.site ma fly.brandx.site i drive.brandx.site, to te to różne subdomeny w tej samej witrynie. Pliki cookie mogą używać SameSite=Lax i nie są one potrzebne.
• W innych witrynach udostępniasz linki do stron zewnętrznych. We wstępie mamy dla Ciebie przykład film z kanału video.site umieszczony w witrynie my-blog.site pochodzi od wyraźnego twórcy dzielenia. Te witryny są obsługiwane przez różne organizacje, a użytkownicy widzą je jako oddzielne podmioty. Te dwie witryny nie powinny znajdować się w zestawie.
• Dostarczasz zewnętrzne usługi logowania do mediów społecznościowych. Dostawcy tożsamości korzystający z takie jak OAuth czy OpenId Connect często wykorzystują pliki cookie innych firm do bezproblemowe logowanie. Prawidłowy przypadek użycia, ale nie odpowiedni w przypadku zestawów źródeł własnych, ponieważ występują znaczne różnice w organizacjach. Wczesne oferty pakietowe, takie jak WebID, są nowych sposobów na wprowadzenie tych przypadków użycia.