Czwarty raport kwartalny z 2024 r. podsumowujący opinie na temat propozycji dotyczących Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wobec CMA Google zgodziło się na publikowanie kwartalnych raportów na temat procesu zaangażowania zainteresowanych stron w przypadku propozycji dotyczących Piaskownicy prywatności (patrz punkty 12 i 17(c)(ii) zobowiązań). Te raporty z opiniami na temat Piaskownicy prywatności są generowane przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii. Dotyczy to m.in. problemów na GitHubie, formularza opinii udostępnionego na stronie privacysandbox.com, spotkań z osobami zainteresowanymi w branży oraz forów dotyczących standardów internetowych. Chrome chętnie przyjmuje opinie z ekosystemu i aktywnie poszukuje sposobów na uwzględnienie wniosków w decyzji o projektowaniu.
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 kolejności malejącej. 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 pojawiły się w ramach zespołów wewnętrznych Google i publicznych formularzy.
W szczególności przejrzeliśmy protokoły spotkań organizacji zajmujących się standardami sieciowymi, a w przypadku bezpośrednich opinii – zapisy spotkań Google z osobami zainteresowanymi, e-maile otrzymane przez poszczególnych inżynierów, listy mailingowe interfejsów API oraz publiczny formularz opinii. Następnie Google skoordynowało działania zespołów biorących udział w różnych działaniach promocyjnych, aby określić względną częstotliwość występowania tematów związanych z poszczególnymi interfejsami API.
Wyjaśnienia dotyczące odpowiedzi Chrome na opinie zostały opracowane na podstawie opublikowanych najczęstszych pytań i odpowiedzi na problemy zgłoszone przez zainteresowane strony oraz określenia stanowiska w ramach tego publicznego raportu. W związku z obecnym kierunkiem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące głównie interfejsów API i technologii Topics, PA API oraz Attribution Reporting.
Ostatnio otrzymane opinie mogą jeszcze nie zawierać odpowiedzi 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
- 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 zależna
- 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
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zobowiązania | Sekcja G zobowiązań jest niezbędna do zapewnienia wykonalności Piaskownicy prywatności. Bez gwarancji, że własne usługi reklamowe Google będą działać wyłącznie na technologiach piaskownicy, rośnie ryzyko coraz mniejszej przydatności, a także możliwość wycofania się Google z tej technologii. Takie odsprzedanie lub ograniczenie użyteczności stanowiłoby zagrożenie dla adresowalności w ramach otwartej sieci internetowej, która kładzie nacisk na ochronę prywatności. | Zobowiązania nie gwarantują, że usługi reklamowe Google będą działać wyłącznie na podstawie technologii Piaskownicy prywatności. Google zamierza stosować podejście portfolio do adresowalności, które będzie obejmować technologie Piaskownicy prywatności, tak jak inne firmy. Zdajemy sobie sprawę, że podejście portfolio jest powszechne w ekosystemie reklam. Uważamy, że deweloperzy powinni mieć dostęp do narzędzi i technologii chroniących prywatność. Będziemy nadal udostępniać interfejsy API Piaskownicy prywatności i inwestować w nie, aby jeszcze bardziej zwiększyć ich prywatność i przydatność. |
| Zarządzanie | Proponowany model zarządzania nie obejmuje konkretnych mechanizmów odpowiedzialności w formalnych konsultacjach ani procesach odwoławczych. | To nie jest poprawna odpowiedź. Zarówno (i) system podejmowania decyzji i powiązane publikacje, jak i (ii) proces rozpatrywania odwołań zapewniają konkretne mechanizmy rozliczalności. Ponadto monitorujący powiernik będzie dokładnie nadzorować ich działanie. |
| Zarządzanie | opinia, że model nie zawiera postanowień dotyczących tworzenia i utrzymywania standardu międzyplatformowego; | Żaden model zarządzania nie może zmusić innych podmiotów, w tym przypadku przeglądarek, do przyjęcia standardu. Nie zaproponowaliśmy więc modelu, który wymagałby stosowania standardów na różnych platformach. Google będzie nadal uczestniczyć w forach dotyczących standardów, na których tworzenie propozycji i dzielenie się doświadczeniami z ich wdrażania jest częstym elementem procesu. |
| Zarządzanie | Zalecamy wydłużenie okresu konsultacji do co najmniej 2 miesięcy. Proponowany model zarządzania nie daje ekosystemowi wystarczająco dużo czasu na przeanalizowanie wpływu proponowanych zmian. | 3-tygodniowy okres nie jest całym okresem zbierania opinii na temat danej zmiany, ponieważ istniejące cykle opinii (które są znacznie dłuższe) będą kontynuowane. Proces konsultacji oferuje nowe, formalne okno na opinie w ramach dotychczasowego procesu podejmowania decyzji strategicznych. W związku z tym podczas tworzenia funkcji firmy zewnętrzne będą nadal mogły przekazywać opinie na różnych forach (w tym na GitHub, W3C i w organizacjach ustalających standardy reklam, takich jak IAB Tech Lab). Dzięki temu, że cykle opinii są tak skonstruowane, użytkownicy mogą analizować i przekazywać swoje opinie na temat proponowanych zmian bez znacznego opóźnienia w procesie rozwoju. |
| Zarządzanie | prośby o szczegółowe informacje o planach dotyczących zarządzania. | Podsumowanie proponowanego modelu zarządzania znajduje się w raporcie CMA za II/III kwartał 2024 r. (strony 3–5 tutaj). |
| Prośba o wyjątek | Prośba o wyjątek dotyczący dostępu do plików cookie innych firm (3PC) dla użytkowników, którzy wyrazili zgodę. | Wyrażenie zgody na dostęp do urządzenia i pamięci masowej w określonych celach przetwarzania danych nie oznacza, że użytkownik chce zastąpić ustawienie 3PC w Chrome. Zezwalanie na zastąpienie ustawień 3PC użytkownika na poziomie witryny mogłoby prowadzić do nadużyć, a Chrome nie byłby w stanie zbadać wszystkich zachowań witryn, które mogą prowadzić do wysłania prośby o wyjątek. |
| Piaskownica prywatności | Prośba o ustawienie interfejsu API Piaskownicy prywatności jako opcjonalnego. | Nie planujemy udostępniać tych informacji w ekosystemie. Programiści mogą wywoływać interfejsy API, w których mają wdrożony kod, aby oszacować dostępność interfejsów API Piaskownicy prywatności. |
| Wersja próbna origin | Czy planujesz przedłużyć okres próbny? | Testowanie wersji próbnej origin zostało przedłużone do 14 kwietnia 2025 r. |
| Piaskownica prywatności | Poproś o zwięzłe, nietechniczne wyjaśnienie Piaskownicy prywatności, które podkreśla jej wartość biznesową i zapewnia poparcie kierownictwa. | Niedawno dodaliśmy na stronie privacysandbox.com tutaj sekcję z informacjami dla firm. |
| Tryb B | Czy gdy przeglądarka jest w „trybie B”, obecny folder cookie (1PC, 3PC, pamięć lokalna) pozostanie czy zostanie wyczyszczony? | Bieżący zestaw plików cookie nie zostanie wyczyszczony. 3PC pozostaną dostępne w kontekście ich właścicieli. |
| Zaktualizowane podejście do 3 PC w Chrome | Czy w przyszłości 3PC zostaną całkowicie usunięte z Chrome? | Proponujemy zaktualizowane podejście, które rozszerza opcje wyboru użytkownika. Jak opisano tutaj, zamiast wycofywać 3 PC, wprowadzimy w Chrome nową funkcję, która pozwoli użytkownikom dokonać świadomego wyboru, który będzie miał zastosowanie podczas przeglądania internetu, i zmieniając który będą mogli w każdej chwili. Rozmawiamy o tej nowej opcji z organami regulacyjnymi i przed jej wdrożeniem skontaktujemy się z branżą. |
| Testowanie w Chrome | Prośba o dalszą dostępność etykiet testowania w Chrome. | Zespół Piaskownicy prywatności rozumie, że firmy chcą nadal używać etykiet wycofywania plików cookie. Proces przedłużania dostępności etykiet jest podobny do przedłużania wersji próbnej origin. W ramach tego procesu eksperyment może być przedłużony tylko o 3 milestones Chrome. Na przykład najnowszy eksperyment w Chrome (I2EE) dotyczący etykiet wycofania plików cookie został rozszerzony na wersje Chrome M130–M132 włącznie. Dzięki temu etykiety będą obsługiwane do czasu stabilnej wersji M133, która zostanie opublikowana na początku lutego. Dodatkowe rozszerzenia będą przechodzić przez ten sam proces, dlatego zalecamy śledzenie aktualizacji w grupie e-maili blink-dev. |
Rejestracja i potwierdzenie
W tym kwartale nie otrzymaliśmy żadnych opinii.
Wyświetlanie odpowiednich treści i reklam
Tematy
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Dane techniczne | Czy model klasyfikatora jest udostępniany na Androida (według nazwy aplikacji) i Chrome (według nazwy hosta)? | Nie, są to osobne modele, ponieważ mają różne taksonomie. |
| Szczegółowość taksonomii Topics | Tematy są zbyt ogólne, aby można było ich używać z informacjami własnymi. | Taksonomia Topics ma na celu zapewnienie równowagi między użytecznością a prywatnością. Chociaż przeanalizowaliśmy możliwe mechanizmy, które pozwoliłyby na bardziej szczegółowe określenie tematów, ostatecznie zrezygnowaliśmy z tego pomysłu ze względu na bezpieczeństwo i prywatność. Technologia reklamowa może przynieść najlepsze wyniki dzięki połączeniu wszystkich dostępnych narzędzi, takich jak uczenie maszynowe i sygnały chroniące prywatność pochodzące z interfejsów API chroniących prywatność, z danymi kontekstowymi, danymi kreacji i danymi własnymi. Więcej informacji na ten temat znajdziesz tutaj. |
| Używanie API | Interfejs Topics API ma niski zasięg. | Typowe przyczyny niskiej pokrycia: - Ustawienia użytkownika lub rezygnacja z usług - Ustawienia wydawcy lub rezygnacja z usług - Kryteria kwalifikowania witryn (następujące witryny nie są kwalifikowane do Topics: niezabezpieczone witryny, WebView, Chrome na iOS i tryb incognito) - Ograniczenia dotyczące użytkowników (użytkownicy Chrome, którzy nie ukończyli 18 roku życia lub korzystają z trybu incognito, nie mogą być obserwowani i przypisywani do Topics) - Wymagania dotyczące obserwacji sprzedawcy (wywołujący musi wcześniej widzieć użytkownika w witrynie powiązanej z kwalifikowalnym tematem) - Czas od wdrożenia (okres około 4 tygodni na zwiększenie skali obserwacji wywołującego) |
| Używanie API | Prośba o informacje na temat interfejsu Topics API, ponieważ karta Networking wskazuje, że wywołanie zostało wysłane i przechwycone, ale chrome://topics-internals/ nie pokazuje zarejestrowanego obserwatora. | Gdy do interakcji z interfejsem Topics API używasz mechanizmu nagłówka HTTP, tematy są wysyłane w nagłówku żądania Sec-Browsing-Topics, ale są obserwowane tylko wtedy, gdy serwer odpowiada nagłówkiem Observe-Browsing-Topics: ?1. Szczegółowe informacje na ten temat znajdziesz tutaj. |
| Udział w Chromium | Czy w przypadku komputerów stacjonarnych Chrome będzie udostępniać innym przeglądarkom opartym na Chromium ten sam kontekst obserwacji i rankingu? Czy w przypadku urządzeń mobilnych przeglądarka Chrome na Androida będzie udostępniać innym przeglądarkom na Androida opartym na Chromium / Chromium In-App ten sam kontekst obserwacji i rankingu? |
Chrome nie udostępnia danych o tematach innym przeglądarkom na urządzeniu. |
| Dane techniczne | W jaki sposób interfejs Topics API określa, czy wyświetlenie strony przez użytkownika jest uznawane za „element historii tematów”? | Aby można było uwzględnić tematy tygodniowe, wizyta na stronie musi zawierać wywołanie „obserwacji” (może być od dowolnego dzwoniącego). Bez wywołania „obserwuj” wizyta nie zostanie uwzględniona w historii tematu. |
| Bezpieczeństwo | Jak interfejs Topics API zapobiega udostępnianiu obserwowanych tematów przez jednego wywołującego innym wywołującym? | Wyjaśnienie znajdziesz tutaj. |
| Taksonomia | Jak jest używana taksonomia struktury drzewa w interfejsie Topics API w obserwacji w każdej epoce? | Podczas obliczania 5 najpopularniejszych tematów uwzględniane są tylko oryginalne tematy dostarczone przez klasyfikator, a rankingi są określane na podstawie (i) częstotliwości odwiedzin strony oraz (ii) wyniku priorytetyzacji (patrz specyfikacja). Podczas obliczania liczby obserwacji poszczególnych 5 najpopularniejszych tematów uwzględniane są osoby, które obserwowały temat główny lub którykolwiek z jego tematów pochodnych. |
| Dane techniczne | Prośba o dodatkowe informacje dotyczące 5% losowego szumu w odpowiedzi. | W każdej epoce jest zawsze 5 najpopularniejszych tematów. Jeśli historia przeglądania nie zawiera 5 tematów, tematy są wybierane losowo, aż będzie ich 5. Nazywamy je tematami z dodatkowymi treściami. Użytkownicy nie otrzymają żadnego z tych losowo dodanych tematów, chyba że w ostatnich tygodniach obserwowaliśmy (wywoływaliśmy interfejs API) użytkownika w witrynie z danym tematem. Gdy wywołujesz interfejs API, obliczany jest hasz na podstawie użytkownika, witryny i epoki. Jeśli ten ciąg znaków jest mniejszy niż prawdopodobieństwo zwrócenia tematu z dodanym szumem, zwracany jest losowy temat na podstawie użytkownika, witryny i ery. Jednak temat z dodanymi szumem zwracany jest tylko wtedy (czyli nie jest filtrowany), gdy wywołujący zaobserwował odpowiadający mu temat bez dodanego szumu dla danego użytkownika/witryny/epoki (patrz wyjaśnienie). Dzięki temu filtrowaniu tematy z szumem są zwracane w 5% przypadków, gdy dzwoniący wywołuje dany temat, niezależnie od jego zdolności obserwacyjnych. |
| Dane techniczne | Jak działają zduplikowane tematy w różnych tygodniach? Czy interfejs API wybiera niezależnie poszczególne tygodnie, a potem je scala? | Tematy z każdego tygodnia (ery) są obliczane niezależnie. Temat wybrany do zwrócenia z każdej epoki zależy od witryny, na której znajduje się wywołujący. Nie bierzemy pod uwagę faktu, że dany temat może być powtarzany w przypadku różnych wywołań (dlatego warto wybrać inny temat), ale chętnie poznamy Twoją opinię na ten temat tutaj. |
Protected Audience API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Testy A/B | Rozwiązanie Shared Storage opisane tutaj zwiększa opóźnienie i ma wysoki współczynnik błędów (czyli znaczna część ruchu kończy się bez identyfikatora populacji). Identyfikator o niskiej entropii (np. 3 bity) może wystarczyć do skutecznego testowania A/B bez znaczącego wpływu na prywatność. | Uważamy, że rozwiązanie w postaci wspólnego miejsca na dane jest nadal możliwe do zastosowania, ale rozważamy tę prośbę i zapraszamy do podzielenia się opinią na temat tego rozwiązania w ekosystemie, jeśli jest ono dla Ciebie szczególnie ważne. |
| Raportowanie | Prośba o dodatkowe bity w interfejsie reportWin(), zwłaszcza że nowe raportowanie kliknięć i wyświetleń w interfejsie PA API będzie używać 6–8 bitów, co znacznie ograniczy liczbę pozostałych bitów dostępnych dla innych raportów PA API. |
Ze względu na kwestie związane z ochroną prywatności nie rozważamy już zwiększenia liczby bitów sygnałów modelowania poza obecne 12 bitów. Zapraszamy do podzielenia się opinią na temat naszej propozycji dotyczącej prywatnego trenowania modeli, która ma na celu wspieranie potrzeb związanych z trenowaniem ML w bezpiecznym środowisku bez limitu bitów narzuconego przez Piaskownicę prywatności. |
| Grupy zainteresowań | Prośba o 90-dniowy cykl życia grup zainteresowań (IG), ponieważ 30 dni to za krótko. | Jak wspomnieliśmy w poście na blogu, planujemy wydłużyć okres ważności identyfikatora IG do 90 dni. Tutaj znajdziesz więcej informacji na ten temat. Pracujemy obecnie nad wdrożeniem tej funkcji i udostępnimy harmonogram jej wprowadzenia, gdy tylko będzie to możliwe. |
| Grupy zainteresowań | Prośba o dynamiczne aktualizacje w przypadku przekazania do IG | Wiemy o tej prośbie od wielu zainteresowanych stron i badamy możliwości jej rozwiązania. Będziemy udostępniać informacje na temat postępów na GitHubie i zapraszamy do dzielenia się opiniami na temat tego ekosystemu. |
| Na urządzeniu | wykazywać większą wartość dla całego ekosystemu, aby zachęcić do dalszych inwestycji w rozwiązania interfejsów API PA na urządzeniu; | Zespół Piaskownicy prywatności nadal rozwija interfejsy API oparte na technologii zwiększającej prywatność (PET), w tym interfejs PA API, aby zapewnić deweloperom więcej opcji ochrony prywatności w przeglądarce. Te technologie są obecnie dostępne w większości przeglądarek Chrome (nie tylko w 1%, jak niektórzy deweloperzy błędnie twierdzą). Niezależnie od tego, czy użytkownicy włączą 3PC, deweloperzy mogą stosować w swoich produktach rozwiązania oparte na PET, podobnie jak wiele firm decyduje się na stosowanie innych rozwiązań opartych na PET poza przeglądarką. Wielu deweloperów korzysta już z inwestowania w rozwiązania interfejsu API na urządzeniu, które umożliwiają rozszerzenie deterministycznego sygnału o własne listy odbiorców i tym samym zwiększenie zasięgu w różnych witrynach. Zdajemy sobie sprawę, że niektórzy deweloperzy zdecydują się na korzystanie z interfejsów API Piaskownicy prywatności lub innych rozwiązań opartych na technologii PET dopiero wtedy, gdy więcej przeglądarek nie będzie już obsługiwać technologii 3PC. Deweloperzy czekają na informacje, które pozwolą im oszacować, ile przeglądarek będzie nadal obsługiwać 3PC. Zdajemy sobie sprawę, że deweloperzy będą czekać, aż znajdą potrzebne informacje, aby podjąć decyzję dotyczącą usługi. |
| Grupy zainteresowań | Zezwalanie dostawcom SSP na udział w tworzeniu IG i powiązanych z nim rolach. Usługodawcy SSP uważają, że jest to ważny element ich wartości dodanej, i chcą pomagać wydawcom w sprzedaży IG za pomocą swoich usług. | Otrzymaliśmy od wielu zainteresowanych stron prośbę o obsługę bardziej zaawansowanych delegowaniach w ramach IG. Uważamy, że SSP mogą w tym procesie dodać wartość. Pracujemy nad znalezieniem najlepszego rozwiązania, które pozwoli różnym stronom uczestniczyć w procesie rozszerzania list odbiorców. Będziemy publikować nowe informacje na GitHubie w miarę ich pojawiania się i zapraszamy do dzielenia się opiniami na temat tego ekosystemu. |
| Raportowanie | rozbieżności między liczbą raportów „stawki inne niż zero” w interfejsach forDebuggingOnly i Private Aggregation API; | Spodziewamy się rozbieżności z 2 przyczyn: po pierwsze, tryb debugowania interfejsu Private Aggregation API jest dostępny tylko wtedy, gdy na urządzeniu są dozwolone 3 PC, podczas gdy interfejs forDebuggingOnly API jest zawsze dostępny w wersji niepróbkowanej (to ostatnie zachowanie wkrótce się zmieni, jak opisano tutaj). Po drugie: interfejs Private Aggregation API ma limity udziału, a interfejs forDebuggingOnly nie. Jednak te informacje wskazują, że nieoczekiwana rozbieżność może być spowodowana czymś innym. Współpracujemy z osobami spoza Google nad rozwiązaniem tego problemu. |
| Klikalność | Jak wspomniano w zaktualizowanej propozycji sygnału klikalności, wyświetlenia i kliknięcia byłyby rejestrowane przez zwrócenie nowego nagłówka odpowiedzi HTTP na żądania zainicjowane przez odpowiedni atrybut „attributionsrc”, a ten nagłówek odpowiedzi zawierałby listę źródeł, które można wykorzystać do wskazania, które inne strony mogą uwzględnić te wyświetlenia i kliknięcia w swoich zbiorczych statystykach. Czy to oznacza, że technologia reklamowa może dowolnie ustawiać pochodzenie? | W opisie klikalności podano, że technologia reklamowa, która przekazuje do zliczonego wyświetlenia i liczby kliknięć zdarzenie wyświetlenia lub kliknięcia (tzw. „źródło przekazujące”), może uwzględnić w nagłówku odpowiedzi opcjonalny parametr, który umożliwia podanie „jednego lub większej liczby źródeł właściciela IG, dla których to zdarzenie może być uwzględnione w obliczonej liczbie wyświetleń i kliknięć, które zostaną przekazane do wywołań generateBid() w aukcjach z użyciem chronionych danych użytkowników” („kwalifikujące się źródła”).Jednak te wyświetlenia i kliknięcia nie są automatycznie uwzględniane w liczbie wyświetleń i kliknięć. Każda technologia reklamowa musi w swoich wywołaniach generateBid() określić zestaw „źródeł wyświetleń i kliknięć”, z których mają być uwzględniane zdarzenia wyświetleń i kliknięć. Do liczby wyświetleń i kliknięć podawanych w wywołaniach generateBid() tej technologii reklamowej będą się zaliczać tylko dane z tych źródeł.Ten mechanizm wymaga zgody obu stron i zapobiega temu, aby złośliwi gracze wpływali na liczbę wyświetleń i kliknięć innych firm technologicznych zajmujących się reklamą. Oznacza to też, że „dostarczająca” technologia reklamowa, która arbitralnie ustawia „kwalifikujące się źródła”, nie będzie mieć wpływu na liczbę wyświetleń i kliknięć tych kwalifikujących się źródeł, chyba że te kwalifikujące się źródła wyraźnie i celowo uwzględnią to źródło w swoim IG. |
| Trenowanie prywatnego modelu | W niektórych przypadkach metoda DP-SGD (prywatność różnicowa – stochastyczny spadek wzdłuż gradientu) może znacznie spowolnić proces trenowania, ponieważ niszczy rzadkość gradientów obliczanych podczas wstecznego propagowania. Czy rozważasz jakieś techniki radzenia sobie z tym problemem lub masz na ten temat jakieś przemyślenia? | Znamy niektóre techniki, które umożliwiają zachowanie rzadkości w DP-SGD (np. tę), i rozważamy możliwość obsługi tego typu technik w ramach prywatnej infrastruktury do trenowania modeli. Będziemy udostępniać informacje na bieżąco. Zachęcamy do dzielenia się opiniami tutaj. |
| Kierowanie wykluczające | Prośba o aktualne informacje na temat wdrażania funkcji filtrowania negatywnych opinii w Instagramie opisanej tutaj. | Jak wspomnieliśmy w odpowiedzi tutaj, planujemy uwzględnić negatywne IG w stawkach w interfejsie PA API. Gdy tylko będzie to możliwe, podamy harmonogram wprowadzania tej funkcji. Zachęcamy do dzielenia się opiniami tutaj. |
| Określanie stawek | Czy podczas określania stawek można łączyć wiele IG? | Obecnie nie jest to możliwe za pomocą interfejsu PA API. Interfejs PA API opiera się na założeniu, że identyfikator IG odnosi się do informacji o użytkowniku, które są dostępne w jednej witrynie. Było to kluczowe założenie w rozmowach z całym ekosystemem. Takie podejście pozwala firmom technologicznym zajmującym się reklamami tworzyć różne rozwiązania, które pomagają reklamodawcom poszerzać zasięg własnych list odbiorców w internecie. Jesteśmy świadomi, że propozycja interfejsu Ads Selection API firmy Microsoft proponuje inny projekt, w którym listy odbiorców są tworzone na podstawie informacji z różnych witryn. Będziemy nadal monitorować ich podejście, ale zanim wprowadzimy podobne zmiany w Chrome, chcielibyśmy przeprowadzić więcej rozmów z ekosystemem, w tym z społecznością zajmującą się ochroną prywatności. |
| Reklamy natywne | Obawy dotyczące tego, czy interfejs PA API może odpowiednio obsługiwać różne formaty i wymagania renderowania reklam natywnych oraz czy interfejs PA API umożliwia elastyczność kreacji i optymalizację potrzebną do skutecznego wyświetlania reklam natywnych. | Aktywnie pracujemy nad rozszerzeniem obsługi reklam natywnych i zapraszamy do dzielenia się opiniami na temat tego ekosystemu. |
| Raportowanie | Prośba o zwiększenie odporności skryptów raportowania, które konkurują o zasoby ze skryptami ustalania stawek i mogą zostać utracone, gdy użytkownik przejdzie do innego okna aukcji. | Mamy nadzieję, że wkrótce opublikujemy odpowiedź na GitHubie, ale nie sądzę, aby te problemy miały znaczący wpływ na prawidłowe raportowanie. |
| Zastępowanie makro | Zastąpienia makro przekazane przez konfigurację aukcji nie działają w przypadku niektórych konfiguracji zewnętrznych. | Główną przyczyną było to, że ta funkcja nie była włączona w przypadku całego ruchu oznaczonego jako „Tryb A/B”. Niedawno zdecydowaliśmy się włączyć tę funkcję (oraz inne funkcje w tej samej sytuacji) we wszystkich ruchach oznaczonych jako „Mode A/B”. Spodziewamy się, że ta zmiana zostanie wprowadzona w I kwartale 2025 r. Dodatkowe opinie możesz przesłać tutaj. |
| Dokumentacja | Prośba o wyjaśnienie, ponieważ w dokumentacji występuje rozbieżność dotycząca jednostki miary wartości recency w obiekcie browserSignals w komponencie generateBid(). |
Szczegółowe informacje na ten temat znajdziesz tutaj. Odpowiednio zaktualizowaliśmy naszą dokumentację. Prawidłowa odpowiedź to milisekundy. |
| 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ą. | Obecnie rozważamy tę prośbę o funkcję tutaj i zapraszamy do dzielenia się opiniami. |
| Grupy zainteresowań | Prośba o wskazanie, jak dynamicznie wykluczać kupujących w grupach zainteresowań podczas korzystania z równoległych przepływów pracy dotyczących aukcji grup zainteresowań | Więcej informacji na ten temat znajdziesz tutaj. |
| Reklamy natywne | Niezależne aukcje interfejsu PA API dla danego wczytania strony uniemożliwiają filtrowanie reklam na tej samej stronie. | Dalsze rozszerzenie obsługi reklam natywnych, w tym widżetów z rekomendacjami, które są określane jako „natywne” i zawierają wiele reklam w jednej jednostce, jest obecnie przedmiotem naszych badań. Zdajemy sobie sprawę, że obecna konstrukcja może nie obsługiwać filtrowania reklam na tej samej stronie, a inne zabezpieczenia, takie jak ramki ograniczone, mogą dodatkowo uniemożliwiać to. |
| Reklamy natywne | Dotychczasowe funkcje PA API, takie jak skanowanie kreacji, raportowanie itp., które opierają się na sygnałach opartych na adresie URL, mogą wymagać dostosowania do obsługi obiektów JSON używanych w natywnej treści reklamowej. | Dalsze rozszerzanie obsługi reklam natywnych jest obecnie przedmiotem naszych badań. Oceniamy też, czy można dostosować interfejs PA API, aby ułatwić renderowanie reklam natywnych. |
| Weryfikacja reklam | Bezpieczeństwo marki w przypadku zewnętrznych dostawców treści w interfejsie PA API jest ograniczone z powodu opóźnień i ograniczeń w przypadku pamięci podręcznej w przypadku sygnałów perBuyerSignals, co powoduje problemy w przypadku treści dynamicznych. | Zdajemy sobie sprawę, że dostawcy SSP i DSP muszą określić optymalny czas przechowywania w pamięci podręcznej, który równoważy cele związane z kierowaniem ruchu i maksymalny czas przechowywania w pamięci podręcznej w celu zapewnienia bezpieczeństwa marki. Badamy ten problem i będziemy informować o jego postępach. |
| Weryfikacja reklam | Zastąpienie makra FullpageURL przez SSP jest wymagane do przeprowadzenia pomiaru bezpieczeństwa marki po ustaleniu stawek. | deprecatedReplaceInURN to obecnie zalecana metoda przekazywania tego sygnału przez SSP-y. |
| Weryfikacja reklam | Brak standaryzacji formatów makr używanych przez SSP do weryfikacji po licytacji może powodować niespójności i błędy w przetwarzaniu i analizie danych. | Platformy SSP i weryfikatory reklam powinni współpracować bezpośrednio, aby określić jasne wytyczne i specyfikacje dotyczące korzystania z makr, co pozwoli na ujednolicenie formatów makro na platformach SSP, zapewni spójność i uniknięcie błędów w przetwarzaniu i analizie danych. To zadanie, do którego najlepiej nadają się organizacje ustalające standardy reklamowe, takie jak IAB Tech Lab. |
| Weryfikacja reklam | Reklamodawcy i weryfikatorzy reklam potrzebują mechanizmu łączenia weryfikacji przed i po ustaleniu stawki w tym samym kontekście wydawcy na potrzeby debugowania i rozwiązywania problemów. | Jedną z opcji weryfikacji po ustaleniu stawki jest wykorzystanie sygnałów dotyczących aukcji i kampanii uwzględnionych w raportach na poziomie zdarzenia. Może to umożliwić złączanie z dziennikami decyzji przed ustaleniem stawki. Sprawdzamy możliwe wzorce, które mogłyby do tego doprowadzić, i będziemy informować o ich rozwoju. |
| Weryfikacja reklam | Prośba o zbadanie rozwiązań serwera z usługami Trusted Key-Value (TKV) (należących do DSP i Ad Verifiera) na potrzeby określania stawek przedokreślonych i radzenia sobie z ograniczeniami dotyczącymi ramek wydzielonych w przypadku określania stawek pookreślonych. | Rozpatrujemy to żądanie i zapraszamy do podzielenia się dodatkowymi opiniami na temat ekosystemu tutaj. Pomoże nam to znaleźć rozwiązanie, które umożliwi weryfikację bezpieczeństwa marki przed ustaleniem stawki i ułatwia koordynację między stronami. |
| Reklamy natywne | Prośba o audyt renderowania reklam natywnych po ustaleniu stawek po stronie sprzedającego | Dalsze rozszerzanie obsługi reklam natywnych jest przedmiotem naszych badań, a naszą uwagę zwracamy na to, jak dostosować istniejące funkcje, takie jak ta, do wspomagania renderowania reklam natywnych. |
Protected Auction (B&A Services)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Czas oczekiwania | Nie zastosowano odpowiednich środków zaradczych w sprawie czasu oczekiwania. Chociaż usługi B&A mogą w długim okresie czasu ograniczyć ten problem, Google nie zobowiązało się do zapewnienia ich powszechnej dostępności przed wprowadzeniem zmian w Chrome dotyczących 3 PC. | W ostatnich kwartałach wprowadziliśmy kilka ulepszeń dotyczących opóźnień na urządzeniu. W miarę potrzeby tworzymy i rozwijamy też usługi dotyczące odpowiedzi na pytania. 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 znajdziesz tutaj. |
| (także w poprzednich kwartałach) Bezpieczeństwo aukcji |
Prośba o dodatkowe wyjaśnienia dotyczące metod zapobiegania próbom manipulowania aukcją na urządzeniu lub ograniczania ich skutków (np. czy Google uważa to za istotne zagrożenie). | Odpowiedź jest taka sama jak w poprzednich kwartałach: „Mechanizmy raportowania reklam w PA API zachowują informacje służące do odróżniania ruchu generowanego przez ludzi od ruchu generowanego przez boty. Ponadto w PA API można stosować obecne techniki uwzględniania i wykluczania domen oparte na domenach. Szczegółowe informacje na ten temat znajdziesz w naszej odpowiedzi na raport IAB Tech Lab na temat Piaskownicy prywatności. |
| Rozwiązania lokalne | Obawy, że dostawcy o największym zasięgu mogą nie wdrożyć Piaskownicy prywatności ani B&A ze względu na brak obsługi chmury prywatnej oraz długą i nieprzejrzytą mapę drogową dotyczącą jej obsługi. | Chcemy rozszerzać infrastrukturę, na której działają usługi Piaskownica prywatności. Niedawno ogłosiliśmy obsługę chmury Azure i nadal szukamy możliwych rozwiązań, które zapewniłyby podobne zabezpieczenia prywatności i bezpieczeństwa w chmurach prywatnych. Od października, kiedy wysłaliśmy naszą informację, poczyniliśmy postępy w badaniu potencjalnych metod ochrony prywatności użytkowników Chrome w zaufanym środowisku wykonawczym (TEE) na urządzeniu lokalnym. Jesteśmy obecnie na etapie badań, na którym chcemy sprawdzić różne podejścia z udziałem zainteresowanych stron ekosystemu. W I kwartale tego roku zamierzamy zacząć zbierać opinie. Opinie i współpraca w ramach ekosystemu pomogą nam udoskonalić możliwe rozwiązania. |
| Testowanie | Czy można tworzyć TEE na potrzeby testowania rozwiązań do raportowania interfejsu PA API (raportowanie w czasie rzeczywistym i prywatna agregacja)? | Do testowania usługi agregującej dostawcy technologii reklamowych mogą używać danych testowych i narzędzi do testowania lokalnego, aby generować raporty podsumowujące do testów funkcjonalnych. Zapoznaj się z Codelab dotyczącym testowania lokalnego tutaj. Aby przetestować funkcję agregacji w TEE, specjaliści ds. technologii reklamowych muszą przejść proces rejestracji, o którym mowa w wymaganiach wstępnych Codelab. Tutaj możesz przesłać dodatkową opinię na temat tej prośby . |
| Integracja z danymi umowy | Prośba o możliwość pobierania informacji o umowach z KV na potrzeby zastosowań biznesowych. | Analizujemy tę prośbę o dodanie funkcji i przekażemy nowe informacje na GitHub. |
| No-win Deal Measure |
Prośba o sygnał lub możliwość określenia, kiedy dostawca usług SSP nie wygrał aukcji i dlaczego. | Rozpatrujemy tę prośbę i przekażemy nowe informacje na GitHub. |
| Propozycja nowej funkcji | Prośba o udostępnienie przez Piaskownicę prywatności struktury słownika, która ułatwi dopasowanie grupy reklam do odpowiedniego zbioru identyfikatorów ofert. | Rozpatrujemy to zgłoszenie, a także inne sposoby zmniejszenia rozmiaru IG w odniesieniu do przechowywania identyfikatorów transakcji. Poinformujemy Cię o tym na GitHubie. |
| Wyniki | Rozwiązania umożliwiające pomiar niewykorzystanych możliwości w aukcji reklam, prawdopodobnie z powodu rozmiaru skryptu ustalania stawek. | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj. |
| Dane techniczne | Obecnie B&A odczytuje tylko pole prevWins, a nie najnowsze pole prevWinMs, które zastąpiło pole prevWins w specyfikacji. | To prawda, że B&A nie przekazuje do generatebid() czasu trwania w milisekundach w prevWins. Chrome wysyła czas trwania w sekundach, aby zmniejszyć obciążenie danych. Poprawka polega na tym, że B&A przekształca sekundy w milisekundy. B&A przekazywałyby w browserSignals zarówno prevWins, jak i prevWinsMs, aby zapewnić zgodność z aukcjami na urządzeniu.Nawet w przypadku aukcji na urządzeniu w internecie wartości prevWins i prevWinsMs są takie same, a wartość prevWinsMs = prevWins * 1000. Pracujemy nad rozwiązaniem problemu. |
| Dokumentacja | Dokumentacja nie zawiera jasnych wskazówek dotyczących testowania interfejsu użytkownika sprzedawcy. Przydałoby się dodatkowe wyjaśnienie testowania zaraz po zakończeniu wdrażania, a także informacji o tym, jak używać Bazel do kompilacji. | To ćwiczenie z programowania zostało opublikowane jako przewodnik, aby ułatwić szerszemu ekosystemowi testowanie SFEs. |
| Wdrożenie | Czy planujecie udostępnić gotowe pliki binarne dla B&A? | Rozważamy udostępnienie gotowych plików binarnych do testów B&A, ale nie mamy jeszcze konkretnego harmonogramu. Do tego czasu dostawcy technologii reklamowych mogą samodzielnie tworzyć pliki binarne i weryfikować je za pomocą podanych haszy. |
| Wdrożenie | Czy obsługiwane powinny być wszystkie typy orkiestracji (serwer, klient, mieszane) czy jeden z nich powinien mieć wyższy priorytet? | Nie mamy żadnych konkretnych zaleceń dotyczących trybów implementacji technologii reklamowych. Wybór zależy od różnych czynników, ale ostatecznie sprowadza się do tego, co jest w najlepszym interesie klientów. |
| Testowanie | Prośba o wyjaśnienie dotyczące nieudanych testów podczas kompilacji wersji B&A. | Może to być spowodowane niestabilnością testu. Poinformowaliśmy dostawcę technologii reklamowych, że musi użyć flagi --no-tests we wszystkich poleceniach build_and_test_all_in_docker dotyczących kompilacji, aby pominąć uruchamianie testów. |
| Logi | Uzyskanie wyjaśnienia, dlaczego logy w eksploratorze logów w GCP są otagowane do instancji maszyny wirtualnej, która uruchamia SFE w trybie testowym, ale w trybie produkcyjnym logy nie są otagowane do instancji maszyny wirtualnej. | Trudno jest to uogólnić, ponieważ zależy to od tego, co dokładnie zostało zauważone, ale ogólnie: - logi z non_prod to prawdopodobnie stderr przekierowane przez dostawcę chmury (w tym przypadku GCP), a GCP dodał tag. - Dzienniki tworzone przez maszynę wirtualną są zwykle oznaczane etykietą instancji maszyny wirtualnej, podczas gdy dzienniki tworzone przez plik binarny nie są oznaczane przez GCP. – dzienniki z wersji produkcyjnej są eksportowane przez Open Telemetry w formacie TEE i mają inne tagi. Oto szczegółowe informacje o tym, co jest dostępne w gałęzi non_prod i prod. |
| B&A | Błąd 403 z powodu braku tajnych informacji, gdy rejestrowanie OTEL jest wyłączone. | Problem został rozwiązany w wersji 4.1 i odpowiednio zaktualizowano dokumentację. |
| B&A | Brakujący plik outputs.tf w konfiguracji terraform w GCP powoduje błąd. | Problem został już rozwiązany. |
| Testowanie | Błąd podczas pobierania klucza prywatnego w trybie testowym. | W takich przypadkach upewnij się, że serwery działają z wartością TEST_MODE=true. Tutaj znajdziesz wyjaśnienie. |
| Plan działań | Czy w przypadku funkcji getInterestGroupAdAuctionData są planowane zmiany, które umożliwią akceptowanie więcej niż 1 źródła sprzedawcy i zwracanie mapy źródła sprzedawcy w postaci zaszyfrowanej zawartości B&A? | Tak, planujemy dodać obsługę funkcji navigator.getInterestGroupAdAuctionData(), która będzie przyjmować dane od wielu sprzedawców. |
| Specyfikacja KV | Czy adres URL KV (trustedScoringSignalsURL) może być dostarczony jako obietnica? | Więcej informacji znajdziesz tutaj. |
| B&A | Prośba o utworzenie nowego nagłówka platformy, aby wskazać sprzedawcy, jakie funkcje wymaga klient (przeglądarka), aby można było przeprowadzić aukcję prywatną. | Obecnie rozważamy tę prośbę o funkcję tutaj i zapraszamy do dzielenia się opiniami. |
| kształtowanie ruchu, | Proponujemy obniżenie dodatkowych kosztów hostingu serwerów B&A, zwłaszcza w przypadku platform DSP. | Obecnie omawiamy tę propozycję tutaj i zapraszamy do dzielenia się opiniami. |
| Bring-Your- Own-Binary |
Rozważ zaktualizowanie opisu, aby wyraźnie wskazać, że obsługiwane są wszystkie pliki binarne. | Ta sekcja została już zaktualizowana. Więcej informacji znajdziesz tutaj. |
| Połączenia KV | Czy funkcja generateBid() czeka na zakończenie wszystkich wywołań magazynu klucz-wartość, czy działa niezależnie? Jak grupowanie elementów KV wpływa na ich czas wyświetlania? |
Więcej informacji znajdziesz tutaj. |
| Wyniki | Prośba o dodatkowe informacje o ponownym używaniu skryptów ustalania stawek i zalecanie ustawiania nagłówków kontroli pamięci podręcznej w przypadku skryptów | Dokumentację dodano tutaj. |
| Wyniki | Prośba o rozważenie i przetestowanie możliwości ładowania zasobów (np. skryptów ustalania stawek) w sposób asynchroniczny w celu zmniejszenia opóźnienia aukcji na urządzeniu. | Obecnie rozważamy tę prośbę o funkcję tutaj i zapraszamy do dzielenia się opiniami. |
| Rejestrowanie zgody | Potrzebna jest pomoc w rozstrzyganiu błędu, który występuje podczas próby użycia rejestrowania zgody przez ustawienie parametru CONSENTED_DEBUG_TOKEN. | W takich przypadkach sprawdź, czy w Menedżerze tajnych danych jest obecny parametr CONSENTED_DEBUG_TOKEN, czy parametr ENABLE_OTEL_BASED_LOGGING ma wartość true, a parametr TELEMETRY_CONFIG ma wartość mode: PROD. Zobacz wyjaśnienie tutaj, które odwołuje się do źródła tutaj. |
| Logi | Czy zdarzenia forDebuggingOnly są dostępne w sekcji Pytania i odpowiedzi? | Opcja forDebuggingOnly w przypadku aukcji z jednym sprzedawcą jest dostępna od kwietnia 2024 r. Planujemy wkrótce udostępnić tę funkcję w aukcjach wielosprzedawców. |
| Logi workletu | Prośba o zgodność rejestrowania workletów z ChromeDriverem | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj. |
Pomiar skuteczności reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Raporty debugowania | W jaki sposób raporty debugowania ARA będą dostępne dla specjalistów ds. reklam po wprowadzeniu zaktualizowanego podejścia do 3PC w Chrome? Czy dostawcy technologii reklamowej powinni mieć dostęp do raportów ARA Debug Reports w przypadku użytkowników, którzy zachowali 3 PC i mają włączone interfejsy API Piaskownicy prywatności? |
Firmy technologiczne zajmujące się reklamami będą mieć dostęp do rozwiązań do debugowania opartych na plikach cookie i bez plików cookie w przypadku użytkowników, którzy mają włączone zarówno 3 PC, jak i ARA. Gdy pliki cookie są wyłączone, mają dostęp tylko do ogólnego rozwiązania do debugowania. Więcej informacji o rozwiązaniach do debugowania znajdziesz tutaj i tutaj. |
| Wykrywanie cech | prośba o wskazanie sposobu wykrywania funkcji ARA po stronie serwera; | Obecnie obsługę funkcji ARA można określić na podstawie wersji Chrome widocznej w ciągu znaków klienta użytkownika. Chętnie poznamy opinie na temat tego problemu. |
| Propozycja nowej funkcji | Prośba o to, aby kolumna source_registration_time używana w ARA Aggregate shared_info była bardziej szczegółowa, np. zaokrąglana do godziny lub minuty (zamiast do dnia), a także konfigurowalna pod kątem uwzględniania strefy czasowej (obecnie tylko UTC). | Zaokrąglanie pola source_registration_time do najbliższego dnia jest mechanizmem ochrony prywatności, który ogranicza możliwość powiązania konkretnego użytkownika z konkretną rejestracją źródła. Obecnie parametr source_registration_time jest obliczany według czasu UTC, a firma zajmująca się technologią reklamową może odpowiednio dostosować swoje raporty reklamowe. Zapraszamy do podzielenia się opinią na temat tego zgłoszenia tutaj. |
| Dane techniczne | Prośba o wyjaśnienie specyfikacji parametrów „trigger_data” i „priority”, zwłaszcza gdy są one używane z wartością tablicy. | Te pola nie akceptują wartości tablicowych. Kwadratowe nawiasy w tłumaczeniu nie oznaczają tablicy, ale wskazują, że tekst nie jest przykładową wartością, tylko zmienną z opisem. Jak sugeruje tekst w nawiasach kwadratowych: – trigger_data to typ int-64 – priority to typ podpisany int-64 Żadne z tych pól nie akceptuje wartości tablicy. Warto też skorzystać z narzędzia do sprawdzania nagłówków w ARA, aby eksperymentować z różnymi wartościami i wykrywać błędy, jeśli dokumentacja jest niezrozumiała. |
| Obsługa reklam na przyspieszonych stronach mobilnych (AMP) | Czy ARA obsługuje reklamy AMP? | Naszą propozycję dotyczącą obsługi AMP znajdziesz tutaj. Zachęcamy do przesyłania dodatkowych opinii. |
| Dane techniczne | Który adres URL będzie uważany za „source-site” w przypadku reklam wbudowanych wielowarstwowych w ramach ARA? | Adres URL witryny najwyższego poziomu. |
| (także w poprzednich kwartałach) Prośba o dodanie funkcji |
Prośba o obniżenie minimalnej wartości atrybutu event_report_window z 3600 sekund (1 godzina) do 1800 sekund (30 minut). | Określanie minimalnego okna raportowania wymaga zrównoważenia kwestii związanych z użytecznością i prywatnością. Minimalne 1-godzinne okno raportowania na poziomie zdarzenia jest niezbędne do zachowania prywatności i ograniczenia pewnych rodzajów ataków polegających na odtwarzaniu historii. Tutaj możesz przesłać dodatkową opinię na temat tego zgłoszenia . |
| Szum | Uzyskanie lepszego zrozumienia tego, jak w raportach ARA na poziomie zdarzenia jest implementowany szum, aby zapewnić prawidłowe interpretowanie i wykorzystywanie danych. | Więcej informacji znajdziesz tutaj i tutaj. |
| Raportowanie | Dane shared_info w raportach zbiorczych nie zawierają już domyślnie kolumny source_registration_time. | Wynika to ze zmian w interfejsie API. Więcej informacji znajdziesz tutaj. |
| Raportowanie | Na karcie „Aggregatable Reports” (Raporty agregowane) w interfejsie chrome://attribution-internals/ nie ma elementu filtering_id. |
filtering_id jest obecnie widoczny w szczegółach karty „Reguły wyzwalające” po kliknięciu wiersza. Umożliwia to potwierdzenie jego ważności. Zdajemy sobie sprawę, że wyświetlanie tej informacji na karcie „Raporty podlegające agregacji” jest przydatne, dlatego omówiliśmy to tutaj. |
| Źródło atrybucji | Prośba o wyjaśnienie działania źródła atrybucji | Wyjaśnienie znajdziesz tutaj. |
| Atrybucja z aplikacji do witryny | Prośba o wskazania dotyczące implementacji, w przypadku których nie wiadomo, czy źródła będą pochodzić z systemu operacyjnego czy z sieci. | Wskazówki znajdziesz tutaj. |
Usługa do agregacji
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Propozycja nowej funkcji | Prośba o możliwość konfigurowania limitu czasu dla AgS lub o lepszą widoczność stanu zadania w przypadku długotrwałego wykonywania. | Rozważamy wprowadzenie funkcji, które umożliwią monitorowanie długotrwałych zadań. Chętnie poznamy opinie na temat tego problemu. |
| Terraform | Terraform próbuje zmodyfikować zasady uprawnień konta, nawet jeśli nie jest ustawiona lista service_account_token_creator_list. | Deweloperzy mogą dodawać uprawnienia w pliku local/modules/adtech_setup/main.tf. |
| Prośba o dokumentację | Poproś o dokumentację lub Codelab wyjaśniający, jak monitorować stan usługi agregacji. | Opis istniejących alarmów, które można używać do monitorowania stanu usługi i zadania, znajdziesz w odpowiednich plikach operatora terraform (alarms.tf i monitoring.tf) w repozytorium coordinator-services-and-shared-libraries. Opublikujemy dodatkową dokumentację i wskazówki dotyczące monitorowania zadań usługi agregacji. |
| Skalowanie | Jak monitorować problemy ze skalowaniem? | Opublikowaliśmy zaktualizowaną wersję tych wskazówek, która opisuje większą skalę usługi agregacji. Obecnie nie ma bezpośredniego sygnału wskazującego na to, że wystąpił błąd, ponieważ maszyna nie może obsłużyć projektu. Sygnały pośrednie to m.in. 90% wykorzystania pamięci przed wystąpieniem błędu oraz zadanie, które nieustannie się nie udaje. Zachęcamy do przekazywania opinii na temat potrzeby wprowadzenia takiego sygnału. |
| Dane techniczne | Jaki jest typowy czas przetwarzania partii raportów AgS? | Zapoznaj się ze wskazówkami tutaj. |
Interfejs Private Aggregation API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Propozycja nowej funkcji | Prośba o zezwolenie na przekazywanie wartości zmiennoprzecinkowych (w tym ujemnych) do funkcji contributeToHistogramOnEvent z czułością 2^16 | Obecnie omawiamy tę propozycję tutaj i zapraszamy do dzielenia się opiniami. |
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 |
|---|---|---|
| Geolokalizacja | Plik z geolokalizacją do ochrony adresu IP. | Plik z przybliżonym podziałem na regiony, który służy do ochrony adresów IP, jest dostępny tutaj. Pamiętaj, że ten plik jest okresowo aktualizowany. |
Łagodzenie śledzenia przekierowań
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Lista dozwolonych | Zmieniona opinia nie dotyczy już listy dozwolonych lub podobnych mechanizmów, które byłyby niezależne od procesu podejmowania decyzji przez Google. | Google nie planuje tworzenia żadnych list dozwolonych związanych z ograniczeniem śledzenia porzuconych sesji. Zabezpieczenia są stosowane równomiernie we wszystkich domenach. |
| Zgodność | Urząd ochrony danych powinien mieć uprawnienia w zakresie zgodności z zasadami ochrony prywatności. | Stan zgodności nie ma związku z wdrażaniem BTM, a Google nie podejmuje żadnych decyzji dotyczących zgodności z tymi zasadami. |
| Konkurencja | Wygląda na to, że Google może wykluczyć konkurentów w zakresie technologii PET, stosując metodę BTM (lub inne środki), a następnie zdecydować, czy zezwolić im na powrót na rynek. Obecny proces odwołań może tymczasowo uniemożliwić konkurentom w zakresie usług telekomunikacyjnych korzystanie z BTM lub podobnych środków. | Obecna propozycja BTM dotyczy śledzenia powrotów jako techniki. Chociaż Google stara się unikać naruszania pewnych przypadków użycia, które mogą obejmować podobne techniki, nie planujemy udzielać indywidualnych wyjątków od zasad BTM. W związku z tym nie ma mowy o tym, że Google ma prawo do podejmowania decyzji dotyczących obecności konkurencji. |
Wzmocnienie granic prywatności między witrynami
Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (raportowane również w poprzednich kwartałach) Limit domen w przypadku zestawów powiązanych witryn |
Obecny limit 5 powiązanych domen nie jest wystarczająco wysoki, aby można było stosować pomiary w wielu witrynach. | Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: Obecnie nie planujemy zwiększać limitu liczbowego. Limit został ustalony na podstawie ochrony prywatności użytkowników, opinii interesariuszy ekosystemu w W3C oraz analizy porównywalnych 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. Tutaj możesz przesłać dodatkową opinię na temat tego problemu . |
Fenced Frames API
Interfejs Shared Storage API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Używanie API | Interfejs Shared Storage API jest niedostępny na niektórych urządzeniach, gdy inne interfejsy API Piaskownicy prywatności działają. | Takie zachowanie jest oczekiwane w przypadku małej grupy użytkowników (około 1%), którzy biorą udział w eksperymencie z miejscem na dane w chmurze. Ten eksperymentalny zestaw służy do oceny skuteczności i wdrażania interfejsów API w różnych scenariuszach. |
| Używanie API | Czy operacje zapisu do Shared Storage są wykonywane z uprawnieniami wydawcy czy skryptu ustalania stawek? Wstępne testy wykazały, że nie dochodziło do zapisów, gdy źródło wydawcy różniło się od źródła skryptu. | Ten problem został rozwiązany i pozostanie otwarty tylko w przypadku możliwego błędu w narzędziach programistycznych. Więcej informacji znajdziesz tutaj. Wspólna pamięć zapisuje dane w źródle kupującego w kontekście określania stawek w wywołaniu generateBid. Zapisy nie są powiązane z pochodzeniem wydawcy, nawet jeśli strona wydawcy znajduje się w innej domenie. |
| Używanie API | Jakie zabezpieczenia chronią przed możliwością odczytania raportów z Udostępnionego miejsca na dane przez osoby niepowołane? | Pamięć współdzielona jest dzielona na partycje przez wywołanie źródła, aby osoby niepowołane lub technologia reklamowa nie mogły odczytać danych z pamięci współdzielonej z innej technologii reklamowej. Raporty prywatnej agregacji są wysyłane bezpośrednio do tego samego źródła za pomocą protokołu TLS, dzięki czemu nie można ich przechwycić. |
CHIPS
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Pliki cookie podzielone na części | W Chrome i Firefoksie pliki cookie są obsługiwane w niejednolity sposób w różnych portach localhost, zwłaszcza przy użyciu atrybutu Partitioned. | Firefox traktuje localhost z różnymi portami jako oddzielne klucze partycji. Chociaż takie działanie jest zgodne z zasadami bezpieczeństwa, odbiega od specyfikacji i podejścia Chrome. Zamierzamy omówić tę kwestię z innymi przeglądarkami w ramach dyskusji na temat specyfikacji HTML. Poinformujemy ekosystem, jeśli dojdzie do zmiany klucza partycji CHIPS. Zachęcamy do przesyłania dodatkowych opinii na ten temat tutaj. |
| Pliki cookie podzielone na części | Wersja robocza polecenia clear-site-data nieprawidłowo zezwala na usunięcie danych poza partycją witryny, która je emituje, co jest sprzeczne z wcześniejszymi dyskusjami, do których linki znajdują się tutaj. | To błąd w dokumencie ze specyfikacją standardów, który chcemy wkrótce naprawić. Właściwe działanie jest opisane w tej sekcji poradnika i jest zgodne z działaniem innych przeglądarek w repozytorium poradnika podziału pamięci. Implementacja w Chrome działa już prawidłowo. |
FedCM
W tym kwartale nie otrzymaliśmy żadnych opinii.
zwalczanie spamu i oszustw,
Interfejs Private State Token API (i inne interfejsy API)
W tym kwartale nie otrzymaliśmy żadnych opinii.