Zestawy źródeł własnych (FPS) mają ułatwiać użytkownikom przeglądanie internetu po wycofaniu obsługi plików cookie innych firm w Chrome. Propozycja została znacznie rozwinięta na forach otwartej sieci podczas okresu inkubacji FPS, najpierw w grupie społeczności dotyczącej prywatności W3C, a obecnie w grupie społeczności dotyczącej inkubatora internetowego.
W tym poście na blogu omówimy proces ewolucji, przedstawimy najważniejsze zmiany i wyjaśnimy, dlaczego uważamy, że takie zmiany poprawiają prywatność w internecie, a jednocześnie nadal wspierają ekosystem.
Tło
Strony często korzystają z dostępu do plików cookie w kontekście zewnętrznym, aby zapewnić użytkownikom płynne i spersonalizowane wrażenia. Oprócz interfejsów API reklam chroniących prywatność (Topics, Protected Audience API i atrybucja) zespół Chrome starał się poznać zakres scenariuszy, w których pliki cookie innych firm były używane nie tylko do personalizacji reklam i pomiarów, ale też do zapewnienia użytkownikom lepszych wrażeń podczas przeglądania.
Okazało się, że organizacje mogą korzystać z plików cookie innych firm, ponieważ ich architektura internetowa jest zaprojektowana pod kątem korzystania z wielu domen. Na przykład organizacja może mieć jedną domenę dla bloga o wędrówkach, a drugą dla sklepu z sprzętem biwakowym i chcieć ułatwić użytkownikom poruszanie się po tych witrynach. Organizacja może też utrzymywać wiele domen z kodem kraju z współdzieloną infrastrukturą dla swojej usługi internetowej. W takich przypadkach staramy się tworzyć rozwiązania dostosowane do potrzeb takich organizacji, które jednocześnie spełniają oczekiwania użytkowników dotyczące prywatności w internecie.
Od czego zaczęliśmy
Ponieważ przeglądarka obecnie używa granicy na poziomie witryny, aby interpretować „własne” i „obce”, uwzględniając zakres domen, którymi może zarządzać organizacja, uznaliśmy, że należy zastąpić tę techniczną granicę bardziej zróżnicowaną definicją.
W 2021 r. Chrome początkowo zaproponował atrybut pliku cookie SameParty dla zestawów źródeł własnych, aby witryny mogły definiować pliki cookie pochodzące z witryn w ramach „tego samego źródła”. Aby określić, co oznacza „ta sama strona”, skorzystaliśmy z zasady dotyczącej klienta użytkownika. W definicji tych zasad staraliśmy się oprzeć się na istniejących ramach „uczestnika” (np. na specyfikacji DNT W3C) i zastosować zalecenia z odpowiednich dyskusji na temat prywatności (np. z raportu Federalnej Komisji Handlu z 2012 r. „Protecting Consumer Privacy in an Era of Rapid Change”).
W tamtym czasie uważaliśmy, że to podejście zapewnia wystarczającą elastyczność w przypadku różnych typów organizacji z różnych branż, a zarazem pozwala nam realizować nasz podstawowy cel, którym jest ograniczenie powszechnego śledzenia za pomocą plików cookie innych firm.
Opinia na temat wstępnej propozycji
W trakcie wielu rozmów z zainteresowanymi stronami w ekosystemie internetowym stwierdziliśmy, że ta pierwotna wersja ma pewne ograniczenia.
Wyzwania związane z prywatnością w przypadku pasywnego dostępu do plików cookie za pomocą atrybutu SameParty
Inni dostawcy preferowali aktywne podejście do dostępu do plików cookie innych firm, które wymagało jawnego wywołania interfejsu API, zamiast wyznaczania granicy, w której można było zachować pasywny dostęp do plików cookie. Aktywna prośba o dostęp do plików cookie zapewnia przeglądarce widoczność i kontrolę, dzięki czemu można ograniczyć ryzyko ukrytego śledzenia za pomocą plików cookie innych firm. Pozwoliłoby to przeglądarkom na umożliwienie użytkownikom zezwolenia na dostęp do takich plików cookie lub ich zablokowania.
Postanowiliśmy pójść w tym kierunku, ponieważ chcemy zapewnić interoperacyjność w różnych przeglądarkach oraz zwiększyć bezpieczeństwo użytkowników.
Problemy z wdrażaniem proponowanych zasad
Pierwotna polityka zawierała 3 wymagania dotyczące domen, które muszą być w jednym zestawie: „wspólna własność”, „wspólna polityka prywatności” i „wspólna tożsamość grupy”.
W większym ekosystemie zauważyliśmy, że opinie na temat zasad koncentrują się wokół 4 głównych tematów.
Wspólna własność jest zbyt restrykcyjna
W odniesieniu do wymagań dotyczących „wspólnej własności” otrzymaliśmy opinię, że definicja FPS, która skupia się wyłącznie na własności korporacyjnej, dałaby większym firmom większą możliwość gromadzenia danych z różnych domen i usług skierowanych do użytkowników niż mniejszym firmom. Naszym celem jest stworzenie Piaskownicy prywatności dla całego ekosystemu, dlatego poważnie potraktowaliśmy te opinie i nadaliśmy priorytety rozwiązaniom, które były bardziej wszechstronne.
Jedna zasada ogranicza rozszerzalność do przypadków użycia
Chociaż idea kompleksowych zasad regulujących granice miała na celu zapewnienie elastyczności w przypadku różnych typów domen, które powinny znajdować się w ramach FPS organizacji, okazało się, że niektóre krytyczne przypadki użycia nie mogą spełniać tych wymagań. Na przykład domeny usług (takich jak domeny hostujące treści generowane przez użytkowników) mogą wymagać dostępu do plików cookie w kontekście zewnętrznym, aby uwierzytelniać lub identyfikować użytkowników. Takie domeny rzadko mają stronę główną dostępną dla użytkowników, więc nie można spełnić wymagań dotyczących „wspólnej tożsamości grupy” lub „wspólnej polityki prywatności” w przypadku innych domen w tym samym FPS.
Sposób postrzegania i rozumienia tożsamości grup przez użytkowników może się różnić.
Pierwotnie zaproponowaliśmy zabezpieczenia mające na celu zdefiniowanie „wspólnej tożsamości grupy” jako próby określenia zakresu domen w jednym zbiorze, które można łatwo powiązać ze wspólną tożsamością grupy. Nie udało nam się jednak zdefiniować środków technicznych, które pozwoliłyby zmierzyć i ocenić, czy wspólna tożsamość grupy jest „łatwo dostępna dla użytkowników”. Mogło to prowadzić do nadużyć i pytań dotyczących egzekwowania zasad.
Otrzymaliśmy też opinię, że rozumienie znaczenia granic „wspólnej własności” może się różnić w zależności od użytkownika, co utrudnia tworzenie wytycznych, które można stosować we wszystkich witrynach.
Zasady oparte na subiektywnej ocenie trudno egzekwować na dużą skalę
Otrzymaliśmy wiele próśb o bardziej szczegółowe wytyczne, biorąc pod uwagę subiektywny charakter niektórych wymagań (np. „wspólna tożsamość grupy”) oraz potrzebę uwzględnienia wyjątków lub przypadków szczególnych (dotyczących „wspólnej polityki prywatności”).
Aby zapewnić sprawiedliwe i spójne stosowanie zasad, Chrome musiałby udostępnić autorom witryn znacznie bardziej szczegółowe wytyczne. Uznaliśmy, że próba stworzenia bardziej rygorystycznych wytycznych może zaszkodzić ekosystemowi.
Początkowo zaproponowaliśmy, aby niezależny podmiot egzekwujący pełnił rolę organu badającego i egzekwującego zgodność z zasadami, ale w obecnym ekosystemie znalezienie niezależnego podmiotu egzekwującego o odpowiednich kompetencjach, który mógłby w obiektywny sposób realizować te obowiązki, było trudne. Zamiast tego staraliśmy się przejść na zasady, które można egzekwować technicznie, aby zapewnić spójne i obiektywne stosowanie zasad.
Ewolucja
W odpowiedzi na opinie użytkowników zmieniliśmy interfejs FPS. Wróciliśmy do konkretnych problemów, które chcieliśmy rozwiązać, i postanowiliśmy przedstawić propozycję w prostszy sposób, skupiając się na konkretnych przypadkach użycia.
Rozwiązywanie najważniejszych problemów
Aby sprostać najważniejszym potrzebom użytkowników w internecie, opracowaliśmy 3 różne „podzbiory” Chrome. Podejście z użyciem podzbiorów jest lepsze od starego podejścia, ponieważ jest bardziej prywatne, bardziej szczegółowe i łatwiejsze do konsekwentnego egzekwowania.
- „ccTLD” (domeny krajowe najwyższego poziomu) – organizacje mogą prowadzić witryny z różnymi domenami krajowymi najwyższego poziomu, aby zapewnić lokalizację treści. Te witryny mogą nadal wymagać dostępu do wspólnych usług i infrastruktury.
- Domeny „usługi” – strony mogą używać oddzielnych domen ze względów bezpieczeństwa lub wydajności, a aby mogły one działać, mogą wymagać dostępu do tożsamości użytkownika.
- „Powiązane” domeny – organizacje mogą utrzymywać wiele witryn dla różnych powiązanych marek lub produktów. Mogą one potrzebować dostępu do plików cookie w wielu domenach w takich przypadkach jak analiza ścieżek użytkowników w powiązanych witrynach, aby lepiej zrozumieć, jak użytkownicy danej organizacji wchodzą w interakcje z jej witrynami, lub zapamiętać stan zalogowania użytkownika w powiązanej witrynie, która korzysta z tej samej infrastruktury logowania.
W przypadku każdego z tych zastosowań istnieją odrębne wymagania, odpowiednie weryfikacje techniczne i specyficzne zachowania związane z obsługą przeglądarki (więcej informacji znajdziesz w wytycznych dotyczących przesyłania). Zmiany te eliminują ograniczenia pierwotnej propozycji, ponieważ rezygnujemy z ogólnego rozwiązania na rzecz zróżnicowanych ram opartych na konkretnych przypadkach użycia.
Możliwość interoperacyjności dzięki aktywnym żądaniom dostępu do plików cookie innych firm
Chrome chętnie promuje interoperacyjność z innymi przeglądarkami, aby zapewnić prawidłowe działanie platformy internetowej. Inne przeglądarki, takie jak Safari, Firefox i Edge, korzystają obecnie z interfejsu Storage Access API (SAA) do obsługi żądań aktywnych plików cookie. Zdecydowaliśmy się wykorzystać interfejs SAA w Chrome, aby nie tylko uwzględnić otrzymane od Was opinie, ale też zapewnić interoperacyjność w internecie.
Aby zapewnić deweloperom większą elastyczność i wyeliminować znane ograniczenia związane z interfejsem SAA, proponujemy też interfejs API requestStorageAccessForOrigin.
Możliwość jednoczesnego korzystania z interfejsu Storage Access API i FPS
Podczas wdrażania interfejsu Storage Access API (SAA) przeglądarki mogą prosić użytkowników bezpośrednio o przyznanie uprawnień, a inne mogą zezwolić na ograniczoną liczbę żądań bez wyświetlania prośby o przyznanie uprawnień.
Chrome uważa, że FPS może stanowić przezroczystą warstwę nad SAA, ograniczając trudności użytkowników i zapobiegając zmęczeniu związanemu z wyświetlaniem komunikatów w przypadku kluczowych ograniczonych przypadków użycia. FPS daje też przeglądarkom możliwość zapewnienia użytkownikom dodatkowego kontekstu dotyczącego członkostwa w zestawie, jeśli zdecydują się poprosić użytkowników o pozwolenie.
Dzięki zestawom źródeł własnych deweloperzy mogą identyfikować własne witryny, na których występują problemy, a które służą do obsługi kluczowych przypadków użycia. Dzięki temu deweloperzy w agencji mogą przewidzieć, jak ich witryny będą działać dla użytkowników, i podejmować działania, aby ograniczyć wpływ na wrażenia użytkowników, korzystając z FPS lub alternatywy dla plików cookie innych firm. Dodatkowo FPS zapewnia przewidywalność platformy dla deweloperów, w przeciwieństwie do heurystyki, która może się zmieniać z czasem lub powodować różne zachowania w zależności od użytkownika.
Wreszcie deweloperzy, którzy wdrożą SAA do współpracy z FPS w Chrome, będą mogli korzystać z SAA do zwiększania wydajności swoich witryn w innych przeglądarkach, nawet w tych, które nie obsługują FPS.
Kontynuowanie dyskusji
Uważamy, że nasze najnowsze propozycje stanowią właściwy kompromis, który uwzględnia potrzeby użytkowników i deweloperów. Dziękujemy za opinie, które pomogły nam udoskonalić propozycję dotyczącą FPS.
Zdajemy sobie sprawę, że zainteresowane strony ekosystemu internetowego wciąż zapoznają się ze zaktualizowaną propozycją. Prosimy o współpracę, abyśmy mogli nadal ulepszać projekt w sposób przydatny dla deweloperów i umożliwiający dalsze zwiększanie prywatności w internecie. Google będzie też nadal współpracować z brytyjskim Urzędem ds. Konkurencji i Rynków (CMA), aby zapewnić zgodność z zobowiązaniami.
Aby zachęcić użytkowników do interakcji, zapoznaj się z tymi materiałami:
- Inkubacja w WICG
- Instrukcje testowania liczby klatek na sekundę
- Zestawy źródeł własnych: przewodnik integracji
- FPS Submission Guidelines
Współpraca z ekosystemem
Cieszymy się, że firmy takie jak Salesforce i CafeMedia angażują się w proces gromadzenia opinii i rozwijania zestawów danych własnych. odegrały kluczową rolę w rozwijaniu tej technologii. Inni użytkownicy również podzielili się swoimi przemyśleniami na temat zestawów danych własnych i starań Chrome, aby współpracować z ekosystemem internetowym:
„W Chrome tworzymy zestawy źródeł własnych, aby dostosować je do wielu naszych zastosowań, np. do zachowania ścieżek użytkownika. To pokazuje, że zespół Google stara się zrozumieć różne potrzeby właścicieli witryn w internecie”. – Mercado Libre
„W VWO doceniamy wysiłki Google na rzecz podnoszenia standardów prywatności i zapewnienia, że prawdziwe przypadki użycia są obsługiwane. To świetne, że nasz zespół współpracuje z ekosystemem deweloperów i stale ulepsza implementację propozycji zestawów własnych na podstawie opinii zainteresowanych stron. Cieszymy się, że możemy uczestniczyć w testowaniu tej propozycji i z niecierpliwością czekamy na jej wdrożenie w przeglądarce”. – Nitish Mittal, dyrektor ds. inżynierii, VWO