Raport z opiniami – II i III kwartał 2024 r.

Czwarty raport za II i III kwartał 2024 r. podsumowujący opinie na temat propozycji dotyczących Piaskownicy prywatności oraz odpowiedź Chrome.

W ramach zobowiązań wobec CMA Google zgodziło się na publiczne udostępnianie cokwartalnych raportów dotyczących procesu zaangażowania interesariuszy w przypadku propozycji dotyczących Piaskownicy prywatności (patrz punkty 12 i 17(c)(ii) zobowiązań). 22 lipca 2024 r. Google ogłosił, że nie wycofa plików cookie innych firm w Chrome, a zamiast tego zaproponował wprowadzenie zaktualizowanego podejścia, które zapewnia użytkownikom większy wybór. Dlatego, za zgodą CMA, Google nie przesłał do CMA publicznego raportu za II kwartał 2024 r., aby dać Google i CMA wystarczająco dużo czasu na uwzględnienie konsekwencji ogłoszenia Google.

Raporty z podsumowaniem opinii na temat Piaskownicy prywatności są generowane przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, takich jak problemy z GitHubem, formularz opinii udostępniony na stronie privacysandbox.com, spotkania z zainteresowanymi osobami z branży i fora do spraw standardów internetowych. W Chrome z przyjemnością przyjmujemy opinie z ekosystemu i aktywnie poszukuje sposobów na wykorzystanie wniosków wyciągniętych z decyzji projektowych.

Tematy opinii są klasyfikowane według częstotliwości występowania w przypadku poszczególnych interfejsów API. Polega to na zsumowaniu ilości opinii, które zespół Chrome otrzymał w danym temacie, i posortowaniu ich w malejącym porządku według 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ę standardami internetowymi. 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 zespół Google koordynował pracę zespołów uczestniczących w tych różnych działaniach mających na celu zwiększenie zasięgu, aby określić względną częstotliwość występowania tematów pojawiających się w odniesieniu do poszczególnych interfejsów API.

Wyjaśnienia dotyczące odpowiedzi Chrome na opinie zostały opracowane na podstawie opublikowanych najczęstszych pytań i odpowiedzi na problemy zgłoszone przez zainteresowane strony oraz określenia stanowiska w ramach tego publicznego raportu. W związku z obecnym celem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące głównie interfejsów API Topics, Protected Audience i Attribution Reporting.

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

Słowniczek akronimów

ARA

Attribution Reporting API

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

Interfejs API PAT

Protected Audience API (dawniej FLEDGE)

PatCG

Grupa społeczności technologii reklamowych

RP

Jednostka zależna

RWS

Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)

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, bez konkretnego interfejsu API/technologii

Temat opinii	Podsumowanie	Odpowiedź Chrome
Wycofanie plików cookie innych firm (3PCD)	Jakie są plany Google dotyczące 3PCD i czy zostały ocenione długoterminowe skutki dla branży reklamy cyfrowej?	Proponujemy zaktualizowane podejście, które rozszerza opcje wyboru użytkownika. Zgodnie z opisem tutaj, zamiast wycofywać komputery zewnętrzne, wprowadziliśmy w Chrome nową funkcję, która pozwoli użytkownikom dokonywać świadomych wyborów związanych z przeglądaniem stron internetowych i w każdej chwili je zmienić. Omawiamy tę nową ścieżkę z organami regulacyjnymi i skontaktujemy się z branżą, zanim ją wdrożymy.
Wybór użytkownika	Ogłoszenie dotyczące wyboru użytkownika wpłynęło na zainteresowanie ekosystemu wdrażaniem rozwiązań Piaskownicy prywatności. Istnieje wiele opinii dotyczących ogłoszenia wyboru użytkownika. Dotyczy to też próśb dotyczących funkcji takich jak możliwości monitorowania.	W ramach zaktualizowanego podejścia, które zwiększa wybór użytkownika, ważne jest, aby deweloperzy mieli alternatywy dla identyfikatorów w wielu witrynach, które zapewniają większą ochronę prywatności. Nie wiemy jeszcze szczegółowo, jak będzie to wyglądać w nowej wersji, ale spodziewamy się znacznego zwiększenia ruchu w Chrome bez plików cookie. Oznacza to, że interfejsy API Piaskownicy prywatności pozostają kluczowe dla firm. Będziemy nadal inwestować w technologie Piaskownicy prywatności, aby jeszcze bardziej zwiększyć ochronę prywatności i przydatność.
Interfejs wyboru użytkownika	Pytania dotyczące harmonogramu funkcji rezygnacji z reklamy lub wyrażenia zgody, typu opcji użytkownika, które są rozważane, oraz wpływu interfejsu użytkownika na środowiska testów automatycznych.	W tej chwili nie mamy żadnych nowych informacji na ten temat. Po podjęciu decyzji o nierozwijaniu 3PCD chcieliśmy jak najszybciej przekazać tę informację ekosystemowi. Gdy tylko będziemy mieć nowe informacje, powiadomimy Cię o harmonogramie udostępnienia opcji wyboru dla użytkowników.
Testowanie w Chrome	Prośba o dalszą dostępność etykiet testów obsługiwanych przez Chrome w celu pomiaru akceptacji na rynku i wpływu 3 PC na gospodarkę po I połowie 2024 r.	Zdajemy sobie sprawę, że testerzy będą nadal używać oznaczonych grup przeglądarek do testowania i koordynacji, mimo że w pierwszej połowie 2024 roku testowanie obsługiwane przez Chrome w pierwszej połowie 2024 roku dobiega końca. W świetle ogłoszonego przez nas wyboru użytkownika analizujemy, jakie kroki podjąć w sprawie etykiet. Tymczasem zespół Chrome opublikował oświadczenie o chęci przedłużenia obsługi grup przeglądarek z oznaczoną etykietą do wersji Chrome Milestone 132, która będzie obowiązywać do stycznia 2025 roku.
Piaskownica prywatności na Androida	Piaskownica prywatności w Androidzie i w Chrome są ze sobą nierozerwalnie powiązane, a bez Androida nie możemy właściwie ocenić Piaskownicy prywatności. Typowa ścieżka klienta, która obejmuje różne urządzenia i różne punkty styczności z klientem, ma kluczowe znaczenie zarówno dla Piaskownicy prywatności w Chrome, jak i w Piaskownicy prywatności na Androida.	Zobowiązania Google dotyczące CMA nie obejmują Piaskownicy prywatności na urządzeniach z Androidem. Jeśli opinia dotyczy harmonogramu i wdrażania Androida, nie mamy żadnych nowości do przekazania, poza tym, że nadal pracujemy nad Androidem, który traktujemy jako niezależny strumień pracy służący do poprawy prywatności. Jak już wspomnieliśmy, dostępność interfejsów API Piaskownicy prywatności na Androidzie będzie zależeć także od tego, jak często użytkownicy aktualizują swoje urządzenia. Nie jest to zależne od Google.
Ograniczony ruch w trybie B	Ruch z aukcji reklam dostępny w trybie B był mniejszy od oczekiwanego.	Istnieje wiele powodów, dla których wolumeny aukcji w przypadku interfejsu Protected Audience API (PA API) mogą być niższe niż oczekiwano. Oto niektóre z nich: - Firmy, które, jak nam wiadomo, zintegrowały PA API, uwzględniły tylko formaty banerów. - Platformy SSP nie zawsze mogą rozpocząć aukcję. – przeglądarka może nie mieć grup zainteresowań. – Być może nie ma żadnych stawek. Nie wiemy jednak o żadnym użytkowniku, który próbował przetestować interfejs PA API i nie uzyskał żadnego ruchu.
Widoczność przerwy	Informacje o przerwach w działaniu i problemach dotyczących interfejsów API Piaskownicy prywatności.	Istnieje publiczna strona stanu interfejsów API Piaskownicy prywatności, które obsługują usługi poza przeglądarką. Zespół Chrome stawia na pierwszym miejscu niezawodność naszej platformy i wszystkich kluczowych interfejsów API używanych przez najważniejsze strony i usługi w internecie, w tym technologie Piaskownicy prywatności. Do tej pory miała miejsce tylko 1 przerwa w działaniu usługi. Było to związane z tymczasową konfiguracją na potrzeby testów przy 1%. Wkrótce eksperymentalna konfiguracja, która była przyczyną przerwy w działaniu, nie będzie już potrzebna. Jesteśmy przekonani, że ten problem nie wystąpi, gdy interfejsy API zostaną włączone w zwykły sposób w Chrome.
Badanie wykresu plików cookie	Jakie jest podejście Chrome do metody CookieGraph opisanej w tym artykule w ramach Piaskownicy prywatności?	Raport zawiera interesujące kwestie dotyczące wykrywania i powszechności własnych plików cookie ustawianych przez domeny inne niż odwiedzane przez użytkownika. Jak czytamy w artykule, te pliki cookie są niezwykle przydatne do zbierania informacji analitycznych i informacji o tym, jak użytkownicy wchodzą w interakcje z witryną. Te dane są kluczowe dla deweloperów, którzy chcą zapewnić użytkownikom lepsze wrażenia z przeglądania. Główny argument artykułu jest wadliwy, ponieważ uznaje pliki cookie 1P za wektor śledzenia w wielu witrynach. Jest to jednak możliwe tylko przy bardzo agresywnych założeniach opisanych w artykule: Użytkownicy są gotowi udostępnić witrynie swoje dane osobowe. Urządzenia mają stabilny odcisk palca, który może służyć do śledzenia użytkownika w witrynach. Pamiętaj, że są to wektory ponownej identyfikacji, które można wykorzystać bez użycia plików cookie 1P (np. przez udostępnianie danych po stronie serwera). Należy je rozpatrywać osobno od naszych obecnych działań, które koncentrują się na mechanizmach śledzenia opartych na stanie, takich jak pliki cookie 3PC. Na koniec chcielibyśmy zwrócić uwagę, że artykuł utożsamia pliki cookie analityczne i reklamowe z plikami cookie śledzącymi, a pliki cookie ściśle niezbędne z plikami cookie, które nie śledzą, co nie zawsze jest prawdą. Własne analizy lub usługi dostawców zewnętrznych, takie jak widżety lokalizatora sklepów, widżety czatu czy pliki cookie systemu równoważenia obciążenia, mogą być często ograniczone do tylko jednej domeny, a niektóre bezwzględnie niezbędne pliki cookie mogą być używane do śledzenia w wielu witrynach w celu zapobiegania oszustwom.
Zmiany w UX	Zmiany w UX w Chrome 112, które umieszczają ustawienia plików cookie 1P w sekcji „Dane witryn na urządzeniu” w ustawieniach Chrome, mogą utrudniać użytkownikom blokowanie wszystkich plików cookie.	Ta zmiana została wprowadzona w ramach działań mających na celu oddzielenie i ulepszenie kontroli nad 3 PC (czyli niepartycjonowanej pamięci) od wszystkich innych rodzajów danych witryny. Ustawienia 3PC są dostępne w panelu Prywatność i bezpieczeństwo, a ustawienia plików cookie własnych i wszystkich innych rodzajów danych witryn, od których zwykle zależy działanie kluczowych funkcji witryny, są pogrupowane w sekcji „Dane witryn na urządzeniu”. Będziemy nadal zbierać opinie na ten temat, ale uważamy, że obecne rozdzielenie zapewnia odpowiednią równowagę między możliwością znalezienia istotnych ustawień prywatności a zachowaniem funkcjonalności przeglądania.
Rozliczenia i płatności	Rozliczenia i płatności nie są w pełni testowane, ponieważ testerzy są bardziej zaangażowani w testowanie innych obszarów interfejsów API Piaskownicy prywatności.	To, kiedy i co deweloperzy oraz firmy decydują się testować, to ich wybór. Interfejsy API są ogólnie dostępne do testowania od września 2023 r.
Testowanie	Nie cały ruch eksperymentalny, który platformy DSP otrzymują z SSP, jest oznaczony etykietą. Niektóre DSP zgłosiły, że udział eksperymentalnych wyświetleń bez etykiet może się różnić w przypadku grup eksperymentalnej i kontrolnej.	Chrome nie może kontrolować, czy firmy przekazują etykiety w pytaniach o stawkę. Udostępniamy metodę pobierania etykiety z przeglądarki. Jeśli partner nie jest w stanie bezpośrednio odczytać etykiet, to od danego ekosystemu zależy jego przekazanie partnerom.
Pliki cookie innych firm w komponencie WebView Androida	prośba o wskazówki dotyczące włączenia flagi „Testowanie wycofywania plików cookie innych firm” w komponencie WebView na Androida na potrzeby testowania wycofywania.	Pliki cookie innych firm są domyślnie zablokowane w komponencie WebView Androida.
Prywatność różnicowa w celu zminimalizowania ryzyka związanego z trenowaniem modeli	Dlaczego prywatność różnicowa jest używana w trenowaniu modeli?	Prywatność różnicowa w połączeniu z zaufanymi środowiskami wykonawczymi (TEE) ma kluczowe znaczenie w trenowaniu modeli, ponieważ umożliwia zapobieganie wyciekom danych i zabezpieczanie informacji poufnych przed zagrożeniami. Dzięki temu wagi modelu nie mogą ujawniać danych poszczególnych użytkowników.

Rejestracja i poświadczenie

Temat opinii	Podsumowanie	Odpowiedź Chrome
Rejestracja	Prośba o wyjaśnienie, jak działa rejestracja weryfikacji między zaewidencjonowanym punktem początkowym a punktem początkowym technologii reklamowej z subdomeną www.	Technologie reklamowe trzeba wdrożyć tylko https://example.com. Po umieszczeniu atestu w regionie https://example.com/.well-known/privacy-sandbox-attestations.json tag https://www.example.com jest uwzględniany, ponieważ jest to subdomena.
Specyfikacja interfejsu API	Sugerowanie dodania do repozytorium schematu JSON dla pliku potwierdzenia.	Rozpatrujemy tę sugestię. Chętnie poznamy Twoją opinię tutaj.

Wyświetlanie odpowiednich treści i reklam

Tematy

Temat opinii	Podsumowanie	Odpowiedź Chrome
Waga tematów	Najważniejszą rzeczą, o której należy pamiętać w przypadku interfejsu Topics, jest rzadkość określonego sygnału. Obecna wersja powinna się zmienić, aby umożliwić dodawanie wartości wagi do każdego zaobserwowanego tematu. Waga to względna waga danego tematu w porównaniu z wszystkimi przeglądarkami, które go używają.	Chcemy lepiej zrozumieć, dlaczego rzadkość sygnału jest najważniejszym sygnałem. Zachęcamy do przesyłania opinii o przydatności tego przypadku użycia tutaj.
Tematy Rzetelność	Google musi zapewnić większą pewność co do niezawodności funkcji Topics w ciągu czasu.	Zmiany w interfejsach API będą nadal wprowadzane na podstawie opinii ekosystemu i zostaną omówione publicznie z wyprzedzeniem. Nasza propozycja dotycząca zmienionej struktury zarządzania zapewni dodatkowe gwarancje.
Klasyfikator	Witryny wydawców są często błędnie klasyfikowane lub przypisane do nich tematy są zbyt ogólne, by służyć do jakichkolwiek ważnych celów.	Jak opisano w objaśnieniu dotyczącym klasyfikacji tematów, witryny są klasyfikowane na podstawie utworzonej przez człowieka listy zastąpień, która zawiera najpopularniejsze witryny oraz model systemów uczących się działający na urządzeniu. Chrome cały czas analizuje, czy witryny mogą uczestniczyć w klasyfikacji tematów. Wszelkie ulepszenia funkcji muszą być rozpatrywane pod kątem ryzyka związanego z prywatnością i nadużyciami. Przykładowe zagrożenia: – witryny używające samooznaczenia jako metody kodowania różnych (i potencjalnie wrażliwych) znaczeń w tematach; – witryny atakujące tematy, aby zmniejszyć ich przydatność dla innych (np. spamowanie tematów użytkownika bezsensownym hałasem). Społeczność może sprawdzać te komponenty za pomocą narzędzi dostępnych na stronie chrome://topics-internals lub w tej usłudze Colab. Na podstawie testów spodziewamy się, że z czasem klasyfikacja będzie się poprawiać. Zapraszamy do przesyłania przykładów witryn, które mogą być niewłaściwie skategoryzowane.
Pytanie dotyczące interfejsu API	Potencjalne problemy związane z tym, że interfejs Topics API zapewnia trwałe i antykonkurencyjne korzyści platformom SSP, które zarabiają na złych treściach.	Podobnie jak w przypadku 3PC przeglądarka nie ma znaczenia, do kogo zwraca tematy, o ile ten podmiot jest zarejestrowany i zaakceptowany.
(również w poprzednich kwartałach) Przydatność dla różnych typów osób zainteresowanych	Klasyfikator tematów korzysta obecnie tylko z nazwy hosta strony do definiowania odpowiednich tematów, dlatego duże witryny z różnorodnymi treściami przyczyniają się do tematów ogólnych, a małe witryny – do tematów niszowych, które mają większą wartość reklamową.	Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: Podobnie jak w przypadku 3 PC, wartość informacji pochodzących z różnych witryn jest różna. Witryny niszowe nie mają spójnego poziomu udziału w wartości: nie wszystkie witryny o niszowych zainteresowaniach mają kontekst komercyjny i dlatego przynoszą mniejszą wartość. To witryny, które będą korzystać z interfejsu Topics API. Rozważaliśmy możliwość klasyfikacji na poziomie strony, a nie witryny, ale wiąże się to z licznymi poważnymi problemami związanymi z prywatnością i bezpieczeństwem.
Klasyfikator	Mniejsze witryny często otrzymują nieprawidłową klasyfikację lub nie są klasyfikowane, więc nie mogą uczestniczyć w wymianie wartości.	Jeśli chodzi o rzekomą szkodę, konkretne witryny, które zostały potencjalnie błędnie sklasyfikowane, nie są bardziej poszkodowane niż inne witryny, ponieważ informacje kontekstowe dotyczące aukcji w danej witrynie będą zawsze dostępne, co zapewni porównywalne informacje o prawidłowym temacie nawet w przypadku błędnej klasyfikacji. Tematy są zwykle używane do zbierania potencjalnie przydatnych informacji reklamowych z witryn zewnętrznych, a nie z własnych witryn.
Wersja taksonomii	Jak mogę uzyskać dostęp do wersji taksonomii, aby zapewnić zgodność wsteczną?	Wersja taksonomii jest częścią nagłówka żądania wysyłanego z żądaniem pobierania z włączonymi tematami. Jeśli na przykład nagłówek to „(1 2);v=chrome.1:2:5, ();p=P000000000”, wersja to chrome.1:1:2. Gdzie chrome.1 to wersja konfiguracji, 2 to wersja taksonomii, a 5 to wersja modelu. Informacje na ten temat znajdziesz w specyfikacji, a także w artykule wyjaśniającym.
Dane Topics	Prośba o wyjaśnienie, jak są aktualizowane dane z Topics.	Nie określono aktualizacji taksonomii. Daje to dostawcom przeglądarek większą elastyczność w wdrożeniu. Zanim przejdziemy do szczegółów, oto heurystyka aktualizacji taksonomii Chrome z wersji 1 na wersję 2: – Dla tematów z wersji 1 i 2 jest utrzymywane jedno drzewo taksonomii. Identyfikator tematu o tym samym znaczeniu. – drzewo tylko rośnie – dodawane są do niego nowe tematy i połączenia, nigdy nie jest ono pomniejszane. - Niektóre tematy lub linki mogą być „nieaktywne” w wersji, co może sprawiać wrażenie, że zostały usunięte lub zreorganizowane. Przykłady: - kategoria „Pickup Trucks” ma teraz pośrednią kategorię nadrzędną „Pickup Trucks”. – element „Nauka języka obcego” ma teraz element „Edukacja” jako drugi element nadrzędny, a jego pierwotny element nadrzędny „Informacje dodatkowe” staje się nieaktywny. Wpływ „nieaktywnych” tematów: te tematy nie będą używane do nowej klasyfikacji. Są one jednak nadal uwzględniane przy wymuszaniu blokowania użytkowników: jeśli użytkownik zablokował temat w wersji 1, jego elementy podrzędne pozostaną zablokowane w wersji 2 (nawet jeśli temat podrzędny występuje pod innym elementem nadrzędnym w wersji 2).
Klasyfikator	Chcesz poznać przyczyny błędów klasyfikacji i dostępne opcje ich poprawiania.	Najpierw chcielibyśmy podkreślić, że identyfikacja tematów witryny przez Chrome służy tylko do podawania danych wejściowych algorytmowi Topics, który określa zainteresowania użytkownika na potrzeby reklamy. Nie jest ona przeznaczona do innych, bardziej ogólnych celów klasyfikacji. Nas interesuje ogólna dokładność naszego modelu klasyfikacji. Staramy się zwiększać jego dokładność i przyrosty w miarę możliwości, ale na poziomie globalnym, a nie na poziomie klasyfikacji poszczególnych witryn. Dzieje się tak, ponieważ błędna klasyfikacja nie szkodzi poszczególnej witrynie, która została nieprawidłowo sklasyfikowana, lecz obniża jakość sygnału Topics podczas wybierania reklamy w innych witrynach. Podczas wybierania reklam w nieprawidłowo sklasyfikowanej witrynie jej prawdziwe tematy są już znane i mogą być używane jako dane wejściowe w zapytaniach reklamowych. Tutaj możesz przesłać dodatkową opinię .
Testowanie interfejsu API	Czy interfejs Topics API i ogólne interfejsy API Piaskownicy prywatności można testować w Chromium?	Interfejs Topics API nie jest dostępny w Chromium, tylko w Chrome.
Rozmówca z tematem	Prośba o zwiększenie wartości dodanej funkcji Topics, która wykorzystuje usługi TEE dla technologii reklamowych, aby pokryć koszty zaawansowanej analizy w sposób zgodny z zasadami ochrony prywatności.	Odpowiedzieliśmy na podobne opinie tutaj. Rozważaliśmy odwrotną częstotliwość, ale po jej zmodelowaniu okazało się, że nie koreluje ona dobrze z wartością tematu, jaką podają kupujący i sprzedający. Tutaj możesz przesłać dodatkową opinię .
Specyfikacja interfejsu API	Czy ustawienie dotyczące grupy użytkowników o takich samych zainteresowaniach może blokować interfejs Topics API?	Odpowiedzieliśmy na tę opinię tutaj. Interfejs Topics API jest ulepszoną wersją interfejsu FLoC i jest zgodny z zasadami dotyczącymi uprawnień FLoC. Jak wyjaśniono w tłumaczeniu: „Uwaga: stara wartość Permissions-Policy: interest-cohort=() z FLoC również uniemożliwia obliczanie tematów”.
Ranking tematów	Czy w przypadku „najpopularniejszych 5 tematów” częstotliwość wizyt w witrynie będzie zliczana na podstawie każdego kwalifikującego się wywołującego elementu czy zawsze na podstawie całej historii wizyt w przeglądarce? Czy tematy są dalej porządkowane w przypadku każdego rozmówcy z osobna?	Jest ona określana na podstawie częstotliwości występowania podzbioru historii przeglądania. Wpis w historii przeglądania (strona) może kwalifikować się do udziału tylko wtedy, gdy strona miała co najmniej 1 wywołanie Topics. Więcej informacji o przechowywaniu historii tematów znajdziesz tutaj. Jak opisaliśmy w oświadczeniu o ulepszeniach interfejsu Topics API, ranking zależy od częstotliwości, a także od binarnego poziomu priorytetu (więcej informacji znajdziesz tutaj i tutaj). Nie zależy to jednak od częstotliwości połączeń. Nie oznacza to jednak, że wszyscy wywołujący mogą uzyskać 5 najpopularniejszych tematów w następnej epoce. Zgodnie z wyjaśnieniem „Ten temat mogą otrzymać tylko osoby dzwoniące, które w ciągu ostatnich 3 tygodni odnotowują, że użytkownik odwiedza stronę poświęconą danemu zagadnieniu”. Przeglądarka musi śledzić, które 5 najpopularniejszych tematów zostało wyświetlonych przez wywołującego (odpowiada to 5 najpopularniejszym tematom z domenami wywołujących w specyfikacji). Tutaj możesz przesłać dodatkową opinię na temat tego problemu .

Protected Audience API (wcześniej FLEDGE)

Temat opinii	Podsumowanie	Odpowiedź Chrome
(raportowane również w poprzednich kwartałach) Koszty	Czy uruchamianie TEE w chmurach publicznych jest droższe niż w przypadku lokalnych centrów danych technologii reklamowych?	Nasz obecny model zabezpieczeń TEE korzysta z praktyk wdrażania chmury publicznej (więcej szczegółów znajdziesz w objaśnieniu wymagań TEE dotyczących chmury publicznej). Na przykład obecne TEE oparte na sprzęcie nie chronią przed wszystkimi atakami fizycznymi. Nasi obecni obsługiwani dostawcy chmur publicznych, AWS i GCP, opracowali i wdrožili rozwiązania ograniczające ryzyko związane z dostępem fizycznym, w tym ze strony pracowników. Chociaż niektórzy dostawcy usług reklamowych twierdzą, że prowadzenie usług w chmurze jest droższe niż w lokalnych centrach danych, inni korzystają z chmur publicznych ze względu na koszty lub inne korzyści. Cały czas rozważamy możliwość rozszerzenia obsługi TEE, także poza chmurami publicznymi. W tym celu badamy lokalizowane na miejscu centra danych i współpracujemy z ekosystemem, aby znaleźć potencjalne rozwiązania umożliwiające oferowanie takiej pomocy. Na obecnym etapie badań nie możemy zagwarantować, że doprowadzi to do znalezienia skutecznego rozwiązania dla całego ekosystemu.
Interfejs PA API i Google Ad Manager (GAM)	GAM nie może osiągnąć wyniku sprawiedliwego rynku. GAM nie wyświetla reklam w odpowiednim czasie, nie raportuje liczby reklam wyświetlonych za pomocą interfejsu PA API i nie umożliwia konfiguracji metody wyświetlania reklamy, np. przez wyłączenie interfejsu PA API w przypadku niektórych slotów.	Odpowiedź Google Ad Manager: Zespół GAM pracuje i nadal będzie pracował nad optymalizacją opóźnień podczas wyświetlania reklam za pomocą interfejsu PA API, aby dodatkowe przychody wydawcy uzyskane dzięki popytowi w PA API przewyższały wszelkie koszty poniesione z powodu dodatkowego opóźnienia aukcji PA API. Wstępne testy wskazują, że wydawcy, którzy używają interfejsu PA API, odnotowują wzrost przychodów netto z ruchu w witrynie bez użycia plików cookie innych firm. Oznacza to, że dodatkowy popyt uzyskany dzięki temu interfejsowi przewyższa wszelkie koszty wynikające z opóźnień. Więcej informacji o naszym podejściu znajdziesz w odpowiedziach na najczęstsze pytania. Dodatkowo GAM udostępnia wydawcom raporty na temat reklam wyświetlanych przez interfejs PA API. Obejmuje to reklamy wyświetlane, gdy GAM jest sprzedawcą komponentów, oraz reklamy wyświetlane przez innych sprzedawców komponentów, gdy GAM jest sprzedawcą na najwyższym poziomie. Więcej informacji o raportowaniu znajdziesz w Centrum pomocy. Ponadto GAM umożliwia wydawcom włączanie i wyłączanie korzystania z interfejsu PA API w ich ruchu za pomocą kontrolera w interfejsie użytkownika (więcej informacji znajdziesz w Centrum pomocy). Chętnie zapoznamy się z opiniami na temat dodatkowych ustawień, których mogliby potrzebować wydawcy, i będziemy traktować wszelkie prośby o dodanie funkcji priorytetowo zgodnie z naszym standardowym procesem priorytetyzacji funkcji.
PA API i GAM/AdX	Wygląda na to, że Google zajął stanowisko, w którym po prostu nie kupi żadnych wyświetleń interfejsu PA API, w przypadku których GAM nie podejmie ostatecznej decyzji o sprzedaży. Wygląda to na zwykłe nadużywanie pozycji rynkowej, ponieważ GAM/AdX może przesłać konfigurację aukcji komponentów do alternatywnego sprzedawcy najwyższego poziomu, tak jak do każdej innej giełdy.	Odpowiedź menedżera platformy Google Ads: Nie jest to stanowisko Google. platformy Google do zakupu reklam (Google Ads i DV360) do kupowania wyświetleń na giełdach innych niż Google; Dotyczy to zarówno wyświetleń w ramach interfejsu PA API, jak i poza nim.
Odpowiedź rynku	Zastrzeżenia Mozilli: Zabezpieczenia Google dotyczące odbiorców chronią reklamodawców (i Google) bardziej niż Ciebie.	Jesteśmy wdzięczni za opinię Mozilli. Będziemy nadal korzystać z opinii na publicznych forach. Tematem oceny jest to, że obecna implementacja PA API nie egzekwuje jeszcze wszystkich planowanych zabezpieczeń. Nasze podejście do wprowadzania na rynek interfejsu PA API miało na celu znalezienie odpowiedniej równowagi między zachęcaniem do korzystania z interfejsu a jak najszybszym wdrożeniem środków ochrony prywatności. W tym celu opracowaliśmy plan wprowadzania ograniczeń prywatności w ciągu pewnego czasu, aby ułatwić integrację z interfejsami API i dać nam czas na zebranie większej ilości opinii, które możemy uwzględnić w przyszłych zabezpieczeniach (np. funkcje VAST w ramkach ograniczonych). Z przyjemnością przyjmujemy też najnowsze wiadomości Mozilli na temat podejścia do prywatności i reklamy cyfrowej: „Swobodny i otwarty internet nie powinien kosztować prywatność” oraz „Ulepszanie reklam online za pomocą usług i infrastruktury”.
(również w poprzednich kwartałach) Wyniki aukcji	żądanie dotyczące pojedynczej aukcji, aby zwrócić wiele adresów URL renderowania z odpowiednimi wartościami, co ułatwia deduplikację reklam natywnych i uniknięcie problemów z UX oraz opóźnieniami;	Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: Udostępnianie wielu adresów renderURL i odpowiednich wyników z jednej aukcji API PA rozważaliśmy, ale nie wdrożyliśmy tego ze względu na kwestie prywatności. Rozumiemy, że nie chcesz wyświetlać tej samej reklamy wielokrotnie na jednej stronie, i bierzemy to pod uwagę. Tutaj czekamy na dodatkowe opinie z ekosystemu dotyczące tego, jakie dodatkowe wsparcie interfejsu PA API jest potrzebne do optymalnego obsługi reklam natywnych.
Wyniki	Problemy z czasem oczekiwania wpływającym na interfejs PA API.	Słyszeliśmy, że wiąże się to z opóźnieniami, dlatego w ramach interfejsu PA API opracowaliśmy szereg funkcji, dzięki którym platformy SSP mogą ustawiać limity czasu oczekiwania na DSP, a także wprowadzać usprawnienia, które pozwalają zmniejszyć czas oczekiwania. Niedawno zaktualizowaliśmy przewodnik po sprawdzonych metodach dotyczących opóźnień, który zawiera więcej informacji o korzystaniu z tych funkcji. Cały czas pracujemy też nad nowymi ulepszeniami dotyczącymi opóźnień. Niektóre z nich można zobaczyć tutaj.
Najlepsi sprzedawcy	Google powinno umożliwić wydawcom wybór alternatywnych sprzedawców aukcji na najwyższym poziomie interfejsu PA API.	Interfejs PA API nie ma znaczenia, kto inicjuje aukcję, zarówno w przypadku sprzedawców pojedynczych, jak i sieci sprzedawców. Decyzja o tym, czy i jak obsługiwać aukcje interfejsu PA API, należy do poszczególnych firm.
(również w poprzednich kwartałach) Kierowanie na odbiorców spełniających kryteria wykluczające	Prośba o rozwiązanie problemu polegającego na tym, że reklamodawca nie chce wyświetlać reklam określonej grupie odbiorców.	Kierowanie na wykluczające grupy elementów jest obsługiwane za pomocą dodatkowych stawek (kontekstowych). Pozwala to zaspokoić potrzeby reklamodawców, którzy nie chcą wyświetlać reklam określonym odbiorcom. Szczegółowe informacje znajdziesz w tym artykule i tym zgłoszeniu na GitHubie. Pracujemy też nad rozwiązaniami, które umożliwią stosowanie wykluczeń w kierowaniu na Instagram w przypadku stawek w interfejsie API PA. Zachęcamy do dzielenia się opiniami tutaj.
(również w poprzednich kwartałach) Reklamy natywne	Prośba o obsługę odizolowanego elementu w ramach reklam natywnych	Rozważamy obsługę tego przypadku użycia i omawiamy możliwe obejścia problemu oraz rozwiązania tutaj.
WebView | komponent WebView	Poszukiwanie wyjaśnienia sytuacji, w której zespół IG dołączył do Chrome, nie był dostępny w przypadku aukcji przeprowadzanej z komponentem WebView.	Chcemy uwzględniać takie przypadki użycia, gdy dostępna będzie wystarczająca infrastruktura prywatności. W tej chwili nie mamy żadnych dodatkowych ogłoszeń, ale chętnie poznamy Twoją opinię tutaj.
Ujemne grupy IG	Prośba o zaktualizowanie przetwarzania adresów URL, aby obsługiwać wykluczające identyfikatory reklam w ramach funkcji nagłówka.	Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj.
Filtrowanie zróżnicowania	Prośba o wskazówki dotyczące wdrażania filtrowania różnorodności podczas wyświetlania reklam natywnych w interfejsie PA API w przypadku wielu sprzedawców i wielu aukcji.	Omawiamy tę prośbę tutaj i zapraszamy do podzielenia się dodatkowymi opiniami.
(również w poprzednich kwartałach) Filtry blokowania	Prośba o wskazania, jak egzekwować reguły „blokowania wydawcy” (filtry) podczas korzystania z reklam natywnych w PA API z wielu sprzedawców	Wskazówki znajdziesz tutaj. Zachęcamy do dzielenia się opiniami.
Ograniczenia	Poproś o zezwolenie na ograniczenia na poziomie domeny, a nie subdomeny.	Ograniczenia na poziomie subdomeny lub pochodzenia są zgodne z podstawowym modelem bezpieczeństwa w internecie, więc jest to nasz domyślny projekt. Omówiliśmy to szczegółowo tutaj i tutaj.
Zaufane określanie stawek	Żądanie klienta użytkownika i powiązanych wskazówek dotyczących klienta w żądaniach zaufanego sygnału ustalania stawek.	Śledzimy prośbę o dodanie tej funkcji. Tutaj możesz przesłać dodatkową opinię.
(raportowane również w poprzednich kwartałach) Wiele IG	Używać wielu tagów typu Instagram z tą samą stawką.	Obecnie interfejs PA API nie obsługuje tej funkcji, ponieważ spowodowałoby to zmianę podstawowego modelu ochrony prywatności. Zapraszamy do dalszej dyskusji tutaj.
(raportowano też w poprzednich kwartałach) Skuteczność	Przeniesienie większej ilości logiki na klienta może pogorszyć wydajność strony i UX, a także obniżyć wyniki SEO witryny.	Obecnie omawiamy ten problem. Zachęcamy do przesyłania dodatkowych opinii tutaj.
Dynamika aukcji	Interfejs PA API ogranicza ilość informacji o dynamice aukcji (np. kto bierze udział, kto wygrywa poszczególne komponenty aukcji itp.), co zmniejsza możliwość identyfikacji wydawców i utrudnia ustalenie, czy umowy są przestrzegane.	Proponowane rozwiązanie dotyczące śledzenia ofert znajdziesz tutaj. Planujemy zmodyfikować niektóre istniejące pola i utworzyć nowe pola w obiekcie IG, w których będą przechowywane identyfikatory DealID i SetID, a potem umożliwić ich przekazywanie z narzędzia generateBid do wyniku ScoreAd lub ruchu wychodzącego w ramach raportowania na poziomie zdarzenia. Powinny one zapewniać odpowiednią obsługę przypadku użycia umowy. Cieszymy się z opinii na temat innych metadanych, które specjaliści ds. technologii reklamowych uważają za kluczowe dla dynamiki aukcji i które pozwalają zachować śledzenie dla wydawców. Zachęcamy specjalistów ds. technologii reklamowych do podawania konkretnych przykładów metadanych, do których się odnoszą, oraz informacji o tym, od której strony do której strony mają one trafiać.
GAM	Obawy dotyczące wymagań dotyczących korzystania z serwera reklam GAM jako serwera reklam wydawcy w celu uzyskania dostępu do ofert reklamowych AdX.	Odpowiedź Google Ad Managera: GAM nie wymaga, aby wydawcy korzystali z funkcji serwera reklam, aby uzyskać dostęp do funkcji giełdy.
(Uwzględniono też w poprzednich kwartałach) Aukcja komponentów	Zwycięzcy aukcji komponentów interfejsu PA API będą widoczni dla GAM, co budzi obawy o nierówny dostęp do informacji.	Odpowiedź pozostaje niezmieniona w porównaniu z poprzednimi kwartałami: Odpowiedź Google Ad Manager: "Od lat kładziemy duży nacisk na uczciwość aukcji, w tym na naszej obietnicy, że żadna cena z żadnego z niegwarantowanych źródeł reklamy wydawcy, w tym ceny niegwarantowanych elementów zamówienia, nie zostanie udostępniona innemu kupującemu przed złożeniem przez niego stawki w aukcji. Zostało to później potwierdzone w naszych zobowiązaniach wobec francuskiego urzędu ds. konkurencji. W przypadku aukcji interfejsów API PA chcemy dotrzymać naszej obietnicy i nie udostępniać stawki żadnego uczestnika aukcji przed zakończeniem aukcji w aukcji wielu sprzedawców. Zapewniamy, że nie udostępnimy ceny aukcji kontekstowej żadnej aukcji komponentów, w tym naszej, jak wyjaśniliśmy w tym komunikacie. Ponadto w ramach naszej aukcji nie używamy informacji o konfiguracjach aukcji komponentów, w tym sygnałów przekazywanych przez kupujących do SSP. Chcielibyśmy wprowadzić zmiany w interfejsie PA API, które umożliwiłyby sprzedawcom komponentów określanie konfiguracji aukcji komponentów w sposób zaciemniony dla sprzedawcy najwyższego poziomu”.
GAM	Czy GAM będzie prosić o udział w przychodach z udziału w aukcjach najwyższego poziomu lub w raportach z nich, jeśli GAM nie brał udziału w utworzeniu aukcji z reklamami na potrzeby reklam w Google ani z aukcji komponentów interfejsu PA API?	Odpowiedź Google Ad Managera: Gdy wydawcy zdecydują się używać GAM jako serwera reklam, GAM będzie prowadzić aukcję na najwyższym poziomie i obciążać opłatą za wyświetlanie reklam za korzystanie z funkcji serwera reklam (ta sama opłata za wyświetlanie reklam obowiązuje poza aukcjami PA API). Jeśli jednak reklama, która wygrała aukcję, pochodzi od sprzedawcy komponentów, który nie jest użytkownikiem usługi GAM (czyli usługa GAM nie uczestniczyła w tworzeniu aukcji komponentów interfejsu API w ramach IG lub PA), usługa GAM nie obsługuje rozliczeń ani nie pobiera opłaty procentowej za media.
Klikalność	Czy rejestracja zdarzeń kliknięcia podlega tej samej prywatności różnicowej?	Obecnie nie planujemy, aby ta funkcja podlegała ograniczeniom „k-anon”, ponieważ „liczba kliknięć” będzie dostępna tylko jako browserSignal w ramach funkcji generateBid(). Nie będzie ona dostępna jako nowy atrybut w raportach na poziomie zdarzenia.
Wyniki	Wysokie koszty wyjścia z powodu bezwarunkowej odpowiedzi na żądania dotyczące stawek kontekstowych.	Ze względu na kwestie związane z ochroną prywatności nie możemy bezpośrednio podać informacji o tym, które platformy DSP mają IG. Pracujemy jednak nad alternatywnymi rozwiązaniami, które mogłyby zapewnić dostęp do statystyk, a jednocześnie chronić prywatność.
Reklamy natywne i Out-Stream	Prośba o aktualne informacje o stanowisku Chrome w sprawie reklam natywnych i outstreamowych.	Pozycja Chrome zależy od konkretnego przypadku użycia. Jeśli chodzi o reklamy wideo, naszym zadaniem jest zachęcenie ekosystemu do korzystania z efektywnych rozwiązań do tworzenia reklam wideo typu In-Stream przy użyciu naszych interfejsów API. Do tej pory jedyną konkretną propozycją, o której wiemy, jest propozycja GAM. W przypadku reklam natywnych aktywnie zbieramy opinie tutaj. Planujemy wkrótce udostępnić kolejne kroki związane z odkrywaniem nowych technologii reklamowych.
Monitorowanie w czasie rzeczywistym (RTM)	Ruch z etykietą nie wysyła raportów RTM.	Jesteśmy świadomi istnienia tej luki i pracujemy nad jej rozwiązaniem. Gdy tylko będzie to możliwe, poinformujemy Cię o tym tutaj.
Obsługa rozszerzenia liczby odbiorców	Prośba o aktualność na temat obsługi list odbiorców z rozszerzenia liczby odbiorców/list odbiorców wybranych przez sprzedawcę w interfejsie PA API.	Pracujemy nad rozwiązaniem tego przypadku użycia. Zbieramy opinie z całego ekosystemu na temat tego, co powinniśmy tworzyć i wspierać. Gdy tylko będzie to możliwe, przekażemy więcej informacji. Zachęcamy do podzielenia się opinią tutaj.
Debugowanie	W narzędziu dla programistów Chrome nie ma panelu do monitorowania szczegółowej wydajności interfejsu PA API. Na przykład ogólna skuteczność może zależeć od liczby IG lub liczby kupujących.	Choć ta opinia dotyczy funkcji interfejsu użytkownika Narzędzia deweloperskiego w Chrome, która ułatwia monitorowanie, 7 października umożliwiliśmy technikom reklamowym konfigurowanie zdarzeń niestandardowych, które można wykorzystać do monitorowania i alertów. Więcej informacji znajdziesz tutaj. Mamy nadzieję, że ta aktualizacja rozwiąże większość problemów zgłoszonych w tych opiniach. Czekamy na opinie na temat tej funkcji, dotyczące zarówno obsługiwanych punktów danych, jak i doświadczenia deweloperów. Możesz podzielić się nimi w odpowiedniej dyskusji na GitHubie tutaj.
Sygnały	Obawy dotyczące tego, czy systemy DSP mogą zapewnić, że sygnały perBuyerSignals będą wysyłane do SSP niezależnie od wyników aukcji kontekstowych.	Zakłada się, że w aukcji kontekstowej występuje tylko 1 wygrana stawka z 1 platformy DSP lub że jest 1 stawka, którą można spróbować pokonać w kolejnych aukcjach interfejsu PA API. W przypadku procesu PA API SSP decyduje, które DSP zaprosić, aby sprawdzić, czy mają dostępnych użytkowników (w postaci identyfikatora IG na urządzeniu), którzy mogą przesłać zapytanie. Jest całkowicie możliwe i w rzeczywistości bardzo prawdopodobne, że platforma DSP, która przegrała aukcję kontekstową, zostanie „ponownie zaproszony” do udziału w aukcji interfejsu PA API. W przypadku tego „ponownego zaproszenia” platforma DSP, która zdecyduje się ją zaakceptować, przekazuje do platformy SSP wszelkie sygnały, które weryfikator reklam chciałby upewnić się, że platforma ta bierze pod uwagę, o ile istnieją jakieś sygnały dla danej kampanii. Innymi słowy, w aukcji interfejsu PA API platforma DSP zawsze może przesłać sygnały kupującego do platformy SSP niezależnie od tego, co miało miejsce w aukcji kontekstowej.
Sygnały	Prośba o dodanie prevClicks do obiektu browserSignals przekazanego do generatedBid().	Prośbę tę można spełnić, wprowadzając obsługę sygnałów dotyczących klikalności. Ogłosiliśmy tę funkcję w naszym ostatnim poście na blogu oraz w odpowiednim artykule. Tutaj możesz przesłać dodatkową opinię na temat tej propozycji .
(są też raportowane w poprzednich kwartałach) Sygnały modelowania	Poproś o zwiększenie liczby bitów sygnałów modelowania z 12 do 30 bitów.	W odpowiedzi na tę opinię przesłaliśmy propozycję tutaj. Aktywnie współpracujemy z całą branżą, aby zrozumieć ich poglądy na temat naszej propozycji, i obecnie oceniamy korzyści dla branży względem wpływu na użytkowników Chrome i inne zainteresowane osoby.
Dokumentacja	prośba o wskazówki dotyczące korzystania z serwerów klucz-wartość (K/V) i elementów TEE;	Wskazówki dotyczące wykorzystania TEE w kontekście K/V są dostępne w szczegółach projektu modelu zaufania usługi K/V tutaj.
Czas trwania negatywnych IG	Prośba o wydłużenie czasu ważności negatywnych haseł do 365 dni	Negatywne IG są używane do zapobiegania wyświetlaniu reklam, ale osoby nieuprawnione mogą ich używać do ujawniania informacji o użytkownikach, co powoduje ryzyko ponownej identyfikacji (np. jedną z metod ataków jest wielokrotne licytowanie wysokich stawek z ujemnymi IG, aby dowiedzieć się, czy użytkownik odwiedził określone witryny). Jeśli zachowamy 365-dniowy okres TTL, nieuczciwe podmioty będą miały znacznie więcej danych o ujemnych grupach kont, co skutkuje znacznie większym zagrożeniem dla prywatności. Z tego powodu nie możemy spełnić tej prośby w celu ochrony prywatności użytkowników.
Specyfikacje interfejsu API	Co można wstawiać jako wartości przekazywane w ramach elementu perBuyerSignals? Czy sprzedawca może dowolnie zdefiniować tę zasadę?	perBuyerSignals to miejsce, w którym sprzedawcy mogą przekazywać kupującym wszystkie informacje, które chcą udostępnić na aukcji. Decyzja o tym, co ma się znaleźć w ekosystemie, należy do jego twórców, ale zachęcamy do dalszej dyskusji tutaj.
Zastępowanie makr rozmiaru reklamy	Wskazówki dotyczące zastępowania makr rozmiaru reklamy nie działają.	Wkrótce podamy więcej informacji.
Zastąpienie makra platformy SSP stawki w poście: podszywanie się pod URL najwyższego poziomu	Jakie mechanizmy może wprowadzić Chrome, aby umożliwić dostawcom usług weryfikacyjnych zweryfikowanie adresu URL najwyższego poziomu w ramach Piaskownicy prywatności? Czy istnieją alternatywne punkty danych lub sygnały, które można stosować w ramach ograniczonych ramek, aby zapewnić dokładność adresu URL najwyższego poziomu udostępnionego przez SSP?	Obecnie omawiamy tę dodatkową opinię tutaj.
Propozycja nowej funkcji	Prośba o przesyłanie UACH o niskiej entropii podczas pobierania danych z updateURL i w ramach wywołań zwrotnych raportowania w czasie rzeczywistym.	Tego typu zgłoszenia są rozpatrywane tutaj. Zachęcamy do przesyłania dodatkowych opinii tutaj i tutaj.
Propozycja nowej funkcji	Prośba o aktywowanie funkcji debugowania z użyciem zaufanych serwerów, gdy dany klient został uruchomiony, aby wysłać za pomocą interfejsów forDebuggingOnly.reportAdAuctionWin() i forDebuggingOnly.reportAdAuctionLoss() raporty na poziomie zdarzenia z próbkowaniem w dół tylko do celów debugowania.	Tę prośbę śledzimy obecnie. Poinformujemy o ekosystemie, gdy będzie to możliwe. Czekamy na dodatkowe opinie tutaj.
Używanie API	Prośba o wskazania, jak zliczać zasięg wśród unikalnych użytkowników i zasięg wyświetleń.	Rozważamy propozycję dotyczącą odczytu IG z poziomu workletu w udostępnionym miejscu na dane, który można wykorzystać do wysyłania prywatnych raportów zbiorczych. Więcej informacji znajdziesz tutaj. Chętnie poznamy Twoją opinię na temat propozycji i jej przydatności w ekosystemie.
Używanie API	Niejasne jest to, co wydawcy powinni testować, które interfejsy API są ważne, które należy włączyć i co nastąpi później.	Trwają prace nad lepszym wsparciem dla wydawców i ich ról w ekosystemie.
Używanie API	Czy można dodać detektory do zdarzeń Worklet aukcji reklam?	Nie jest to możliwe za pomocą zwykłych zdarzeń, ale zdarzenia w ramach protokołu w Narzędziach programistycznych Chrome częściowo obsługują ten przypadek użycia. Pamiętaj, że zwykłe zdarzenia mogą wpływać na właściwości izolacji/prywatności, ale szczegóły znajdziesz tutaj.
K-anonimowość	prośba o wyjaśnienie wymagań dotyczących renderowania reklam (np. co najmniej 50 użytkowników zobaczyło reklamę, gdyby została wyświetlona);	W dokumentacji dla deweloperów znajdziesz omówienie naszych oczekiwań dotyczących przyszłych rozwiązań. W szczególności wyjaśnia on, że początkowy próg k-anonimowości wynosi k=10 osób. Na liście mailingowej blink-dev znajdziesz informacje o aktualnych wydarzeniach związanych z Chrome. Jak opisano w wątku na liście mailingowej k-anonimowości, obecnie eksperymentalnie stosujemy wymóg k-anonimowości w przypadku około 1% stabilnego ruchu w Chrome, ale nigdy nie stosujemy go w przypadku obszarów wyraźnie oznaczonych jako „Tryb A” i „Tryb B”.
Podgrzewacz	Czy można tymczasowo usunąć lub ograniczyć tworzenie chaffingu K/V w TEE z konieczności wywoływania wszystkich fragmentów N do takiej liczby, która równoważy ochronę prywatności z użytecznością (np. skuteczność/koszt)?	Te typy żądań są obsługiwane tylko w instancjach nieprodukcyjnych, w których można kontrolować podszywanie. W przypadku instancji produkcyjnych nadal wymagane jest chaffing. Gdy otrzymamy opinię na temat korzystania z wersji nieprodukcyjnej, będziemy mogli ocenić sytuację.
ocieplenie	Prośba o dodanie flagi wyłączającej chaffing z binarnego pliku K/V do debugowania lub nieprodukcyjnego.	Ta flaga jest dostępna w wersji 1.0.0.
Błąd interfejsu API	Po przejściu na Chrome 126 interfejs API przestał działać, mimo że został włączony w ustawieniach.	Okazało się, że problem jest związany z flagą „enable-fenced-frames” w Chrome, która została włączona przez użytkowników na potrzeby programowania. Zresetowanie tej flagi do wartości domyślnej rozwiąże problem.
Raportowanie	Prośba o zmianę interfejsu API do raportowania w czasie rzeczywistym tak, aby nie zależał od sprzedawcy	Ta prośba jest rozpatrywana tutaj. Rozwiązanie RTM zostało niedawno opublikowane i chcielibyśmy poznać opinie zwłaszcza tych specjalistów ds. technologii reklamowych, którzy już korzystają z tej funkcji.
Raportowanie	Prośba o raportowanie przez osoby trzecie: choć DSP i SSP otrzymują powiadomienia o wyświetleniach z Chrome, dostawcy usług technicznych na poziomie pośrednim domyślnie ich nie otrzymują.	Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj.

Chronione usługi aukcji

Temat opinii	Podsumowanie	Odpowiedź Chrome
TEEs	Wymaganie Google dotyczące ręcznego wdrażania zgodnie ze standardami technicznymi stanowi poważne ograniczenie w wyborze dostawcy usług w chmurze. Standardowych standardów technicznych można przestrzegać bez odwiedzania biura dostawców usług w chmurze, o czym myśle Google. Opóźnienie w wprowadzeniu alternatywnych dostawców do 2025 r. (najwcześniej) jest nie do przyjęcia, ponieważ spowoduje to efekt sieciowy, który zachęci użytkowników do korzystania z rozwiązań Google.	Usługa agregacji jest jedyną usługą, która musi działać w usłudze TEE, aby obsługiwać niektóre przypadki użycia technologii reklamowych. Usługa agregacji obsługuje zarówno Amazon Web Services (AWS), jak i Google Cloud Platform (GCP). Na podstawie opinii ekspertów ds. technologii reklamowych uważamy, że na tym etapie jest to wystarczające wsparcie. W przypadku dodatkowych dostawców usług chmury Google opublikowała szczegółowe kryteria dotyczące TEE w przypadku dostawców chmury publicznej. Ich celem jest zapewnienie, aby rozwiązanie TEE spełniało cele Piaskownicy prywatności dotyczące prywatności i bezpieczeństwa. W szczególności serwery TEE piaskownicy prywatności przetwarzają niezaszyfrowane dane użytkowników w różnych witrynach (np. dane z witryn wydawców i reklamodawców na potrzeby usługi agregacji). Muszą być one bezpieczne, aby można było zapewnić zgodność interfejsu API z celami dotyczącymi prywatności użytkowników. Bezpieczne środowisko jest też konieczne, aby interfejsy API nadal chronią poufne informacje biznesowe firmy (na przykład aby uniemożliwić innym uczestnikom aukcji interfejsu PA API dostęp do zastrzeżonych danych biznesowych kupującego). Według naszej najlepszej wiedzy obecnie nie ma technologii TEE, która w pełni chroniłaby dane użytkownika przed potencjalnie nieprzyjaznym operatorem. Dlatego uwzględniamy wiele wymagań, aby potwierdzić wiarygodność dostawcy usług w chmurze. Nie mamy pewności, do czego odnosi się termin „Biura dostawców chmury”, więc nie jest to częścią wymagań. Zachęcamy do przekazywania opinii na temat wymagań. Nadal oceniamy możliwość oferowania usług nowym dostawcom, m.in. na podstawie próśb o przesłanie ich przy użyciu procesu opisanego w objaśnieniu. Do tej pory otrzymaliśmy tylko prośbę o obsługę Azure, którą obecnie analizujemy.
B&A	Trudno jest ocenić techniczną złożoność i możliwość wykonania usługi B&A, ponieważ jej projekt wciąż się rozwija.	Aby rozwiązać te problemy, udostępniliśmy na GitHub szczegółowe informacje na temat projektu funkcji B&A, opublikowaliśmy harmonogram dostępności oraz mapę drogową funkcji obsługujących interfejs PA API. Wspieramy dostawców technologii reklamowych, którzy chcą wdrażać B&A, i zbieramy opinie na temat tego rozwiązania w ekosystemie w GitHub.
B&A	Szukam wskazówek i lepszego sposobu na obliczenie kosztów korzystania z TEE w przypadku B&A, aby zacząć z niego korzystać lub przenieść go na urządzenie.	Niedawno opublikowaliśmy przewodnik po rozmiarach instancji serwera K/V, który zawiera narzędzia do dokładniejszego pomiaru kosztów.
Serwer K/V	Ad-verifier prosi o możliwość użycia pełnego adresu URL strony na serwerze K/V do przeprowadzenia weryfikacji reklamy.	Obecnie rozważamy możliwość udostępnienia serwerowi K/V pełnego adresu URL strony w celu weryfikacji reklam. Pełny adres URL strony nie będzie dostępny w przypadku K/V BYOS.
Zabezpieczenia aukcji	Seeking auction security features to ensure bad actors don't access sensitive data or act as impersonators - which features protect the auction from replay attacks and how can security safeguards be implemented?	Obecny model bezpieczeństwa B&A może chronić integralność aukcji. Testy B&A są przeprowadzane w TEE, który chroni poufność sygnałów i kodu technologii reklamowych przed nieuczciwymi podmiotami. W architekturze B&A szyfrowany ładunek danych żądania B&A (szyfrowany tekst żądania) jest przekazywany z klienta przez nieufny serwer reklam do usługi SellerFrontEnd (SFE), która jest uruchamiana przez SSP-y w TEE. Tekst szyfrowany żądania zawiera identyfikator generowania oparty na sygnaturze czasowej. SFE sprawdzi sygnaturę czasową żądania i odrzuci wszystkie odtwarzane żądania, które nie mieszczą się w okresie +/- n sekund od czasu serwera. Ponadto B&A może zwracać wypełniony ładunek odpowiedzi o stałym rozmiarze w przypadku komunikacji między serwerami. Te rozwiązania mogą pomóc ograniczyć ataki typu replay w systemie, gdy atakujący spróbuje ponownie odtworzyć ten sam ładunek żądania, aby dowiedzieć się więcej o jego zawartości. Zespół pomocy B&A dokumentuje i aktualizuje modele zabezpieczeń w materiałach informacyjnych.
Sygnały przez serwer K/V	Prośba o uwzględnienie sygnałów perBuyerSignals wysyłanych za pomocą usługi K/V w ramach żądania sygnałów zaufanych licytowania z Chrome.	Sprawdzamy możliwość dołączenia informacji z sygnałów dla poszczególnych kupujących, przesłanych do serwera K/V działającego w TEE, w tym do pełnego adresu URL strony.
Serwer K/V	Prośba o bardziej stopniowy harmonogram wdrażania ograniczeń związanych z ochroną prywatności w bazie wiedzy i analizie pytań i odpowiedzi.	Rozumiemy, że chcesz wdrożyć TKV w kilku etapach, i doceniamy Twoje konkretne prośby dotyczące K/V i B&A. Po dokładnym przeanalizowaniu tej kwestii zdecydowaliśmy się jednak na razie nie łagodzić zasad ochrony prywatności w tych interfejsach API. Uważamy, że te środki, takie jak chaffing, są kluczowe dla ochrony prywatności użytkowników i zaufania do Piaskownicy prywatności.
Serwer K/V	Szukam wskazówek dotyczących skalowania magazynu K/V za pomocą zgodnej konfiguracji.	W tym przypadku może Ci pomóc opublikowany niedawno przewodnik po określaniu rozmiaru instancji serwera K/V. Narzędzie poda zapytanie na sekundę (nazywane w objaśnieniu „RPS”) zapytaniem na sekundę w każdej kombinacji parametrów.
Serwer K/V	Dodaj informacje o sprzedawcy w żądaniu do serwera K/V.	Wciąż o tym rozmawiamy. Zachęcamy do przesyłania dodatkowych opinii tutaj.
K/V + B&A Services	Poproś o sprecyzowanie harmonogramu publikacji lub planu publikacji materiałów K/V i B&A.	W przypadku serwera K/V i B&A mamy etapy i harmonogramy: W przypadku serwera K/V w połączeniu z aukcjami interfejsu API PA na urządzeniu (w porównaniu z B&A) publiczny harmonogram jest dostępny tutaj. Aby dowiedzieć się, jak zdefiniowano „dostępność ogólną” w przypadku kluczy-wartości, zapoznaj się z sekcją mapy drogowej, która definiuje zestaw funkcji w wersji beta i ogólnej. W przypadku zapytań z możliwością uzupełnienia zapoznaj się z publiczną linią czasową tutaj i mapą drogową tutaj. Testowanie skalowania definiujemy jako „pełne stabilne, produkcyjne testy na skali produkcyjnej”. Informacje o konkretnym zestawie funkcji na tym etapie znajdziesz tutaj. W przypadku testów A/B są też etapy alfa i beta, więc testowanie na dużą skalę będzie obejmować superzbiór funkcji z wcześniejszych etapów. W przypadku zarówno pytań i odpowiedzi, jak i rozmów z ekspertem daj nam znać, czy definicje etapów pomagają w określeniu, co będzie dostępne w danym momencie. Jeśli nadal istnieją jakieś luki, daj nam znać. Chętnie je doprecyzujemy, aby ułatwić Ci planowanie.

Pomiary reklam cyfrowych

Attribution Reporting API (i inne interfejsy API)

Temat opinii	Podsumowanie	Odpowiedź Chrome
Odpowiedź rynku	Wymaganie, aby konkurencyjne systemy atrybucji używały tylko raportowania na poziomie zdarzenia i raportowania zbiorczego lub zbiorczego w ścisłych granicach, jest arbitralnym ograniczeniem konkurencji. Zapobiega to ponownemu kierowaniu i atrybucji z uwzględnieniem urządzeń w czasie rzeczywistym na poziomie zdarzenia, nawet jeśli obowiązują środki ochrony danych, które zapewniają zgodność z zasadami ochrony danych (np. deidentyfikację).	Rozwiązanie to opiera się na celach związanych z ochroną prywatności w interfejsie API, np. na ochronie informacji przekazywanych z jednej witryny do drugiej. Na przykład ARA obsługuje atrybucję na poziomie zdarzenia za pomocą raportów o zdarzeniach. Raporty o zdarzeniach są opóźnione z co najmniej godziną, co jest konieczne, aby utrudniać powiązanie raportu na poziomie zdarzenia z tożsamością użytkownika w witrynie reklamodawcy za pomocą ataków czasowych na kanały zewnętrzne, jak opisano tutaj. Oprócz ARA istnieją też inne sposoby atrybucji, np. bezpośrednie zbieranie informacji od użytkowników, którzy świadomie podają dane identyfikacyjne. Jesteśmy otwarci na opinie na temat przypadków użycia, których nie można osiągnąć przy obecnych ograniczeniach prywatności interfejsów API Piaskownicy prywatności.
Wiele powierzchni	Prośba o potwierdzenie, czy interfejsy ARA i Shared Storage API obsługują przypadki użycia na wielu urządzeniach i gdzie można znaleźć dowody na to.	Obecnie ARA i Shared Storage nie obsługują atrybucji na wielu powierzchniach (na różnych urządzeniach). Obsługiwana jest atrybucja w różnych aplikacjach i internecie na tym samym urządzeniu (za pomocą interfejsu ARA).
(raportowane również w poprzednich kwartałach) Różne urządzenia	Czy ARA obsługuje konwersje na różnych urządzeniach?	Nasze odpowiedzi są podobne do tych z poprzednich kwartałów: Ustawienia dla wielu urządzeń stawiają nowe wyzwania związane z prywatnością, które dochodzą do tych związanych z 3PC, a dodatkowo stwarzają nowe wyzwania związane z rozpowszechnianiem technologii, ponieważ użytkownicy mogą korzystać z różnych urządzeń i platform. Rozważamy potencjalne rozwiązania, ale skupiamy się na krytycznych przypadkach użycia, które są obecnie obsługiwane przez ARA. Nie mamy jeszcze harmonogramu wprowadzenia obsługi na różnych urządzeniach.
Skalowanie	Wątpliwości związane z tym, czy interfejs Attribution Report API (ARA) jest obecnie skonfigurowany i czy może zostać niezawodnie wdrożony oraz przeskalowany tak, aby obsługiwał wszystkich użytkowników Chrome.	ARA jest obecnie dostępna dla wszystkich użytkowników Chrome i działa zgodnie z oczekiwaniami. Ponadto kontynuujemy testowanie oraz monitorowanie jego niezawodności i skalowalności ze względu na rosnącą liczbę firm z branży technologii reklamowych, które testują interfejs ARA. Zapraszamy do podzielenia się opinią na temat tego tematu tutaj.
(raportowane również w poprzednich kwartałach) Deduplication	Obawy dotyczące tego, jak ARA proponuje ograniczenie mechanizmu atrybucji na urządzeniach, tak aby wydawcy nie mogli skutecznie stosować logiki po atrybucji w przypadku raportów zbiorczych, w tym usuwania duplikatów konwersji tego samego typu dla tego samego kliknięcia reklamy.	Nasza reakcja pozostaje bez zmian w porównaniu z poprzednimi kwartałami: Duplikowanie na różnych urządzeniach i w ramach potoków pomiarów jest znanym i obecnym wyzwaniem, z którym stoją obecnie specjaliści ds. technologii reklamowych także w przypadku komputerów zewnętrznych. Dzięki ARA specjaliści ds.technologii reklamowych mogą decydować, kiedy zarejestrować określone konwersje, i dodawać określone metadane wskazujące, które potoki pomiarowe zostały wykorzystane do śledzenia konwersji (tj. część klucza agregacji), które można porównać z innymi potokami pomiarów. Zapraszamy do podzielenia się opinią na temat tego tematu tutaj.
Śledzenie konwersji	Prośba o możliwość działania z konwersjami z wielu domen.	Rozmawiamy o tej prośbie tutaj i zapraszamy do dzielenia się opiniami na temat ekosystemu.
Raportowanie	Przeglądarka czeka co najmniej 2 dni, ale nawet 30 dni na wysłanie konwersji, co może być niepokojące, ponieważ większość zainteresowanych reklamodawców to reklamodawcy skoncentrowany na marketingu efektywnościowym, którzy pracują w czasie zbliżonym do rzeczywistego.	Domyślne ustawienia raportów na poziomie zdarzenia mają te domyślne okna raportowania: 2 dni, 7 dni i 30 dni. Dzięki elastycznemu raportowaniu na poziomie zdarzenia specjaliści ds. technologii reklamowych mogą zmienić liczbę i długość okien raportowania w stosunku do wartości domyślnych. Okna raportowania można zmienić na co najmniej 1 godzinę, co może być przydatne w przypadku reklamodawców, którzy stawiają na skuteczność. Zapraszamy do podzielenia się opinią na temat tego tematu tutaj.
Atrybucja konwersji online do konwersji offline	Czy w ARA będą dostępne opcje implementacji reklam online-to-offline? Czy są też inne sugestie dotyczące pomiaru atrybucji offline-to-online?	Obecnie nie planujemy obsługi przypadków użycia pomiarów online–offline w ARA. Aby korzystać z tego rodzaju pomocy, musisz wziąć pod uwagę poważne wyzwania w zakresie prywatności i bezpieczeństwa. Zapraszamy do dzielenia się opiniami na temat dodatkowych zastosowań tej funkcji w ekosystemie tutaj.
Raportowanie błędów	Jak przechowywać i pobierać identyfikator reklamy w taki sposób, aby był on dostępny w przypadku rejestracji w Chrome (źródło/wyzwalacz) na potrzeby przypisywania danych z aplikacji do witryny?	Aby umożliwić korzystanie z raportów na temat debugowania, technologie reklamowe muszą nam udowodnić, że mogą już dołączać do użytkowników w aplikacji i na stronie internetowej. Ma to na celu zapewnienie, że raporty na temat debugowania nie wyjdą nowych informacji. Technologia reklamowa może potwierdzić złączenie, podając klucz złączenia, który jest unikalny dla każdego użytkownika. Kluczem łączenia może być identyfikator reklamy (AdID) lub klucz łączenia pierwszego podmiotu. Jeśli technologia reklamowa korzysta z identyfikatora AdID, Chrome nie obsługuje natywnego dostępu do tego identyfikatora z przeglądarki, a interfejs API wymaga, aby każda technologia reklamowa miała własną metodę przekazywania identyfikatora AdID podczas rejestracji w sieci.
Szczegółowość przedziału	Czy można stosować różne strategie grupowania na reklamodawcę?	Zalecamy wypróbowanie różnych metod skalowania budżetu w ramach darowizn, aby znaleźć tę, która sprawdzi się najlepiej w Twoich przypadkach. Interfejs ARA został zaprojektowany tak, aby był elastyczny i można go było dostosować do różnych zastosowań w branży technologii reklamowych. Dlatego zalecamy eksperymentowanie z różnymi strategiami grupowania według reklamodawcy lub według branży. Stosowanie różnych strategii grupowania może być przydatne, gdy reklamodawcy mają różne wartości pomiarowe, które chcą śledzić, oraz wartości pomiaru.
Dokumentacja	Prośba o dodatkową dokumentację dotyczącą implementacji aplikacji<>web for ARA.	Dokumentację dotyczącą App<>Web w ARA znajdziesz tutaj.
Wyniki	Liczba żądań związanych z ARA może być zbyt dużym obciążeniem dla serwerów wydawcy w porównaniu z liczbą żądań keepalive, które są niezbędne do działania witryny. Grupowanie zdarzeń źródłowych w jednym żądaniu może pomóc zmniejszyć obciążenie serwera. Jednym z możliwych rozwiązań jest dodanie tablicy obiektów zakodowanych w formacie JSON.	Zdarzenia źródłowe można grupować według określonej logiki, korzystając z logiki JavaScriptu w połączeniu z interfejsem API. Obecnie rozpatrujemy tę prośbę. Zachęcamy do przekazywania dodatkowych opinii z ekosystemu tutaj.
Propozycja nowej funkcji	Propozycja obejścia problemu z powodu braku obsługi integracji typu „serwer-serwer”.	Obecnie nie planujemy wdrażać obsługi integracji między serwerami w ARA. Aby umożliwić obsługę integracji między serwerami, trzeba wziąć pod uwagę wiele wyzwań związanych z ochroną prywatności. Zapraszamy do dzielenia się opiniami na temat dodatkowych zastosowań obsługi komunikacji między serwerami tutaj.
Dokumentacja	Prośba o przekazany przewodnik „Szybki start”, który wyjaśnia najważniejsze części ARA i sposób rozpoczęcia pracy z kilkoma prostymi przypadkami użycia.	Krótki przewodnik dotyczący ARA jest dostępny tutaj. W tym roku będziemy dalej ulepszać tę dokumentację. Zachęcamy do przesyłania opinii na temat konkretnych przypadków użycia lub scenariuszy, które wymagają dodatkowej dokumentacji (tutaj).
Używanie API	Prośba o rekomendacje dotyczące skalowania wkładów w przypadku wielu małych wartości.	Zalecamy eksperymentowanie z różnymi podejściami do skalowania budżetu na podstawie opłaty, aby znaleźć to, które najlepiej sprawdza się w Twoim przypadku. W przypadku scenariusza z wiele małymi wartościami zalecamy eksperymentowanie z różnymi wartościami epsilona w celu zidentyfikowania punktów zwrotnych, w których szum z epsilona może być akceptowalny w danym przypadku użycia. Więcej informacji znajdziesz w naszym artykule Optymalizacja raportu podsumowania w ARA (w języku angielskim).
Elastyczne na poziomie zdarzenia	Kiedy zostanie wdrożona elastyczna reguła na poziomie zdarzenia (wiele specyfikacji reguł)?	Obecnie elastyczne raportowanie na poziomie zdarzenia umożliwia dostosowywanie tych aspektów konfiguracji rejestracji: liczby raportów, które można wygenerować na źródło, liczby i długości okien raportowania oraz mocy zbioru danych wyzwalacza. Obecnie zbieramy opinie na temat dodatkowych usprawnień na poziomie zdarzeń elastycznych, ale nie planujemy ich wdrażać. Cieszymy się z dodatkowych opinii na temat przypadków użycia, które mogą korzystać z elastycznego ulepszonego działania na poziomie zdarzenia wymienionego tutaj.
Przetwarzanie zasobnika	Poproś o ograniczenie zagregowanych danych zbieranych w zasobnikach oraz zwiększenie rozszerzalności i zgodności wstecznej.	Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj.
Epsilon	Co się dzieje z zakresem epsilon, gdy ARA staje się ogólnodostępny?	Interfejs ARA jest ogólny w przypadku Chrome w III kwartale 2023 r. Obecnie nie planujemy zmiany okna wartości epsilon. Nasz wniosek dotyczący poprawionej struktury zarządzania zapewniłby dodatkowe gwarancje w przypadku planowanych modyfikacji.
Raportowanie	Raporty o nieznanym błędzie w wywołaniu nie zawierają w swoim tekście atrybutów źródła.	Zgodnie ze specyfikacją w ciele raportu trigger-unknown-error nie trzeba podawać innych pól. Zdajemy sobie sprawę, że tabela z polami w tekstu raportu mogła być potencjalnie myląca, ponieważ pola związane ze źródłem mogą się pojawiać lub nie pojawiać w zależności od przyczyny błędu. Na przykład przed zastosowaniem logiki dopasowywania źródeł może wystąpić błąd wewnętrzny, co oznacza, że nie będzie dostępnych żadnych danych źródłowych, które mogłyby wypełnić raport debugowania. Zaktualizowaliśmy dokumentację, aby wyjaśnić tę kwestię.
Używanie API	Czy w przypadku pracy z 2 celami pomiarowymi – liczbą i wartością – czy jest odpowiedni podział zarówno budżetu przekazania, jak i wartości ypsilon?	W przypadku pracy z 2 celami pomiarowymi zalecamy rozdzielenie między nie budżetu przeznaczonego na darowiznę.
Raportowanie	Czy ARA obsługuje raporty o przypisaniu wieloetapowym lub wspomagane (zwane też raportami o udziale)?	ARA nie obsługuje obecnie atrybucji wieloetapowej ani raportów o pomocy. Obecnie nie planujemy tego robić. Dodatkowe opinie na temat przypadków użycia i ich priorytetów czekamy tutaj.
Błąd interfejsu API	W przypadku ARA dokumentacja podaje, że do łączenia elementów klucza agregacji źródła i wyzwalacza używana jest operacja XOR, ale w praktyce jest to operacja LUB. Ta rozbieżność prowadzi do zamieszania i potencjalnych błędów podczas implementacji.	Dokumentacja została zaktualizowana, aby odzwierciedlała ten błąd.

Usługa do agregacji

Temat opinii	Podsumowanie	Odpowiedź Chrome
Zadania agregacji	Prośba o zezwolenie na używanie wielu prefiksów w zadaniach agregacji	Sprawdzamy tę opinię i opublikowaliśmy propozycję tutaj. Chętnie poznamy opinię na temat tej propozycji tutaj.
Propozycja nowej funkcji	Prośba o zmianę skryptu terraform, tak aby w przypadku, gdy parametr service_account_token_creator_list nie jest ustawiony (lub jest pusty), pomijać modyfikację zasad uprawnień konta.	Szukamy przyczyny tego problemu tutaj i zapraszamy do dzielenia się opiniami na temat ekosystemu.
Używanie API	Potrzebna jest informacja o tym, że plan Terraform zawsze pokazuje zmiany.	Ten problem został rozwiązany w wersji AgS 2.8.
Używanie API	Poszukiwanie rekomendacji dotyczących konfiguracji ustawień częstotliwości agregacji dla poszczególnych reklamodawców z elastycznym filtrowaniem darowizn.	Obecnie za pomocą ARA można tworzyć zbiorcze raporty według reklamodawcy. Elastyczne filtrowanie darowizn może być używane w bardziej zaawansowanych przypadkach, gdy technologie reklamowe chcą dodatkowo dzielić raporty na segmenty według częstotliwości. Techniki reklamowe mogą dowiedzieć się więcej o grupowaniu tutaj i o używaniu identyfikatorów filtrowania za pomocą interfejsu ARA tutaj. Pracujemy też nad dodatkową dokumentacją dotyczącą filtrowania identyfikatorów.
Propozycja nowej funkcji	Poproś o pomoc dotyczącą funkcji „log_sum_exp” w usłudze do agregacji (AgS).	Skontaktowaliśmy się z tą osobą, aby uzyskać więcej informacji o tym przypadku użycia. Przekażemy więcej informacji, gdy tylko je poznamy.
Propozycja nowej funkcji	Prośba o możliwość wyświetlania większej liczby dzienników, statystyk i innych danych, gdy występują problemy z usługą w chmurze i potencjalne problemy z wdrożonymi usługami w chmurze.	Wprowadziliśmy zmiany w dokumentacji, aby uwzględnić więcej błędów, sposobów ich zminimalizowania i opisów tutaj. Czekamy na dodatkowe opinie na temat błędów, danych, logów itp., które nie są udokumentowane lub nie są dostępne. Możesz też podać przydatne informacje tutaj.
Testowanie interfejsu API	Jaka będzie ostateczna wartość epsilona po okresie testowym?	Obecnie nie planujemy zmiany okna wartości epsilon. Zachęcamy testerów do eksperymentowania z różnymi parametrami i przekazywania opinii.
Raportowanie	Raport jest generowany, ale w kodzie zwracanym nadal występuje błąd PRIVACY_BUDGET_AUTHORIZATION_ERROR.	Udostępniliśmy wskazówki dotyczące określania prawidłowego źródła zgłoszeń i raportów zbiorczych, które pozwolą uniknąć tego błędu. Chętnie przyjmiemy dodatkowe opinie na temat tego problemu, zwłaszcza jeśli występują powtarzające się błędy.
Odkrywanie kluczy	Jakie są plany dotyczące kluczowej propozycji dotyczącej odkrywania informacji?	Nie mamy jeszcze harmonogramu wdrożenia propozycji kluczowej funkcji odkrywania, ale prosimy o opinie ekosystemu na jego temat tutaj.
Dostosowywanie	Szukanie opcji dostosowywania dostępnych w usłudze agregacji.	W ramach usługi spersonalizowanej nie można dostosowywać usługi agregacji, ale można to robić w przypadku niektórych komponentów spoza usługi spersonalizowanej. Wynika to ze standardów prywatności i bezpieczeństwa, które musimy zachować w ramach TEE. Pracujemy nad zaktualizowaniem naszej dokumentacji, aby pomóc specjalistom ds. technologii reklamowych zrozumieć architekturę i to, które komponenty można dostosować. Nie możemy obsługiwać niektórych dostosowań, dlatego w miarę możliwości zalecamy stosowanie standardowych konfiguracji.
Spoty a instancje na żądanie	Czy system został przetestowany przy użyciu instancji typu spot i instancji na żądanie? Czy oprócz tymczasowej niedostępności istnieją inne wady korzystania z instancji typu spot?	Nie stawiamy priorytetu testom w przypadku instancji na żądanie, ponieważ zalecamy, aby firmy technologiczne korzystały z in instancji na żądanie. Wadą spotów jest to, że zadanie może zostać przerwane podczas wykorzystania budżetu. Jeśli budżet został wykorzystany, a zadanie zostało przerwane, zanim specjalista ds. technologii reklamowych otrzymał raport podsumowujący, nie będzie on mógł po prostu ponownie uruchomić zadania, ale będzie musiał poprosić o przywrócenie budżetu. Przywracanie budżetu jest zalecane tylko w przypadku katastrofalnych awarii, aby zachować prywatność. Zalecamy, aby specjaliści ds. technologii reklamowych skonfigurowali autoskalowanie, aby zminimalizować koszty. Wybranie 0 w przypadku autoskalowania oznacza, że nie będzie żadnych uruchomionych instancji, dopóki nie zostanie wysłane żądanie zadania (pamiętaj, że może to zwiększyć opóźnienie, ponieważ instancje będą uruchamiane w momencie otrzymania żądania).
Znane błędy i ich rozwiązania	Usługa agregacji wyświetla komunikat „Błąd usługi”. Potrzebna jest pomoc w rozwiązaniu tego problemu	Problem został rozwiązany tutaj. Zaktualizowaliśmy też niektóre komunikaty o błędach, aby były bardziej opisowe. Na przykład zaczęliśmy generować w AWS bardziej szczegółowe błędy związane z uprawnieniami/uwierzytelnianiem, w przeciwieństwie do sytuacji, gdy były one widoczne jako błędy wewnętrzne. Zaktualizowaliśmy dokumentację dotyczącą kodów błędów i sposobów ich łagodzenia tutaj. Zachęcamy do przesyłania dodatkowych informacji o błędach, które nie zostały udokumentowane lub nie są dostępne, oraz o szczegółach, które mogą być przydatne tutaj.

Interfejs Private Aggregation API

Temat opinii	Podsumowanie	Odpowiedź Chrome
Key Design	Prośba o wskazówki dotyczące projektowania klucza agregacji prywatnej	Nie mamy poradnika dotyczącego prywatnej agregacji, ale możesz skorzystać z ramy testowania obciążenia usługi agregacji i poradnika Zaawansowane zarządzanie kluczami.
Budżet na wkład	Na jakim poziomie jest obliczany i ograniczony budżet na udział?	Budżet na udział w dochodach jest równy 2^16 w przedziałach 10-minutowych i 2^20 w przedziałach 24-godzinnych.

Ograniczanie śledzenia ukrytego

Redukcja klienta użytkownika/Wskazówki dotyczące klienta użytkownika

W tym kwartale nie otrzymaliśmy żadnych opinii.

Ochrona IP (dawniej Gnatcatcher)

Temat opinii	Podsumowanie	Odpowiedź Chrome
Android	Jakie są plany dotyczące wdrożenia ochrony przed atakami na adres IP w Androidzie?	Chociaż pracujemy nad udostępnieniem na Androidzie funkcji zapobiegania pokryciu, w tym ochrony IP, nie mamy obecnie oficjalnych planów.
Używanie API	Czy istnieje lub czy w przyszłości będzie możliwe wyłączenie ochrony przed oszustwami w przypadku ochrony IP?	Staramy się znaleźć równowagę między ochroną użytkowników przed śledzeniem w internecie na podstawie ich adresów IP a jednoczesnym minimalizowaniem zakłóceń w normalnej pracy serwerów, w tym używania adresów IP do zwalczania nadużyć. W tej chwili nie możemy podać więcej szczegółów, ale mamy nadzieję, że przekażemy je w niedalekiej przyszłości.
Identyfikacja niewłaściwego aktora	Obawy dotyczące skuteczności tradycyjnych środków bezpieczeństwa w odniesieniu do szkodliwych adresów IP.	Ochrona IP nie będzie pośredniczyć w przypadku żądań 1P, więc spodziewamy się, że większość systemów wykrywania włamań nie będzie na to wpływać. W przyszłości udostępnimy więcej informacji na temat zapobiegania oszustwom i unikania problemów z witrynami w przypadku użytkowników w trybie incognito.
Maskowanie adresów IP	Jeśli witryna wydawcy wiadomości używa tej samej domeny co witryna reklamowa (innej firmy), czy adres IP zostanie maskowany w obu przypadkach? Jeśli nie, to jak je odróżnić?	Obecnie ochrona adresów IP wykorzystuje podejście oparte na listach, aby określać, który ruch pochodzący od innych firm przechodzi przez serwery proxy. Jednak nawet jeśli źródło znajduje się na tej liście, nie będzie obsługiwane przez serwer proxy, gdy uzyska do niego dostęp z poziomu własnego. Kończymy pracę nad szczegółami dotyczącymi tego, które konkretne domeny zewnętrzne będą miały początkowo priorytet, i jak dokładnie zdefiniujemy konteksty własne i zewnętrzne w ramach ochrony adresów IP.
Maskowanie adresów IP	Kwestia ochrony własności intelektualnej i jej wpływu na systemy zapobiegające oszustwom.	Nasze plany ochrony adresów IP nie mają wpływu na adresy 1P, więc strony takie jak fora powinny mieć dostęp do adresów IP w celu rozstrzygania sporów. W przyszłości podamy więcej informacji na temat oszustw reklamowych.
Maskowanie adresów IP	Czy adres IP jest zamaskowany w nagłówku w przypadku domen, których dotyczy problem?	Użytkownicy zostaną przypisani do obszaru geograficznego na podstawie adresu IP przed serwerem proxy, który reprezentuje ich bieżącą lokalizację. Więcej informacji znajdziesz tutaj.

Łagodzenie śledzenia przekierowań

Temat opinii	Podsumowanie	Odpowiedź Chrome
Specyfikacja interfejsu API	Potrzebna jest jasność dotycząca sposobu obsługi rozszerzonej nawigacji w Chrome po zamknięciu karty.	Rozwiązaliśmy ten problem tutaj i odpowiednio zaktualizowaliśmy specyfikację.
Śledzenie nawigacji	Omówienie podejścia do ograniczania śledzenia, które polega na korzystaniu z ograniczonego zbioru linków w celu zmniejszenia entropii w żądaniach między witrynami.	Nadal rozmawiamy na ten temat z innymi dostawcami przeglądarek tutaj. Zachęcamy do przesyłania dodatkowych opinii i propozycji dotyczących tego problemu.

Budżet na potrzeby prywatności

Jak wyjaśniono na GitHubu i na stronie dla deweloperów, budżet prywatności nie jest już aktywnie
uwzględniany w ramach propozycji Piaskownicy prywatności.

Wzmacnianie granic prywatności między witrynami

Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)

Temat opinii	Podsumowanie	Odpowiedź Chrome
(również w poprzednich kwartałach) Limit domeny zestawu powiązanych witryn (RWS)	Prośba o zwiększenie limitu powiązanych domen w RWS	Nasza odpowiedź jest podobna do poprzednich kwartałów: Obecnie nie przewidujemy zwiększenia limitu. Limit został ustalony na podstawie kwestii związanych z ochroną prywatności użytkowników, opinii zainteresowanych osób z ekosystemu W3C oraz uwzględnienia podobnych implementacji w innych przeglądarkach. Więcej informacji znajdziesz w naszych postach na blogu (1, 2). Zalecamy zapoznanie się z przypadkami użycia, które wymagają dostępu do plików cookie w wielu witrynach, oraz skorzystanie z naszych wskazówek dotyczących przypadków użycia związanych z tożsamością, zamieszczania z użyciem uwierzytelnienia i przypadków użycia związanych z reklamami. Jeśli sesje użytkowników są powiązane z działaniami związanymi z logowaniem, zalecamy użycie interfejsu API Federated Credential Management (FedCM) w celu zachowania funkcjonalności. Czekamy na opinie na temat innych przypadków użycia, które mogą być wymagane tutaj.
Obsługa plików cookie w witrynach	Pliki cookie z innych witryn ustawione przez domenę podrzędną nie są przekazywane w kolejnych żądaniach z domeny podstawowej. Problem występuje nawet przy prawidłowych konfiguracjach CORS i danych logowania.	Wskazówki dotyczące prawidłowego używania interfejsu requestStorageAccessFor API, który musi zawierać pełny adres źródłowy (czyli zawierać subdomeny), aby pliki cookie między witrynami mogły być wysyłane w kolejnych żądaniach pobierania, znajdziesz tutaj.
Wybór użytkownika	Prośba o dodatkowe informacje dotyczące funkcji requestStorageAccessFor używanej przez RWS po wdrożeniu opcji wyboru użytkownika, w szczególności o to, jak w nowym systemie będzie działać gest użytkownika (domyślny lub jawny), który obecnie umożliwia dostęp do 3 PC.	Oczekujemy, że zachowanie RWS w trybie wyboru użytkownika (czyli niezależnie od tego, czy użytkownicy zdecydują się zachować lub ograniczyć 3PC) będzie zgodne z obecnym zachowaniem w Chrome, gdy 3PC są dozwolone, lub gdy 3PC są blokowane przy włączonym RWS (ustawienie „Zezwalaj powiązanym witrynom na dostęp do danych o Twojej aktywności w grupie”). Zalecamy najpierw wywołanie metody hasStorageAccess, aby sprawdzić, czy element wbudowany ma już dostęp do niezagregowanych plików cookie w wielu witrynach, a dopiero potem wywołać metodę requestStorageAccess. Metoda hasStorageAccess zwraca wartość „prawda”, jeśli użytkownik zezwolił na korzystanie z komputerów innych firm. requestStorageAccessFor obecnie nie wymaga gestu użytkownika, jeśli dozwolone są urządzenia zewnętrzne. Otworzyliśmy nowy problem na GitHubie, aby omówić i określić, jak powinno wyglądać prawidłowe działanie w takim przypadku. Zachęcamy do dzielenia się opiniami na temat tego ekosystemu.
Używanie API	Wątpliwości dotyczące niejasności co do wykorzystania RWS do celów „komercyjnych”, co utrudnia jego wdrożenie. Osoba zainteresowana zgrupowaniem publikacji na potrzeby reklamy ukierunkowanej.	Zamierzonym zastosowaniem RWS jest obsługa podstawowej funkcjonalności witryny i podstawowych ścieżek użytkowników. Zachęcamy do korzystania z naszych dedykowanych interfejsów API reklamowych do celów związanych z reklamami kierowanymi.
Używanie API	Zgłoszono problem z funkcją requestStorageAccess, w której można było ustawić dane localStorage, ale nie pliki cookie.	Problem został spowodowany literówką w atrybucie SameSite. Sprawdź pisownię i ustaw wartość na „Brak” w przypadku 3 elementów.
Specyfikacja interfejsu API	rozbieżności w schematach JSON w repozytorium, np. błędne umieszczenie pola „contact” i sugestie dotyczące ulepszeń, w tym użycie słowa kluczowego „oneOf” w celu zapewnienia spójności;	Sprawdzamy tę informację i w najbliższej przyszłości wprowadzimy odpowiednie poprawki w schemacie. Tutaj możesz przesłać dodatkową opinię .
Dostęp aplikacji zewnętrznych do RWS	Za zgodą użytkownika zezwól sprzedawcy na wskazanie domen innych firm, które będą miały taki dostęp do danych interfejsu RWS API.	Pozwolenie dostawcom zewnętrznym na łączenie własnych danych niepartiowanych z danymi witryn RWS podważałoby zabezpieczenia przed śledzeniem na wielu stronach w Piaskownicy prywatności. Rozważamy jednak możliwość umożliwienia firmom zewnętrznym zachowania danych partycjonowanych w RWS i prosimy o opinie na temat projektu takiego rozwiązania tutaj.

Fenced Frames API

Temat opinii	Podsumowanie	Odpowiedź Chrome
Pytanie dotyczące interfejsu API	Wątpliwości dotyczące tego, jak Fenced Frames bez dostępu do sieci mogą zagrażać bezpieczeństwu marki i ochronie przed oszustwami dla reklamodawców.	Śledzimy ten problem w kontekście naszego planu wprowadzenia ramek ograniczonych. Wkrótce zaczniemy szukać rozwiązań zgodnych z wymaganiami dotyczącymi odizolowanych ramek. Gdy tylko pojawią się wystarczająco istotne propozycje, udostępnimy je.
Pytanie dotyczące interfejsu API	Czy interfejs Fenced Frames API jest nadal zaplanowany na 2026 r.?	Jak wspomnieliśmy w oświadczeniu publicznym, stosowanie ograniczonych ramek będzie wymagane nie wcześniej niż w 2026 r.
Błąd interfejsu API	Gdy reportEvent() pomyślnie wyśle dane kliknięć z elementu iframe w innej domenie, setReportEventDataForAutomaticBeacons() nie nadpisze danych z ramki nadrzędnej.	Rozmawiamy o tym problemie i zapraszamy do podzielenia się opinią tutaj.

Interfejs Shared Storage API

Temat opinii	Podsumowanie	Odpowiedź Chrome
Reklamowanie aplikacji	W Piaskownicy prywatności na Androida nie ma odpowiednika interfejsu Shared Storage API.	Oceniamy rozwiązania na Androida na podstawie potrzeb związanych z przypadkami użycia i ograniczeń platformy. W tej chwili nie mamy żadnych planów, ale chętnie poznamy opinie na temat tego problemu.
Używanie API	Pomieszanie dotyczące potrzeby użycia dodatkowego workleta JavaScript w ramach implementacji interfejsu Shared Storage API.	Sprawdzamy tę informację i rozważamy aktualizację naszej dokumentacji, aby wyjaśnić, dlaczego potrzebne są dodatkowe skrypty workletów w przypadku interfejsu Share Storage API.
Niezawodność	Interfejs Shared Storage API może się znacznie zmienić lub zostać usunięty z powodu krytyki prywatności, przez co nie jest wiarygodne.	Nie planujemy wprowadzać istotnych zmian w infrastrukturze Shared Storage ani jej porzucać. Zapowiedzieliśmy główne zmiany dotyczące bramy wyjściowej Select URL, w której wymagane będą ramki chronione, a raportowanie na poziomie zdarzenia zostanie wycofane. Jednak te zmiany wejdą w życie dopiero w 2026 roku.

CHIPS

Temat opinii	Podsumowanie	Odpowiedź Chrome
Pliki cookie podzielone na części	W odróżnieniu od Firefoksa Chrome nie rozróżnia kluczy partycji na podstawie elementów nadrzędnych ramki, co prowadzi do niespójności.	Przeglądarka Chrome zastosowała „łańcuch łańcucha elementów nadrzędnych”, aby rozwiązać problem z bezpieczeństwem i rozbieżności w działaniu przeglądarki Firefox. Więcej informacji znajdziesz tutaj.
Pliki cookie partycjonowane	Umieszczone ramki iframe z różnymi poziomami dostępu do pamięci masowej udostępniają i zastępują ten sam plik cookie podzielony na partycje, powodując niespójności w stanach uwierzytelniania.	W przypadku tej konkretnej konfiguracji zalecamy używanie plików cookie bez partycji z wywołaniem interfejsu Storage Access API. Więcej informacji na ten temat znajdziesz tutaj.
Pliki cookie podzielone na części	Czy oddzielone cookie zostaną usunięte, gdy wyłączysz 3PC? Czy można przetestować to zachowanie?	W tej chwili nie mamy żadnych planów, które moglibyśmy Ci przekazać. Programiści mogą jednak przetestować tę funkcję, ręcznie usuwając partycjonowane pliki cookie na panelu Narzędzia deweloperskie w Chrome – Aplikacja> Pliki cookie.

FedCM

Temat opinii	Podsumowanie	Odpowiedź Chrome
Zakres rejestracji dostawcy tożsamości (IdP) i selektor organizacji	Pytanie dotyczące rozszerzenia rejestracji dostawcy tożsamości z obecnej zasady „tego samego pochodzenia” na zasadę „tej samej witryny”. Ta zmiana umożliwiłaby szersze i bardziej elastyczne zarządzanie tożsamością, np. rejestrowanie na stronie powitalnej uczelni wielu dostawców tożsamości na podstawie subdomen bez konieczności rejestracji na podstawie poszczególnych źródeł. Opinie na temat ulepszenia możliwości debugowania, obsługi zatwierdzonych klientów w ramach cichej mediacji, wyjaśnienia działania plików cookie, umożliwienia dostosowywania tekstu wyskakujących okienek i rozwiązywania problemów z czasem oczekiwania.	Dziękujemy za tę opinię. Rozważamy, jak wdrożyć w FedCM opcję wyboru organizacji. Cieszymy się na każdą opinię z ekosystemu, którą możesz przesłać tutaj. Będziemy ją uwzględniać w dalszych pracach nad ulepszaniem tego podejścia.
Pliki cookie dostawcy tożsamości	Dyskusja na temat wpływu wdrożenia krótkotrwałych plików cookie sesji w ramach oferty dotyczącej danych uwierzytelniających sesji powiązanych z urządzeniem (DBSC). Wątpliwości budzi sposób obsługi w FedCM, w którym wygasłe pliki cookie dostawcy tożsamości wymagają od użytkownika widocznego modala do odnowienia.	Proponowany DBSC powinien umożliwiać odnawianie plików cookie bez interakcji z użytkownikiem, zapewniając ciągłość działania. Więcej informacji na ten temat znajdziesz tutaj.
Specyfikacja interfejsu API	Pytanie o odpowiednie użycie w specyfikacji interfejsu FedCM API wartości „NetworkError”, gdy rozmiar tablicy „providers” nie jest równy 1.	Zgadzamy się, że w tej sytuacji bardziej odpowiedni byłby błąd „TypeError”, ponieważ odzwierciedla on błąd kodowania, a nie problem z siecią. Rozważymy tę zmianę i zbadamy możliwość usunięcia tej restrykcji w przyszłych aktualizacjach, gdy będziemy się zbliżać do obsługi wielu dostawców tożsamości. Tutaj możesz przesłać dodatkową opinię .

Walka ze spamem i oszustwami

Interfejs Private State Token API (i inne interfejsy API)

Temat opinii	Podsumowanie	Odpowiedź Chrome
Wycofanie wersji próbnej i tryb B	Wątpliwości związane z procesem wycofywania, testowaniem w trybie B, potencjalnym wycofaniem tokenów prywatnych (PST) oraz możliwości utworzenia nowego interfejsu API lepiej dopasowanego do ochrony przed oszustwami.	Testowanie wycofywania i testowanie w trybie B pozostają bez zmian. Wszelkie informacje będziemy informować na blogu dla programistów. Nie planujemy rezygnacji z PST. Wciąż pracujemy nad rozwojem tej funkcji i regularnie publikujemy aktualizacje na GitHub. Nie ogłosiliśmy żadnych nowych interfejsów API, ale chętnie poznamy opinie na temat tego, jak PST mogą lepiej spełniać potrzeby związane z zapobieganiem oszustwom.
Opinie o interfejsie API	Prośba o możliwość wycofania tokenów w celu przeciwdziałania oszustwom.	Wydawca może cofnąć wszystkie tokeny, zmieniając używane klucze, ale cofnięcie poszczególnych tokenów jest niemożliwe w ramach interfejsu API, ponieważ wymagałoby zezwolenia wydawcy na powiązanie emisji i wykorzystania tokenu, co narusza model ochrony prywatności PST, który zapobiega śledzenia między tymi 2 zdarzeniami.