Raport kwartalny za IV kwartał 2022 r. podsumowujący opinie ekosystemu na temat ofert pakietowych Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wynikających z umowy CMA firma Google zobowiązała się do publicznego udostępniania kwartalnych raportów z procesu zaangażowania zainteresowanych osób w przypadku propozycji Piaskownicy prywatności (zob. art. 12 i 17(c)(ii) Zobowiązań). Te raporty z podsumowaniem Piaskownicy prywatności są generowane na podstawie opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym między innymi na temat problemów na GitHubie, formularza opinii dostępnego na stronie privacysandbox.com, spotkań z zainteresowanymi osobami z branży i forów standardów internetowych. Chrome z radością korzysta z opinii otrzymywanych od ekosystemu i aktywnie analizuje sposoby wykorzystywania zdobytych informacji na potrzeby podejmowania decyzji projektowych.
Tematy opinii są uporządkowane według częstości występowania w poszczególnych interfejsach API. Na podstawie zebranych przez zespół Chrome opinii na temat danego motywu są one uporządkowane w kolejności malejącej. Wspólne tematy opinii zostały zidentyfikowane przez przejrzenie tematów dyskusji ze spotkań publicznych (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz częstych pytań zadawanych przez wewnętrzne zespoły Google i formularze publiczne.
Dokładniej rzecz ujmując, przeanalizowano protokoły ze spotkań zebrań standardowych instytucji internetowych, a w przypadku bezpośrednich opinii – zapisy Google ze spotkań 1:1, e-maile otrzymane przez poszczególnych inżynierów, listę adresową interfejsu API oraz publiczny formularz opinii. Następnie zespół Google skoordynował zespoły zaangażowane w te działania informacyjne, aby określić względną popularność tematów pojawiających się w odniesieniu do poszczególnych interfejsów API.
Wyjaśnienia odpowiedzi Chrome na opinie opracowano na podstawie opublikowanych odpowiedzi na najczęstsze pytania, rzeczywistych odpowiedzi zgłoszonych przez zainteresowane osoby oraz określenia stanowiska na potrzeby tego publicznego raportowania. W związku z obecnym celem programowania i testowania otrzymaliśmy pytania i opinie dotyczące interfejsów API Topics, Fledge i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu raportowania mogły jeszcze nie zostać uznane za odpowiedź Chrome.
Słowniczek akronimów
- ELEMENTY
- Pliki cookie z niezależnym trybem partycjonowania
- (procesor) DSP
- Platforma DSP
- FedCM
- Sfederowane zarządzanie danymi uwierzytelniającymi
- kl./s
- Zestawy własne
- IAB
- Interactive Advertising Bureau ,
- dostawca tożsamości
- Dostawca tożsamości
- IETF
- Internet Engineering Task Force
- IP
- Adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Wersja próbna
- PatCG
- Grupa społecznościowa Private Advertising Technology
- RP
- Grupa uzależniona
- platforma 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
- Niewiarygodna ślepotyka na adresy IP
Ogólna opinia, brak konkretnego interfejsu API/technologii
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (raport zaraportowano też w III kwartale) Przydatność różnych rodzajów zainteresowanych osób |
obawy, że technologie Piaskownicy prywatności są faworyzowane przez większych deweloperów oraz że niszowe (mniejsze) witryny mają w ich przypadku większy udział niż ogólnikowe (większe) witryny. | Nasza odpowiedź się nie zmieniła: „Google zobowiązało się do projektowania i wdrażania ofert Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samopoczucie, że firma Google jest ważna, oraz uwzględniać wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszej pracy z tymi zobowiązaniami. W miarę postępów w testach Piaskownicy prywatności jednym z najważniejszych pytań, które omówimy, będzie skuteczność nowych technologii w przypadku różnych zainteresowanych osób. Opinie użytkowników są w tym przypadku bardzo ważne, zwłaszcza w przypadku konkretnych i przydatnych informacji, które mogą nam pomóc w ulepszaniu projektów technicznych. Wspólnie z CMA opracowaliśmy nasze podejście do testów ilościowych i popieramy publikację przez CMA notatki na temat projektu eksperymentu, która zapewni uczestnikom rynku dodatkowe informacje i możliwość wypowiedzenia się na temat proponowanych metod”. |
| (raportowane również w III kwartale) Prośby o dokumentację |
Prośby o dostęp do dodatkowych materiałów na temat zarządzania testowaniem, analizą i wdrażaniem | Aktualizacja w IV kwartale: Dziękujemy, że nasze obecne materiały są dla deweloperów przydatne. Nadal dokładamy wszelkich starań, aby dostarczać im więcej materiałów, które pomogą im zrozumieć, jak nowe technologie mogą im pomóc. W ubiegłym kwartale na stronie privacysandbox.com dodaliśmy sekcję „Aktualności” i opublikowaliśmy obszerny przegląd tego, jak Piaskownica prywatności może pomóc w zwiększaniu trafności reklam w przyszłości. Organizujemy też publiczne sesje konsultacji dla programistów, podczas których dzielimy się sprawdzonymi metodami i prezentacjami, a także organizujemy sesje pytań i odpowiedzi z udziałem potencjalnych klientów ds. usług i inżynierów, podczas których można zadawać pytania lub dyskutować na żywo. |
| Podstawowe wskaźniki internetowe | Jak czas oczekiwania na interfejs API Piaskownicy prywatności wpływa na podstawowe wskaźniki internetowe? | Zmniejszenie czasu oczekiwania do minimum to kluczowy cel projektowania interfejsów API Piaskownicy prywatności. Przewidujemy, że czas oczekiwania na interfejs API powinien mieć minimalny wpływ na podstawowe wskaźniki internetowe witryny, ponieważ większość interfejsów API jest wywoływana po wstępnym wyrenderowaniu strony. Stale monitorujemy i wprowadzamy ulepszenia w celu dalszego skrócenia czasu oczekiwania każdego z interfejsów API oraz zachęcamy do dalszego testowania i przesyłania opinii. Czas oczekiwania w procesie określania stawek w czasie rzeczywistym jest opisany w sekcji FLEDGE w części „Skuteczność aukcji FLEDGE”. |
| Interoperacyjność | wątpliwości dotyczące interoperacyjności z innymi potencjalnymi rozwiązaniami, | Piaskownica prywatności ma chronić użytkowników przed śledzeniem w witrynach, a jednocześnie zaspokajać potrzeby ekosystemu internetowego. Chcemy to osiągnąć, odchodząc od starszych technologii przeglądarek, które umożliwiają takie śledzenie w witrynach, takich jak pliki cookie innych firm, i udostępniając nowe technologie opracowane z myślą o konkretnych zastosowaniach. Oferty pakietowe Piaskownicy prywatności zwiększają prywatność, ograniczając ilość danych opuszczających urządzenie użytkownika. Te propozycje nie nakładają ograniczeń technicznych na możliwość udostępniania lub przetwarzania przez witrynę danych po ich zebraniu przez przeglądarkę. Technologie te nie uniemożliwiają więc zawieraniu przez firmy umów dotyczących „zarządzania danymi” ani innych podobnych relacji umownych. Nie ograniczają też możliwości wyrażenia przez użytkowników zgody na udostępnianie ich danych w inny sposób. Aby uniknąć wątpliwości: firma Google zobowiązała się stosować technologie Piaskownicy prywatności w taki sam sposób do wszystkich witryn, w tym do produktów i usług Google. Po zakończeniu obsługi plików cookie innych firm w Chrome wyraźnie określono, że Google nie będzie używać innych danych osobowych, takich jak synchronizowana historia przeglądania w Chrome, aby śledzić użytkowników na potrzeby kierowania i pomiaru reklam cyfrowych. |
Wyświetlaj trafne treści i reklamy
Tematy
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wpływ na ranking wyszukiwania Google | Pytanie o to, czy obsługa interfejsu Topics API witryny będzie uwzględniana jako potencjalny sygnał dotyczący pozycji w rankingu wyników wyszukiwania Google | Niektóre witryny mogą zrezygnować z korzystania z interfejsu Topics API. Zespół Piaskownicy prywatności nie koordynował organizacji wyszukiwarki, aby nie zachęcała one tej organizacji do stosowania rankingu stron jako zachęty do wdrożenia interfejsu Topics API. Według agencji CMA wyszukiwarka Google nie weźmie pod uwagę decyzji witryny o rezygnacji z korzystania z interfejsu Topics API jako sygnału rankingowego. |
| Klasyfikator tematów | Do określenia tematu strony internetowej dodaj adres URL i zawartość strony oprócz nazwy hosta, co pozwoli zwiększyć przydatność dla różnych zainteresowanych osób. | Historia przeglądania użytkownika jest obecnie klasyfikowana na podstawie nazw hosta witryny. Chrome stale analizuje opcje uwzględniania metadanych na poziomie strony (np. wszystkich lub niektórych komponentów adresu URL i treści strony) w klasyfikacji Topics. Wszelkie ulepszenia należy wziąć pod uwagę w kontekście ryzyka związanego z prywatnością i nadużyciami. Oto niektóre z zagrożeń dotyczących metadanych: – witryny modyfikujące metadane na poziomie strony w celu kodowania różnych (i potencjalnie kontrowersyjnych) znaczenia w tematach; – modyfikowanie metadanych na poziomie strony w celu przedstawienia nieprawdziwych informacji na temat korzyści finansowych; – dynamicznego modyfikowania metadanych na poziomie strony w witrynach jako metody śledzenia w różnych witrynach. |
| (również w III kwartale) Wpływ na sygnały własne |
Sygnał dotyczący tematów może być bardzo wartościowy, w związku z czym obniża wartość innych własnych sygnałów opartych na zainteresowaniach. | Nasza odpowiedź się nie zmieniła: „Uważamy, że reklamy oparte na zainteresowaniach to ważny przypadek użycia w internecie, dlatego Topics API ma to ułatwić. Jak opisano [w naszym raporcie za III kwartał], inne zainteresowane osoby z ekosystemu wyraziły obawy, że Topics mogą być za mało przydatne, aby zapewnić wartość. We wszystkich przypadkach nieustannie pracujemy nad ulepszaniem taksonomii i spodziewamy się, że taksonomia będzie ewoluować w miarę testowania ekosystemu i danych wejściowych”. |
| Aktualizowanie taksonomii | Jak zostanie zaktualizowana lista taksonomii? | Aktywnie szukamy opinii na temat taksonomii, która byłaby najbardziej przydatna dla tego ekosystemu. Taksonomia uwzględniona we wstępnej ofercie interfejsu Topics API została zaprojektowana tak, aby umożliwić testowanie funkcjonalne. Chrome aktywnie rozważa różne podejścia do aktualizacji taksonomii. Na przykład Chrome może wykorzystać wartość handlową każdego tematu, aby określić, którą kategorię uwzględnić w kolejnych iteracjach. |
| Skuteczność klasyfikatorów regionalnych tematów | Słabe wyniki klasyfikatorów tematów w domenach regionalnych | Cały czas pracujemy nad ulepszaniem klasyfikatora. Na podstawie otrzymanych opinii stwierdziliśmy, że jedną z możliwości jest rozszerzenie listy zastąpień tematów. Zgodnie z naszymi analizami zwiększy to zasięg na całym świecie i zwiększy dokładność. Aby wyjaśnić, że klasyfikacja Topics API składa się z 2 odpowiednich komponentów: (1) lista zastąpień zawierająca 10 tys. najpopularniejszych witryn i ich tematów oraz (2) model ML działający na urządzeniu, który klasyfikuje nazwy hostów według tematów. Rozszerzając listę zastąpień (1), możemy poprawić skuteczność klasyfikacji w regionach, w których klasyfikator może być nieskuteczny. |
| Tydzień epoki | Tygodniowy okres jest za długi dla użytkowników, którzy chcą podejmować decyzje krótkoterminowe. | Aktywnie sprawdzamy, jaka powinna być odpowiednia długość epoki i chętnie poznamy dalsze opinie na temat tego, jaka epoka będzie lepsza dla ekosystemu. |
| Pobieranie nagłówka HTTP | Obawia się, że brakuje wystarczających informacji o pobieraniu tematów z nagłówka HTTP. | Pracujemy nad nagłówkami i metodą fetch(). Informacje na ten temat znajdziesz też tutaj. Do wyjaśnienia dodaliśmy informacje dotyczące pomijania danych. |
| Narzędzie Topics ma pomagać tylko reklamodawcom, a nie użytkownikom | Wydaje się, że podejście do tematów i Piaskownicy prywatności jest ściśle związane z 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 Topics polegają na tym, że interfejs Topics API obsługuje reklamy oparte na zainteresowaniach, które zapewniają swobodę i otwartość sieci. Uważamy też, że znacznie poprawia ona poziom prywatności w porównaniu z plikami cookie innych firm. Usunięcie plików cookie innych firm, które nie mają realnych możliwości alternatywnych, może negatywnie wpłynąć na wydawców i może prowadzić do pogorszenia sposobów korzystania z nich, ponieważ są mniej prywatne i nieprzejrzyste, a użytkownicy nie mogą zresetować tych plików ani ich kontrolować. Wiele firm aktywnie testuje interfejsy Topics API i Sandbox API, a my dokładamy wszelkich starań, aby udostępniać narzędzia zwiększające prywatność i ułatwiające działanie sieci. Grupa W3C Technical Architecture Group opublikowała niedawno swój wstępny widok interfejsu Topics API. Będziemy na niego odpowiadać publicznie. Ponieważ otrzymaliśmy od ekosystemu pytania dotyczące tego, co ta weryfikacja może oznaczać dla rozwoju i uruchomienia interfejsu Topics API, chcielibyśmy potwierdzić nasz plan udostępnienia w tym roku wersji stabilnej w Chrome. Chociaż doceniamy wkład grupy W3C Technical Architecture Group, jest dla nas niezwykle ważne, aby kontynuować wysiłki na rzecz rozwijania i testowania tematów we współpracy z CMA i ekosystemem. |
| Wyciek danych | obawiasz się, że tematy mogą zostać ujawnione innym witrynom bez pozwolenia; | Układ interfejsu Topics API sprawia, że jest mało prawdopodobne, że dane od jednego wydawcy (a nawet mniejszej grupy wydawców) mogą zostać w jakikolwiek sposób ujawnione. Witryny wydawców mają też pełną kontrolę nad interfejsem Topics API i mogą zabraniać dostępu do tego interfejsu za pomocą zasad dotyczących uprawnień. |
| Brak reklamodawców do testowania | Wydawcy martwią się, że obecnie nie są w stanie pokazać reklamodawcom wartości interfejsu Topics. | W drugiej połowie 2023 roku planujemy udostępnić wszystkie interfejsy API związane z reklamami na potrzeby testowania integracji i umożliwimy reklamodawcom analizę ekosystemu wartości Topics. Testowanie i publikowanie wyników będzie nadzorowane przez CMA, która przeanalizuje dane, analizę i metodologię. Zachęcamy do dzielenia się opiniami z Google i CMA. |
| Topics i FLEDGE | Prośba o więcej informacji o korzystaniu z Topics w ramach logiki ustalania stawek FLEDGE | Istnieje możliwość używania Topics w ramach logiki ustalania stawek FLEDGE. Przygotowujemy też przewodnik po integracji, który będzie zawierał dodatkowe informacje o wdrażaniu. |
| Niestandardowy ranking tematów wywołujących | Zezwalaj na dostosowywanie rankingów według rozmówcy | Problem z rankingiem tematów niestandardowych lub wartościami w przypadku każdej technologii reklamowej polega na tym, że może to stać się mechanizmem, za pomocą którego technologie reklamowe mogą wpływać na zwracane tematy, a tym samym wektor odcisków cyfrowych. |
| Lista priorytetów dzwoniących na tematy | Zezwalaj elementom wywołującym na podawanie rankingu tematów, które interfejs Topics API zwraca po spełnieniu warunków. | Obecnie dyskutujemy na temat tego pomysłu i chętnie poznamy dodatkowe opinie. |
FLEDGE
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Google Ad Manager, | Obawia się, że ostatecznie decyduje o tym, że w aukcjach FLEDGE podejmuje Google Ad Manager, dlatego wolą tagi wydawcy Google i Google Ad Managera. | FLEDGE pozwala każdemu wydawcy wybrać strukturę aukcji, w tym sprzedawców najwyższego poziomu i sprzedawców komponentów. Każdy kupujący i sprzedawca w aukcji składowej wie, kto jest sprzedawcą najwyższego poziomu i może zdecydować o licytowaniu. |
| Zbyt mało uczestników testujących FLEDGE | Wysłanie prośby o zachęcenie większej liczby firm do testowania FLEDGE, na przykład przez ulepszenie funkcji interfejsu API i zniechęcenie rozwiązań uciążliwych dla prywatności, takich jak odcisk cyfrowy. | Piaskownica prywatności jest realizowana etapami, w ścisłej współpracy z wytycznymi CMA i ICO, a funkcjonalne testy FLEDGE wykazały niezbędną stabilność i możliwości. Google nadal zachęca ekosystem do testowania interfejsów API Piaskownicy. Publikujemy niedawno dokumentację „Maksymalizuj trafność reklam”, w której pokazujemy, jak FLEDGE i inne interfejsy API mogą pomóc w obsłudze newralgicznych przypadków użycia w branży reklamowej po wycofaniu plików cookie innych firm. Inne części Piaskownicy prywatności obsługują już środki łagodzące skutki śledzenia (patrz UA-CH, ochrona adresów IP i łagodzenie śledzenia przekierowań), a z czasem będziemy je ulepszać. Celem Google nie jest ustanowienie FLEDGE jako jedynego skutecznego rozwiązania do kierowania reklam. Zamiast tego nadal zależy nam na współpracy z branżą i organami regulacyjnymi w celu rozwijania najlepszych technologii reklamowych chroniących prywatność w przeglądarce Chrome. |
| Przypadki użycia systemów uczących się | Więcej wskazówek na temat tego, w jaki sposób FLEDGE i raporty atrybucji będą obsługiwać przypadki użycia systemów uczących się do trenowania algorytmów ustalania stawek na aukcjach. | Zdajemy sobie sprawę, że potrzeba pomocy testerom w znajdowaniu najprzydatniejszych 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 systemów uczących się. W najnowszym artykule zatytułowanym „Maksymalizuj trafność reklam” omawiamy, jak branża reklamowa może wykorzystać te sygnały na potrzeby systemów uczących się. Planujemy nadal publikować tego typu wskazówki. |
| Zapytanie do serwera wartości klucza FLEDGE (K/V) | Dlaczego do serwera K/V można wysyłać zapytania? | Serwer K/V ma na celu dostarczanie sygnałów w czasie rzeczywistym do aukcji FLEDGE. W związku z tym serwer K/V musi być dostępny z miejsca, w którym odbywają się aukcje FLEDGE, czyli na urządzeniach użytkowników, i musi być dostępny publicznie. Wartość przechowywana na serwerze K/V może zostać pobrana tylko przez stronę, która ma już swój klucz. Jeśli więc technologia reklamowa przekaże klucze tylko przeglądarkom należącym do grupy zainteresowań i nie używa kluczy, które można losowo odgadnąć, będą mogły ją pobrać tylko te przeglądarki, które potrzebują tej wartości do przeprowadzenia aukcji. |
| Jak ustawić kierowanie na datę i godzinę? | Obsługa obiektów dat w funkcji logiki ustalania stawek. | Możesz to zrobić na kilka sposobów. Kupujący mogą poprosić sprzedawcę o podanie aktualnej daty i godziny. Sprzedawcy powinni móc udostępniać te informacje wszystkim kupującym. Kupujący mogą też podać datę i godzinę w odpowiedzi na żądanie pary klucz-wartość w czasie rzeczywistym. Kupujący mogą też podać datę i godzinę w ramach odpowiedzi kontekstowej w sygnałach dla poszczególnych kupujących, którą sprzedawca może przekazać do jego skryptu generateBid. |
| Preferencje użytkownika | Użytkownicy mogą blokować kreacje według reklamodawcy, gdy są wyświetlane przez FLEDGE lub alternatywne rozwiązania. | Użytkownicy mogą zrezygnować z interfejsów Ads API w Chrome. W przypadku konkretnych reklam odpowiednia technologia reklamowa pozwala kontrolować, które kreacje są wyświetlane i w jaki sposób są wybierane. |
| Bardziej przejrzyste ramy czasowe | Poproś o więcej informacji o dostępności zabezpieczeń prywatności FLEDGE, takich jak wymaganie ramek chronionych. | Bardziej szczegółowe harmonogramy działań planujemy opublikować w I kwartale. |
| Zgłaszanie niejasności | Poproś o większą jasność, jak raportowanie FLEDGE będzie działać z innymi interfejsami API, takimi jak Fenced Frames i Private Aggregation API. | W najbliższych tygodniach planujemy opublikować wyjaśnienie interakcji między interfejsem Private Aggregation API, FLEDGE i Fenced Frames. |
| Określanie stawek w czasie rzeczywistym a FLEDGE | Wskazówki dotyczące integracji FLEDGE ze standardowym określaniem stawek w czasie rzeczywistym. | Dwie główne aspekty, które utrudniają technikom reklamowym określanie stawek w czasie rzeczywistym, to dostęp do danych na poziomie zdarzenia i łatwiejsza integracja z ARA. W I kwartale planujemy udostępnić aktualne informacje i wyjaśnienia na te tematy. |
| Skuteczność aukcji FLEDGE | Raport od testerów o dużym czasie oczekiwania aukcji FLEDGE | Doceniamy zgłoszenia od testerów, którzy dzielą się swoimi wynikami i przypadkami użycia. Udostępniliśmy też kilka sugestii na temat poprawy wydajności FLEDGE. Ponadto dodaliśmy do przeglądarki narzędzia, które pozwalają deweloperom lepiej diagnozować, co spowalnia aukcje, i systematycznie eliminujemy główne źródła zaobserwowanych opóźnień. Najnowsze ulepszenia obejmują limity czasu oczekiwania w przypadku powolnych aukcji, metodę szybkiego filtrowania licytujących, możliwość powtórnego użycia roboczych arkuszy FLEDGE w celu uniknięcia opłat za uruchomienie oraz bieżące działania, aby zezwolić na realizację żądania reklamy kontekstowej równolegle z czasem uruchamiania FLEDGE i pobieraniem przez sieć. Spodziewamy się, że optymalizacja opóźnień będzie kontynuowana w ramach dyskusji między deweloperami Chrome a testerami FLEDGE na podstawie ich rzeczywistych doświadczeń związanych z korzystaniem z interfejsu API. |
| Limit pamięci rozmiaru grupy zainteresowań | Poproś o zwiększenie limitu rozmiaru pojedynczej grupy zainteresowań z 50 KB. | Aktywnie analizujemy tę prośbę i nie możemy się dowiedzieć, jaka wartość limitu działa. |
| Łączenie danych udostępnianych przez FLEDGE z własnym plikiem cookie | Czy FLEDGE będzie obsługiwać integrację z danymi własnymi reklamodawcy? | FLEDGE został opracowany z myślą o obsłudze wyświetlania reklam korzystających z danych własnych reklamodawcy, które już ma. FLEDGE nie ma jednak na celu wspierania reklamodawców, którzy uczą się, w jaki sposób użytkownik przegląda strony inne niż witryna reklamodawcy. Powiązanie informacji o przeglądaniu internetu poza witryną z danymi własnymi jest sprzeczne z celami Piaskownicy prywatności. W najbliższych tygodniach planujemy udostępnić przewodniki po integracji z bardziej szczegółowymi informacjami o tym, jak FLEDGE będzie obsługiwać integrację z danymi własnymi. |
| Wartość k-anonimowości | Jak zostanie określona wartość z „K” na „k-anon” i czy zostanie ona opublikowana? | Wartość „K” jest wciąż w fazie realizacji. Więcej informacji przekażemy w miarę rozwoju naszych planów. Chcemy się dowiedzieć, jak nieznana wartość k może utrudniać przygotowanie i określanie zakresu modeli ML FLEDGE. Chętnie poznamy też dodatkowe opinie na ten temat. |
| Obsługa wielu platform SSP | W jaki sposób FLEDGE będzie obsługiwać wiele platform SSP? | FLEDGE obsługuje aukcje z wieloma sprzedawcami, jak zaznaczono w tej ofercie pakietowej. |
| Widoczność logiki ustalania stawek | Obawia się, że logika ustalania stawek DSP będzie ujawniana w kodzie JavaScript | Zgodnie z obecną logiką ustalania stawek w projekcie kod JavaScript jest dostępny dla innych użytkowników, ale chętnie poznamy więcej opinii na temat tego, dlaczego platformy DSP mogą obawiać się tego problemu. |
| prebid.js | Jaki jest harmonogram wdrażania obsługi przedbid.js we FLEDGE? | Moduł FLEDGE jest obsługiwany tylko w wersji 7.14 i nowszych wersji Prebid.js. Wszyscy wydawcy zainteresowani testowaniem muszą dodać moduł FLEDGE i uaktualnić wystąpienie Prebid. |
| Funkcje zdefiniowane przez użytkowników we FLEDGE | Jak FLEDGE będzie obsługiwać funkcje definiowane przez użytkownika (UDF)? Są to funkcje, które użytkownicy mogą zaprogramować, aby zwiększyć funkcjonalność interfejsu API. | Wyjaśnienie jest dostępne tutaj. Wciąż pracujemy nad tym, więc chętnie poznamy dodatkowe opinie na temat przypadków użycia. |
| Łagodzenie ograniczenia dotyczącego tego samego pochodzenia w przypadku zasobów grupy zainteresowań | Prośba o złagodzenie ograniczenia związanego z tym samym źródłem w przypadku zasobów grupy zainteresowań, aby umożliwić korzystanie z określonych przypadków użycia technologii reklamowych | W obecnej implementacji FLEDGE API biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl i trustedBiddingSignalsUrl musi mieć to samo źródło co właściciel grupy zainteresowań.To ograniczenie służy do zapobiegania określonym sytuacjom wykorzystującym luki w zabezpieczeniach przez hakerów. Więcej informacji na ten temat znajdziesz tutaj. |
| prawo własności do grupy zainteresowań | Prośba o ograniczenie możliwości korzystania przez technologię reklamową z funkcji joinInterestGroup w przypadku tych samych grup zainteresowań w różnych witrynach | Koncentrujemy się na wykorzystaniu list odbiorców, a nie na sposobie ich tworzenia. O potencjalnych rozwiązaniach omawiamy tutaj. Zachęcamy też do przesyłania opinii. |
| Wygaśnięcie klucza serwera klucz-wartość | Dyskusja na temat usuwania kluczy serwera po wygaśnięciu odpowiednich grup zainteresowań | Szukamy sposobów radzenia sobie z wygaśnięciem kluczy i szukamy opinii tutaj. |
Pomiary reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ruch z testu origin | Obecny ruch w środowisku próbnym źródła jest niewystarczający do przeprowadzenia testów narzędziowych. | Bieżące wersje próbne Origin są przeznaczone dla graczy ekosystemu, którzy przeprowadzają testy funkcjonalne, aby sprawdzić, czy interfejs API działa zgodnie z oczekiwaniami. Zdajemy sobie sprawę, że wraz z doświadczeniem w tworzeniu różnych interfejsów API Piaskownicy prywatności konieczne będzie przeprowadzenie testów praktycznych w przypadku większych ilości ruchu. Obecny harmonogram testów przewiduje, że stanie się to w momencie ogólnej dostępności (czyli gdy technologie przeznaczone do określonych zastosowań zostaną udostępnione i dostępne dla całego ruchu w Chrome) w III kwartale 2023 r. (zapoznaj się z naszym aktualnym harmonogramem na stronie privacysandbox.com). Zachęcamy do wszelkich dodatkowych opinii na temat testowania przypadków użycia, które wymagają dodatkowego ruchu. |
| Pokrywanie się funkcji różnych interfejsów API Piaskownicy prywatności do pomiarów | Kwestie związane z pokrywaniem się różnych metod pomiarowych w Piaskownicy prywatności będą zwiększać złożoność, np. Attribution Reporting API i Private Aggregation API. | Pracujemy nad ulepszeniem dokumentacji, aby wyjaśnić różne przypadki użycia interfejsów API. Czekamy też na dodatkowe opinie na temat obszarów, w których brakuje wyjaśnień. Na przykład interfejs Attribution Reporting API służy do obsługi pomiaru konwersji, natomiast interfejs Private Aggregation API i Shared Storage to interfejsy API ogólnego przeznaczenia służące do obsługi szerszego zakresu przypadków użycia pomiarów w różnych witrynach. |
| Ponów nieudane żądanie raportu | Wyjaśnienie, ile razy nie udało się przesłać żądania zgłoszenia. | Opublikowaliśmy wskazówki na ten temat. Podsumowując, raporty są wysyłane tylko wtedy, gdy przeglądarka jest uruchomiona lub online. Jeśli nie uda się wysłać raportu, po 5 minutach ponawiamy próbę wysłania raportu. Jeśli wystąpi 2 nieudana próba, raport jest ponawiany po 15 minutach. Po tym czasie raport nie jest wysyłany. |
| Opóźnienie raportowania | Jakie jest oczekiwane opóźnienie w raportowaniu? | Chcielibyśmy otrzymać więcej opinii od ekosystemu na temat występujących opóźnień w raportowaniu, ponieważ gromadzimy dane, aby równolegle analizować te opóźnienia. |
| Wstępne renderowanie stron | Czy atrybucja ARA będzie działać na stronach renderowanych z wyprzedzeniem? | Rejestracja atrybucji jest wstrzymywana na stronach renderowania z wyprzedzeniem do chwili jej aktywacji (rzeczywiste kliknięcie lub wyświetlenie). Oznacza to, że odroczymy ping żądania „attributionsrc”. |
| Pomiar zwiększenia liczby konwersji | Pomiar zwiększenia liczby konwersji za pomocą testów A/B w tej samej domenie | Dzięki raportom atrybucji witryny mogą mierzyć wzrost liczby konwersji za pomocą testów A/B w tej samej domenie. Mogą zakodować swoje parametry A/B jako klucze za pomocą zagregowanego interfejsu API, a potem otrzymywać raporty podsumowujące wartości konwersji w tych segmentach kluczy. |
| (Również w III kwartale) Konwersje w wielu domenach | Śledzenie konwersji w wielu domenach, np. z co najmniej 2 miejscami docelowymi | Aktualizacja z IV kwartału: Opublikowaliśmy propozycję usunięcia ograniczenia miejsca docelowego strony docelowej, co umożliwi śledzenie rozmów w wielu domenach. Ta oferta pakietowa została wdrożona. |
| (Również odnotowano w III kwartale) Ustawienie wygaśnięcia w raporcie o konwersjach |
Prośba o włączenie filtra raportu / włączenie tej funkcji na mniej niż 24 godziny | Aktualizacja w IV kwartale: Udostępniliśmy to żądanie wycofania , które spowoduje odłączenie okresu ważności i okresów raportowania, co pozwoli ograniczyć porównanie czasu oczekiwania w raportowaniu i wygaśnięcia konwersji. Ta funkcja została wprowadzona w wersji M110. |
| Oszustwa i nadużycia | Prośby od reklamodawców i marketerów o możliwość zbierania i agregowania danych na podstawie witryn wydawców, na których są wyświetlane ich reklamy, co dałoby lepszy wgląd w potencjalne fałszywe praktyki reklamowe | Aktywnie omawiamy tę opinię tutaj . Zachęcamy do dodatkowych informacji. |
| (raportowane również w III kwartale) Opóźnienie raportowania na poziomie zdarzenia | Opóźnienie 2–30 dni w raportowaniu na poziomie zdarzenia może być za długie w niektórych przypadkach. | Raportowanie na poziomie zdarzenia domyślnie oferuje okres 2, 7 i 30 dni. Można go zmienić za pomocą parametru „expiry”. Technologie reklamowe mogą skonfigurować czas wygaśnięcia wynoszący co najmniej 1 dzień, aby uzyskać potencjalne raporty w czasie krótszym niż 2 dni. Ze względu na ochronę prywatności ograniczamy szczegółowość okresu ważności do 1 dnia, ponieważ bardziej szczegółowe raportowanie może prowadzić do ataków czasowych. Na poziomie zdarzenia i raportów zbiorczych zezwalamy też na ustawianie niezależnych parametrów „wygaśnięcie”. Skorzystaj z tego artykułu. Dodatkowo Google Ads nie będzie mieć żadnych specjalnych okien raportowania, które są niedostępne dla innych technologii reklamowych za pomocą Attribution Reporting API. |
| Wymaganie dotyczące tego samego źródła raportowania | Prośba o usunięcie wymogu, aby źródło rejestracji źródła było takie samo jak źródło rejestracji konwersji | Proponujemy użycie przekierowań HTTP do przekazywania rejestracji. Zachęcamy do wszelkich dodatkowych opinii na temat nowych wytycznych. |
| Śledzenie konwersji | Konieczne jest sprawdzenie, czy konwersja miała miejsce przed czy po określonych godzinach ustawionych przez reklamodawcę | Interfejs Attribution Reporting API obsługuje ustawianie okresu ważności i priorytetu atrybucji źródła. Korzystając z obu tych rozwiązań, technicznie będzie możliwe przypisanie konwersji, która miała miejsce w ciągu X dni, niezależnie od konwersji, która miała miejsce po X. |
| Symulacja szumu | Poproś o możliwość symulowania różnych liczby konwersji na grupę, aby poznać wpływ na reklamodawców o mniejszej liczbie konwersji | W kolejnych wersjach Noise Lab zamierzamy dodać sposoby symulacji tego działania. Chętnie poznamy Twoją opinię. |
| Raportowanie na urządzeniach mobilnych | Czy raport będzie nadal wysyłany, gdy Chrome działa w tle na urządzeniach mobilnych? | Obecnie, nawet na urządzeniach mobilnych, raport nie jest wysyłany, gdy Chrome działa w tle. Może się to zmienić po zintegrowaniu interfejsu API z Piaskownicą prywatności na Androida. Skorzystaj z tego artykułu. Pamiętaj, że Piaskownica prywatności na Androida nie jest częścią zobowiązań zaakceptowanych przez CMA. |
| Dostępność danych | obawiasz się, że Google będzie mieć dodatkowy dostęp do danych przez interfejsy API Piaskownicy prywatności. | Po pierwsze, Google Ads nie otrzymuje preferowanego dostępu do danych z Attribution Reporting API ani z innych interfejsów API Piaskownicy prywatności. Ten problem został też omówiony w sekcji „Ogólne opinie” w części „Interoperacyjność”, w której znajdziesz więcej informacji na temat zobowiązań Google. Po drugie, w odniesieniu do różnicy między większymi a mniejszymi witrynami, Google rozpoznaje, że zabezpieczenia prywatności oparte na szumach mogą mieć większy wpływ na mniejsze wycinki danych. Istnieją jednak pewne sposoby pozwalające złagodzić ten problem: na przykład zastosowanie agregacji w dłuższym przedziale czasu może rozwiązać ten problem. Jednak trudno jest stwierdzić, czy wnioski wyciągane na podstawie bardzo małych wycinków danych (np. jednego lub dwóch zakupów) są w ogóle istotne dla reklamodawców. W trakcie testowania origin zachęcaliśmy testerów do wypróbowania szerokiego zakresu parametrów związanych z prywatnością i hałasem, co pozwoli im przekazać bardziej szczegółową opinię na temat tego problemu. |
Ogranicz ukrycie
Redukcja klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Opóźnij redukcję klienta użytkownika do czasu przygotowania ekosystemu internetowego | Nie ma wystarczająco dużo czasu na przystosowanie się do nadchodzących zmian dotyczących redukcji klienta użytkownika. | Opinie na ten temat omawiamy w pełnym raporcie w części „Uwagi zainteresowanych osób” w sekcji zatytułowanej „Interakcja Google z CMA”. |
| Opóźnij redukcję klienta użytkownika do czasu przygotowania ekosystemu internetowego | Żądanie opóźnienia wdrożenia redukcji klienta użytkownika do czasu wdrożenia ustrukturyzowanych klientów użytkownika (SUA) | Zespół Google Ads zaproponował dodanie uporządkowanych danych klienta użytkownika (patrz specyfikacja) do OpenRTB w październiku 2021 roku i zostało ono włączone w aktualizacji specyfikacji do wersji 2.6 opublikowanej w kwietniu 2022 r. Mamy dowody na wdrożenie i udostępnienie usługi SUA. Można je znaleźć w poście na blogu Scientia Mobile, w którym pokazano, jak użyć UA-CH i interfejsu WURFL API do utworzenia konta SUA. |
###
Wskazówki dotyczące klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Przetestuj UA-CH z innymi technikami zapobiegającymi ukryciu | Wskazówki dotyczące testowania wszystkich interfejsów API Piaskownicy prywatności i technik pobierania odcisków cyfrowych zaproponowanych razem w ramach podejścia holistycznego | Nasz plan testów został opracowany z myślą o asynchronicznym harmonogramie opracowywania niektórych środków zapobiegających drukowaniu cyfrowym w odróżnieniu od pozostałych propozycji w trybie piaskownicy. Jest to odpowiedź na to, że niektóre rozwiązania zapobiegające odciskowi palców (np. budżet prywatności, ochrona adresu IP i łagodzenie śledzenia przekierowań) zostaną w pełni opracowane i będą gotowe do udostępnienia wszystkim użytkownikom dopiero po wycofaniu plików cookie innych firm. Chociaż metody zapobiegające odciskowi palców nie zostaną uwzględnione w testach ilościowych, zostaną poddane ocenie jakościowej na podstawie danych dostępnych w momencie zatrzymania. |
| (również w II kwartale) Skuteczność |
Obawy związane z opóźnieniem otrzymywania wskazówek przez tag critic-CH (przy pierwszym wczytaniu strony). | Zapoznaj się poniżej z sekcją dotyczącą UA-CH |
| Niewystarczająca opinia | Opinie z ekosystemu na temat zmiany UA-CH mogą być niewystarczające, dlatego mogą pojawić się obawy o brak wiedzy na temat zmian w ekosystemie. | Aktywnie informujemy o naszych planach, aby wdrożenie tych rozwiązań pozwalało zminimalizować zakłócenia w działaniu usługi. Plany dotyczące redukcji klienta użytkownika oraz interfejsu UA-CH API zostały przedstawione 18 marca 2022 r. grupie W3C Anti-Fraud Community Group oraz 20 stycznia 2022 r. zarówno grupie roboczej Web Payments, jak i Web Payments Security Interest Group. Nie zgłoszono żadnych poważnych obaw w trakcie prezentacji ani po ich zakończeniu. Aktywnie współpracujemy z ponad 100 operatorami witryn, aby uzyskać ich opinie. Ponadto na podstawie opinii zainteresowanych osób z ekosystemu firma Google wykorzystała też kanały Blink-Dev do publicznego informowania o wdrożeniu redukcji klientów użytkownika. |
| Czas | wątpliwości dotyczące terminu wdrożenia i przygotowania branży do zmian. | Zapoznaj się poniżej z sekcją dotyczącą UA-CH |
| Stan platformy Chrome | Poproszono o zaktualizowanie strony chromestatus dotyczącej UA-CH | 19 grudnia wpis chromestatus został zmieniony na „Różne sygnały”. |
Ochrona IP (dawniej Gnatcatcher)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Włączanie i wyłączanie funkcji | Czy prywatność dla adresów IP jest włączona czy nie? | Naszym celem jest zapewnienie wszystkim użytkownikom ochrony adresów IP. Mając to na uwadze, analizujemy obecnie opcje wyboru użytkowników w zakresie ochrony adresu IP. |
| Przypadek użycia adresu IP w przypadku danych własnych | Czy można używać adresów IP do łączenia ścieżek użytkowników w domenach własnych po włączeniu ochrony adresu IP? | Jak wcześniej opublikowaliśmy, ochrona adresów IP będzie początkowo koncentrować się na śledzeniu w kontekście rozwiązań zewnętrznych, co oznacza, że nie będzie to miało wpływu na domeny własne. |
| Przypadki użycia technologii reklamowych | W jaki sposób firmy mogą skonfigurować zabezpieczenia przed oszustwami przy użyciu ochrony adresu IP? | Zdajemy sobie sprawę, jak duże znaczenie ma adres IP jako sygnał do zwalczania oszustw we współczesnym internecie. W ramach zobowiązań wynikających z ustawy CMA (paragraf 20) postanowiliśmy nie wdrożyć ochrony własności intelektualnej, jeśli nie dołożymy uzasadnionych starań, aby wspomóc witryny zwalczające spam i oszustwa. Jednym z naszych priorytetów jest zrozumienie, jak ochrona własności intelektualnej wpływa na przypadki użycia i funkcje wykrywania oszustw. Dzięki temu możemy dalej inwestować w technologie chroniące prywatność, które pomagają firmom zachować bezpieczeństwo w sieci. Zachęcamy do przekazywania opinii i opinii dotyczących nowych propozycji mających na celu zaspokajanie potrzeb firm w zakresie bezpieczeństwa i zwalczania oszustw, nawet jeśli sygnały zmieniają się z czasem. |
| Oszustwa i nadużycia | Czy ochrona adresów IP obejmuje ochronę przed atakami typu DoS (Denial of Service)? | Dokładamy wszelkich starań, aby poprawić prywatność, a jednocześnie zapewnić bezpieczeństwo w internecie. Ochrona przed atakami typu DoS jest też ważnym przypadkiem użycia przeciwdziałania nadużyciom. Mamy nadzieję, że uda nam się zminimalizować wpływ na zabezpieczenia związane z atakami typu DoS zarówno przez opracowanie samej ochrony IP, jak i przez nowe rozwiązania zwalczające nadużycia. Ochrona adresów IP koncentruje się początkowo na osadzonych usługach innych firm, dlatego część zainteresowanych osób twierdzi, że powinna mieć ona ograniczony wpływ na ochronę przed atakami typu DoS w witrynach własnych. Nadal prosimy jednak o publiczne opinie, aby ocenić ryzyko związane z DoS, w szczególności w przypadku wbudowanych usług innych firm. Jednocześnie badamy mechanizmy związane z nadużyciami w zakresie zgłaszania nadużyć oraz mechanizmami blokowania klientów, które umożliwiłyby witrynie lub usłudze blokowanie użytkowników spamerskich bez identyfikowania tego użytkownika. |
| Filtrowanie treści | Filtrowanie treści za pomocą ochrony adresu IP | Różne firmy mają różne potrzeby w zakresie filtrowania treści i dostosowywania materiałów do potrzeb użytkowników. Wiele takich przypadków użycia nie korzysta obecnie z adresów IP, więc funkcja ochrony adresu IP nie powinna mieć na nie wpływu. Na przykład wydawca, który chce dostosować swoje treści i zwiększyć zaangażowanie, może wykorzystać własne pliki cookie lub pliki cookie partycjonowane przez inną firmę, aby poznać zainteresowania użytkowników i wcześniejsze interakcje z nim. Z kolei partner w zakresie technologii reklamowych, którego celem jest wyświetlanie trafnych reklam właściwym użytkownikom, może np. zastosować FLEDGE i Topics, aby uzyskać podobne wyniki reklamowe jak obecnie w przypadku plików cookie innych firm lub innych technologii śledzenia w witrynach. Pracujemy też nad dodaniem do ochrony adresu IP nowych funkcji, takich jak przybliżona geolokalizacja, które pozwolą w dalszym ciągu obsługiwać filtrowanie treści w sytuacjach, gdy istniejące mechanizmy mogą być niewystarczające. Chętnie poznamy też dodatkowe opinie na temat przypadków użycia filtrowania treści, na które może mieć wpływ ochrona adresu IP. |
| (Również w III kwartale) Przypadki użycia geolokalizacji |
Ochrona IP może uniemożliwić działanie prawidłowych przypadków użycia geolokalizacji w przyszłości, np. personalizacji treści na podstawie geolokalizacji. | Aktualizacja w IV kwartale: Współpracujemy z zainteresowanymi osobami, aby przeglądarka Chrome nadal obsługiwała uzasadnione przypadki użycia adresów IP. Chętnie poznamy Twoją opinię o szczegółowości geolokalizacji IP z ekosystemu tutaj. |
Budżet prywatności
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Bardziej przejrzysta dokumentacja | Więcej przykładów, aby zainteresowane osoby mogły przewidzieć, jak może zostać ograniczona po wdrożeniu budżetu dotyczącego prywatności | Propozycja budżetu na potrzeby prywatności jest nadal w fazie dyskusji i nie została wdrożona w żadnej przeglądarce. Najwcześniejsza data skalowanej dostępności to najwcześniejszy dzień, w którym można wdrożyć budżet prywatności. Nie będzie to miało miejsca przed usunięciem plików cookie innych firm w 2024 roku. W tej chwili nie mamy żadnych dodatkowych dokumentów do udostępnienia. Dodatkowe szczegóły przekażemy, gdy oferta pakietowa będzie bardziej sfinalizowana. Tymczasem zachęcamy zainteresowane osoby do podzielenia się opinią, które pomogą nam opracować ofertę. |
Wzmocnij granice prywatności między witrynami
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (raport zaraportowany również w III kw.) Limit domen | Poproś o zwiększenie liczby powiązanych domen | Aktualizacja za 4 kwartał: Udostępniliśmy funkcje FPS na potrzeby testów lokalnych, w tym proces przesyłania próbnego zestawu ćwiczeń na GitHubie oraz flagę do testów RSA i rSAFor lokalnie. Zorganizowaliśmy też 2 otwarte spotkania dla deweloperów zajmujących się FPS, aby nadal omawiać przypadki użycia dotyczące powiązanych podzbiorów. Zachęcamy deweloperów do przetestowania funkcji FPS, aby poinformować ich o tym, jak limit domeny w powiązanym podzbiorze wpłynie na użyteczność tych klatek w danym przypadku. Podczas rozmów WICG wyjaśniliśmy, że celem Chrome jest dostarczanie przydatnego rozwiązania, które uwzględnia także interesy użytkowników dotyczące prywatności. W związku z tym będziemy wdzięczni za opinie społeczności na temat konkretnych przypadków użycia, na które może mieć wpływ limit domen. Dzięki temu zespół będzie mógł zastanowić się, jak rozwiązać te problemy, a jednocześnie nadal chronić prywatność użytkowników. |
| Prośba o więcej informacji na temat środków mających na celu zapobieganie nadużyciom | Co się stanie, jeśli domena zostanie dodana do zestawu, na który użytkownicy nie wyrazili zgody? | Wskazówki dotyczące przesyłania zestawów źródeł własnych opublikowaliśmy tutaj 2 grudnia 2022 r. Zgodnie z wytycznymi dotyczącymi przesyłania zgłoszeń każdy zbiór zmian musi być zgodny z procesem weryfikacji na GitHubie (w tym weryfikacji własności), co powinno zminimalizować to ryzyko. |
| Łagodzenie nadużyć | obawiasz się, że może dojść do wykorzystania formacji z zestawu źródeł własnych. | Szukamy sposobów na rozszerzenie kontroli technicznych dotyczących podzbiorów. Aktywnie szukamy dodatkowych informacji od społeczności, którą znajdziesz tutaj. |
| Przypadki użycia reklam | Wątpliwości dotyczące tego, czy do kierowania reklam powinny być używane zestawy źródeł własnych | Nie obsługujemy przypadków użycia kierowania reklam w przypadku zestawów źródeł własnych. Zalecamy korzystanie z dostępnych w nich interfejsów API Google Ads. |
| (Dodatkowo odnotowano w III kwartale) | Wątpliwość, że zasady FPS są niezgodne ze zobowiązaniami CMA w odniesieniu do „Obowiązującego ustawodawstwa dotyczącego ochrony danych”, ponieważ RODO nie nakłada limitu na liczbę witryn w zestawie, podczas gdy w przypadku FPS obowiązuje limit 3 witryn. | Nasza odpowiedź się nie zmieniła: „Google zobowiązuje się nadal tworzyć i wdrażać propozycje CMA w celu projektowania i wdrażania propozycji Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samopostrzeganie własnej firmy Google oraz uwzględniać wpływ na konkurencję w reklamie cyfrowej, wydawców i reklamodawców, jak również na wyniki związane z prywatnością i zgodność z zasadami ochrony danych określonymi w Obowiązującym ustawodawstwie dotyczącym ochrony danych. Wyrażone obawy nie wskazują na brak zgodności z RODO. W dalszym ciągu ściśle współpracujemy z CMA, aby mieć pewność, że nasza praca wywiązuje się z tych zobowiązań”. |
| Alternatywna propozycja | Zestawy zweryfikowane pod kątem RODO | Oprócz opinii przekazanych przez ekosystem na temat propozycji wprowadzenia „zestawów zweryfikowanych pod kątem zgodności z RODO” Chrome ma wątpliwości co do tych ograniczeń związanych z alternatywną ofertą:
Ponieważ podjęto tę alternatywę, zaktualizowaliśmy ofertę pakietową zestawów źródeł własnych i opublikowaliśmy wytyczne dotyczące przesyłania tworzenia nowych zestawów w Chrome. |
Interfejs Fenced Frames API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ograniczenia dotyczące chronionych ramek w czasie dogrzania | Jakie są aktualne ograniczenia dotyczące ramek Fenced Frame w okresie testowania origin? | Pracujemy nad dokumentacją dotyczącą ograniczeń i stanu implementacji. Planujemy udostępnić ją w I kwartale 2023 r. |
| Wiele reklam w jednej chronionej ramce | Wysyłanie prośby o wyświetlanie wielu reklamodawców w jednej chronionej ramce w ramach jednej aukcji | Obecnie nie pracujemy nad tym, ale jeśli gracze ekosystemu uznają tę funkcję za ważną, zachęcamy do dodatkowych opinii. |
| Pakiety internetowe | Jakie są wymagania dotyczące pakietów internetowych z zabezpieczonymi ramkami i jakie będą obsługiwane usługi? | Obecnie nie jesteśmy w stanie stwierdzić, czy w przyszłości stanie się to wymogiem. Wszelkie zmiany są zapowiadane z wyprzedzeniem i nie zostaną zastosowane do czasu wycofania plików cookie innych firm. Aktualny stan znajdziesz w tym wyjaśnieniu. |
Interfejs API pamięci współdzielonej
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Pamięć współdzielona na potrzeby technologii reklamowych | Niepewność co do wykorzystania pamięci współdzielonej na potrzeby technologii reklamowych | Interfejsu API współdzielonej i prywatnej agregacji można używać do różnych celów pomiarowych, które wymagają pomiaru miejsca na dane w różnych witrynach. Ich listę znajdziesz tutaj. Przewidujemy, że dostawcy platform DSP i rozwiązań pomiarowych będą głównym integratorem przypadków użycia reklam. |
ELEMENTY
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wymagania dotyczące partycjonowania (raportowane również w III kwartale) | Dodaj wymagania dotyczące działania atrybutu „Partitioned” (przydzielone) w przypadku własnych plików cookie. | Aktualizacja za IV kwartał: Po dyskusjach na temat wywołań GitHub i PrivacyCG stwierdziliśmy, że partycjonowane pliki cookie ustawione na własnych plikach cookie będą używać klucza partycji (A,A), gdzie „A” to strona najwyższego poziomu. Działanie tej funkcji zostanie udokumentowane w wyjaśnieniu i specyfikacji. |
| Zarządzanie plikami cookie | Czy są dostępne narzędzia do zarządzania własnymi plikami cookie i plikami cookie innych firm? | Do testowania witryn z włączonym blokowaniem plików cookie innych firm można używać Narzędzi deweloperskich w Chrome i NetLog. Oba narzędzia zgłaszają blokowanie plików cookie ze względu na konfigurację użytkownika. Chętnie poznamy opinie na temat tego, jakie dodatkowe witryny kontrolne powinny być dostępne. |
FedCM
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Dostawca tożsamości wymaga znajomości RP, aby zezwolić na sesję | Problem, gdy użytkownik próbuje zalogować się do dostawcy tożsamości Feide z 2 różnych RP | Możliwe rozwiązania tego problemu omawiamy tutaj. |
| Interoperacyjność | wątpliwości dotyczące wpływu FedCM na relacje między użytkownikami a witrynami, w których logują się za pomocą FedCM, a także na „interoperacyjność” witryn. | FedCM chce nadal obsługiwać sfederowane usługi tożsamości, które obecnie po usunięciu z Chrome plików cookie innych firm korzystają z plików cookie innych firm. Spodziewamy się, że FedCM będzie tylko jedną z opcji dostępnych w takich usługach. Dostawcy tożsamości i strony uzależnione mogą korzystać z innych technologii, które mogą lepiej odpowiadać ich potrzebom. Wygląda na to, że obawy dotyczące relacji między użytkownikiem a RPA oraz „interoperacyjności” wynikają z niezrozumienia oferty FedCM. FedCM pozostawia to dostawcom tożsamości, by zdecydować, które informacje udostępnić grupie objętej ograniczeniami i w jakiej formie, gdy użytkownik zaloguje się na stronie tej grupy. FedCM nie wymaga od dostawców tożsamości „tworzenia unikalnego pseudonimowego identyfikatora dla każdej [RP], u której użytkownik się uwierzytelnia”. Zamiast tego dla każdego dostawcy tożsamości dostępna jest usługa FedCM, która umożliwia określenie, czy udostępnić rzeczywisty identyfikator użytkownika, wersję tego identyfikatora przeznaczoną dla witryny czy inną wersję tych informacji. (Specyfikacja FedCM identyfikuje korelację między witrynami jako ryzyko związane z prywatnością związane z interfejsem API i dyskutuje na identyfikatory kierowane (na witrynę) jako możliwe środki zaradcze. Jednak o decyzji o korzystaniu z identyfikatorów skierowanych do określonych dostawców tożsamości decydują dostawcy tożsamości, a nie przeglądarka. FedCM umożliwia już wybór użytkownika w odniesieniu do tożsamości. Jeśli na przykład użytkownik ma kilka tożsamości z tym samym dostawcą tożsamości (np. profil służbowy i osobisty), FedCM umożliwia mu wybranie jednej z nich, by zalogować się w witrynie grupy objętej ograniczeniami. Poza tym każda grupa z ograniczonym dostępem decyduje o tym, których dostawców tożsamości będzie obsługiwać w swojej witrynie. Jednym z aspektów takiej decyzji jest uwzględnienie mechanizmu, na którym opiera się dostawca tożsamości, niezależnie od tego, czy jest to FedCM czy inna technologia. Również w przypadku RP i dostawców tożsamości przeglądarka nie decyduje o tych opcjach. |
Zwalczanie spamu i oszustw
Private State Token API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Obsługa botów | Co się stanie, jeśli wydawca dowie się, że tokeny prywatności zostały wydane botom? | Aby zapobiec pozostawaniu tokenów wydanych dla botów przez dłuższy czas, wydawcy powinni dokonywać rotacji kluczy, których używają do regularnego podpisywania tokenów, tak aby stare tokeny wydawane zgodnie z potencjalnie uszkodzoną logiką wystawiania, a witryny wykorzystywały nowsze tokeny ze zaktualizowaną logiką wystawiania. |
| Przesłania formularza z tej samej witryny | Czy tokeny prywatności mogą być używane w przypadku przesyłania formularzy w tej samej witrynie, które obejmują nawigację na całej stronie (tj. Content-Type: application/x-www-form-urlencoded) zamiast żądania z interfejsów API fetch/XMLHttpRequest? | Obecnie nie jest to obsługiwane w pierwszej wersji prywatnych tokenów prywatności. Jeśli istnieje duże zapotrzebowanie na ten przypadek użycia, chętnie poznamy opinie członków ekosystemu. |
| Weryfikacja po stronie serwera | Pytania o możliwość weryfikacji tokenów prywatności po stronie serwera | Tokeny są realizowane u wydawcy i wydawca tworzy rejestr wykorzystania, który może zawierać sam token lub wskazaną wartość uzyskaną z tego tokena. Serwery mogą użyć tego rekordu w celu zweryfikowania autentyczności tokena. Spodziewamy się, że różne ekosystemy wydawców będą opracowywać odmienne standardy dotyczące interpretacji rejestrów wykorzystania. |