Opinie – IV kwartał 2022 r.

Czwarty raport kwartalny z 2022 r. podsumowujący opinie ekosystemu dotyczące propozycji dotyczących Piaskownicy prywatności i odpowiedzi Chrome.

W ramach zobowiązań wobec CMA Google zgodziło się na publiczne udostępnianie kwartalnych raportów na temat procesu zaangażowania interesariuszy w przypadku propozycji dotyczących Piaskownicy prywatności (patrz punkty 12 i 17(c)(ii) zobowiązań). Te raporty zbiorcze opinii na temat Piaskownicy prywatności są generowane przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym m.in. z GitHub Issues, formularza opinii udostępnionego na privacysandbox.com, spotkań z osobami zainteresowanymi w branży oraz forów dotyczących standardów internetowych. Chrome z zadowoleniem przyjmuje opinie pochodzące z ekosystemu i aktywnie poszukuje sposobów na uwzględnienie wniosków w decyzji dotyczących projektowania.

Tematy opinii są klasyfikowane według częstotliwości występowania w przypadku poszczególnych interfejsów API. Polega to na zsumowaniu liczby opinii, które zespół Chrome otrzymał w danym temacie, i posortowaniu ich według malejącej się liczby. Najczęstsze tematy opinii zostały zidentyfikowane na podstawie przeglądu tematów dyskusji z publicznych spotkań (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz najczęściej zadawanych pytań, które pojawiają się w zespole wewnętrznym Google i w formularzach publicznych.

W szczególności zostały sprawdzone protokoły spotkań organizacji zajmujących się opracowywaniem standardów internetowych. W przypadku bezpośrednich opinii uwzględniono zapisy Google z indywidualnych spotkań z partnerami, e-maile otrzymane przez poszczególnych inżynierów, listę mailingową API oraz publiczny formularz opinii. Następnie Google skoordynowało działania zespołów biorących udział w różnych działaniach promocyjnych, aby określić względną częstotliwość występowania tematów związanych z poszczególnymi interfejsami API.

Wyjaśnienia dotyczące odpowiedzi Chrome na opinie zostały opracowane na podstawie opublikowanych najczęstszych pytań i odpowiedzi na nie, a także na podstawie rzeczywistych odpowiedzi na problemy zgłoszone przez zainteresowane strony i stanowiska przyjętego specjalnie na potrzeby tego publicznego raportu. W związku z obecnym kierunkiem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące przede wszystkim interfejsów API do raportowania tematów, zobowiązań i atrybucji.

Opinie otrzymane po zakończeniu bieżącego okresu sprawozdawczego mogą nie zostać jeszcze rozpatrzone przez zespół Chrome.

Słowniczek akronimów

CHIPS
Pliki cookie z niezależnym stanem partycji
(procesor) DSP
Platforma DSP
FedCM
Federated Credential Management
FPS
Zestawy źródeł własnych
IAB
Interactive Advertising Bureau
IDP
Dostawca tożsamości
IETF
Internet Engineering Task Force
IP
adres IP
openRTB
Określanie stawek w czasie rzeczywistym
DOLICZONY CZAS
Testowanie wersji Origin
PatCG
Grupa społeczności technologii reklamowych
RP
Jednostka zależna
SSP
Platforma dostawców reklam
TEE
Zaufane środowisko wykonawcze
UA
Cięg znaków klienta użytkownika
UA-CH
Wskazówki dotyczące klienta użytkownika
W3C
World Wide Web Consortium
WIPB
Celowe ignorowanie adresów IP

Ogólna opinia, nie dotyczy konkretnego interfejsu API lub technologii

Temat opinii Podsumowanie Odpowiedź Chrome
(raportowane również w kolumnie „Q3”)

Przydatność dla różnych typów interesariuszy		 Obawy, że technologie Piaskownicy prywatności faworyzują większych deweloperów, a specjalne (mniejsze) witryny mają większy wpływ niż ogólne (większe) witryny Odpowiedź na pytanie 3 pozostaje niezmieniona:

„Google zobowiązało się do opracowania i wdrożenia propozycji dotyczących Piaskownicy prywatności w sposób, który nie zakłóca konkurencji przez samopromowanie działalności Google, oraz do uwzględnienia wpływu na konkurencję w reklamie internetowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. Wciąż ściśle współpracujemy z CMA, aby zapewnić zgodność naszych działań z tymi zobowiązaniami.

W miarę postępów w testowaniu Piaskownicy prywatności będziemy oceniać m.in., jak nowe technologie sprawdzają się w przypadku różnych typów zainteresowanych osób. W tym zakresie opinie są bardzo ważne, zwłaszcza konkretne i możliwe do wdrożenia, które mogą pomóc nam w dalszym ulepszaniu projektów technicznych.

Współpracowaliśmy z CMA nad naszym podejściem do testów ilościowych i popieramy opublikowanie przez CMA notatki na temat projektowania eksperymentów, aby zapewnić uczestnikom rynku więcej informacji i możliwość komentowania proponowanych podejść."
(Zgłoszone też w Q3)
Prośby o dokumentację		 prośby o dodatkowe materiały dotyczące zarządzania testowaniem, analizą i wdrażaniem; Aktualizacja z IV kwartału:

Cieszymy się, że materiały, które udostępniliśmy do tej pory, okazały się przydatne dla deweloperów. Będziemy nadal udostępniać więcej materiałów, aby deweloperzy mogli zrozumieć, jak nowe technologie mogą im pomóc. W ostatnim kwartale dodaliśmy sekcję „Nowości i aktualizacje” na stronie privacysandbox.com oraz opublikowaliśmy obszerną analizę tego, jak Piaskownica prywatności może w przyszłości zwiększać trafność reklam.

Zorganizowaliśmy też publiczne sesje dla programistów, podczas których prezentowaliśmy sprawdzone metody i demo, a także sesje pytań i odpowiedzi z udziałem liderów zespołów ds. produktów i inżynierów, aby umożliwić prowadzenie dyskusji i zadawanie pytań na żywo.
Core Web Vitals Jak opóźnienie interfejsu API Piaskownicy prywatności wpływa na podstawowe wskaźniki internetowe? Minimalizacja opóźnień jest kluczowym celem projektowania interfejsów API Piaskownicy prywatności. Obecnie zakładamy, że opóźnienie interfejsu API powinno mieć minimalny wpływ na podstawowe wskaźniki internetowe witryny, ponieważ większość interfejsów API jest wywoływana po początkowym renderowaniu witryny. Cały czas monitorujemy i ulepszamy interfejsy API, aby skrócić czas oczekiwania. Zachęcamy do dalszego testowania i przesyłania opinii.

Opóźnienia w procesie określania stawek w czasie rzeczywistym są omawiane w sekcji FLEDGE w ramach sekcji „Wydajność aukcji FLEDGE”.
Interoperacyjność Problemy związane z interoperacyjnością z innymi potencjalnymi rozwiązaniami Piaskownica prywatności ma chronić użytkowników przed śledzeniem w różnych witrynach, a jednocześnie wspierać potrzeby ekosystemu internetowego. Chcemy to osiągnąć, rezygnując ze starszych technologii przeglądarki, które umożliwiają śledzenie w wielu witrynach, takich jak pliki cookie innych firm, i zastępując je nowymi technologiami stworzonymi specjalnie do obsługi konkretnych przypadków użycia.

Proponowane rozwiązania w Piaskownicy prywatności zwiększają prywatność, ograniczając dane, które opuszczają urządzenie użytkownika. Proponowane zmiany nie nakładają technicznych ograniczeń na możliwość udostępniania przez witrynę danych zebranych z przeglądarki lub ich przetwarzania w inny sposób. Technologie te nie uniemożliwiają firmom zawierania umów dotyczących zarządzania danymi ani innych podobnych umów. Nie ograniczają też możliwości wyrażenia przez użytkowników zgody na udostępnianie ich danych w inny sposób.

W celu zapewnienia przejrzystości Google zobowiązuje się stosować technologie Piaskownicy prywatności w taki sam sposób we wszystkich witrynach, w tym w produktach i usługach Google. Gdy Chrome przestanie obsługiwać pliki cookie innych firm, Google nie będzie też używać innych danych osobowych, takich jak zsynchronizowana historia przeglądania w Chrome, do śledzenia użytkowników w celu kierowania reklam cyfrowych lub pomiaru skuteczności reklam.

Wyświetlanie odpowiednich treści i reklam

Tematy

Temat opinii Podsumowanie Odpowiedź Chrome
Wpływ na ranking w wyszukiwarce Google Zapytanie o to, czy obsługa interfejsu Topics API przez witrynę będzie używana jako potencjalny sygnał rankingowy w wyszukiwarce Google Niektóre witryny mogą zrezygnować z korzystania z interfejsu Topics API. Zespół Piaskownicy prywatności nie uzgadniał z organizacją wyszukiwania ani nie prosił o to, aby używała rankingu stron jako zachęty do stosowania interfejsu Topics API. Google potwierdziło CMA, że wyszukiwarka Google nie będzie używać decyzji witryny o rezygnacji z interfejsu Topics API jako sygnału rankingowego.
Klasyfikator tematów Dodaj adres URL i treści strony oprócz nazwy hosta, aby określić temat strony internetowej i ulepszyć użyteczność dla różnych zainteresowanych stron. Historia przeglądania użytkownika jest obecnie klasyfikowana na podstawie nazw hostów witryn. Chrome nadal analizuje opcje uwzględniania metadanych na poziomie strony (takich jak wszystkie lub niektóre komponenty adresu URL strony lub jej zawartości) w klasyfikacji tematów. Wszelkie ulepszenia funkcji muszą być rozpatrywane pod kątem ryzyka związanego z prywatnością i nadużyciami.

W przypadku metadanych niektóre z ryzyk to:
- witryny modyfikujące metadane na poziomie strony w celu zakodowania w tematach różnych (i potencjalnie wrażliwych) znaczeń;
- witryny modyfikujące metadane na poziomie strony w celu nieprawdziwego przedstawiania tematów w celu osiągnięcia korzyści finansowych;
- witryny modyfikujące metadane na poziomie strony dynamicznie w celu śledzenia w wielu witrynach
(również zgłoszone w kwartale 3)
Wpływ na sygnały własne		 Sygnał dotyczący tematów może być bardzo wartościowy, przez co zmniejsza znaczenie innych sygnałów własnych opartych na zainteresowaniach. Odpowiedź na to pytanie nie uległa zmianie od udzielenia odpowiedzi na pytanie 3:

„Uważamy, że reklamy oparte na zainteresowaniach to ważny przypadek użycia w internecie, a Topics jest przeznaczony do obsługi tego przypadku użycia. Jak opisano [w naszym raporcie za III kwartał], inni interesariusze ekosystemu wyrazili obawy, że funkcja Tematy może nie być wystarczająco przydatna, aby przynosiła korzyści. W każdym przypadku ulepszanie mapy kategorii jest procesem ciągłym. Oczekujemy, że będzie ona się rozwijać wraz z testowaniem i opiniami dotyczącymi ekosystemu”.
Aktualizowanie taksonomii Jak będzie aktualizowana lista taksonomii? Aktywnie zbieramy opinie na temat taksonomicznego uporządkowania, które byłoby najbardziej przydatne dla ekosystemu. Taksonomia zawarta w pierwotnym projekcie interfejsu Topics API została zaprojektowana w celu umożliwienia testów funkcjonalnych. W Chrome aktywnie rozważamy różne podejścia do aktualizowania taksonomii. Chrome może na przykład wykorzystać pojęcie wartości komercyjnej każdego tematu, aby określić, które kategorie uwzględnić w przyszłych iteracjach.
Skuteczność regionalnego klasyfikatora tematów Klasyfikator tematów działa słabo w domenach regionalnych Stale pracujemy nad ulepszaniem klasyfikatora. Na podstawie otrzymanych opinii rozważamy możliwość rozszerzenia listy zastąpień w Topics, co według naszych analiz zwiększy zasięg globalny i poprawi dokładność.

Klasyfikacja interfejsu Topics API składa się z 2 komponentów: (1) listy zastąpienia zawierającej 10 najpopularniejszych witryn i ich tematy oraz (2) modelu ML na urządzeniu, który klasyfikuje nazwy hostów według tematów. Dzięki poszerzeniu listy zastąpień (1) możemy poprawić skuteczność klasyfikacji w regionach, w których klasyfikator może działać nieefektywnie.
Era tygodnia Okres 1 tygodnia jest zbyt długi dla użytkowników, którzy chcą podejmować decyzje w krótszym terminie. Aktywnie szukamy optymalnej długości ery i chętnie poznamy Twoją opinię na temat tego, która era będzie lepsza dla ekosystemu.
Pobieranie nagłówka HTTP Obawa, że brakuje informacji dotyczących wyodrębniania nagłówka HTTP tematów Trwają prace nad nagłówkami i funkcją fetch(). Więcej informacji znajdziesz tutaj. Dodaliśmy też informacje o funcji skipObservation do opisu.
Tematy mają służyć tylko reklamodawcom, a nie użytkownikom Tematy/Piaskownica prywatności to rozwiązanie ukierunkowane na branżę. Korzyści dla użytkowników nie są tak oczywiste jak korzyści dla branży. Uważamy, że korzyścią dla użytkowników jest to, że Topics obsługuje reklamy oparte na zainteresowaniach, które zapewniają otwartość i wolność internetu. Jesteśmy też zdania, że znacznie poprawia prywatność w porównaniu z plikami cookie innych firm. Usunięcie plików cookie innych firm bez realnych alternatyw może negatywnie wpłynąć na wydawców i prowadzić do stosowania gorszych metod
, które są mniej prywatne, nieprzejrzyste i nie nadają się do resetowania ani kontrolowania przez użytkowników. Wiele firm aktywnie testuje interfejsy API Topics i Sandbox. Dokładamy wszelkich starań, aby udostępniać narzędzia, które zwiększają prywatność i wspierają internet.


Grupa W3C ds. architektury technicznej opublikowała niedawno wstępną opinię na temat interfejsu Topics API. Opublikujemy na ten temat publiczną odpowiedź. Otrzymaliśmy od przedstawicieli ekosystemu pytania o to, jakie konsekwencje może mieć ta weryfikacja dla rozwoju i wdrożenia interfejsu Topics API. Dlatego chcemy potwierdzić, że w tym roku udostępnimy go w wersji stabilnej przeglądarki Chrome. Google docenia opinie grupy ds. architektury technicznej W3C, ale uważa, że kontynuowanie prac nad tworzeniem i testowaniem Topics w konsultacji z CMA i ekosystemem jest sprawą najwyższej wagi.
wyciek danych, obawa, że tematy mogą zostać udostępnione innym witrynom bez zgody; Ze względu na sposób działania interfejsu Topics API jest mało prawdopodobne, aby dane pojedynczego wydawcy (czy nawet mniejszej grupy wydawców) mogły w jakikolwiek sposób wyciec. Wydawcy mają też pełną kontrolę nad interfejsem Topics API i mogą zablokować dostęp do tego interfejsu za pomocą zasad dotyczących uprawnień.
Brak reklamodawców do testowania Wydawcy obawiają się, że obecnie nie są w stanie udowodnić reklamodawcom wartości tematów. W drugiej połowie 2023 r. planujemy udostępnić wszystkie interfejsy API związane z reklamami do testów integracji i umożliwić analizę ekosystemu pod kątem wartości interfejsu Topics dla reklamodawców. Testowanie i publikowanie wyników będzie nadzorować CMA, które sprawdzi dane, analizę i metodologię. Ekosystem zachęcany jest do dzielenia się opiniami z Google i CMA.
Tematy i FLEDGE Prośba o więcej informacji o tym, jak korzystać z Tematów w ramach logiki ustalania stawek FLEDGE Tematy można stosować w ramach logiki ustalania stawek FLEDGE. Trwają też prace nad przewodnikiem integracji, który będzie zawierać dodatkowe informacje o wdrażaniu.
Niestandardowy ranking dla funkcji topics Zezwalanie na dostosowanie rankingów do dzwoniącego Problem z rankingiem lub wartościami niestandardowych tematów w przypadku poszczególnych usług reklamowych polega na tym, że może to stać się mechanizmem, za pomocą którego usługa reklamowa może wpływać na zwracane tematy, a zatem na wektor fingerprintingu.
Lista priorytetów rozmówców w ramach funkcji Topics Umożliwianie wywołującym podanie posortowanej listy priorytetów tematów, które interfejs Topics API zwróci na podstawie ich kwalifikowalności. Obecnie rozpatrujemy tę propozycję i zapraszamy do dzielenia się opiniami.

FLEDGE

Temat opinii Podsumowanie Odpowiedź Chrome
Google Ad Manager Obawa, że Google Ad Manager będzie decydentem w przypadku aukcji FLEDGE i będzie faworyzować tagi wydawcy Google i Google Ad Manager. FLEDGE umożliwia każdemu wydawcy wybór struktury aukcji, w tym wybór sprzedawców na poziomie najwyższym i sprzedawców komponentów. Każdy kupujący i sprzedający w aukcji komponentów wie, kim jest sprzedawca najwyższego poziomu, i może zdecydować, czy chce licytować.
Niewystarczająca liczba uczestników testujących FLEDGE Zachęcanie większej liczby firm do testowania FLEDGE, np. poprzez ulepszanie funkcji interfejsu API i zniechęcanie do stosowania alternatyw naruszających prywatność, takich jak fingerprinting Piaskownica prywatności jest wdrażana etapami we współpracy z CMA i ICO, a testy funkcjonalności FLEDGE wykazały odpowiednią stabilność i możliwości. Google nadal zachęca do testowania interfejsów API Piaskownicy. Niedawno opublikowaliśmy dokument „Maksymalizacja trafności reklam”, aby pokazać, jak interfejsy FLEDGE i inne interfejsy API mogą wspierać kluczowe przypadki użycia w branży reklamowej po wycofaniu plików cookie innych firm.

Inne części Piaskownicy prywatności już obsługują środki zaradcze dotyczące śledzenia (patrz: UA-CH, ochrona adresów IP i środki zaradcze dotyczące śledzenia powrotów), które będą się z czasem ulepszać. Celem Google nie jest uczynienie FLEDGE jedynym możliwym rozwiązaniem do kierowania reklam, ale współpraca z branżą i organiami regulacyjnymi nad wdrażaniem w przeglądarce Chrome najlepszych technologii reklamowych chroniących prywatność.
Przypadki użycia systemów uczących się Wskazówki dotyczące korzystania z systemów uczących się do trenowania algorytmów określania stawek w aukcjach będą obsługiwane w FLEDGE i raportach atrybucji Zdajemy sobie sprawę, że testerzy potrzebują pomocy w znajdowaniu najbardziej przydatnych sposobów stosowania technologii Piaskownicy prywatności. Zaczęliśmy publikować wskazówki dotyczące korzystania z różnych aspektów interfejsów API Piaskownicy prywatności jako danych wejściowych do uczenia maszynowego. Najnowsza publikacja Maksymalizowanie trafności reklam zawiera informacje o tym, jak branża reklamowa może wykorzystywać te sygnały do uczenia maszynowego. Planujemy też publikować kolejne tego typu wskazówki.
Przesyłanie zapytań do serwera FLEDGE Key Value (K/V) Dlaczego serwer K/V jest publicznie dostępny? Serwer K/V ma na celu dostarczanie sygnałów w czasie rzeczywistym do aukcji FLEDGE. Dlatego serwer K/V musi być dostępny z miejsca, w którym są przeprowadzane aukcje FLEDGE, czyli z urządzeń użytkowników, co wymaga, aby był on dostępny publicznie. Wartość przechowywana na serwerze K/V może być pobierana tylko przez stronę, która ma już klucz. Jeśli więc firma zajmująca się technologią reklamową udostępnia klucze tylko przeglądarkom należącym do grupy zainteresowań i nie używa kluczy, które można odgadnąć na chybił trafił, tylko przeglądarki, które potrzebują wartości do przeprowadzania aukcji, będą mogły ją pobrać.
Jak działa kierowanie na datę i godzinę? Obsługa obiektów daty w funkcji ustalania stawek. Możesz to zrobić na kilka sposobów. Kupujący mogą poprosić sprzedawcę o podanie bieżącej daty i godziny, a sprzedawcy powinni mieć możliwość łatwego udostępnienia tych informacji wszystkim kupującym. Kupujący mogą też podać datę i godzinę w odpowiedzi w czasie rzeczywistym. Kupujący mogą też podać datę i godzinę w ramach swojej odpowiedzi kontekstowej w sygnałach dotyczących kupującego, którą sprzedawca może przekazać do skryptu generateBid kupującego.
Preferencje użytkownika Możliwość blokowania przez użytkowników kreacji według reklamodawcy wyświetlanych za pomocą FLEDGE lub alternatywnych rozwiązań. Użytkownicy mogą zrezygnować z interfejsów API Ads w Chrome. W przypadku konkretnych reklam odpowiednia technologia reklamowa jest stroną, która najlepiej nadaje się do oferowania kontroli nad tym, które kreacje są wyświetlane lub jak są wybierane.
przejrzystość terminów, prośba o dodatkowe informacje o dostępności zabezpieczeń prywatności w FLEDGE, takich jak wymaganie ramek Fenced. W pierwszym kwartale planujemy opublikować bardziej szczegółowe harmonogramy.
Zgłoszenie niejasności Prośba o doprecyzowanie, jak raportowanie FLEDGE będzie działać z innymi interfejsami API, takimi jak Fenced Frames i Private Aggregation API. W najbliższych tygodniach opublikujemy artykuł wyjaśniający interakcje między interfejsem Private Aggregation API, FLEDGE i Fenced Frames.
Określanie stawek w czasie rzeczywistym i FLEDGE Wskazówki dotyczące integracji FLEDGE ze standardowym określaniem stawek w czasie rzeczywistym 2 główne czynniki, które utrudniają dostawcom technologii reklamowych określanie stawek w czasie rzeczywistym, to dostęp do danych na poziomie zdarzenia i łatwiejsza integracja z ARA. W pierwszym kwartale planujemy wysłać aktualizacje i informacje na temat obu tych kwestii.
Skuteczność aukcji FLEDGE Raport testerów o tym, że aukcje FLEDGE mają długi czas oczekiwania Doceniamy raporty testerów, którzy udostępniają wyniki i przypadki użycia. Udostępniliśmy też kilka sugestii dotyczących ulepszania działania FLEDGE.

Równocześnie dodaliśmy do przeglądarki narzędzia, które pozwalają deweloperom lepiej zdiagnozować, co spowalnia aukcje, i systematycznie eliminujemy główne źródła zaobserwowanych opóźnień. Ostatnie ulepszenia obejmują limity czasu dla wolnych aukcji, technikę filtrowania szybkich licytujących, sposób na ponowne wykorzystanie workletów FLEDGE, aby uniknąć opłat za uruchamianie, oraz trwające prace nad zezwoleniem na równoległe działanie żądania reklamy kontekstowej z czasem uruchamiania FLEDGE i pobieraniem sieci. Spodziewamy się, że optymalizacja opóźnień będzie kontynuowana w ramach trwającej rozmowy między programistami Chrome a testerami FLEDGE na podstawie ich rzeczywistych doświadczeń z korzystania z interfejsu API.
Limit rozmiaru pamięci grupy zainteresowań Prośba o zwiększenie limitu rozmiaru pojedynczej grupy zainteresowań z 50 KB. Aktywnie rozpatrujemy tę prośbę i prosimy o opinię na temat tego, jaka wartość limitu jest odpowiednia.
Łączenie danych serwowanych przez FLEDGE z plikami cookie własnymi Czy FLEDGE będzie obsługiwać integrację z danymi własnymi reklamodawcy? FLEDGE został stworzony, aby umożliwiać reklamowanie się na podstawie danych własnych, które reklamodawca już posiada. FLEDGE nie ma jednak na celu umożliwienia reklamodawcy poznania zachowań użytkownika w innej witrynie niż jego własna. Powiązanie zachowania poza witryną z danymi własnymi jest sprzeczne z celami Piaskownicy prywatności.

W najbliższych tygodniach udostępnimy przewodniki integracji z dodatkowymi informacjami o tym, jak FLEDGE będzie obsługiwać integrację z danymi własnymi.
Wartość k-anonimowości W jaki sposób zostanie ustalona wartość „K” i „k-anon” oraz czy zostanie ona opublikowana? Wartość „K” jest nadal określana. W miarę rozwoju naszych planów będziemy przekazywać więcej informacji. Chcielibyśmy dowiedzieć się więcej o tym, jak nieznana wartość k może utrudniać przygotowanie do FLEDGE i określanie zakresu trenowania modelu ML. Zapraszamy też do przesłaniania dodatkowych opinii na ten temat.
Obsługa wielu SSP Jak wiele SSP-ów będzie obsługiwanych w FLEDGE? FLEDGE obsługuje aukcje z udziałem wielu sprzedawców, jak opisano w tej propozycji.
Widoczność logiki ustalania stawek Obawa, że logika określania stawek przez DSP będzie widoczna w JavaScript Przy obecnej konstrukcji logiki ustalania stawek w JavaScriptie dostęp do niej mają inne osoby, ale chętnie poznamy Twoją opinię na temat tego, dlaczego może to stanowić problem dla dostawców platform reklamowych.
prebid.js Jaki jest harmonogram obsługi prebid.js w FLEDGE? Moduł FLEDGE obsługują tylko wersje Prebid.js 7.14 i nowsze. Wszyscy wydawcy zainteresowani testowaniem muszą dodać moduł FLEDGE i uaktualnić instancję Prebid.
Funkcje zdefiniowane przez użytkownika w FLEDGE Jak zdefiniowane przez użytkownika funkcje (UDF) będą obsługiwane w FLEDGE? Są to funkcje, które użytkownicy mogą zaprogramować, aby rozszerzyć funkcjonalność interfejsu API. Wyjaśnienie znajdziesz tutaj. Ta funkcja jest nadal rozwijana, dlatego prosimy o dodatkowe opinie na temat przypadków użycia.
Zmniejszenie restrykcji dotyczących zasobów pochodzenia wewnętrznego w przypadku zasobów grupy zainteresowań Prośba o zniesienie ograniczenia dotyczącego tego samego źródła w przypadku zasobów Grupy zainteresowań, aby umożliwić pewne przypadki użycia technologii reklamowych W obecnej implementacji FLEDGE wartości biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl i trustedBiddingSignalsUrl muszą mieć tę samą origin co właściciel grupy zainteresowań.

Ograniczenie to ma na celu zapobieganie niektórym atakom ze strony hakerów, jak wyjaśniono tutaj.
Właściciel grupy zainteresowań Prośba o ograniczenie możliwości korzystania przez dostawcę technologii reklamowych z funkcji joinInterestGroup w przypadku tych samych grup zainteresowań w różnych witrynach Naszym celem jest zapewnienie możliwości korzystania z list odbiorców, a nie ich tworzenia. Rozważamy różne podejścia i zapraszamy do dzielenia się opiniami.
Utrata ważności klucza serwera Key Value Service Dyskusja na temat usuwania kluczy serwera po wygaśnięciu odpowiednich grup zainteresowań Szukamy sposobów na rozwiązanie problemu wygaśnięcia klucza i prosimy o opinię.

Pomiar skuteczności reklam cyfrowych

Attribution Reporting (i inne interfejsy API)

Temat opinii Podsumowanie Odpowiedź Chrome
Ruch w wersji próbnej origin Ruch z bieżącej wersji próbnej Origin nie wystarcza do przeprowadzenia testów użyteczności. Obecne testy Origin Trials są przeznaczone dla uczestników ekosystemu, którzy chcą przeprowadzić testy funkcjonalne, aby sprawdzić, czy interfejs API działa zgodnie z oczekiwaniami. Zdajemy sobie sprawę, że do przeprowadzenia testów przydatności potrzebne będą większe ilości ruchu, gdy tylko interfejsy API Piaskownicy prywatności zostaną dopracowane. Zgodnie z obecnym harmonogramem testów nastąpi to w trzecim kwartale 2023 r. (czyli gdy technologie dla poszczególnych przypadków użycia zostaną wdrożone i staną się dostępne dla 100% ruchu w Chrome) (patrz aktualny harmonogram na stronie privacysandbox.com). Zapraszamy do przesyłania dodatkowych opinii na temat testowania przypadków użycia, które wymagają dodatkowego ruchu.
Zastosowanie interfejsów API do pomiarów w Piaskownicy prywatności Wprowadzenie w ramach Piaskownicy prywatności kilku metod pomiaru, które się nakładają, zwiększy złożoność, np. interfejs Attribution Reporting API i Private Aggregation API. Pracujemy nad ulepszoną dokumentacją, która wyjaśni różne zastosowania interfejsów API. Czekamy na opinie na temat obszarów, które wymagają wyjaśnienia. Na przykład interfejs Attribution Reporting API jest przeznaczony do obsługi pomiaru konwersji, a interfejsy Private Aggregation API i Shared Storage to interfejsy API o ogólnym zastosowaniu, które obsługują szerszy zakres przypadków użycia pomiarów w wielu witrynach.
Ponowna próba przesłania nieudanej prośby o raport Więcej informacji o tym, ile razy próba zgłoszenia jest podejmowana, jeśli nie powiedzie się. Opublikowaliśmy już na ten temat wskazówki. Podsumowując, raporty są wysyłane tylko wtedy, gdy przeglądarka jest uruchomiona lub online. Po pierwszym niepowodzeniu wysyłania raportu próba zostanie powtórzona po 5 minutach. Po drugim niepowodzeniu raport jest ponownie wysyłany po 15 minutach. Po tym czasie zgłoszenie nie jest wysyłane.
Opóźnienie w raportowaniu Jakie jest oczekiwane opóźnienie raportowania? Chcemy uzyskać więcej opinii od użytkowników z ekosystemu na temat opóźnień w przekazaniu raportów, ponieważ równolegle zbieramy dane, aby dokładniej ocenić te opóźnienia.
Wstępne renderowanie stron Czy atrybucja ARA będzie działać na stronach z przedrenderowaniem? Rejestrowanie atrybucji jest opóźniane na stronach wstępnie renderowanych do momentu aktywacji (do momentu, gdy nastąpi kliknięcie lub wyświetlenie). Oznacza to, że odłożymy ping żądania parametru „attributionsrc”.
Pomiar wyników marki Jak mierzyć wzrost liczby konwersji za pomocą testów A/B w tej samej domenie Strony internetowe mogą mierzyć wzrost liczby konwersji za pomocą testów A/B w tej samej domenie za pomocą raportowania atrybucji. Mogą one kodować parametry testów A/B jako klucze za pomocą interfejsu API do agregacji, a potem otrzymywać raporty podsumowujące wartości konwersji według tych kluczy.
(są też uwzględniane w sekcji „Konwersje”): Jak śledzić konwersje w wielu domenach, np. z co najmniej 2 miejscami docelowymi Aktualizacja z IV kwartału:

Opublikowaliśmy propozycję usunięcia ograniczenia dotyczącego miejsca docelowego na stronie docelowej, która umożliwia śledzenie rozmów między domenami. Ta propozycja została wdrożona.
(również w sekcji Pytanie 3)
Ustawienie „Wygaśnięcie” w raporcie „Konwersje” 		Prośba o pomoc dotycząca filtrowania raportów lub wygasania raportów w ciągu mniej niż 24 godzin Aktualizacja z IV kwartału:

udostępniliśmy pull request , który rozdziela okna wygaśnięcia i raportowania, aby zminimalizować kompromis między opóźnieniem raportowania a wygaśnięciem konwersji. Ta funkcja została wprowadzona w wersji M110.
Oszustwa i nadużycia prośby reklamodawców i marketerów o możliwość dzielenia i uogólniania danych na podstawie witryn wydawców, w których wyświetlają się ich reklamy, co pozwoliłoby też uzyskać więcej informacji o potencjalnych nieuczciwych praktykach reklamowych; Te opinie są obecnie omawiane tutaj . Zachęcamy do podzielenia się dodatkowymi uwagami.
(także zgłoszone w kwartale III) Opóźnienie raportowania na poziomie zdarzenia Opóźnienie w raportowaniu na poziomie zdarzenia wynoszące 2–30 dni może być zbyt długie w niektórych przypadkach użycia. Raportowanie na poziomie zdarzenia ma domyślnie okresy raportowania 2, 7 i 30 dni. Można to zmienić za pomocą parametru „expiry”. Firmy technologiczne zajmujące się reklamami mogą skonfigurować okres ważności, który wynosi co najmniej 1 dzień, aby potencjalne raporty były dostępne w mniej niż 2 dni. W ramach mechanizmu ochrony prywatności ograniczamy dokładność daty wygaśnięcia do 1 dnia, ponieważ bardziej szczegółowe raportowanie może prowadzić do ataków czasowych. Pozwalamy też na niezależne ustawianie parametrów „expiry” na poziomie zdarzenia i w raportach zbiorczych. Skorzystaj z tego artykułu. Ponadto Google Ads nie będzie otrzymywać żadnych specjalnych okresów raportowania, których nie otrzymują inne firmy z branży adtech za pomocą interfejsu Attribution Reporting API.
Wymaganie dotyczące tego samego źródła raportu Prośba o usunięcie wymagań dotyczących pochodzenia rejestracji źródła, które muszą być takie same jak pochodzenie rejestracji konwersji Aby rozwiązać ten problem, zalecamy użycie przekierowań HTTP do delegowania rejestracji. Zachęcamy do przesyłania dodatkowych opinii na temat nowych wytycznych.
Śledzenie konwersji Musisz rozróżnić, czy konwersja nastąpiła przed czy po określonych godzinach ustawionych przez reklamodawcę Interfejs Attribution Reporting API obsługuje ustawianie okna ważności i priorytetu atrybucji źródeł. Dzięki zastosowaniu obu tych metod technicznie możliwe będzie przypisanie konwersji, która miała miejsce w okresie X dni, oddzielnie od konwersji, która miała miejsce po tym okresie.
Symulacja szumu Prośba o możliwość symulowania różnej liczby konwersji na kolumnę, aby poznać wpływ na reklamodawców z mniejszą liczbą konwersji W przyszłych wersjach Noise Lab chcemy dodać sposoby na symulowanie tego procesu. Czekamy na dodatkowe opinie.
Raportowanie na urządzeniach mobilnych Czy raport zostanie wysłany, gdy Chrome działa w tle na urządzeniu mobilnym? Obecnie raport nie jest wysyłany, gdy Chrome działa w tle, nawet na urządzeniach mobilnych. Sytuacja ta może się zmienić, gdy interfejs API zostanie zintegrowany z Piaskownicą prywatności na Androida. Skorzystaj z tego artykułu. Pamiętaj, że Piaskownica prywatności Androida nie jest częścią zobowiązań przyjętych przez CMA.
Dostępność danych Obawy, że Google będzie mieć dodatkowy dostęp do danych za pomocą interfejsów API Piaskownicy prywatności Po pierwsze, Google Ads nie ma preferencyjnego dostępu do danych z interfejsu Attribution Reporting API ani innych interfejsów API Piaskownicy prywatności. Ten problem jest również omówiony w sekcji Ogólne opinie w sekcji „Współdziałanie”, która zawiera więcej informacji o zobowiązaniach Google.

Po drugie, jeśli chodzi o różnice między większymi a mniejszymi witrynami, Google zdaje sobie sprawę, że ochrona prywatności oparta na szumie może mieć większy wpływ na mniejsze fragmenty danych. Istnieją jednak pewne możliwe sposoby ograniczenia tego problemu: na przykład metody takie jak agregacja danych za dłuższe okresy czasu. Nie wiadomo jednak, czy wnioski oparte na bardzo małych przedziałach danych (np. 1 lub 2 zakupy) są w ogóle istotne dla reklamodawców. Podczas testów pochodzenia Google zachęcał testerów do korzystania z możliwości eksperymentowania z wielką liczbą parametrów prywatności i szumów, aby mogli oni przekazać bardziej szczegółowe opinie na temat tego problemu.

Ograniczanie śledzenia ukrytego

Redukcja klienta użytkownika

Temat opinii Podsumowanie Odpowiedź Chrome
Opóźnienie redukcji klienta użytkownika do czasu, gdy ekosystem internetowy będzie bardziej gotowy Nie ma wystarczająco dużo czasu na dostosowanie się do nadchodzących zmian dotyczących ograniczenia użycia user-agenta. Odpowiadamy na tę opinię w pełnym raporcie w sekcji „Zastrzeżenia interesariuszy” zatytułowanej „Interakcje Google z CMA”.
Opóźnienie redukcji klienta użytkownika do czasu, gdy ekosystem internetowy będzie bardziej gotowy Prośba o opóźnienie wdrożenia redukcji klienta użytkownika do czasu wdrożenia ustrukturyzowanych klientów użytkownika W październiku 2021 r. zespół Google Ads zaproponował w OpenRTB dodanie informacji o strukturze User-Agent (patrz specyfikacja). Została ona uwzględniona w specyfikacji 2.6, która została opublikowana w kwietniu 2022 r.

Mamy pewne dowody na to, że SUA jest wdrożony i dostępny, co potwierdza post na blogu firmy Scientia Mobile, w którym opisano, jak utworzyć SUA za pomocą UA-CH i interfejsu WURFL API.

###

Wskazówki dotyczące klienta użytkownika

Temat opinii Podsumowanie Odpowiedź Chrome
Testowanie UA-CH z innymi technikami zapobiegania śledzonym skryptom wskazówki dotyczące testowania wszystkich interfejsów API Piaskownicy prywatności i proponowanych technik identyfikacji w ramach kompleksowego podejścia; Nasz plan testów został opracowany w taki sposób, aby uwzględnić asynchroniczne harmonogramy tworzenia niektórych środków zapobiegających odciskom palców w porównaniu z pozostałymi propozycjami dotyczącymi Piaskownicy. Odpowiada ono rzeczywistości, w której niektóre środki zapobiegające odciskom palców (np. budżet prywatności, ochrona adresów IP i środki zapobiegające śledzonym odrzuceniom) zostaną w pełni opracowane i będą gotowe do udostępnienia publicznie dopiero po wycofaniu plików cookie innych firm.

Chociaż te środki zapobiegające pozyskiwaniu odcisków palców nie będą uwzględniane w testach ilościowych, podlegają ocenie jakościowej na podstawie faktów dostępnych w momencie zawieszenia.
(również w Q2)
Skuteczność		 Problemy z opóźnieniem w dostarczaniu podpowiedzi przez Critical-CH (przy pierwszym wczytaniu strony) Zobacz sekcję poświęconą UA-CH poniżej
Niewystarczająca opinia Opinie z ekosystemu dotyczące zmiany w UA-CH mogą być niewystarczające, co może wywołać obawy o brak świadomości w ekosystemie. Udostępniamy informacje o naszych planach, aby wdrożenie przebiegło sprawnie i bez zakłóceń.

Plany dotyczące redukcji klienta użytkownika i interfejsu API UA-CH zostały przedstawione grupie W3C Anti-Fraud Community 18 marca 2022 r. oraz grupie roboczej Web Payments Working Group i grupie zainteresowań Web Payments Security Interest Group 20 stycznia 2022 r. Podczas prezentacji i po ich zakończeniu nie zgłoszono żadnych istotnych obaw.

Google skontaktowało się z ponad 100 operatorami witryn, aby uzyskać opinie. Ponadto Google używa kanałów Blink-Dev do informowania o publicznym wdrażaniu ograniczenia korzystania z user-agenta na podstawie opinii interesariuszy ekosystemu.
Czas Obawy dotyczące terminu wdrażania i gotowości branży Zobacz sekcję poświęconą UA-CH poniżej
Stan platformy Chrome Prośba o zaktualizowanie strony chromestatus w przypadku UA-CH 19 grudnia wpis chromestatus został zaktualizowany na „Zróżnicowane sygnały”.

Ochrona IP (dawniej Gnatcatcher)

Temat opinii Podsumowanie Odpowiedź Chrome
Włączanie i wyłączanie Czy można włączyć lub wyłączyć ochronę prywatności adresu IP? Naszym celem jest zapewnienie ochrony IP wszystkim użytkownikom. Z tego powodu obecnie rozważamy opcje wyboru użytkowników w przypadku ochrony IP.
Przypadek użycia adresu IP w przypadku danych własnych Czy po wdrożeniu ochrony adresów IP można używać adresów IP do łączenia ścieżek użytkowników w domenach własnych? Zgodnie z informacjami opublikowanymi wcześniej ochrona adresów IP będzie początkowo dotyczyć śledzenia w kontekście zewnętrznym, co oznacza, że domeny własne nie będą na nią narażone.
Przypadki użycia Ad Tech Jak firmy mogą skonfigurować środki zapobiegające oszustwom za pomocą ochrony IP? Zdajemy sobie sprawę, jak ważne jest, aby adres IP był sygnałem dla działań związanych z zapobieganiem oszustwom w dzisiejszym internecie. W ramach naszych zobowiązań wobec CMA (punkt 20) zadeklarowaliśmy, że nie wprowadzimy ochrony IP bez podjęcia uzasadnionych działań, aby umożliwić witrynom prowadzenie działań antyspamowych i antyfraudowych. Jednym z naszych priorytetów jest zrozumienie, jak ochrona IP wpływa na przypadki użycia i możliwości wykrywania oszustw, abyśmy mogli dalej inwestować w technologie zapewniające ochronę prywatności, które pomagają firmom dbać o bezpieczeństwo w internecie. Zapraszamy do przesyłania opinii i uwag na temat nowych propozycji, które mają na celu wspieranie potrzeb firm zajmujących się bezpieczeństwem i zwalczaniem oszustw, nawet jeśli sygnały zmieniają się z czasem.
Oszustwa i nadużycia Czy ochrona IP obejmuje ochronę przed odmową usługi (DoS)? Zależy nam na zwiększaniu prywatności i jednocześnie zapewnianiu bezpieczeństwa w internecie. Ochrona przed atakami typu „odmowa usługi” jest ważnym przypadkiem użycia w ramach zapobiegania nadużyciom. Mamy nadzieję, że zminimalizujemy wpływ ochrony przed atakami DoS dzięki projektowi ochrony adresów IP i nowym rozwiązaniom zapobiegającym nadużyciom. Ochrona IP jest początkowo skoncentrowana na usługach wbudowanych innych firm, dlatego niektórzy interesariusze zasugerowali, że powinna mieć ograniczony wpływ na ochronę przed atakami DoS w witrynach własnych. Nadal jednak prosimy o opinie, aby ocenić ryzyko związane z przypadkami użycia DoS, zwłaszcza w przypadku usług zewnętrznych.

Równocześnie badamy mechanizmy zgłaszania nadużyć i blokowania klientów, które umożliwiłyby witrynie lub usłudze blokowanie użytkownika wysyłającego spam bez konieczności jego identyfikacji.
Filtrowanie treści Filtrowanie treści za pomocą ochrony adresu IP Różne firmy mają różne potrzeby dotyczące filtrowania treści i dostosowywania sposobu działania. Wiele takich przypadków użycia nie opiera się obecnie na adresach IP, więc ochrona adresów IP nie powinna na nie wpływać. Na przykład wydawca, który chce dostosować swoje treści i zwiększyć zaangażowanie użytkowników, może używać własnych plików cookie lub partycjonowanych plików cookie innych firm (CHIPS), aby poznać zainteresowania użytkownika i jego wcześniejsze interakcje z wydawcą. Partner technologiczny zajmujący się wyświetlaniem odpowiednich reklam odpowiednim użytkownikom może np. stosować FLEDGE i Topics, aby uzyskiwać podobne wyniki reklamowe jak obecnie dzięki plikom cookie innych firm lub innym technologiom śledzenia w wielu witrynach.

Badamy też możliwość dodania do Ochrona adresu IP nowych funkcji zapewniających ochronę prywatności, takich jak przybliżone położenie geograficzne, aby jeszcze lepiej filtrować treści w przypadkach, gdy obecne mechanizmy mogą okazać się niewystarczające. Zachęcamy do przesyłania dodatkowych opinii na temat przypadków użycia filtrowania treści, na które może mieć wpływ ochrona adresów IP.
(również zgłoszone w 3 kwartale)
Zastosowania lokalizacji geograficznej		 Ochrona adresu IP może uniemożliwić prawidłowe korzystanie z lokalizacji geograficznej w przyszłości, np. personalizację treści na podstawie lokalizacji geograficznej. Aktualizacja z IV kwartału:

Współpracujemy z partnerami, aby zapewnić, że Chrome będzie nadal obsługiwać uzasadnione przypadki użycia adresów IP. Zapraszamy do podzielenia się opinią na temat szczegółowości geolokalizacji adresu IP tutaj.

Budżet na potrzeby prywatności

Temat opinii Podsumowanie Odpowiedź Chrome
przejrzystszą dokumentację, więcej przykładów, aby zainteresowane strony mogły przewidzieć, jak może wyglądać ograniczenie po wdrożeniu budżetu na prywatność; Proponowana kwota budżetu na prywatność jest nadal przedmiotem dyskusji i nie została jeszcze wdrożona przez żadne przeglądarki. Najwcześniejsza data dostępności w ramach skalowania to najwcześniejsza data, od której można zastosować budżet na potrzeby prywatności. Nie nastąpi to przed usunięciem plików cookie innych firm w 2024 r. W tej chwili nie mamy żadnej dodatkowej dokumentacji.

Dodatkowe informacje o propozycji podamy, gdy będzie ona bardziej dopracowana. Tymczasem zachęcamy zainteresowane strony do przesyłania opinii, które pomogą w rozwijaniu propozycji.

Wzmocnienie granic prywatności między witrynami

Zestawy źródeł własnych

Temat opinii Podsumowanie Odpowiedź Chrome
(również zgłoszone w III kwartale) Limit domen Prośba o zwiększenie liczby powiązanych domen Aktualizacja z IV kwartału:

Wprowadziliśmy FPS do testów lokalnych, w tym proces przesyłania mockupów na GitHubie i oznaczenie do testowania rSA i rSAFor lokalnie. Zorganizowaliśmy też 2 otwarte spotkania dla programistów korzystających z FPS, aby odpowiedzieć na pytania dotyczące zastosowań powiązanego podzbioru. Zachęcamy programistów do przetestowania funkcji FPS i przesłania opinii na temat tego, jak limit domen dla powiązanego podzbioru wpłynie na użyteczność FPS w ich przypadkach użycia.

Podczas rozmów w ramach WICG wyjaśniliśmy, że Chrome jest zdeterminowane, aby zapewnić użyteczne rozwiązanie, które będzie uwzględniać również interesy użytkowników w zakresie prywatności. W związku z tym prosimy o opinie społeczności na temat konkretnych przypadków użycia, na które może mieć wpływ limit domen, aby nasz zespół mógł rozważyć sposoby rozwiązania tych problemów przy jednoczesnym zachowaniu prywatności użytkowników.
Prośba o więcej informacji o środkach zapobiegania nadużyciom Co się stanie, jeśli domena zostanie dodana do zbioru, na który nie wyraził zgody? 2 grudnia 2022 r. opublikowaliśmy tutaj wskazówki dotyczące przesyłania zestawów danych własnych.

Jak wyjaśniono we wskazówkach dotyczących przesyłania, wszelkie zmiany w zestawie będą podlegać procesowi weryfikacji w GitHub, w tym weryfikacji własności, co powinno ograniczyć to ryzyko.
Zapobieganie nadużyciom Obawy dotyczące możliwości wykorzystania zestawów źródeł własnych Szukamy sposobów na rozszerzenie kontroli technicznych w przypadku podzbiorów i aktywnie poszukujemy dodatkowych opinii społeczności tutaj.
Przypadki użycia reklam Pytania o to, czy zestawy danych własnych powinny być używane do obsługi kierowania reklam Nie obsługujemy przypadków użycia kierowania reklam z użyciem zbiorów danych własnych. W takich przypadkach zalecamy korzystanie z interfejsów API reklam Google.
(Zgłoszone również w III kwartale) Zasady Obawa, że FPS jest niezgodny z zobowiązaniami CMA dotyczącymi „obowiązującego prawa ochrony danych”, ponieważ RODO nie nakłada limitu liczby witryn w zestawie, podczas gdy FPS przewiduje limit 3 Odpowiedź na pytanie 3 nie uległa zmianie:

„Google nadal zobowiązuje się do opracowania i wdrożenia propozycji dotyczących Piaskownicy prywatności w sposób, który nie zakłóca konkurencji przez uprzywilejowanie własnej działalności. Będzie też uwzględniać wpływ na konkurencję w reklamach cyfrowych, wydawców i reklamodawców, a także na ochronę prywatności i przestrzeganie zasad ochrony danych określonych w obowiązujących przepisach dotyczących ochrony danych. Podniesione wątpliwości nie wskazują na niezgodność z RODO. Nadal ściśle współpracujemy z CMA, aby mieć pewność, że nasze działania są zgodne z tymi zobowiązaniami”.
Propozycja alternatywna Zestawy z weryfikacją RODO Oprócz opinii udzielonych przez środowisko dotyczące propozycji przyjęcia „zbiorów zweryfikowanych pod kątem RODO” Chrome ma wątpliwości dotyczące tych ograniczeń tej alternatywnej propozycji:

  • „Zestawy zweryfikowane pod kątem RODO” mają „spełniać wymogi” RODO (chociaż nie jest jasne, co to dokładnie oznacza). Natomiast zobowiązania Google wymagają, aby firma uwzględniała „wpływ na prywatność” w bardziej ogólnym ujęciu. W swojej decyzji o przyjęciu zobowiązań CMA wskazuje, że jest to odrębne od zobowiązania Google do uwzględnienia „przestrzegania zasad ochrony danych określonych w obowiązujących przepisach dotyczących ochrony danych”. Jak wyjaśnia CMA, odzwierciedla to fakt, że Google jest związane obowiązującymi przepisami dotyczącymi ochrony danych, zarówno w zakresie zobowiązań, jak i w ogóle.
  • Proponowane zezwolenie na wyświetlanie domen w kilku zestawach budzi nasze obawy związane z prywatnością. Zestawy własnych plików cookie mają służyć do obsługi konkretnych przypadków użycia, które obecnie są zależne od plików cookie innych firm, bez włączania powszechnego śledzenia w wielu witrynach. Zezwolenie domen na dołączanie do wielu zbiorów zniweczyłoby główną funkcję ochrony prywatności, która jest częścią propozycji zbiorów własnych, bez wprowadzania żadnych innych istotnych ograniczeń.
  • W ramach zestawów zatwierdzonych pod kątem RODO proponujemy też „zdefiniowanie zestawu jako grupy administratorów i podmiotów przetwarzających dane, którzy mają wspólne zasady użytkowania”. Jest to podobne do wymagań w naszej pierwotnej propozycji dotyczącej zestawów źródeł własnych, zgodnie z którymi wszystkie strony w takim zestawie muszą mieć wspólną politykę prywatności. Usunęliśmy to wymaganie, ponieważ w naszej społeczności pojawiły się liczne głosy zaniepokojenia dotyczące wymagań związanych z polityką prywatności. Na przykład wydawcy witryn twierdzili, że prowadzenie wspólnej polityki prywatności jest niemożliwe ze względu na różnice w produktach i lokalizacjach, a także inne problemy zgłoszone przez członków społeczności W3C (1, 2, 3). Uważamy, że w tym przypadku wystąpiłyby te same problemy.

Od czasu przedstawienia tej alternatywy zespół Chrome zaktualizował propozycję zestawów źródeł własnych i opublikował wytyczne dotyczące przesyłania nowych zestawów.

Fenced Frames API

Temat opinii Podsumowanie Odpowiedź Chrome
Ograniczenia dotyczące wydzielonych ramek podczas OT Jakie są aktualne ograniczenia dotyczące wydzielonych ramek w okresie próbnym Origin? Pracujemy nad dokumentacją dotyczącą ograniczeń i stanu wdrożenia. Planujemy udostępnić ją w I kwartale 2023 r.
Wiele reklam w jednym ograniczonym obszarze Prośba o wyświetlanie reklam wielu reklamodawców w jednym odizolowanym ramach w ramach jednej aukcji Obecnie nie pracujemy nad tą funkcją, ale chętnie poznamy opinie użytkowników, którzy uważają, że jest ona ważna.
Pakiety internetowe Jakie są wymagania i jakie wsparcie jest planowane w przypadku pakietów internetowych z ramkami odizolowanymi? Obecnie nie możemy podać, czy w przyszłości będzie to wymagane. Wszelkie zmiany zostaną ogłoszone z wyprzedzeniem i nie zostaną wprowadzone przed wycofaniem plików cookie innych firm. Aby poznać aktualny stan, zapoznaj się z tym artykułem.

Interfejs Shared Storage API

Temat opinii Podsumowanie Odpowiedź Chrome
Pamięć współdzielona dla technologii reklamowych Niepewność dotycząca używania wspólnego miejsca na dane w przypadkach użycia technologii reklamowych Interfejsy Shared Storage API i Private Aggregation API można używać do różnych celów pomiarowych, które wymagają pomiaru miejsca na dane w różnych witrynach. Przykłady znajdziesz tutaj.

Spodziewamy się, że dostawcy rozwiązań DSP i rozwiązań do pomiarów staną się głównymi integratorami w przypadku zastosowań reklam.

CHIPs

Temat opinii Podsumowanie Odpowiedź Chrome
(również zgłoszone w III kwartale) Wymagania dotyczące partycji Dodaj wyraźne wymagania dotyczące działania atrybutu „Partitioned” (Partycjonowany) w przypadku własnych plików cookie. Aktualizacja z IV kwartału:

Po dyskusjach na GitHubie i w ramach rozmów w ramach PrivacyCG doszliśmy do wniosku, że pliki cookie podzielone na partycje ustawione w własnych plikach cookie będą używać klucza partycji (A,A), gdzie „A” to witryna najwyższego poziomu. Opiszemy to zachowanie w dokumentacji i specyfikacji.
Zarządzanie plikami cookie Czy istnieją narzędzia do zarządzania własnymi plikami cookie lub plikami cookie innych firm? Narzędzie Chrome DevTools i  NetLog można wykorzystać do testowania witryn z włączonym blokowaniem plików cookie innych firm. Oba narzędzia informują, kiedy pliki cookie są blokowane ze względu na konfigurację użytkownika. Chętnie poznamy Twoją opinię na temat tego, jakie dodatkowe funkcje witryn weryfikujących chciałbyś/chciałabyś zobaczyć.

FedCM

Temat opinii Podsumowanie Odpowiedź Chrome
Dostawca tożsamości musi znać RP, aby umożliwić sesję Problem, gdy użytkownik próbuje zalogować się w dostawcy tożsamości Feide z 2 różnych rejestratorów Rozważamy potencjalne rozwiązania tego problemu.
Interoperacyjność Obawy dotyczące wpływu FedCM na relacje między użytkownikami a witrynami, do których logują się za pomocą tego standardu, oraz „interoperacyjności” między witrynami Po usunięciu z Chrome plików cookie innych firm FedCM będzie nadal obsługiwać usługi tożsamości federacyjnej, które obecnie korzystają z tych plików. Spodziewamy się, że FedCM będzie tylko jedną z dostępnych opcji dla takich usług. Dostawcy tożsamości i strony korzystające z usług mogą używać innych technologii, które lepiej odpowiadają ich potrzebom.

Wygląda na to, że obawy dotyczące relacji między użytkownikiem a RP i „współdziałania” wynikają z nieporozumienia dotyczącego propozycji FedCM. FedCM pozostawia dostawcom usług uwierzytelniania decyzję o tym, jakie informacje i w jakiej formie udostępnić dostawcy usług rejestracji, gdy użytkownik zaloguje się na jego stronie. FedCM nie wymaga od dostawców tożsamości tworzenia unikalnego pseudonimowego identyfikatora dla każdego podmiotu, u którego użytkownik się uwierzytelnia. Zamiast tego FedCM umożliwia każdemu dostawcy tożsamości wybranie, czy udostępnić rzeczywisty identyfikator użytkownika, wersję tego identyfikatora dla danej witryny czy inną wersję tych informacji.

(W specyfikacji FedCM korelacja między witrynami jest określana jako ryzyko związane z prywatnością i omawiane jako możliwe rozwiązanie. Decyzja o używaniu kierowanych identyfikatorów należy jednak do dostawców tożsamości, a nie do przeglądarki.

FedCM umożliwia też użytkownikom wybór w sprawie tożsamości. Jeśli na przykład użytkownik ma wiele tożsamości w ramach tego samego dostawcy tożsamości (np. profil służbowy i osobisty), FedCM umożliwia mu wybranie tożsamości, której chce użyć do zalogowania się na stronie dostawcy usług. Każdy RP sam decyduje, których dostawców tożsamości chce obsługiwać w swojej witrynie. Jednym z elementów tej decyzji jest rozważenie mechanizmu, na którym opiera się dostawca tożsamości, niezależnie od tego, czy jest to FedCM czy inna technologia. Ponownie przypominamy, że przeglądarka nie narzuca tych wyborów dostawcom usług RP ani dostawcom usług IdP.

Walka ze spamem i oszustwami

Interfejs Private State Token API

Temat opinii Podsumowanie Odpowiedź Chrome
Obsługa botów Co się stanie, jeśli wystawca wykryje, że tokeny prywatności zostały wydane botom? Aby uniknąć sytuacji, w której tokeny wydawane botom pozostają w ekosystemie przez długi czas, wydawcy powinni regularnie zmieniać klucze używane do podpisywania tokenów, tak aby stare tokeny wydane na podstawie potencjalnie uszkodzonej logiki wydawania wygasły, a witryny mogły odzyskać nowsze tokeny z zaktualizowaną logiką wydawania.
Przesłane formularze w tej samej witrynie Czy tokeny stanu prywatnego można używać do przesyłania formularzy na tej samej stronie, które wymagają pełnej nawigacji po stronie (czyli Content-Type: application/x-www-form-urlencoded) zamiast żądania z interfejsów API fetch/XMLHttpRequest? Obecnie nie jest to obsługiwane w pierwszej wersji tokenów prywatności. Jeśli istnieje duże zapotrzebowanie na ten przypadek użycia, zapraszamy do dzielenia się opiniami na temat naszego ekosystemu.
Weryfikacja po stronie serwera Pytania o to, czy tokeny prywatności można zweryfikować po stronie serwera Tokeny są odkupywane przez wydawcę, który tworzy rekord odkupu, który może zawierać sam token lub jakąś podpisaną wartość pochodzącą z tokena. Serwery mogą używać tego rekordu odkupu do weryfikacji autentyczności tokena. Spodziewamy się, że różne ekosystemy wydawców będą stosować różne standardy interpretacji rekordów odkupu.