Raport z opiniami – I kwartał 2025 r.

Czwarty raport kwartalny z 2025 r. podsumowujący opinie o propozycjach dotyczących Piaskownicy prywatności i odpowiedzi Chrome.

Google opracowało ten kwartalny raport w ramach zobowiązań wobec Urzędu ds. Konkurencji i Rynków (CMA) zgodnie z punktami 12, 17(c)(ii) i 32(a). Raport zawiera informacje o postępach Google w realizacji propozycji dotyczących Piaskownicy prywatności, zaktualizowane oczekiwania dotyczące harmonogramu, szczegółowe wyjaśnienia dotyczące sposobu uwzględniania przez Google uwag innych firm oraz podsumowanie interakcji między Google a CMA, w tym opinie CMA i sposób, w jaki Google zareagował na te opinie.

Google informuje CMA o postępach w realizacji propozycji dotyczących Piaskownicy prywatności podczas regularnych spotkań dotyczących stanu prac, które odbywają się zgodnie z punktem 17 b zobowiązań. Ponadto zespół prowadzi dokumentację dla deweloperów, która zawiera omówienie głównych funkcji reklam prywatnych i zmian w pliku cookie, a także informacje o implementacji interfejsu API i informacje o stanie. Najważniejsze informacje są publikowane na blogu dla deweloperów, a także na listach adresowych deweloperów.

Słowniczek akronimów

ARA

Attribution Reporting API

CHIPS

Pliki cookie z oddzielnymi stanami w oddzielnych partycjach

(procesor) DSP

Platforma DSP

FedCM

Federated Credential Management

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

PA API

Protected Audience API (dawniej FLEDGE)

PatCG

Grupa społeczności technologii reklamowych

RP

Jednostka uzależniona

RWS

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

SSP

Platforma dostawców reklam

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

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Wybór użytkownika	Nie jest jasne, jak będzie wyglądać zaktualizowane podejście Google do zwiększenia możliwości wyboru użytkowników, jak będzie ono przedstawiane użytkownikom i jakie są przewidywane wskaźniki wyrażenia zgody lub rezygnacji z niej. Aby odróżnić to od wycofania plików cookie innych firm, potrzebujemy więcej informacji.	W kwietniu 2025 r. opublikowaliśmy w blogu artykuł Kolejne kroki w przypadku Piaskownicy prywatności i ochrony przed śledzeniem w Chrome, w którym ogłosiliśmy, że utrzymujemy obecne podejście do oferowania użytkownikom plików cookie innych firm w Chrome i nie wprowadzimy nowego osobnego komunikatu dotyczącego plików cookie innych firm. Będziemy na bieżąco publikować kolejne informacje.
Odciski cyfrowe	Google nie udostępnia wydawcom ani marketerom żadnych informacji o tym, jak mogą polegać na alternatywach dla systemów reklamowych Google bez korzystania z bardziej ryzykownych identyfikatorów konsumentów jako wspólnego klucza do dopasowania (np. odcisków palców).	Wyróżniliśmy kilka systemów reklamowych innych niż Google, które oferują rozwiązania dla wydawców i marketerów, oparte częściowo na interfejsach API Piaskownicy prywatności. Dotyczy to systemów reklamowych innych niż Google na różnych rynkach i w różnych kanałach. Więcej informacji i studium przypadku znajdziesz w sekcji Zasoby dla firm na stronie privacysandbox.com tutaj.
Piaskownica prywatności	Interfejsy API Piaskownicy prywatności zastąpiłyby składniki danych internetowych własnymi gotowymi produktami Google. Ponieważ alternatywa Google to interfejs API, firma oferuje dostęp do usługi, której jest właścicielem i którą kontroluje, a która podlega warunkom, które Google może zmieniać według własnego uznania. Nie zastępuje komponentów, których używają inni użytkownicy do tworzenia własnych gotowych produktów.	Interfejsy API Piaskownicy prywatności zostały opracowane i wdrożone po szeroko zakrojonych konsultacjach z organami regulacyjnymi i wielu interesariuszami z ekosystemu. Podobnie jak w przypadku innych technologii platformowych, interfejsy API Piaskownicy prywatności muszą uwzględniać fakt, że będą używane jako komponenty w usługach innych firm. Zachęcamy do rozwijania dodatkowych technologii, które będą współpracować z interfejsami API Piaskownicy prywatności.
Wybór użytkownika	Prośba o informację, czy zaktualizowane podejście Google do 3 PC w Chrome będzie zgodne z pewnymi wymaganiami regulacyjnymi, które mogą mieć wpływ na sposób zarządzania zgodami w ramach platformy	W kwietniu 2025 r. opublikowaliśmy w blogu artykuł Kolejne kroki w przypadku Piaskownicy prywatności i ochrony przed śledzeniem w Chrome, w którym ogłosiliśmy, że utrzymujemy obecne podejście do oferowania użytkownikom plików cookie innych firm w Chrome i nie wprowadzimy nowego osobnego komunikatu dotyczącego plików cookie innych firm. Będziemy na bieżąco publikować kolejne informacje.
Piaskownica prywatności – harmonogram i wdrożenie	Firmy z branży technologii reklamowych wstrzymały testowanie interfejsów API Piaskownicy prywatności i szukają mocniejszych powodów, aby ponownie inwestować w te technologie w ramach działań związanych z usługami i marketingiem. Na ich decyzje o ponownie zainwestowaniu środków duży wpływ ma potrzeba większej przejrzystości dotyczącej harmonogramu wdrażania opcji User Choice oraz obawy związane z opóźnieniami w przypadku interfejsu Protected Audience API (PA API) i harmonogramem dotyczącym B&A. Pojawiają się też obawy dotyczące nadchodzącego przeglądu zobowiązań CMA, zwłaszcza w odniesieniu do roli Google jako głównego promotora technologii Piaskownicy prywatności, które nie korzystają z identyfikatorów innych firm, oraz ogólnego kierunku rozwoju tej inicjatywy, która ma służyć do tworzenia strategii inwestycyjnych.	W kwietniu 2025 r. opublikowaliśmy w blogu artykuł Kolejne kroki w przypadku Piaskownicy prywatności i ochrony przed śledzeniem w Chrome, w którym ogłosiliśmy, że utrzymujemy obecne podejście do oferowania użytkownikom plików cookie innych firm w Chrome i nie wprowadzimy nowego osobnego komunikatu dotyczącego plików cookie innych firm. Będziemy na bieżąco publikować kolejne informacje. Aukcji w ramach interfejsu API Chrome PA jest o 35% więcej niż rok wcześniej. Zauważyliśmy też znaczny wzrost wykorzystania aukcji równoległych, które zapewniają jeszcze większe korzyści. Naszą aktualną mapę drogową dotyczącą pytań i odpowiedzi znajdziesz tutaj.
Piaskownica prywatności – harmonogram	Co zostało zaktualizowane na stronie Piaskownicy prywatności?	Na stronie Piaskownicy prywatności w sekcji Chronologia dodano niedawno omówienie interfejsu Topics API.
Piaskownica prywatności	Czy istnieją jakieś badania dotyczące prywatności a użyteczności, które pomogą zrozumieć wpływ Piaskownicy prywatności na przychody?	Odpowiedzi na te pytania znajdziesz w przypadkowych badaniach rynku tutaj, a wyniki testów interfejsów API Piaskownicy prywatności – tutaj.
Wdrożenie Piaskownicy prywatności	Wcześni użytkownicy zgłosili początkowe problemy z interfejsami API Piaskownicy prywatności z powodu powolnego wdrażania przez większe firmy, co wpływa na uruchamianie testów. Mimo to doceniamy współpracę i szybką reakcję zespołu Piaskownicy prywatności na opinie.	Dziękujemy za opinie użytkowników, którzy jako pierwsi korzystają z nowego rozwiązania. Chcemy współpracować z pierwszymi użytkownikami i nadal będziemy współpracować z ekosystemem oraz zbierać opinie, aby ocenić rolę technologii Piaskownicy prywatności w obsługiwaniu ekosystemu.
Testowanie w Chrome	Obawy dotyczące możliwości kontynuowania skutecznego testowania Piaskownicy prywatności po usunięciu etykiet testowych, które wskazują na znaczną różnicę w jakości ruchu między Chrome z wyłączonymi 3PC (Tryb B) a użytkownikami, którzy sami wyłączyli 3PC w ustawieniach Chrome.	Nasze stanowisko jest podobne do tego z poprzednich kwartałów: Zespół Piaskownicy prywatności rozumie, że firmy chcą nadal używać etykietek wycofywania plików cookie. Proces przedłużania dostępności etykiet jest podobny do przedłużania wersji próbnej origin. Obsługa etykiet była kilkakrotnie rozszerzana. Zamierzamy zaproponować dalsze rozszerzenie obsługi etykiet wycofywania plików cookie i w miarę ich udostępniania będziemy publikować informacje na ten temat na blink-dev.

Rejestracja i potwierdzenie

W tym kwartale nie otrzymaliśmy żadnych opinii.

Wyświetlanie odpowiednich treści i reklam

Tematy

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Włączanie i wyłączanie	Czy potwierdzenie przez Google, że wyszukiwarka Google nie będzie używać decyzji witryny o rezygnacji z interfejsu Topics API jako sygnału rankingowego, uniemożliwi Google używanie decyzji witryny o włączeniu interfejsu Topics API jako sygnału rankingowego?	Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: Zespół Piaskownicy prywatności nie uzgadniał z organizacją wyszukiwania, aby używała rankingu stron jako zachęty do korzystania z interfejsu Topics API. Wyszukiwarka Google nie będzie używać decyzji witryny o obsługiwaniu (lub nie) interfejsu Topics API jako sygnału rankingowego.
Dostrzegalność wykorzystania	Prośba o mechanizm obserwowalności dla platformy SSP lub ogólnej technologii reklamowej, aby sprawdzić, czy ich implementacja interfejsu Topics API jest używana w internecie.	Oceniamy obsługę tej funkcji i zapraszamy do dzielenia się opiniami na temat tego ekosystemu, jeśli ta funkcja ma wysoki priorytet.
Prywatność	Pytania dotyczące zgody i potencjału ponownej identyfikacji.	Obecnie omawiamy ten problem tutaj i zapraszamy do dzielenia się opiniami.

Protected Audience API

Motyw opinii	Podsumowanie	Odpowiedź Chrome
PA API i GAM/AdX	Google nie będzie wysyłać żadnych zapytań GAM/AdX do wydawcy, który chce korzystać z serwera reklam konkurencyjnego wydawcy. Google powinien umożliwić konkurencyjnym wydawcom wybór alternatywnych sprzedawców aukcji na najwyższym poziomie interfejsu PA API, aby mogli oni kontrolować aukcję końcową. Informacje z interfejsu PA API będą dostępne dla GAM, ale będą ograniczone dla konkurencyjnych SSP. W rezultacie wydawcy nie mogą porównywać skuteczności zasobów reklamowych pochodzących z PA API w GAM, np. z AdX lub z platform SSP zintegrowanych z PA API.	Odpowiedź Chrome: Standard interfejsu PA API jest elastyczny i umożliwia różnym stronom prowadzenie aukcji najwyższego poziomu. Ten wybór zależy od konkretnych implementacji i możliwości oferowanych przez serwer reklam wydawcy (czy to GAM, czy inny) oraz inne firmy uczestniczące w ekosystemie. Dzięki projektowi interfejsu PA API skoncentrowanemu na ochronie prywatności raportowanie szczegółowe jest ograniczone w sposób spójny dla wszystkich uczestników. Określone dane przesyłane z aukcji API PA podlegają tym samym regułom i ograniczeniami dotyczącymi ochrony prywatności, które są zdefiniowane w interfejsie API i dotyczą wszystkich uczestników, w tym SSP. Aby oceniać skuteczność, wydawcy korzystają z raportów zbiorczych interfejsu PA API, które chronią prywatność. Umożliwia to ocenę ogólnego wkładu ofert reklamowych pochodzących z interfejsu PA API i porównanie ich z innymi kanałami ofert reklamowych zgodnie z zasadami ochrony prywatności w projektowaniu. Odpowiedź Google Ad Managera: Aby uzyskać dostęp do zapotrzebowania AdX, wydawcy nie muszą korzystać z funkcji serwera reklam GAM. Ponadto interfejs PA API nie ma znaczenia, kto inicjuje aukcję, zarówno w przypadku sprzedawców pojedynczych, jak i sieci sprzedawców.
Najlepszy sprzedawca	Sprzedawca na najwyższym poziomie ma dostęp do informacji, do których nie mają dostępu inni sprzedawcy komponentów, co budzi obawy o nierówny dostęp do informacji. Każdy podmiot może być TLS, ale aby uzyskać dostęp do popytu AdX, wydawcy muszą używać GAM jako serwera reklamowego wydawcy. Zachęca to wydawców do korzystania z GAM jako serwera reklamowego, co daje Google przewagę konkurencyjną.	Odpowiedź Chrome: Konstrukcja interfejsu PA API nie określa, które podmioty mogą działać jako TLS. Rola TLS wymaga koordynowania aukcji i dostępu do powiązanych informacji o aukcji zgodnie ze strukturą interfejsu API. Odpowiedź Google Ad Managera: Od lat kładziemy duży nacisk na uczciwość aukcji, w tym na naszej obietnicy, że żadna cena z żadnego niegwarantowanego źródła reklam 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. Potwierdziliśmy to później w zobowiązaniach wobec francuskiego urzędu antymonopolowego. W przypadku aukcji w interfejsie PA API zamierzamy dotrzymać naszej obietnicy i nie udostępniać stawki żadnego uczestnika aukcji żadnemu innemu uczestnikowi przed zakończeniem aukcji w aukcjach wielosprzedawców. Zapewniamy, że nie udostępnimy ceny aukcji kontekstowej żadnej aukcji komponentów, w tym naszej, jak wyjaśniliśmy w tej aktualizacji. Co więcej, w ramach naszej aukcji nie używamy informacji o konfiguracjach aukcji komponentów, w tym sygnałów przekazywanych przez kupujących do SSP. Jak już wspomnieliśmy, GAM nie wymaga, aby wydawcy korzystali z funkcji serwera reklam, aby uzyskać dostęp do popytu AdX. Na koniec, jak zauważono wcześniej w raporcie Google za II i III kwartał 2024 r., platformy Google po stronie kupującego – Google Ads (dawniej AdWords) i DV360 – kupują wyświetlenia z giełd innych niż Google, w tym za pomocą interfejsu PA API.
PA API i GAM/AdX	Wydawcy nie rozumieją, dlaczego należy aktywować interfejs PA API w przypadku 100% zasobów reklamowych, ponieważ oznaczenie tej opcji nie wyjaśnia, do czego służy. W przypadku dostawców SSP, których głównym sposobem dostępu do zasobów reklamowych jest często aukcja wielopoziomowa z usługą GAM pełniącą rolę serwera TLS, nie ma możliwości przeprowadzenia testów ani zarabiania za pomocą interfejsu PA API bez korzystania z usługi GAM.	Odpowiedź Chrome: Standard PA API definiuje role techniczne (np. TLS i sprzedawca komponentów) oraz proces aukcji, co pozwala na elastyczność w tym, które platformy pełnią te role. Czynności operacyjne, takie jak konfiguracja, koordynacja i umowy, są zarządzane przez strony wdrażające (wydawców, dostawców SSP i dostawców TLS), aby ułatwić udział w ramach interfejsu PA API. Odpowiedź Google Ad Managera: Jak opisano w Centrum pomocy, Ad Manager oferuje wydawcom opcję umożliwiającą testowanie z udziałem sprzedawców komponentów spoza Google, np. innych SSP, w 100% zasobach reklamowych wydawcy, w których jest dostępne API (z ignorowaniem próbkowania lub ograniczania, które może być stosowane przez GAM). Jeśli wydawca włączy to ustawienie, to za każdym razem, gdy sprzedawca komponentów inny niż Google udostępni konfigurację aukcji, GAM spróbuje uruchomić aukcję najwyższego poziomu z uwzględnieniem tej aukcji komponentu, o ile wydawca uzyskał niezbędną zgodę użytkownika. GAM wyraźnie informuje wydawców, że to ustawienie może mieć wpływ na skuteczność, aby mogli oni podjąć świadomą decyzję.
Po stronie serwera a na urządzeniu	Rozwiązania po stronie serwera, takie jak określanie stawek i aukcje, mogą być przydatne do kształtowania ruchu przy jednoczesnym zachowaniu prywatności. Rozwiązania po stronie serwera to jedyna realna droga do przodu, a Google powinno zrezygnować z rozwiązań na urządzeniu.	Piaskownica prywatności ma obsługiwać zarówno rozwiązania po stronie serwera (usługi B&A), jak i aukcje na urządzeniu, oferując opcje dostosowane do różnych potrzeb i przypadków użycia technologii reklamowych.
Zabezpieczenia aukcji	Ataki na stawki w PA API wykluczają w zasadzie określanie stawek i przeprowadzanie aukcji na urządzeniu. Użytkownicy nadal proszą o gwarancje techniczne, które zapewnią, że stawki w PA API nie zostaną naruszone, oraz wyczerpujący tryb debugowania, który umożliwi wykrywanie incydentów w czasie rzeczywistym i skuteczne debugowanie.	Głównym celem Piaskownicy prywatności jest zapewnienie integralności aukcji interfejsu PA API, w tym zapobieganie potencjalnym atakom. Interfejs API został zaprojektowany z uwzględnieniem środków zapewniających integralność. Zapraszamy do dalszej technicznej dyskusji na temat konkretnych obaw. W maju 2024 r. przedstawiliśmy szczegółową listę potencjalnych ataków na interfejs PA API oraz nasze metody zapobiegania im podczas spotkania grupy społeczności W3C ds. zapobiegania oszustwom. Zachęcamy do dalszych dyskusji i przekazywania opinii na temat potencjalnych „ataków na stawki w interfejsie PA API”.
Ruch bez plików cookie	Czy będzie można włączyć interfejs PA API tylko w przypadku ruchu bez plików cookie na potrzeby testów lub w innych celach?	Technologia reklamowa może wykryć, czy występują 3PC. Szczegółowe informacje na ten temat znajdziesz tutaj.
Identyfikator miejsca	W przypadku propozycji Seat ID znajomość identyfikatora miejsca jest niezbędna w przypadku większości żądań stawek, co budzi obawy związane z połączeniem identyfikatora miejsca z rejestracją kreacji. Czy dotyczy to tylko „głównej reklamy”, czy też reklam komponentowych?	Propozycja BuyerAndSellerReportingId rozwiązuje problem braku identyfikatora miejsca kupującego podczas rejestracji kreacji dla reklamy głównej. Identyfikator ten służy do przekazywania sprzedawcy identyfikatora miejsca kupującego. Oceniamy obsługę reklam komponentów.
Monitorowanie i raportowanie	Prośba o dodanie funkcji monitorowania w czasie rzeczywistym (RTM) umożliwiającej: (1) wysyłanie raportów RTM o anulowanych aukcjach oraz (2) tworzenie nowych zbiorów wypełnianych przez przeglądarkę, aby wyraźnie wskazywać, jakiego rodzaju anulowanie miało miejsce.	Wygląda na to, że raportowanie typu RTM nie jest odpowiednim rozwiązaniem do badania współczynnika uczestnictwa. Interfejs RTM to interfejs API do monitorowania o niskiej latencji, który umożliwia wykrywanie krytycznych, nagłych i tymczasowych przerw w działaniu. W odróżnieniu od tego współczynnik udziału nie wymaga raportowania o niskiej latencji i nie jest krytycznym, nagłym, tymczasowym przestój. Wątpliwości dotyczące współczynników udziału w programie najlepiej rozwiewają sprzedawcy, z którymi współpracują kupujący, a nie kupujący, którzy sprawdzają informacje w przeglądarce. Co więcej, anulowane aukcje są bardzo częste, więc jeśli przeglądarka generowałaby raporty RTM po każdej anulowanej aukcji, mogłaby przytłoczyć raporty RTM dotyczące rzeczywistych przerw w działaniu.
Dokumentacja Uszczegółowienie	Zgłoszenie rozbieżności w dokumentacji interfejsu PA API (wyjaśnienie), która mówi, że wartość nonce powinna być ciągiem znaków UUID, ale zwraca obietnicę.	Tutaj znajdziesz wyjaśnienie.
Mrożony Kontekst	Jakie opcje są dostępne w przypadku pracy z zamrożonym kontekstem, aby rozwiązać problemy i wyzwania związane z (1) łączeniem, (2) bibliotekami zewnętrznymi i (3) nieobsługiwanymi typami danych?	Odpowiedź na to pytanie znajdziesz tutaj.
Dane techniczne	Do interfejsu Private Aggregation API dodano ogólną operację contributeToHistogramOnEvent. W konsekwencji definicja w interfejsie PA API stała się operacją przeciążoną, a operacje w interfejsie IDL sieci Web „nie mogą być przeciążone w całości interfejsu, częściowym interfejsie itd.”, więc ta definicja jest teraz nieprawidłowa.	Ten problem wskazuje na tymczasową niezgodność specyfikacji interfejsu PA API i Private Aggregation, ponieważ łączymy podobne zmiany w obu specyfikacjach. Aby rozwiązać ten problem, scaliliśmy prośbę o przeniesienie.
Grupy zainteresowań	Prośba o wskazanie zalecanej i efektywnej pod względem zasobów metody zakończenia udziału grupy zainteresowań (IG) w ustalaniu stawek po zakończeniu kampanii.	Oto kilka sugestii: Uważamy, że mechanizm o najkrótszym czasie oczekiwania, najmniej trwały, a także najmniejszy mechanizm uwalniający zasoby to korzystanie z sygnałów określania stawek w czasie rzeczywistym, aby informować generateBid() o zatrzymaniu określania stawek. Drugą opcją, która wykorzystuje mniej zasobów, jest ustawienie negatywnego priorytetu dla tego IG w odpowiedzi na sygnały ustalania stawek w czasie rzeczywistym, ponieważ generateBid() nie zostanie nawet wywołany. Trzecią opcją, która zużywa jeszcze mniej zasobów, jest usunięcie reklam z IG. IG bez reklam nie mają wywołanych generateBid(). Czwartym rozwiązaniem, które zużywa jeszcze mniej zasobów, jest usunięcie biddingLogicURL z IG. W tym momencie IG może zostać zaktualizowany lub ponownie dołączony, aby go reaktywować. Dodatkowe opcje dotyczą opuszczenia IG, np. za pomocą leaveAdInterestGroup() lub clearOriginJoinedAdInterestGroups() albo po wygaśnięciu IG. Jak już wspomnieliśmy, różne opcje różnią się pod względem opóźnień i zużycia zasobów. Dostawcy technologii reklamowych mogą wybrać opcję, która zapewnia najlepsze kompromisy w przypadku ich konkretnych zastosowań.
Odbiorcy	Prośba o mechanizm umożliwiający wykonywanie operacji logicznych na utworzonych listach odbiorców (np.możliwość kierowania na zbiór korespondencji list odbiorców A i B).	Dzięki interfejsowi PA API można obecnie wykonywać operacje logiczne na listach odbiorców z tego samego witryny. Z powodu ochrony prywatności, o której piszemy w naszych zasadach dotyczących prywatności, obecnie nie obsługujemy operacji logicznych dotyczących list odbiorców w różnych witrynach. Wciąż prowadzimy badania w tym zakresie i będziemy przekazywać wszelkie nowe informacje.
Propozycja nowej funkcji	Propozycja usunięcia ograniczenia dotyczącego dodatkowych stawek, które wymagają, aby TLS był znany z wyprzedzeniem.	Obecnie omawiamy tę propozycję tutaj i zapraszamy do dzielenia się opiniami.
Zaktualizowane podejście do 3 PC w Chrome	Czy interfejsy API Piaskownicy prywatności, takie jak interfejs PA API, będą ogólnie dostępne dla wszystkich użytkowników stabilnej wersji Chrome, czy też interfejsy API (lub ich podzbiór) będą dostępne tylko dla użytkowników, którzy odrzucili 3PC?	Nie chcemy, aby decyzja użytkownika o odmowie korzystania z 3PC miała wpływ na dostępność interfejsów API Piaskownicy prywatności w Chrome Stable.
Ulepszone sygnalizowanie	Czy planujecie dodanie funkcji, która wskazuje, czy TLS zamierza przeprowadzić aukcję interfejsu PA API?	Oceniamy możliwość obsługi tej funkcji. Więcej informacji na temat terminów podamy, gdy będą dostępne. Chętnie poznamy Twoją opinię na temat tego zgłoszenia.
ID oferty	Obawa, że wymaganie serwera KV w ofercie Identyfikator umowy może być kosztownym i czasochłonnym procesem po stronie serwera.	Propozycja identyfikatora umowy umożliwia SSP-om wysyłanie zapytań o metadane wybranych identyfikatorów umów do serwera klucz-wartość podczas aukcji automatyzacji gwarantowanej, dzięki czemu nie muszą wstępnie wczytywać wszystkich metadanych związanych z umową na urządzenie. Ta propozycja jest opracowywana w odpowiedzi na prośby dostawców usług płatnego dostępu do treści (SSP), a my chętnie poznamy opinie na temat tego rozwiązania tutaj. Zdajemy sobie sprawę, że konfiguracja serwera par klucz-wartość wymaga pracy, ale uważamy, że ogólnie jest to korzystne dla firm zajmujących się technologiami reklamowymi. Nadal chętnie przyjmujemy opinie i sugestie dotyczące tego, jak ułatwić ten proces.
Ograniczenie liczby wyświetleń w ramach usług Google	Prośba o ograniczenie liczby wyświetleń na użytkownika w Instagramie za pomocą interfejsu PA API.	Ograniczenie liczby wyświetleń w ramach usług w Google ma trudne do rozwiązania problemy związane z ochroną prywatności. Jeśli ta funkcja jest dla Ciebie ważna, prosimy o dodatkowe opinie na temat ekosystemu.
Raportowanie identyfikatorów umów i miejsc	Prośba o możliwość dodawania identyfikatorów ofert lub miejsc do raportowania zbiorczego.	Funkcja identyfikatora raportowania, nad którą pracujemy tutaj , umożliwi raportowanie identyfikatorów umów i miejsc. Wskaźnik selectedBuyerAndSellerReportingId jest przekazywany do funkcji reportResult(), więc najłatwiejszym sposobem raportowania jest raportowanie na poziomie zdarzenia (czyli zakodowanie identyfikatora umowy w adresie URL przekazanym do funkcji sendReportTo()). Można też użyć raportowania zbiorczego. Funkcja identyfikatora raportowania jest obecnie aktywna w przypadku 10% ruchu w Chrome w wersji stabilnej. Rozważamy rozszerzenie tej funkcji na 100%.
Grupy zainteresowań	Używaj tej samej kolejności priorytetów zarówno w przypadku wyboru, jak i oceny IG, a także we wszystkich trybach oceny.	Obecnie omawiamy tę kwestię tutaj i zapraszamy do dzielenia się opiniami.
Grupy zainteresowań	Sugerowanie korzystania z aktywności i delegowania odbiorców jako sposobu na zwiększenie stosowania interfejsów API Piaskownicy prywatności.	Wiemy o tej prośbie od wielu zainteresowanych stron i szukamy rozwiązania. Chętnie poznamy opinie na temat ekosystemu.
Grupy zainteresowań	Problemy związane z tworzeniem interfejsów API PA, zwłaszcza w zakresie delegowania i własności podczas działania w imieniu wielu kupujących lub w imieniu wydawców.	Otrzymaliśmy od wielu zainteresowanych stron prośbę o obsługę bardziej zaawansowanych delegacji IG. Uważamy, że dodanie do tego procesu SSP-ów przyniesie dodatkową wartość. Prowadzimy badania, aby znaleźć najlepsze rozwiązanie, które pozwoli różnym stronom uczestniczyć w procesie rozszerzania list odbiorców. Zapraszamy do dzielenia się opiniami na temat ekosystemu.
Wydajność po stronie klienta	Prośba o wskazania dotyczące ułatwienia buforowania sygnałów TrustedBidding po stronie klienta w celu optymalizacji kosztów infrastruktury i opóźnień	Obecnie omawiamy tę kwestię tutaj i zapraszamy do dzielenia się opiniami.

Protected Auction (B&A Services)

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Usługi kluczy-wartości	Jak grupowane są żądania z przeglądarki do serwera KV sprzedawcy? Jak będzie wyglądać żądanie z przeglądarki w przypadku sprzedawcy: GET czy POST? Dodatkowo potrzebne jest wyjaśnienie wymagań dotyczących k-anonimowości.	W przypadku wersji 1 Chrome wysyła żądanie GET do usługi KV sprzedawcy, aby pobrać trustedScoringSignalsURL z użyciem sygnałów w parametrach zapytania żądania. Parametry obejmują hostname, renderUrls, adComponentRenderUrls i experimentGroupId. Obecnie eksperymentujemy z kilkoma rozszerzeniami umożliwiającymi wysyłanie dodatkowych informacji na potrzeby skanowania kreacji, ale nie zostały one jeszcze wprowadzone. Jeśli ustawienie maxTrustedScoringSignalsURLLength ma wartość 0, Chrome może potencjalnie połączyć wszystkie sygnały w jednym żądaniu (co może spowodować przekroczenie limitu długości adresu URL na serwerze), ale nie jest to gwarantowane. Obecnie Chrome wybiera do tego samego zbioru żądania, które są gotowe do wysłania w ciągu 10 ms, ale pracujemy nad optymalizacją tego procesu. Podczas pracy z trustedScoringSignals warto pamiętać, że Chrome respektuje nagłówki buforowania. Nagłówki takie jak Stale-While-Revalidate „Cache-Control” mogą zmniejszyć średnie opóźnienie, umożliwiając Chrome korzystanie z kopii w buforze (i aktualizowanie bufora na potrzeby następnej aukcji), co skutecznie usuwa pobieranie sygnałów z ścieżki krytycznej. Na koniec, jeśli chodzi o k-anonimowość, wydaje się, że jedna sekcja artykułu jest nieaktualna. Pierwotnie wymagaliśmy, aby adresy URL zaufanych sygnałów były anonimowe, ale zrezygnowaliśmy z tego wymagania. Usuniemy to zdanie z treści wyjaśniających.
Usługi fuzji i przejęć	Przejście na najnowszą wersję B&A zajmuje dużo czasu. Przydałoby się skrócenie czasu kompilacji lub gotowe obrazy.	Dostawcy technologii reklamowych mogą samodzielnie tworzyć pliki binarne i weryfikować je za pomocą podanych haszy. W przyszłości rozważymy udostępnianie gotowych artefaktów lub skrócenie czasu kompilacji.
Prośba o funkcję interfejsu API	Prośba o zgodność z systemem macOS w przypadku skryptów kompilacji usług licytacji i aukcji (B&A), obrazów kontenera i narzędzi wywoływania, aby ułatwić rozwój i testowanie lokalnie.	Obecnie obsługujemy amd64, co wystarcza do wdrożenia na obsługiwanych platformach chmurowych (GCP i AWS). W przyszłości możemy zbadać obsługę innych architektur.
AWS	Czy w przypadku wersji produkcyjnych wymagane jest utworzenie ról uprawnień?	Tak. Role uprawnień są wymagane, aby zapewnić odpowiednie uprawnienia i komunikację z koordynatorami. Klucze te służą do odszyfrowywania szyfrogramu ProtectedAudienceInput, który jest generowany na urządzeniu zgodnie z opisem tutaj. Dodatkowo te role są wymagane do przejścia weryfikacji serwera/TEE kompilacji produkcyjnych z tymi samymi koordynatorami. Więcej informacji znajdziesz w przewodniku samoobsługowym.
Flagi B&A	Prośba o uwzględnienie w dokumentacji definicji dostępnych flag B&A. Obecnie definicje te znajdują się w kodzie Terraform, plikach cc i proto, ale specjaliści ds. technologii reklamowych mogliby skorzystać z dokumentacji dotyczącej tych flag, która posłużyłaby im jako źródło wiarygodnych informacji o tym, jak dostosować wdrożenia.	Badamy możliwość udokumentowania opisów flag w Terraform i zapraszamy do podzielenia się opinią tutaj.
AWS Usługa określania stawek	Potrzebuję wskazówek dotyczących usługi określania stawek w AWS oraz domyślnego zachowania i konfiguracji logowania.	Aby debugować usługi określania stawek w TEE (np. usługę określania stawek), zalecamy użycie debugowania z użyciem zgody Ad Tech. Dzięki temu możesz włączyć szczegółowe rejestrowanie i przechwytywać dane żądania/odpowiedzi dotyczące konkretnych żądań testowych bezpośrednio z klienta, co ułatwi debugowanie.
TEE K/V Dokumentacja	Prośba o wyjaśnienie dotyczące rozpoczęcia egzekwowania zasad dotyczących treści szkodliwych, jak stwierdzono na stronie dla deweloperów.	Powiadomimy Cię z wyprzedzeniem o wymaganiach dotyczących korzystania z etykietek TEE. Do tego czasu możesz nadal używać własnego serwera do przesyłania sygnałów klucz-wartość w czasie rzeczywistym.
Testowanie i analiza A/B	Analiza i testowanie B&A są kosztowne i nie wydają się gotowe do wdrożenia.	Aby dokładniej zbadać tę kwestię, potrzebujemy więcej informacji o analizie kosztów i czynnikach, które prowadzą do oceny gotowości do wdrożenia wersji produkcyjnej.
Trusted Server Optimization	Propozycja połączenia parametrów dotyczących sprzedawców komponentów w jeden parametr inputsPerSeller, którego wartość będzie łańcuchem JSON.	Rozważamy tę propozycję i zapraszamy do dzielenia się opiniami tutaj.
Bezpieczeństwo	Jak za pomocą B&A można ograniczyć zagrożenia dla bezpieczeństwa związane z usługami TKV?	Można uniemożliwić zewnętrzne połączenia z TKV. Obecnie jest to w pełni obsługiwane i konfigurowalne w GCP. W przypadku AWS należy opracować dodatkowe funkcje ze względu na wycofanie AWS App Mesh, które wcześniej umożliwiało to działanie. Tutaj możesz przesłać dodatkową opinię.
Usługi fuzji i przejęć	Prośba o wyjaśnienie narracji lub komunikacji dotyczącej wartości strumieniowego przesyłania danych przez HTTP w optymalizacji pod kątem konwersji.	Piaskownica prywatności obsługuje przesyłanie strumieniowe danych dotyczących rozmów z klientami, aby skrócić czas oczekiwania dla dostawców technologii reklamowych, którzy z niej skorzystają. Jest to opcjonalna optymalizacja skuteczności w przypadku trybu mieszanego.
Prebid	Prośba o aktualizacje dotyczące wkładu w bibliotekę open source Prebid, aby umożliwić korzystanie z funkcji B&A w PA API w ekosystemie	W marcu 2025 r. w stabilnej wersji Chrome uruchomiliśmy preferowaną optymalizację przed wyświetleniem reklamy, zgodnie z dokumentem publiczna ścieżka rozwoju B&A (patrz marzec 2025 r.).
kształtowanie ruchu,	Prośba o mechanizmy rejestrowania sygnałów kontekstowych otrzymywanych przez systemy Q&A, aby lepiej zrozumieć, kiedy aktywowane są interfejsy głosowe i jak ulepszać logikę „zamierzania się na stawkę” w odpowiedziach kontekstowych. Umożliwia to lepsze wykorzystanie zasobów sieciowych, aby uniknąć „niepotrzebnego ruchu” (czyli kształtowania ruchu).	Obecnie omawiamy propozycję tutaj i zapraszamy do podzielenia się opinią.
Dokumentacja Uszczegółowienie	Potrzebna jest informacja na temat błędu „Nie można uzyskać dostępu do serwera proxy usługi/Vsock” zauważonego podczas konfiguracji testowej integracji z B&A.	Wynika to z minimalnych wymagań dotyczących pamięci.Opis konfiguracji AWS został zaktualizowany, aby uwzględnić to wymaganie.

Pomiar skuteczności reklam cyfrowych

Attribution Reporting API (i inne interfejsy API)

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Dane w czasie rzeczywistym	Brak danych w czasie rzeczywistym ma wpływ na wszystkich w branży. Opóźnianie danych w czasie rzeczywistym jest poważnym problemem dla reklamodawców. Kupujący przenoszą się na platformy, które mają Google Analytics, ponieważ jest to jedyne miejsce, w którym mogą uzyskać potwierdzenie dotarcia do odbiorców.	Opóźnienia danych w czasie rzeczywistym, które są częścią interfejsu Attribution Reporting API (ARA), są wdrażane jako mechanizmy ochrony prywatności, aby ograniczyć możliwość korzystania przez technologie reklamowe z raportów na poziomie zdarzenia do śledzenia użytkowników w różnych witrynach. ARA zapewnia jednak elastyczność w sposobie dostarczania raportów atrybucji, ponieważ pozwala na ustawienie minimalnego 1-godzinnego okna raportowania dla raportów na poziomie zdarzenia oraz umożliwia natychmiastowe wysyłanie raportów zbiorczych do dostawców technologii reklamowych bez opóźnień.
Używanie API	Prośba o potwierdzenie prawidłowej konfiguracji przepływu atrybucji w aplikacji internetowej, zwłaszcza gdy równolegle działa atrybucja z witryny do witryny i z witryny do aplikacji.	Podczas równoległego prowadzenia kampanii internetowych i kampanii internetowych na rzecz aplikacji technologia reklamowa powinna wybrać tylko jedną platformę do rejestrowania każdego źródła lub każdego wyzwalacza, aby uniknąć podwójnego zliczania. Zdecydowanie zalecamy korzystanie z systemu operacyjnego (OS), ponieważ umożliwia on przypisywanie zarówno konwersji z sieci na sieć, jak i z sieci do aplikacji, o ile źródła i reguły internetowe zostały prawidłowo zadelegowane. Oznacza to, że w przypadku źródeł należy używać nagłówka Attribution-Reporting-Register-OS-Source, a w przypadku aktywatorów – nagłówka Attribution-Reporting-Register-OS-Trigger. Za pomocą nagłówka Attribution-Reporting-Support możesz sprawdzić, czy dostępna jest pomoc na poziomie Chrome lub Androida. Nagłówek Attribution-Reporting-Info jest przydatny, gdy w żądaniu nie ma nagłówka Attribution-Reporting-Support. W takim przypadku przeglądarka podejmuje decyzję o rejestracji platformy na podstawie dostępności obsługi platformy na urządzeniu użytkownika.
Specyfikacja interfejsu API	Uzyskanie wyjaśnień dotyczących nagłówka żądania HTTP Attribution-Reporting-Support ustawionego przez interfejs Attribution Reporting API oraz tego, czy nagłówek ma zawierać klucze web i os niezależnie od platformy.	Nagłówek Attribution-Reporting-Support jest dodawany przez przeglądarkę, która dodaje parametry „GREASE”, aby zapewnić, że serwery używają zgodnego ze specyfikacją parsarza nagłówków strukturalnych. W tym nagłówku należy interpretować tylko klucze słownika uporządkowanego. Wartości i parametry są obecnie nieużywane. Przykład znajdziesz tutaj.
Raporty oparte na 3PC	Prośba o wskazania, jak rozwiązać problemy z rozbieżnościami w danych ARA i 3PC w kampaniach reklamowych.	ARA obsługuje 2 typy raportów debugowania, które można wykorzystać do rozwiązywania problemów i rozwiązywania rozbieżności. Raporty debugowania atrybucji umożliwiają łatwe porównywanie wyników ARA z wynikami innych technologii pomiarowych, a rozwinięte raporty debugowania – uzyskiwanie dodatkowych informacji i rozwiązywanie potencjalnych problemów z rejestracją atrybucji.
Używanie API	Podczas testowania ARA wykryliśmy pewne problemy: niewystarczająco szczegółowe raporty, które powodowały niespójność danych i nieelastyczne optymalizowanie kampanii, wysokie progi wykluczające mniejszych reklamodawców oraz trudności w porównywaniu kampanii z powodu niespójności kluczowych wskaźników efektywności.	ARA zapewnia elastyczność dzięki wielu parametrom, które mogą być dostosowywane przez specjalistów ds. technologii reklamowych do konkretnych zastosowań pomiarów. Raporty na poziomie zdarzenia umożliwiają elastyczne raportowanie na poziomie zdarzenia, co pozwala specjalistom ds. technologii reklamowych dostosowywać okna raportowania, liczbę raportów, które mogą otrzymywać, oraz dane o wyzwalaczach, które chcą mierzyć. Dzięki temu mogą oni ograniczać wpływ szumu na dane i stosować raporty w różnych przypadkach użycia. Podobnie w przypadku raportów zbiorczych specjaliści ds. technologii reklamowych mogą dostosowywać ich konfigurację na różne sposoby, np. pod kątem liczby śledzonych wymiarów, częstotliwości łączenia danych i używania budżetu na udział, aby zmienić wpływ szumu i osiągnąć różne przypadki użycia.
Specyfikacja interfejsu API	Pytanie o zależność ARA od plików cookie innych firm, w szczególności o to, czy nadal wymagają one fazy testowania.	ARA jest włączona niezależnie od 3PC, ale 3PC muszą być włączone, aby umożliwić raportowanie przejściowe ARA w ramach debugowania, aby porównać wyniki ARA z wynikami przypisania na podstawie plików cookie.
Używanie API	Zapytanie dotyczące rejestrowania źródeł atrybucji aplikacji do witryny w starszych wersjach Androida (11, 12 i 13) za pomocą ARA	ARA jest obecnie obsługiwana na Androidzie S i nowszych (12 i nowszych).
Używanie API	Poproś o szczegółowe informacje o stawkach i rozpowszechnianiu ARA.	Nasza odpowiedź nie zmieniła się od poprzednich kwartałów: „Nie planujemy udostępniać tych informacji ekosystemowi. Deweloperzy mogą wywoływać interfejsy API, w których przypadku mają wdrożony kod, aby oszacować dostępność interfejsów API Piaskownicy prywatności”.
Dostępność interfejsu API	Gdy ARA jest włączona, czy 3PC są włączone, czy wyłączone?	Gdy w przeglądarce użytkownika jest włączona ARA, nie ma to wpływu na ustawienia plików cookie użytkownika. ARA może być włączona, a pliki cookie mogą być włączone lub wyłączone.
Raportowanie	Czy istnieje wstępnie zdefiniowana lista wartości, które możemy otrzymać w nagłówku „Attribution-reporting-support”?	Zgodnie z naszą instrukcją wartość jest strukturyzowanym słownikiem nagłówków, którego jedyną zdefiniowaną semantycznie cechą jest obecność lub brak kluczy web i OS. Pozostałe części nagłówka należy zignorować. Innymi słowy, parsowanie wymaga użycia parsowania nagłówka o strukturze, a nie prostego dopasowywania ciągu znaków.

Usługa do agregacji

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Propozycja nowej funkcji	Prośby o wprowadzenie funkcji w usłudze do agregacji: integracje serwer-serwer, pomiar na różnych urządzeniach, ułatwienie raportowania atrybucji i wkładu w ramach kampanii wielodotykowej, atrybucja na wielu kanałach oraz obsługa zaawansowanych pętli optymalizacji opartej na uczeniu maszynowym (np. Trenowanie modelu prywatnego).	Rozpatrujemy te prośby i przekażemy więcej informacji, gdy tylko to będzie możliwe. Zapraszamy do podzielenia się opinią na temat tego, czy te prośby powinny być traktowane priorytetowo.
Propozycja nowej funkcji	Prośba o ustawienie parametru EBS delete_on_termination na wartość Prawda w środowisku terraform, aby zmniejszyć obawy dotyczące resetowania podczas aktualizowania zbioru usług agregacji.	Rozpatrujemy tę prośbę i przekażemy więcej informacji, gdy tylko będzie to możliwe. Zapraszamy do podzielenia się opinią na temat tego, czy ta prośba powinna być traktowana priorytetowo tutaj.
Dokumentacja Uszczegółowienie	prośba o wskazanie, co można zmienić (np. progi monitorowania), a co powinno pozostać bez zmian;	Rozważamy opublikowanie dodatkowej dokumentacji i instrukcji dotyczących dostępnych opcji personalizacji usługi agregacji.
Wdrożenie	Prośba o wyjaśnienie dotyczące nowego wdrożenia, które nie działa w przypadku polecenia bazel.	Wdrożenie może się nie udać z powodu wersji bazel używanej w środowisku. Dokumentacja zostanie dostosowana tak, aby obejmować debugowanie w przypadku błędów Terraform, a także wskazywać wymaganą wersję bazel.

Interfejs Private Aggregation API

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Używanie API	prośba o wskazówki dotyczące niektórych problemów z wdrażaniem, takich jak potencjalna utrata danych z powodu zgłoszonych ograniczeń usługi Shared Storage, trudności związane z dużą mocą zbioru wymagającą skomplikowanych list dozwolonych usługi Aggregation Service (zalecane użycie symbolu wieloznacznego) oraz spowolnione testowanie spowodowane regułą „bez duplikatów” usługi Aggregation Service.	Jeśli chodzi o ograniczenia Shared Storage, limit 20 wkładów (szczegóły tutaj) dotyczy każdego wykonania, a nie miesiąca. Dodatkowo wywołujący interfejs API mogą zastąpić to ograniczenie. Limit ma pomóc w zarządzaniu kosztami przetwarzania raportów w usłudze agregującej, a nie ograniczać możliwości narzędzia do raportowania. Jeśli chodzi o zapytania z symbolami wieloznacznymi, analizujemy to żądanie i przekażemy więcej informacji, gdy tylko będzie to możliwe. W przypadku reguły „Brak duplikatów” tymczasowo obsługujemy tryb debugowania, aby umożliwić testowanie i ominięcie tej reguły. Szczegółowe informacje na ten temat znajdziesz tutaj .
Identyfikatory filtrowania i zbiory	Czy w ramach 2 oddzielnych sesji agregacji można wysłać do usługi agregacji żądanie dotyczące tego samego zasobnika z 2 różnymi identyfikatorami filtrowania? Czy identyfikator filtrowania może pełnić funkcję dodatkowego podziału domen?	Tak, ta funkcja jest obsługiwana. Podczas wykonywania agregacji przetwarzane są tylko dane z identyfikatorem filtra zgodnym z listą w parametrach zadania, a pozostałe pozostają dostępne do przetworzenia w oddzielnych wywołaniach.
Atrybucja uwzględniająca różne interakcje	Prośby o wyjaśnienie dotyczące wdrożenia atrybucji wielodostępnej: 1) Czy istnieje limit liczby udziałów, jeśli wartość agregacji nie przekracza 2^16? 2) Czy istnieje limit liczby unikalnych kluczy agregacji (zasobników), które można przechowywać w przypadku danego kontekstu? 3) Jak usługa do agregacji przetwarza raporty zbiorcze, gdy każdy agent użytkownika (przeglądarka) ma unikalny klucz agregacji, jak to ma miejsce w przypadku MTA?	1) Mamy domyślne limity udziału, ale wywołujący interfejs API może je zastąpić, jak wyjaśniono tutaj. Ich celem jest pomoc osobom wywołującym interfejs API w zarządzaniu kosztami przetwarzania raportów w usłudze agregującej. 2) Nie ma takiego limitu, ale dostawcy technologii reklamowych powinni wziąć pod uwagę szczegółowość kluczy agregacji, aby poprawić stosunek sygnału do szumu, co zostało wyjaśnione tutaj. 3) Zapoznaj się z tymi wskazówkami, zwłaszcza z informacjami dotyczącymi stosunku sygnału do szumu opisanym powyżej w punkcie 2.

Ograniczanie śledzenia ukrytego

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

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Propozycja nowej funkcji	Prośba o dodanie wskazówek klienta User-Agent (UA-CH) Sec-CH-UA-Robot, ponieważ pozwoli to serwerom rozpoznawać ruch automatyczny w celu dostosowania treści, bezpieczeństwa i analizy.	Jest to ważne zastosowanie, które jest omawiane w ramach innych grup standardów (więcej informacji znajdziesz tutaj ). Zachęcamy zainteresowane strony do udziału w tym procesie i przesłania opinii. Uważamy jednak, że UA-CH może nie być odpowiednim rozwiązaniem, ponieważ nagłówki żądań HTTP można łatwo manipulować za pomocą ruchu automatycznego.

Ochrona IP (dawniej Gnatcatcher)

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Prywatność adresu IP	Udostępnianie adresów IP firmie Google jest sprzeczne z jej deklarowanymi celami dotyczącymi ochrony prywatności. Chociaż Google twierdzi, że anonimizuje dane za pomocą ochrony adresu IP, użytkownicy muszą się zalogować w Chrome, aby korzystać z tej funkcji, więc Google i tak poznaje ich tożsamość.	Powody logowania są związane z zapobieganiem oszustwom i nadużyciami, głównie ograniczeniem szybkości dostępu do serwerów proxy. Co więcej, aby chronić prywatność użytkowników w kontekście wymagań dotyczących uwierzytelniania, nasz token jest podpisywany anonimowo, co oznacza, że token wydawany podczas logowania jest inny niż token używany podczas uwierzytelniania przez serwer proxy, a dlatego wydane tokeny nie mogą być później powiązane z tożsamością użytkownika w Google. Oznacza to, że Google nie wie, kim jest użytkownik, gdy jego ruch jest kierowany przez serwer proxy w trybie incognito, mimo wymagań uwierzytelniania ze względów związanych z zapobieganiem oszustwom.
Prywatność adresu IP	Korzystanie z adresów IP to krok w nieodpowiednim kierunku. Nie można ich usunąć z przeglądarki, tak jak plików cookie, a użytkownicy nie mają takich samych ustawień przejrzystości jak w przypadku plików cookie. Jeśli pliki cookie zostaną wycofane, branża zacznie używać adresów IP jako alternatywnego rozwiązania, stawiając na pierwszym miejscu ochronę przed utratą danych, a nie prywatność.	Chrome to platforma, która ma zapewniać użytkownikom funkcje poprawiające komfort przeglądania internetu. W przypadku użytkowników Chrome, którzy korzystają z trybu incognito, oznacza to zapewnienie lepszej ochrony przed śledzeniem w wielu witrynach przez ograniczenie dostępności informacji o adresach IP w kontekstach zewnętrznych.
Zamaskowana lista domen	Jakie są kryteria wyboru na liście zamaskowanych domen?	Chrome stosuje kryteria, aby określać, które domeny powinny być uwzględnione w MDL i które powinny otrzymywać zamaskowane adresy IP w kontekście zewnętrznym. Google nawiązało współpracę z Disconnect.me, firmą specjalizującą się w ochronie prywatności w internecie, która współpracuje też z innymi przeglądarkami internetowymi. Chrome będzie korzystać z usługi Disconnect.me, aby identyfikować domeny zgodne z określonymi przez Chrome kryteriami. Oprócz tego w Chrome opracowano metodę identyfikowania często używanych funkcji JavaScriptu, które zapewniają spójne dane wyjściowe z stabilnych interfejsów API o wysokiej entropii, dzięki czemu można ich używać do tworzenia identyfikatorów probabilistycznych o wysokiej entropii. Te funkcje są wykrywane, gdy są ładowane w witrynach w kontekście witryn innych firm. W efekcie powstaje lista domen, które udostępniają skrypty o tych właściwościach. Są one uwzględniane w liście domen MDL i dlatego są proxy. System wykrywania, który wykrywa te wzorce niewłaściwego użycia interfejsu API, uwzględnia wszystkie domeny, w tym domeny Google.
Zapobieganie oszustwom	Opinia dotycząca tokenów prawdopodobieństwa ujawnienia (PRT) o tym, że proponowany 24-godzinny czas oczekiwania na ujawnienie i częstotliwość ujawniania utrudniają wykrywanie oszustw w czasie rzeczywistym. poprosić o krótsze opóźnienia (1 godzina) i wyższe stawki (co najmniej dwucyfrowe). Dalsze sugestie obejmują stosowanie stawek różnicowych na podstawie sygnałów ryzyka (VPN-y, automatyczne przeglądarki) oraz umożliwianie ukierunkowanego ujawniania określonych tokenów.	Większość deweloperów, z którymi rozmawialiśmy, przesyła klientom raporty co godzinę, a kilku z nich aktualizuje listy blokowania adresów IP kilka razy dziennie. Krótszy okres opóźnienia umożliwia częstsze aktualizacje, a w przypadku czasu krótszego niż godzina ponownie włącza pomiar IVT w statystykach godzinowych, ale zwiększa też prawdopodobieństwo ponownej identyfikacji użytkowników. Jesteśmy otwarci na możliwość skrócenia okresów opóźnienia i zmiany szybkości ujawniania na podstawie badań ekosystemu oraz opinii zainteresowanych stron. Zachęcamy do dzielenia się opiniami tutaj.
Zamaskowana lista domen	Pytanie dotyczące umieszczenia domeny w MLD mimo braku przypadku użycia związanego z reklamami Obawa, że może to umożliwić „łączenie adresów IP” w celu tworzenia profili na podstawie adresów IP.	Zdajemy sobie sprawę, jak ważne jest wdrożenie procesu odwołań w przypadku naszego podejścia opartego na listach. Odwołania umożliwiają firmom zgłaszanie, że ich domena w MDL nie spełnia kryteriów włączenia i powinna zostać usunięta, co pozwoli tej domenie nadal otrzymywać oryginalne adresy IP użytkowników w kontekście innych firm w trybie incognito. Rozpoczęliśmy proces odwołań, aby dać właścicielom domen wystarczająco dużo czasu na złożenie odwołania i uzyskanie decyzji przed uruchomieniem ochrony IP w trybie incognito w wersji stabilnej Chrome. Więcej informacji o procesie odwołań znajdziesz tutaj.
Zamaskowana lista domen	opinie, że wydawcy sprawdzają konsekwencje włączenia ich partnerów do MDL; Zapewniliśmy ich, że zapisy dotyczące GeoIP w informacjach o ochronie adresów IP są wystarczające.	Chrome rozumie znaczenie obsługi przypadków użycia opartych na lokalizacji. Serwer proxy przypisze adresy IP, które odpowiadają przybliżonej lokalizacji użytkownika, w tym krajowi. Więcej informacji znajdziesz w artykule wyjaśniającym geolokalizację adresu IP.
Zamaskowana lista domen	Pytanie dotyczące MDL: czy kierowanie na kraj jest nadal dostępne.	Chrome rozumie znaczenie obsługi przypadków użycia opartych na lokalizacji. Serwer proxy przypisze adresy IP, które odpowiadają przybliżonej lokalizacji użytkownika, w tym krajowi. Więcej informacji znajdziesz w artykule wyjaśniającym geolokalizację adresu IP.
Wykrywanie oszustw	Obawy dotyczące wpływu ochrony adresu IP na systemy wykrywania oszustw. Czy użytkownicy zobaczą adresy IP serwera proxy lub nagłówek? Czy SSP-y i DSP-y będą widzieć ten sam adres IP serwera proxy w przypadku danego użycia? Niezgodności mogą wpływać na wykrywanie oszustw i OpenRTB.	Użytkownicy przeglądający strony w trybie incognito z włączoną ochroną adresu IP, którzy wysyłają żądania do domen w MDM, otrzymają adres IP serwera proxy na podstawie zdefiniowanego geofeeda. Organizacje mogą poprosić o przekazywanie identyfikatorów PRT jako dodatkowych nagłówków w przypadku ruchu z serwera proxy, gdzie po okresie opóźnienia można ujawnić niewielką próbkę oryginalnych adresów IP. Podejrzewamy, że wiele platform SSP będzie przekazywać adres IP serwera proxy w żądaniach stawek po stronie serwera do partnerów w zakresie popytu, ale nie ma gwarancji, że wygrane platformy DSP będą w momencie wyświetlenia znać ten sam adres IP serwera proxy.
Wykrywanie oszustw	Pytania dotyczące częstotliwości aktualizacji pliku z lokalizacją geograficzną adresu IP, harmonogramu aktualizacji informacji o zgłaszaniu nieuczciwego działania i zgłoszenia typu PRT oraz sposobu wykrywania nieuczciwych działań przez technologie reklamowe.	Informacje o protokołach PRT są dostępne, podobnie jak lista adresów IP serwerów proxy i ich mapowane regiony geograficzne. Zalecamy okresowe sprawdzanie tego pliku pod kątem aktualizacji i zmian, ponieważ adresy IP będą się zmieniać. Publiczny adres e-mail do zgłaszania nadużyć zostanie ogłoszony bliżej daty rozpoczęcia wdrażania.
Geolokalizacja	Prośba o publiczną listę adresów IP używanych do serwerów proxy.	Plik z mapowaniem adresów IP na przybliżone lokalizacje w przypadku ochrony adresów IP jest dostępny tutaj. Pamiętaj, że ten plik jest okresowo aktualizowany.
Używanie API	Twierdzenie, że ochrona adresu IP jest domyślnie włączona, a użytkownicy nie mogą zrezygnować z tej funkcji.	Ochrona adresu IP będzie dostępna dla użytkowników w trybie incognito w Chrome na platformach Android i komputerów. Użytkownicy będą mogli wyłączyć ochronę IP. W przypadku wersji Chrome zarządzanych przez firmę można włączyć ochronę IP, ale domyślnie jest ona wyłączona.
Używanie API	Zapytanie dotyczące dostępności flagi eksperymentalnej umożliwiającej włączenie i testowanie ochrony adresu IP w wersjach Chrome Canary i Beta.	Obecnie nie mamy flagi eksperymentalnej, która umożliwiłaby przetestowanie pełnej funkcji ochrony adresu IP. Eksperymenty funkcjonalne przeprowadzamy tylko w przypadku ruchu z serwerów proxy kierowanego do domen Google.
Prywatność adresu IP	Jak działają ustawienia promptów 3PC, gdy przeglądarka przechodzi w tryb incognito?	W trybie incognito 3 PC są domyślnie blokowane.
Tryb incognito	Użytkownik prosi o wyjaśnienie, czy ochrona adresu IP działa w trybie incognito, gdy użytkownik nie jest zalogowany w Chrome.	Ochrona adresu IP nie jest aktywna, jeśli użytkownik nie zaloguje się w Chrome przed uruchomieniem trybu incognito. Powodem jest zapobieganie oszustwom i nadużyciam, a precyzyjniej ograniczenie szybkości dostępu do serwerów proxy. Ochrona adresów IP będzie wykorzystywać uwierzytelnianie klienta, aby ograniczyć możliwość wykorzystywania przez osoby niepowołane serwerów proxy do wzmacniania ataków na usługi w mDL. Dlatego ochrona adresów IP będzie dostępna tylko dla użytkowników, którzy zostali uwierzytelnieni przy użyciu konta Google, na którym są zalogowani w przeglądarce Chrome przed otwarciem nowego okna incognito.
Tryb incognito	Prośby o ocenę wpływu ochrony adresu IP przed jej wdrożeniem, w tym: (1) Propozycja użycia flagi stanu przeglądarki lub zbiorczego raportowania interfejsu API w celu ilościowego określenia korzystania z trybu incognito; (2) Wysyłanie nagłówka ochrony adresu IP przez pewien czas przed włączeniem funkcji; (3) Wdrażanie funkcji w przypadku niewielkiego, znanego odsetka ruchu na potrzeby ekstrapolacji.	Zdajemy sobie sprawę, że uczestnicy ekosystemu chcą poznać i zmierzyć skalę oraz wpływ ochrony własności intelektualnej. Chrome stara się jednak zapewnić prywatność użytkownikom, którzy korzystają z trybu incognito. Chrome nie udostępnia metody wykrywania użytkowników przeglądających w trybie incognito i podejmuje działania mające na celu ograniczenie innych sygnałów, które mogą ujawnić tryb przeglądania użytkownika. Rozważamy sposoby ułatwienia testowania bez naruszania prywatności użytkowników przeglądających w trybie incognito i zapraszamy do dzielenia się opiniami na temat ekosystemu.

Łagodzenie śledzenia przekierowań

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Zgodność	Brak zgody Google na autoryzowanie stosowania techniki łagodzenia śledzenia porzuceń, która jest zgodna z przepisami o ochronie danych, nie ma podstaw prawnych i czyni bezcelowym proces odwoławczy w Privacy Sandbox.	Jak wyjaśniliśmy w poprzednim raporcie z opiniami, stan zgodności nie ma żadnego związku z wdrażaniem BTM, a Google nie podejmuje żadnych decyzji dotyczących zgodności z tym programem. BTM, podobnie jak inne funkcje ochrony prywatności w Chrome, skupia się na zwiększeniu kontroli użytkowników nad tym, czy i jakie dane są udostępniane. Proces odwołań zarządzany przez stronę trzecią, o którym mowa w raporcie CMA za II i III kwartał, dotyczy obszarów, w których Google podejmuje decyzje o włączeniu lub wykluczeniu poszczególnych firm z list.
Zgodność	Dyskusja na temat tego, jak przeglądarki zapewniają zgodność z wymaganiami prawnymi dotyczącymi zgody w kontekście RODO. Omówiono scenariusze, w których przeglądarki mogą pomijać działania (np. przekierowania lub ustawienia plików cookie), na które użytkownicy wyraźnie wyrazili zgodę, co powoduje konflikt między zgodą prawną a ustawieniami prywatności w przeglądarce.	Przeglądarka nie ma wglądu w charakter relacji między użytkownikiem a witryną. Poza tym w przypadku obecnego zachowania BTM istnieją już obejścia, które umożliwiają użytkownikowi wyraźne wyrażenie zgody na śledzenie odrzuceń z określonej witryny. Więcej informacji o zgodzie znajdziesz w najczęstszych pytaniach dotyczących zgodności z zasadami prywatności.
Miejsca o podwójnym przeznaczeniu	Czy można wyjaśnić, czy przejścia z WebView lub z aplikacji do przeglądarki (Chrome) będą uważane za „strony o podwójnym zastosowaniu” w ramach BTM?	Przeglądarka nie wie, czy łańcuch powrotów rozpoczął się od przejścia z komponentu WebView czy aplikacji. Dlatego BTM nie traktuje tych ścieżek w specjalny sposób. Zamiast tego interpretuje przepływ jako odrzucenie w innej witrynie, który zaczyna się od adresu „about:blank”, i działa zgodnie ze standardowymi zasadami.

Wzmacnianie granic prywatności między witrynami

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

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Używanie API	Obawy dotyczące potencjalnego nadużywania RWS w połączeniu z ochroną IP. Udostępnianie adresów IP organizacjom w ramach zbioru RWS może zachęcać organizacje do dołączania do wielu zbiorów RWS, aby uzyskać dostęp do przenośnych danych adresów IP na potrzeby śledzenia użytkowników w trybie incognito.	Wymagania dotyczące zestawów, powiązanych witryn i witryn usługowych oraz zestawów jako całości, które są egzekwowane przez automatyczne weryfikacje, ograniczają potencjalną motywację do łączenia wielu zestawów. Łączenie aktywności użytkowników w różnych zbiorach za pomocą adresów IP wymagałoby uwzględnienia w zbiorze domeny MDL, co wymaga koordynacji między właścicielem zbioru a właścicielem domeny. To samo ryzyko dotyczy pojedynczych witryn (czyli bez RWS) współpracujących z domenami MDL. Więcej informacji na ten temat znajdziesz tutaj.

Fenced Frames API

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Reklamy natywne	opinia, że obecnie stosowane ramki ograniczone są niezgodne z ich modelem biznesowym reklam natywnych, który wymaga elastycznego dostosowywania reklam do otaczających je treści;	Kontynuujemy ocenę potrzeb ekosystemu i obecnej oferty wydzielonych ramek. W każdym razie, jak już wspomnieliśmy, stosowanie ujęć ograniczonych będzie wymagane nie wcześniej niż w 2026 r.

Interfejs Shared Storage API

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Błąd interfejsu API	Raport, że Chrome rejestruje błąd, gdy mechanizm budżetowania interfejsu Shared Storage API uniemożliwia wykonanie operacji selectURL, mimo że jest to oczekiwane działanie. Poproś Chrome o obniżenie poziomu rejestrowania z błędu na ostrzeżenie lub informacje, ponieważ błąd nie wymaga działania po stronie wywołującego.	Ta zmiana została wprowadzona i uwzględniona w Chrome M134, dostępnej od 4 marca 2025 r.

CHIPS

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Dokumentacja API	Potrzebna jest informacja na temat zabezpieczeń oferowanych przez partycjonowane pliki cookie w porównaniu z plikami cookie SameSite=Lax/Strict. Sugerowanie, że dokumentacja powinna wyraźnie stwierdzać, że pliki cookie z partycjami nie zapewniają takiego samego poziomu ochrony przed atakami XSS i CSRF jak pliki cookie SameSite=Lax/Strict.	Zaktualizujemy wyjaśnienie i specyfikację, aby wyjaśnić semantykę i zabezpieczenia oferowane przez pliki cookie z partycjonowaniem.

FedCM

Motyw opinii	Podsumowanie	Odpowiedź Chrome
Interfejs użytkownika i bezpieczeństwo	Opinia: interfejs FedCM jest zbyt podobny do poprzedniej metody logowania się Google z jednym kliknięciem, trudno jest określić skuteczność FedCM z powodu braku śledzenia prezentacji w trybie pasywnym. Zalecamy też wzmocnienie języka dokumentacji w odniesieniu do PKCE.	Aktywnie współpracujemy z zainteresowanymi stronami, aby uwzględnić ich opinie. W ramach trwających dyskusji rozważamy sposoby udostępniania dostawcom tożsamości lepszych danych, które pozwolą im śledzić skuteczność FedCM, oraz możliwe ulepszenia, które umożliwią stosowanie FedCM w nowych przypadkach użycia związanych z subskrypcjami.
Używanie API	Gdy użytkownik odświeża stronę i wywołuje funkcję navigator.credentials.get, aby się zalogować, pojawia się wyskakujące okienko, w którym musi kliknąć, aby kontynuować. Spowoduje to opóźnienie, które wpłynie na komfort użytkownika. Czy strony trzecie mogą zapisać w pamięci podręcznej token zwracany przez navigator.credentials.get, aby zwiększyć wygodę użytkowników?	Reprezentanci mogą używać własnych plików cookie do przechowywania tokena. Przed wywołaniem navigator.credentials.get RP mogą sprawdzić swoje pliki cookie, aby określić, czy użytkownik jest zalogowany. Więcej informacji znajdziesz tutaj.
Wybór wielu dostawców tożsamości	Jak przeglądarka wyświetla opcje logowania się do wielu dostawców tożsamości (IdP) w FedCM?	Więcej informacji o wyświetlaniu wielu dostawców tożsamości znajdziesz w dokumentacji dla deweloperów. Zainteresowane strony mogą eksperymentować z tą funkcją, włączając flagę fedcm-multi-idp na stronie chrome://flags.
Przeglądarki i usługi uwierzytelniania	Czy przeglądarka, np. Chrome, może pełnić funkcję dostawcy tożsamości? Przeglądarki mogą używać zapisanych danych konta i profilu jako zaufanych źródeł uwierzytelniania.	Ponieważ przeglądarki można modyfikować (np. za pomocą rozszerzeń), bez dodatkowej weryfikacji na serwerze nie można ufać żadnym twierdzeniom o weryfikacji adresu e-mail dokonywanej bezpośrednio przez przeglądarkę. Dlatego nie zalecamy korzystania z rozwiązania opartego wyłącznie na kliencie. Więcej informacji na ten temat znajdziesz tutaj.
Specyfikacja interfejsu API	Dyskusja na temat tego, czy parametr algorytmu IdentityCredential.disconnect() powinien być wymagany czy opcjonalny.	Problem został już rozwiązany. Więcej informacji znajdziesz tutaj.
Bezpieczeństwo interfejsów API	Problemy z wyciekiem tokenów podczas procesu logowania sfederowanego, jeśli RP ma podatność na atak XSS. Atakujący może wykonać navigator.credentials.get w złośliwym kodzie, aby uzyskać token.	FedCM nie powoduje nowych zagrożeń XSS; te zagrożenia są nieodłącznym elementem aplikacji internetowych i dotychczasowych protokołów uwierzytelniania. Aby ograniczyć te zagrożenia, RP powinny weryfikować w tokenach ID żądanie aud i akceptować tylko oświadczenia wydane przez ich własne źródło. Jak już wspomnieliśmy tutaj, istnieją sprawdzone metody zabezpieczania wymiany tokenów, które można stosować w FedCM. Ponadto interfejs Storage Access API można używać z FedCM, a wywołania Storage Access API są automatycznie przyznawane, gdy wcześniej nastąpiło wywołanie FedCM. Powinna to umożliwić wdrożenie przekierowania omówionego w problemie na GitHubie.
Specyfikacja interfejsu API	W przypadku FedCM pole client_metadata_endpoint jest wymagane w odpowiedzi punktu końcowego konfiguracji. Pusty obiekt jest prawidłową odpowiedzią, a Chromium ignoruje odpowiedź 404, co sugeruje, że w praktyce punkt końcowy jest traktowany jako opcjonalny.	Zgadzamy się, że specyfikacja może zostać zmieniona, aby odzwierciedlić tę zmianę i uczynić z client_metadata_endpoint opcjonalne pole.
Używanie API	Obawy dotyczące trudności w testowaniu implementacji FedCM z powodu interfejsów sterowanych przez przeglądarkę, które nie są dostępne w DOM.	Do testów regresji używamy interfejsów API automatyzacji przeglądarki, które mogą rozwiązać te problemy. Dokumentację tych interfejsów API znajdziesz tutaj.
Specyfikacja interfejsu API	Parametr login_url, który jest wymaganą częścią odpowiedzi punktu końcowego konfiguracji, nie został udokumentowany w sekcji 3.2 specyfikacji.	Przesłaliśmy aktualizację dokumentacji, aby uwzględnić parametr login_url w sekcji 3.2.
Specyfikacja interfejsu API	Problem dotyczący potencjalnego wektora śledzenia w FedCM. IdP może wstawiać identyfikatory jako parametry ścieżki w punktach końcowych określonych w odpowiedzi punktu końcowego konfiguracji (accounts_endpoint, client_metadata_endpoint) i używać tych identyfikatorów do korelacji żądań metadanych konta i klienta.	Nie mamy dowodów na to, że dostawcy tożsamości wstawiają identyfikatory w tych punktach końcowych, ale aktywnie rozważamy sposoby złagodzenia tego problemu tutaj.

Walka ze spamem i oszustwami

Interfejs Private State Tokens API (i inne interfejsy API)

W tym kwartale nie otrzymaliśmy żadnych opinii.