Zestawy źródeł własnych (FPS) umożliwiają użytkownikom przeglądanie internetu po wycofaniu plików cookie innych firm z Chrome. W trakcie inkubacji FPS propozycja rozwinęła się znacząco na forach w otwartej sieci, najpierw w grupie Społeczności ds. prywatności W3C, a teraz w grupie społeczności Web Incubator.
W tym poście podsumujemy proces ewolucji, omówimy najważniejsze zmiany i porozmawiamy, dlaczego wierzymy, że takie zmiany poprawiają ochronę prywatności w sieci, a jednocześnie wspierają ekosystem.
Wprowadzenie
Witryny często polegają na dostępie do plików cookie w kontekście innych firm, aby zapewnić użytkownikom płynne i dostosowane działanie. Oprócz interfejsów interfejsów API reklam z zachowaniem prywatności (Topics, Protected Audience API, Attribution) zespół Chrome chciał poznać też zakres sytuacji, w których stosowane były pliki cookie innych firm – poza personalizacją reklam i pomiarami – w celu zwiększenia wygody użytkowników podczas przeglądania internetu.
Odkryliśmy, że organizacje mogą polegać na plikach cookie innych firm, ponieważ ich architektura internetowa umożliwia wykorzystywanie wielu domen. Na przykład organizacja może mieć jedną domenę dla swojego bloga o treningach, a drugą do sklepu kempingowego, i chceć wspierać użytkowników w tych witrynach. Organizacja może też mieć wiele domen krajowych ze wspólną infrastrukturą dla usług internetowych. W takich przypadkach postawiliśmy sobie za cel stworzenie rozwiązania, które będzie odpowiadało potrzebom takich organizacji, a jednocześnie spełniło oczekiwania użytkowników dotyczące ochrony prywatności w internecie.
Pierwsze kroki
Ponieważ przeglądarka używa obecnie granic na poziomie witryny do interpretowania pojęć własnych i innych firm, tak aby uwzględnić zakres domen, którymi może zarządzać organizacja, wydawało się nam zastąpienie tej granicy technicznej bardziej szczegółową definicją.
W 2021 r. Chrome po raz pierwszy zaproponował atrybut pliku cookie SameParty dla zestawów źródeł własnych, aby witryny mogły definiować pliki cookie pochodzące z witryn tej samej strony. Użyliśmy zasad dotyczących klienta użytkownika, aby określić, co uznajemy za „tę samą stronę”. Ta definicja zasad opierała się na istniejących strukturach „stronicowych” (np. ze specyfikacji W3C DNT) oraz uwzględniała zalecenia z odpowiednich dyskusji dotyczących prywatności (np. raport Federalnej Komisji Handlu z 2012 r. zatytułowany „Ochrona prywatności konsumentów w erze Szybkich zmian”).
W tamtym okresie uważaliśmy, że to podejście zapewnia wystarczającą elastyczność dla różnych typów organizacji i branż, a jednocześnie wpisuje się w naszą podstawę, czyli zminimalizowanie powszechnego śledzenia śledzenia z wykorzystaniem plików cookie innych firm.
Opinia na temat początkowej oferty pakietowej
Dzięki licznym rozmowom z zainteresowanymi osobami w ekosystemie internetowym doszliśmy do wniosku, że ten początkowy projekt ma pewne ograniczenia.
Wyzwania związane z prywatnością w przypadku pasywnego dostępu do plików cookie za pomocą atrybutu SameParty
Inne przeglądarki preferują aktywne podejście do uzyskiwania dostępu do plików cookie innych firm, które wymaga wyraźnego wywołania interfejsu API, zamiast wyznaczania granicy, w której można zachować pasywny dostęp do plików cookie. Aktywne prośby o dostęp do plików cookie zapewniają widoczność i kontrolę w przeglądarce, co pozwala ograniczyć ryzyko związane z tajemnym śledzeniem za pomocą plików cookie innych firm. Dodatkowo taka widoczność umożliwi przeglądarkom możliwość zezwolenia na dostęp do plików cookie lub jego zablokowania.
Zdecydowaliśmy się pójść w tym kierunku, ponieważ chcemy zapewnić interoperacyjność między przeglądarkami, a także zapewnić ochronę prywatności.
Problemy z wdrażaniem proponowanej zasady
W pierwotnej zasadzie proponowano 3 wymagania, które trzeba spełnić, aby domeny znajdowały się w jednym zestawie: „wspólna własność”, „wspólna polityka prywatności” i „wspólna tożsamość grupy”.
Na podstawie opinii o tych zasadach dowiedzieliśmy się, że są one związane z 4 głównymi tematami.
Wspólna własność jest zbyt restrykcyjna
Jeśli chodzi o wymóg „wspólnej własności”, otrzymaliśmy opinię, że definicja usług finansowych, które skupiają się wyłącznie na własności korporacyjnej, pozwoli dużym firmom na łączenie danych z wielu różnych domen i usług dla użytkowników w porównaniu z mniejszymi firmami. Ponieważ naszym celem jest stworzenie Piaskownicy prywatności dla całego ekosystemu, potraktowaliśmy te opinie poważnie i postanowiliśmy skupić się na rozwiązaniu bardziej inkluzywnym.
Jedna zasada ogranicza rozszerzalność na przypadki użycia
Chociaż idea holistycznej zasady regulowania granic miała zapewnić elastyczność różnym typom domen, które powinny być uwzględnione w FPS organizacji, okazało się, że niektóre kluczowe przypadki użycia mogą nie być zgodne z tym projektem zasad. Na przykład domeny usług (takie jak te hostujące treści użytkowników) mogą wymagać dostępu do swoich plików cookie w kontekście innej firmy, aby uwierzytelnić lub zidentyfikować użytkowników. W takich domenach rzadko ma stronę główną dostępną dla użytkowników, więc nie mogliśmy spełnić wymagań związanych z „wspólną tożsamością grupy” lub „wspólną polityką prywatności” w przypadku innych domen w tej samej liczbie klatek na sekundę.
Użytkownicy mogą inaczej postrzegać i rozumieć tożsamość grupy
Pierwotnie zaproponowaliśmy bariery definiujące „wspólną tożsamość grupy” jako próbę określenia zakresu domen w jednym zestawie do tych, które można łatwo powiązać ze wspólną tożsamością grupy. Nie udało nam się jednak zdefiniować technicznych środków do pomiaru i oceny, czy wspólna tożsamość grupy da się „łatwo znaleźć dla użytkowników”. Mogło to wiązać się z potencjalnymi nadużyciami i pytaniami o egzekwowanie zasad.
Otrzymaliśmy opinie, że rozumienie granic „wspólnej własności” może być uzależnione od użytkownika, co utrudnia tworzenie wytycznych, które można zastosować do wszystkich witryn.
Subiektywne zasady są trudne do egzekwowania na dużą skalę
Otrzymaliśmy wiele próśb o bardziej szczegółowe wytyczne ze względu na subiektywny charakter pewnych wymagań (takich jak „wspólna tożsamość grupy”) oraz konieczność uwzględnienia wyjątków lub przypadków skrajnych w przypadku innych osób (dotyczy „wspólnej polityki prywatności”).
Aby zapewnić sprawiedliwe i spójne stosowanie zasad, Chrome musiałby przekazać autorom witryn znacznie bardziej szczegółowe wskazówki. Uznaliśmy, że próba stworzenia bardziej rygorystycznych wytycznych może mieć tylko negatywny wpływ na ekosystem.
Chociaż początkowo sugerowaliśmy, że niezależny organ egzekwujący przestrzeganie zasad przyjmuje rolę sprawdzania i egzekwowania zgodności z zasadami, w obecnym ekosystemie trudno jest znaleźć niezależny organ egzekucyjny dysponujący odpowiednim doświadczeniem do wywiązywania się z obowiązków w bezstronny sposób. Zamiast tego postawiliśmy na zasadę, która może być egzekwowana technicznie, aby można było konsekwentnie i obiektywnie wdrażać zasady.
Ewolucja
W odpowiedzi na opinie użytkowników zmieniliśmy liczbę klatek na sekundę. Wróciliśmy do konkretnych problemów, które próbowaliśmy rozwiązać, i postanowiliśmy bardziej bezpośrednio przedstawić propozycję dla konkretnych przypadków użycia, które rozwiązywaliśmy.
Rozwiązania w kluczowych przypadkach użycia
W Chrome opracowały się 3 różne „podzbiory” przeznaczone do obsługi kluczowych przypadków użycia w internecie. Podejście obejmujące podzbiory ulepszyło się od starego podejścia, ponieważ było bardziej prywatne, bardziej szczegółowe i łatwiejsze w spójnym egzekwowaniu.
- Domeny krajowe najwyższego poziomu (ccTLD) – organizacje mogą utrzymywać witryny z różnymi domenami krajowymi na potrzeby zlokalizowanych treści. Mogą one nadal wymagać dostępu do wspólnych usług i infrastruktury.
- Domeny „usługi” – ze względów bezpieczeństwa lub wydajności witryny mogą używać osobnych domen. Aby wykonywać swoje funkcje, witryny te mogą wymagać dostępu do tożsamości użytkownika.
- „Powiązane” domeny – organizacje mogą utrzymywać wiele witryn dotyczących różnych, powiązanych marek lub produktów. Mogą potrzebować dostępu do plików cookie z różnych witryn na potrzeby takich zastosowań jak analiza ścieżek użytkowników w powiązanych witrynach, aby lepiej zrozumieć, jak użytkownicy organizacji korzystają z ich witryn, lub aby zapamiętać stan zalogowania użytkownika w powiązanej witrynie, która korzysta z tej samej infrastruktury logowania.
W przypadku każdego z tych przypadków użycia obowiązują odrębne wymagania wynikające z zasad, odpowiednie testy weryfikacyjne oraz specyficzne zasady obsługi przeglądarek (więcej informacji znajdziesz w wytycznych dotyczących przesyłania zgłoszeń). Zmiany te eliminują ograniczenia zawarte w pierwotnej ofercie przez rezygnację z projektu „uniwersalnego” na rzecz podziału na segmenty, opartego na przykładach użycia.
możliwość interoperacyjności dzięki aktywnym żądaniam dostępu do plików cookie innych firm;
Chrome zależy na współdziałaniu z innymi przeglądarkami, aby utrzymać sprawność platformy internetowej. Inne przeglądarki, takie jak Safari, Firefox czy Edge, używają obecnie interfejsu Storage Access API (SAA) do obsługi aktywnych żądań plików cookie. Zdecydowaliśmy się więc na korzystanie z SAA w Chrome nie tylko w odpowiedzi na najważniejsze opinie, ale także w celu umożliwienia interoperacyjności z internetem.
Aby zapewnić deweloperom większą elastyczność i rozwiązać znane ograniczenia SAA, zaproponowaliśmy 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 o pozwolenie bezpośrednio, a inne mogą zezwolić na ograniczoną liczbę żądań bez pytania o zgodę.
W Chrome uważamy, że tryby klatek na sekundę mogą zapewnić przezroczystość w stosunku do SAA, ponieważ usprawniają działanie użytkowników i zapobiegają zmęczeniu promptów w kluczowych, ograniczonych przypadkach użycia. Klastry FPS dają też przeglądarkom możliwość zapewnienia użytkownikom dodatkowego kontekstu dotyczącego zestawu członkostwa, jeśli użytkownicy zdecydują się poprosić ich o zgodę.
Dzięki FPS deweloperzy mogą zidentyfikować własne witryny, których dotyczą kluczowe przypadki użycia, których dotyczy problem. Dzięki temu deweloperzy mogą przewidzieć, jak witryny będą działać dla użytkowników, i podjąć działania mające na celu ograniczenie wpływu tej zmiany na wrażenia użytkownika, wykorzystując klatki na sekundę (FPS) lub pliki cookie innych firm. Poza tym FPS zapewniają deweloperom przewidywalność platformy, w odróżnieniu od heurystyki, która może się zmieniać z upływem czasu lub wpływać na zachowanie różnych użytkowników.
Deweloperzy, którzy wdrożyli SAA do pracy z FPS w Chrome, będą mogli też korzystać z tej funkcji, aby zwiększyć wydajność swoich witryn w innych przeglądarkach, nawet w tych, które nie udostępniają takich klatek.
Ciągła dyskusja
Uważamy, że nasza najnowsza oferta zapewnia odpowiednią równowagę w trudnej przestrzeni, która uwzględnia potrzeby użytkowników i programistów. Doceniamy opinie osób zainteresowanych ekosystemem internetowym, które pomogły nam rozwinąć propozycję dotyczącą FPS.
Zdajemy sobie sprawę, że zainteresowane osoby z ekosystemu internetowego nadal zapoznają się ze zaktualizowaną propozycją. Zwróć się do nas o pomoc, żebyśmy mogli ulepszać projektowanie w sposób bardziej przydatny dla deweloperów i poprawić ochronę prywatności w internecie. W celu zapewnienia zgodności z zobowiązaniami Google będzie też nadal współpracować z brytyjskim Urzędem ds. Konkurencji i Rynków (CMA).
Jeśli chcesz dowiedzieć się więcej, zapoznaj się z tymi materiałami:
- Inkubacja w WICG
- Instrukcje dotyczące testowania klatek na sekundę
- Zestawy źródeł własnych: przewodnik po integracji
- Wytyczne dotyczące przesyłania danych w ujęciu FPS
Praca z ekosystemem
Cieszymy się, że takie firmy jak Salesforce czy CafeMedia dzielą się z nami kluczowymi opiniami i pomagają rozwijać zestawy źródeł własnych. Odegrali kluczową rolę w rozwoju technologii. Kilka osób podzieliło się też swoimi przemyśleniami o zestawach źródeł własnych i działaniach Chrome mających na celu współpracę z ekosystemem internetowym:
„Chrome opracowuje własne zestawy, aby dostosować je do wielu naszych przypadków użycia, takich jak zachowanie ścieżki użytkownika. To dowód, że zespół Google pracuje nad poznaniem różnych potrzeb właścicieli witryn w internecie”. – Mercado Libre,
„W VWO doceniamy wysiłki Google na rzecz podniesienia standardów ochrony prywatności przy jednoczesnym zapewnieniu obsługi autentycznych przypadków użycia. Cieszy się, że zespół współpracuje z ekosystemem programistów i na podstawie opinii zainteresowanych osób z internetu stale usprawnia wdrażanie propozycji zestawów własnych. Cieszymy się, że mogę wziąć udział w testowaniu tej oferty pakietowej i nie możemy się doczekać jej wprowadzenia w przeglądarce”. – Nitish Mittal, dyrektor ds. inżynierii, VWO