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
lubNone
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ą doLax
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 szerszegoNone
, jeśli nie.
Istnieją dodatkowe wymagania:
- Pliki cookie
SameParty
muszą zawieraćSecure
. - Pliki cookie
SameParty
nie mogą zawierać elementuSameSite=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
mafly.brandx.site
idrive.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 witryniemy-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.