Raport z opiniami – II kwartał 2025 r.

Raport kwartalny za II kwartał 2025 r. podsumowujący opinie ekosystemu na temat propozycji dotyczących Piaskownicy prywatności i odpowiedzi Chrome.

Google przygotowała ten raport kwartalny w ramach zobowiązań wobec Urzędu ds. Konkurencji i Rynków (Competition and Markets Authority, „CMA”) zgodnie z art. 12, 17(c)(ii) i 32(a). Raport ten zawiera informacje o postępach Google w zakresie propozycji dotyczących Piaskownicy prywatności, zaktualizowane oczekiwania dotyczące harmonogramu, szczegółowe wyjaśnienia, jak Google uwzględniło uwagi zgłoszone przez inne firmy, oraz podsumowanie interakcji między Google a CMA, w tym opinie CMA i podejście Google do ich uwzględniania.

Google regularnie informuje CMA o postępach w zakresie propozycji dotyczących Piaskownicy prywatności podczas spotkań dotyczących stanu prac, które są organizowane zgodnie z punktem 17(b) Zobowiązań. Zespół prowadzi też dokumentację dla deweloperów, w której znajdziesz omówienie podstawowych funkcji reklam prywatnych i zmian dotyczących plików cookie, a także informacje o implementacji interfejsu API i stanie. Kluczowe aktualizacje są publikowane na blogu dla deweloperów, a także udostępniane na listach adresowych poszczególnych deweloperów.

Uwzględnianie uwag zgłoszonych przez osoby trzecie

Słowniczek akronimów

ARA
Attribution Reporting API
CHIPS
Pliki cookie z niezależnym stanem partycjonowania
(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
Wersja próbna origin
PA API
Protected Audience API (dawniej FLEDGE)
PatCG
Private Advertising Technology Community Group
RP
Jednostka uzależniona
RWS
Zestawy powiązanych witryn (wcześniej zestawy źródeł własnych)
SSP
Platforma SSP
UA
Ciąg klienta użytkownika
UA-CH
Wskazówki dotyczące klienta użytkownika
W3C
World Wide Web Consortium
WIPB
Celowe ignorowanie naruszeń praw własności intelektualnej

Ogólna opinia, bez konkretnego interfejsu API lub technologii

Motyw opinii Podsumowanie Odpowiedź Chrome
Przyszłość Piaskownicy prywatności W związku z ogłoszeniem, że nie wprowadzimy mechanizmu wyboru użytkownika w przypadku plików cookie innych firm, niektóre interfejsy API są bardziej przydatne niż inne, gdy są obecne pliki cookie innych firm, a inne będą musiały zostać zmodyfikowane, aby były przydatne. Oprócz interfejsów API Piaskownicy prywatności Chrome może inwestować w inne obszary. Dziękujemy za opinie. Nadal współpracujemy z zainteresowanymi stronami, aby ocenić rolę, jaką interfejsy API Piaskownicy prywatności mogą odgrywać w przyszłości, a także zbadać nowe obszary przyszłych inwestycji w świetle ogłoszonego przez Google w kwietniu 2025 r. zamiaru utrzymania obecnego podejścia do oferowania użytkownikom Chrome możliwości wyboru plików cookie innych firm.
Piaskownica prywatności Niektórzy uczestnicy ekosystemu są rozczarowani decyzją o niekontynuowaniu prac nad wprowadzeniem mechanizmu wyboru użytkownika w przypadku plików cookie innych firm, ale są dumni z osiągniętych wyników. Doceniają wyzwania techniczne w ramach Piaskownicy prywatności i podkreślają wartość współpracy z zespołem Chrome oraz przydatność dotacji na testy rynkowe. Dziękujemy za opinię. Zgadzamy się, że Chrome może i powinien współpracować z programistami, aby tworzyć technologie, które zwiększają prywatność w internecie przy jednoczesnym zachowaniu internetu z reklamami.
Udostępnianie danych przeglądarki Udostępnianie danych za pośrednictwem przeglądarki to atrakcyjna technologia, która może rozwiązać problemy związane z nieefektywnością rynku i brakiem zaufania. Przeglądarka ma wartość jako kontekst wykonywania kodu firmy zewnętrznej na potrzeby współpracy. Dziękujemy za opinię. Zgadzamy się, że Chrome może i powinien pomagać deweloperom w tworzeniu technologii, które zwiększają zaufanie między współpracującymi deweloperami a użytkownikami.
Ruch w Chrome Jaki jest odsetek ruchu bez plików cookie w Chrome i odsetek ruchu w trybie incognito? Jak zauważył CMA w swoim „Notice of intention to release commitments” (Zawiadomieniu o zamiarze zwolnienia z zobowiązań), tryb incognito ma wpływ tylko na bardzo małą część aktywności związanej z przeglądaniem. W Wielkiej Brytanii i Europejskim Obszarze Gospodarczym tryb incognito w Chrome stanowi: mniej niż 10% nawigacji na urządzeniach z systemem operacyjnym Android i mniej niż 10% nawigacji na urządzeniach z systemem operacyjnym Windows. Te dane odnoszą się tylko do nawigacji w przeglądarce Chrome opartej na Chromium w Wielkiej Brytanii i Europejskim Obszarze Gospodarczym.
Nie udostępniamy danych o przeglądarkach, które blokują pliki cookie innych firm.
Deweloperzy mogą określać, kiedy pliki cookie są dzielone na partycje, za pomocą nagłówków dostępu do pamięci i odpowiednio stosować dostępne środki zaradcze.
Etykiety testowe Chrome Jakie są plany Chrome dotyczące 1% ruchu niewymagającego plików cookie, który został włączony na potrzeby testów w 2024 r.? Obecnie nie planujemy udostępniać tych informacji, ale zamierzamy je opublikować, gdy tylko będą dostępne.
Chrome Testing Czy obecna konfiguracja etykiet testowych obejmuje wariant w przypadku scenariuszy, w których dostępne są zarówno pliki cookie innych firm, jak i interfejsy API Piaskownicy prywatności? Obecna konfiguracja etykiet testowych obejmuje traktowanie zarówno plików cookie innych firm, jak i interfejsów API Piaskownicy prywatności w formie trybu A.
Piaskownica prywatności Niektórzy reklamodawcy uważają interfejsy API Piaskownicy prywatności za skomplikowane i wykazują apatię z powodu wcześniejszych ćwiczeń przygotowawczych. Zastanawiają się, jak określić korzyści dla osób, które wcześnie wdrożą te interfejsy, i szukają informacji o skutkach remarketingu, pozyskiwania nowych klientów i pomiarów. Dziękujemy za opinię i rozumiemy, że złożoność techniczna i ćwiczenia przygotowawcze mogą budzić pewne obawy.
Jeśli chodzi o ocenę skuteczności obecnych technologii Piaskownicy prywatności, wyniki naszych testów wskazują, że udział w ekosystemie jest kluczowym czynnikiem wpływającym na skuteczność rozwiązań Piaskownicy prywatności. Testowanie przy małych wolumenach nie odzwierciedla dynamiki rynku ani zachęt do korzystania z technologii na dużą skalę.

Rejestracja i atest

W tym kwartale nie otrzymaliśmy żadnych opinii.

Wyświetlanie odpowiednich treści i reklam

Tematy

Motyw opinii Podsumowanie Odpowiedź Chrome
Zainteresowanie wydajnością i użytecznością interfejsu Topics API z ulepszeniami Opinie zainteresowanych stron po stronie kupujących wskazują, że interfejs Topics API jest cennym sygnałem i w przypadku kampanii reklamodawców zapewnia konkurencyjne dane o koszcie wyświetlenia (CPM) w porównaniu z danymi o odbiorcach korzystających z plików cookie innych firm. Niektórzy wydawcy uważają sygnał interfejsu Topics API za lepszy niż standardowe sygnały otwartej sieci. W związku z tymi opiniami na temat przydatności interfejsu Topics API zainteresowane strony proszą o wprowadzenie ulepszeń, takich jak poprawa dokładności i spójności taksonomii oraz rozszerzenie kontroli wydawców, aby zwiększyć popularność tego interfejsu. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Przydatność dla
różnych typów
zainteresowanych osób		 Klasyfikator Topics używa obecnie tylko nazwy hosta strony do określania odpowiednich tematów, dlatego duże witryny z różnorodnymi treściami dostarczają ogólne tematy, a małe witryny – tematy niszowe o większej wartości reklamowej. Nasza odpowiedź jest podobna do odpowiedzi z poprzednich kwartałów:
Podobnie jak w przypadku 3PC, wartość informacji przekazywanych przez różne witryny jest różna. Witryny o tematyce niszowej mają różną wartość: nie wszystkie witryny o tematyce niszowej zawierają treści o wartości komercyjnej, a tym samym mają mniejszą wartość. Są to witryny, które będą korzystać z interfejsu Topics API. Rozważaliśmy możliwość klasyfikowania stron zamiast witryn, ale wiąże się to z poważnymi problemami dotyczącymi prywatności i bezpieczeństwa.
Taksonomia tematów jest zbyt ogólna Interfejs Topics API nie zapewnia wystarczającej szczegółowości wydawcom wiadomości z różnymi sekcjami treści w ramach jednej domeny, co może ograniczać przydatność interfejsu API do kierowania reklam. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Ulepszenie klasyfikatora Zezwalanie wydawcom na przyznawanie Chrome uprawnień do klasyfikowania tematów na podstawie treści strony (np. nagłówka, treści). Rozpatrujemy tę prośbę i zachęcamy do przesyłania dodatkowych opinii tutaj.
Zasady Prośba o wyjaśnienie wytycznych dotyczących używania interfejsu Topics API w połączeniu z informacjami pochodzącymi od podmiotów zewnętrznych. Korzystanie zarówno z interfejsu Topics API, jak i z 3PC nie sprawia trudności, ponieważ interfejs Topics API udostępnia podzbiór funkcji 3PC.
Nagłówek Observe-Browse-Topics Prośba o wyjaśnienie dotyczące wdrożenia nagłówka Observe-Browse-Topics, a w szczególności tego, czy ciągłe zwracanie nagłówka może powodować problemy. Ciągłe zwracanie nagłówka Observe-Browse-Topics: ?1 nie spowoduje żadnych problemów technicznych.
Przeglądarka skutecznie obsługuje ten sygnał, po prostu odnotowując, że wizyta na stronie kwalifikuje się do obliczania tematów, bez powodowania duplikacji ani błędów. Nie jest to wymagane na każdej stronie, ale wysyłanie go jako standardowego nagłówka we wszystkich dokumentach najwyższego poziomu jest prawidłową i prostą strategią.
Kategorie taksonomii Prośba o zaktualizowanie najnowszej taksonomii tematów o nowe tematy. Rozpatrujemy tę prośbę i zachęcamy do przekazywania dodatkowych opinii tutaj.
Wartości null Prośba o wskazówki dotyczące poprawy wydajności interfejsu Topics API i zrozumienia przyczyn odpowiedzi o wartości null, takich jak filtrowanie lub czułość. Dla jasności: null lub puste odpowiedzi z interfejsu Topics API to oczekiwana funkcja ochrony prywatności, a nie błąd.
Odpowiedź null może być spowodowana:
• Reguły ochrony prywatności: 5% szansy losowej null lub tym, że skrypt nie „zaobserwował” użytkownika w witrynach związanych z danym tematem.
• Stan użytkownika: niewystarczająca historia przeglądania, korzystanie z trybu incognito lub rezygnacja użytkownika w ustawieniach prywatności reklam w Chrome.
• Błędy techniczne: witryny wydawców muszą wysyłać nagłówek Observe-Browse-Topics: ?1, a wszystkie wywołujące ramki iframe wymagają uprawnienia allow="Browse-topics".
Aby to sprawdzić, otwórz stronę chrome://topics-internals debugowania, aby zobaczyć, jakie tematy obliczyła Twoja przeglądarka i dlaczego.
Funkcje ochrony prywatności uniemożliwiają osiągnięcie 100% wypełnienia, ale możesz poprawić skuteczność, wykonując te czynności:
• Współpraca z wydawcami: upewnij się, że partnerzy prawidłowo wysyłają nagłówek Observe-Browse-Topics: ?1 w swoich witrynach.
• Weryfikacja kodu: jeśli używasz elementów iframe, sprawdź, czy obowiązują allow="Browse-topics" zasady.

Protected Audience API

Motyw opinii Podsumowanie Odpowiedź Chrome
Wdrażanie interfejsu PA API utrudniają koszty i złożoność Firmy wdrażające tę technologię obniżają priorytet integracji z interfejsem Protected Audience API (PA API) lub wycofują się z nich, powołując się na koszty operacyjne, brak popytu ze strony reklamodawców i małą liczbę zasobów reklamowych na giełdach.
Niektóre opinie dotyczyły potencjalnych korzyści związanych z interfejsem PA API, takich jak możliwość docierania do trwałych odbiorców i większy zasięg dzięki wysokiemu odsetkowi dopasowań.		 Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Funkcjonalność na wielu platformach Funkcjonalność dla wielu platform powinna być obsługiwana przez interfejs PA API na różnych platformach, aby odblokować większe możliwości remarketingu i kierowania na odbiorców. Google powinno umożliwić dostęp do grup zainteresowań zarejestrowanych w Chrome podczas wyświetlania reklam w środowiskach natywnych lub w widoku internetowym, a grupy zainteresowań zarejestrowane na Androidzie powinny być dostępne w aukcjach w Chrome. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
directFromSellerSignals Ograniczając ilość informacji dostępnych w aukcji kontekstowej, uczestnicy aukcji są zawsze kierowani przez serwer reklam Google. Wydawca musi najpierw wywołać wszystkich partnerów wymiany, a potem Google Ad Managera (GAM), aby przeprowadzić aukcję kontekstową, a na koniec zezwolić GAM na wywoływanie aukcji IG. Bez znajomości wyniku aukcji kontekstowej w czasie rzeczywistym żaden konkurent nie może uczciwie podejmować decyzji na najwyższym poziomie.

Funkcja directFromSellerSignals w interfejsie PA API może nie zapewniać przejrzystości w zakresie informacji o aukcji, co może utrudniać dostęp do niezbędnych danych. Google powinien usunąć parametr directFromSellerSignals lub go zaktualizować, aby nie można go było używać do ukrywania ceny rozliczeniowej aukcji serwera reklam. Na przykład cena kontekstowa może być przekazywana przez Chrome za pomocą przejrzystego, niezmiennego i podpisanego pola, do którego wszyscy uczestnicy aukcji (i wydawca) mają dostęp i które mogą zweryfikować.		 Nasza odpowiedź pozostaje bez zmian w porównaniu z poprzednimi kwartałami:
Odpowiedź Chrome:
Informacje przekazywane do funkcji runAdAuction() nie pochodzą od sprzedawcy, chyba że sprzedawca wywoła funkcję runAdAuction() z własnej ramki iframe. W aukcji wielu sprzedawców nie jest możliwe, aby wszyscy sprzedawcy utworzyli ramkę wywołującą funkcję runAdAuction(). directFromSellerSignals rozwiązuje ten problem, wczytując treści z pakietu zasobów podrzędnych wczytanego z domeny sprzedawcy. Dzięki temu nie można manipulować autentycznością i integralnością informacji przekazywanych na aukcję z konfiguracji aukcji sprzedawcy. Jeśli wydawcy chcą używać interfejsu PA API, aby uzyskać informacje o danych przekazywanych przez dostawców technologii do aukcji PA, mogą poprosić tych dostawców o udostępnienie tej funkcji.
Odpowiedź Google Ad Managera:
Od lat dbamy o uczciwość aukcji, w tym o to, aby żadna cena z niegwarantowanych źródeł reklam wydawcy, w tym ceny niegwarantowanych elementów zamówienia, nie była udostępniana innemu kupującemu przed złożeniem przez niego oferty w aukcji. Potwierdziliśmy to później w naszych zobowiązaniach wobec francuskiego urzędu ds. konkurencji.
W przypadku aukcji z użyciem Protected Audience API zamierzamy dotrzymać obietnicy, korzystając z sygnałów directFromSellerSignals i nie udostępniając stawki żadnego uczestnika aukcji innym uczestnikom przed zakończeniem aukcji w przypadku aukcji z udziałem wielu sprzedawców. Wyjaśniamy, że nie będziemy też udostępniać ceny aukcji kontekstowej naszej własnej aukcji komponentowej, co opisaliśmy w tym artykule.
Raportowanie Prośba o dodanie usługi analitycznej lub raportującej w celu włączenia scentralizowanego raportowania. Dyskutujemy o tej prośbie tutaj i chętnie poznamy Twoją opinię.
K-anonimowość w przypadku identyfikatora buyerReportingId Możliwość odrzucania stawek na podstawie k-anonimowości parametru „buyerReportingId”, aby ułatwić selekcjonowanie odbiorców i wywiązywanie się z obowiązków raportowania wobec zewnętrznych dostawców danych. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Ulepszone debugowanie w skrypcie generateBid Prośba o mechanizm szybkiego identyfikowania konkretnego etapu lub „punktu przerwania” w skrypcie generateBid, w którym proces kończy się niepowodzeniem. Wiemy, że pomiary w czasie rzeczywistym mają być używane jako mechanizm ustawiania punktów przerwania w aukcjach na urządzeniu. Bierzemy pod uwagę te opinie, oceniając rolę, jaką w przyszłości będą odgrywać interfejsy API Piaskownicy prywatności, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Detektory zdarzeń do monitorowania stanu runAdAuction Propozycja dodania obsługi detektora zdarzeń do funkcji navigator.runAdAuction interfejsu PA API w celu ulepszenia monitorowania cyklu życia aukcji reklam. Rozpatrujemy tę prośbę i zachęcamy do przesyłania dodatkowych opinii tutaj.
Używanie API Prośba o wyjaśnienie, w jaki sposób interfejs PA API i interfejs Attribution Reporting API (ARA) mogą obsługiwać przypadki użycia reklam internetowych w przypadku braku plików cookie innych firm, zwłaszcza w przypadku użytkowników, którzy zrezygnowali z plików cookie innych firm, ale nie z interfejsów API Piaskownicy prywatności, oraz w scenariuszach obejmujących nieudaną synchronizację plików cookie i widok WebView. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Czas oczekiwania Opóźnienie związane z interfejsem PA API może utrudniać jego wdrażanie, ponieważ wydawcy mogą wyłączyć ten interfejs, jeśli opóźnienie jest zbyt duże. W ciągu ostatnich kilku kwartałów wprowadziliśmy kilka ulepszeń, które zmniejszyły opóźnienie na urządzeniu. W razie potrzeby nadal będziemy rozwijać i skalować usługi określania stawek i aukcji. Zaktualizowaliśmy przewodnik po sprawdzonych metodach dotyczących opóźnień, aby dodać więcej informacji o tym, jak korzystać z tych funkcji. Pracujemy też nad nowymi rozwiązaniami, które pozwolą zmniejszyć opóźnienia. Niektóre z nich możesz sprawdzić tutaj.
Rejestrowanie zachowań w B&A (testowanie a środowisko produkcyjne) Wyjaśnienie różnic w rejestrowaniu danych w trybie testowym i produkcyjnym w przypadku usług B&A. W szczególności dostępność logów w chmurze i wpływ trybu produkcyjnego na logowanie. Najpierw należy odróżnić wersje produkcyjne od nieprodukcyjnych oraz osobny parametr TEST_MODE, który po prostu włącza zakodowany na stałe klucz szyfrowania testowego. Poniższe wyjaśnienie dotyczy typów kompilacji.
W wersjach nieprodukcyjnych serwery B&A mają konfigurowany poziom szczegółowości logowania. Te szczegółowe dzienniki są zapisywane w standardowych strumieniach stdout/stderr. W Google Cloud są one dostępne w natywnym interfejsie logowania, a w Amazon Web Services – w logach dołączonej konsoli.
W przypadku wersji produkcyjnych rejestrowanie jest bardziej ograniczone. Poziom szczegółowości jest stały i nie można go zmienić. Niektóre logi niezwiązane z prywatnością, takie jak komunikaty o uruchamianiu serwera i większość błędów powodujących awarię, są nadal drukowane w stdout/stderr, ale żadne logi dotyczące konkretnych żądań nie są dostępne w tym kanale. Jedynymi dziennikami dotyczącymi poszczególnych żądań z wersji produkcyjnej są dzienniki żądań zawierających token debugowania, na który użytkownik wyraził zgodę. Są one eksportowane wyłącznie za pomocą OpenTelemetry. Ważne jest, aby używać debugowania za zgodą użytkowników oszczędnie, ponieważ duży ruch może obniżyć wydajność serwera i prowadzić do błędów sprawdzania stanu.
W przypadku wskaźników wszystkie są eksportowane za pomocą OpenTelemetry. Dane, które nie są wrażliwe z punktu widzenia prywatności, są zawsze eksportowane w niezmienionej postaci, bez żadnych „szumów”. Z kolei dane wrażliwe z punktu widzenia prywatności są zawsze „zaszumiane” podczas eksportowania z serwera działającego w trybie produkcyjnym. To, czy te dane wrażliwe z punktu widzenia prywatności są eksportowane z szumem, bez szumu czy w obu tych wersjach, zależy od konkretnej konfiguracji telemetrii.
Uwzględnianie pełnej ścieżki strony w bezpiecznych sygnałach licytowania na potrzeby bezpieczeństwa marki Prośba o zaktualizowanie interfejsu PA API, aby w żądaniu pobierania danych dla funkcji trustedBiddingSignals oprócz nazwy hosta uwzględniał pełną ścieżkę URL strony najwyższego poziomu.
Głównym zastosowaniem jest umożliwienie bardziej szczegółowych ustawień bezpieczeństwa marki. Reklamodawcy często muszą blokować wyświetlanie reklam w określonych sekcjach domeny (np. strona-z-wiadomościami.pl/polityka), ale jednocześnie nie mają nic przeciwko wyświetlaniu reklam w innych częściach tej domeny. Listy blokowania mogą zawierać miliony wpisów, dlatego muszą być oceniane po stronie serwera. Obecna specyfikacja, która wysyła tylko nazwę hosta, uniemożliwia serwerowi trustedBiddingSignals przeprowadzenie niezbędnej oceny na poziomie ścieżki, co ogranicza możliwości związane z bezpieczeństwem marki.		 Obecnie omawiamy ten problem tutaj po wcześniejszych obszernych dyskusjach, które można znaleźć tutaj. Zachęcamy do przesyłania dodatkowych opinii.
Chcemy jednak wyjaśnić, że rozważamy dodanie tych informacji tylko wtedy, gdy pobieranie sygnałów trustedBiddingSignals odbywa się na serwerze działającym w zaufanym środowisku wykonawczym (TEE).

Aukcja chroniona (usługi B&A)

Motyw opinii Podsumowanie Odpowiedź Chrome
Sprawdzanie dostępności Informacje o dostępności interfejsu Key/Value (KV) v2 do testowania w środowiskach Chrome i B&A. KV v2 jest dostępna zarówno w B&A, jak i w Chrome. Dodatkowe wskazówki znajdziesz tutaj.
Wdrożenie serwera KV Prośba o wyjaśnienie dotyczące korzystania z serwera KV, w szczególności w zakresie mapowania adresów URL renderowania kreacji na dane żądania, konieczności koordynacji między platformami SSP i DSP w celu zdefiniowania parametrów w adresie URL renderowania oraz dostępności dokumentacji opisującej wymaganą koordynację i przechowywanie danych w trybie KV. Usługa KV używa renderURL jako klucza. Jeśli adres URL jest nowy, zostanie zapisany. Jeśli istnieje, jego wartość jest zwracana do użycia w funkcji scoreAd. Format zwracanych danych zależy od konfiguracji: „Bring Your Own Server” (BYOS) umożliwia użycie dowolnej wartości, a usługa Trusted KV wymaga funkcji zdefiniowanej przez użytkownika.
Chociaż nie zawsze jest to wymagane, koordynacja z platformami DSP jest niezbędna w przypadku funkcji takich jak zastępowanie makr (np. ${AD_WIDTH}) w parametrze renderURL, co umożliwia dynamiczne dostosowywanie i weryfikowanie reklam.
Zalecamy rozpoczęcie od prostego testu z jedną platformą DSP, aby określić niezbędny poziom koordynacji. Aktualizujemy też dokumentację dotyczącą kluczy weryfikacyjnych. Udostępnimy ją publicznie, gdy będzie gotowa.
BYOS w przypadku B&A Dlaczego B&A nie oferuje trybu BYOS podobnego do trybu BYOS KV? Usługa B&A wymaga środowiska TEE, co uniemożliwia korzystanie z modelu BYOS, ponieważ przetwarza kombinacje danych o wysokiej wrażliwości, które wymagają egzekwowania mechanizmów ochrony prywatności, jak wyjaśniono poniżej.
W przypadku platform DSP:
B&A przetwarza kontekst wydawcy (potencjalnie pełny adres URL, jeśli został wyraźnie przesłany przez sprzedawcę za pomocą auctionSignals / perBuyerSignals) w połączeniu ze szczegółowymi danymi użytkownika z IG. Środowisko TEE jest niezbędne do bezpiecznego przetwarzania tej kombinacji i zapobiegania potencjalnemu ponownemu rozpoznaniu użytkownika. W przypadku klucza wartości BYOS nie można wysłać pełnego adresu URL.
W przypadku platform SSP:
nawet sama znajomość kombinacji uczestniczących grup zainteresowań (i ich właścicieli platform DSP) w aukcji może generować sygnaturę identyfikacyjną. W takiej sytuacji przydaje się rozwiązanie chaffing, które wymaga użycia TEE.
Dlatego bezpieczne przetwarzanie tych połączonych sygnałów wrażliwych i egzekwowanie mechanizmów ochrony prywatności wymaga kontrolowanego, potwierdzonego środowiska TEE.

Pomiar skuteczności reklam cyfrowych

Raportowanie atrybucji (i inne interfejsy API)

Motyw opinii Podsumowanie Odpowiedź Chrome
Zasady dotyczące hałasu Wdrożenie ARA było korzystne dla niektórych uczestników rynku, a Google powinno nadal prowadzić raportowanie na poziomie zdarzeń. Google powinno rozważyć złagodzenie zasad dotyczących szumu w sytuacjach, w których dostępne są zarówno ARA, jak i 3PC. Reklamodawcy nastawieni na wyniki coraz częściej korzystają z obecnej implementacji pola „wartość” w przypadku elastycznego zdarzenia ARA, a mniej restrykcyjne zasady dotyczące szumu pomogłyby zmniejszyć opóźnienia i nieprawidłowości w raportowaniu. Ten mechanizm jest podstawową częścią projektu ARA, który ma chronić prywatność użytkowników, uniemożliwiając śledzenie poszczególnych osób. Bierzemy pod uwagę opinie o trudnościach w raportowaniu spowodowanych przez szum. Nadal oceniamy rolę, jaką w przyszłości będą odgrywać interfejsy API Piaskownicy prywatności, a także potencjalne przyszłe ulepszenia, w świetle ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Plany rozwoju i wsparcie długoterminowe Poproszenie o harmonogram rozwoju ARA oraz potwierdzenie długoterminowych inwestycji i wsparcia w związku z ogłoszeniem, że nie zostanie wprowadzony mechanizm wyboru użytkownika w przypadku plików cookie innych firm. Zespół Piaskownicy prywatności współpracuje z ekosystemem, aby zrozumieć, jaką rolę będą odgrywać interfejsy API Piaskownicy prywatności w przyszłości, i ocenić przyszłe inwestycje.
Pomiar w różnych środowiskach (z aplikacji do witryny) Poproś o rozwiązanie, które wykorzystuje ARA do ułatwiania pomiarów w różnych środowiskach, zapewniając czystszy i bardziej niezawodny przepływ danych oraz zwiększając możliwość łączenia interakcji użytkowników na różnych platformach. ARA obsługuje już przejścia z aplikacji do internetu na tym samym urządzeniu. Więcej informacji o rozwiązaniu do pomiaru w aplikacjach i internecie znajdziesz tutaj i tutaj.
Atrybucja w różnych przeglądarkach Ujednolicone, działające w różnych przeglądarkach podejście do ARA znacznie poprawiłoby możliwość pomiaru ROI w otwartym internecie i zapewniłoby stabilną alternatywę przed potencjalnymi zmianami przepisów. Zespół Chrome powinien współpracować z zespołem Safari nad takim rozwiązaniem. W ramach grup PATCG i PATWG w W3C pracujemy już nad interoperacyjnym interfejsem API z innymi dostawcami przeglądarek. Zaznaczamy, że te prace mają charakter wstępny. Zainteresowane strony mogą zapoznać się z naszymi postępami tutaj.
Pomiary na różnych urządzeniach i offline Brak możliwości obsługi pomiarów konwersji na różnych urządzeniach w przypadku ARA jest poważnym ograniczeniem. Pomiar konwersji online na offline ma również duże znaczenie, a przeglądarka może odgrywać rolę we współpracy z dostawcami usług pomiarowych. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Atrybucja uwzględniająca różne interakcje Prośba o umożliwienie reklamodawcom korzystania z danych Piaskownicy prywatności jako obiektywnej „prawdy podstawowej” do weryfikowania i kalibrowania dotychczasowych modeli atrybucji. Można to osiągnąć, używając danych dostarczanych przez przeglądarkę w ramach ARA jako wiarygodnego sygnału kalibracyjnego, co pozwoli utworzyć podstawową wartość referencyjną. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Pomiary ruchu bez zgody użytkowników lub w przypadku rezygnacji z udostępniania danych Rozwiązanie chroniące prywatność, takie jak Interoperable Private Attribution, umożliwiłoby pomiar ruchu bez zgody użytkowników. Pozwoli to uzyskać pełniejszy obraz skuteczności kampanii dzięki uwzględnieniu danych użytkowników, którzy zrezygnowali ze śledzenia. Wypełni to dużą lukę w pomiarach spowodowaną wymaganiami dotyczącymi zgody użytkowników. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Atrybucja serwer-serwer Prośba o umożliwienie platformom technologii reklamowych z zaawansowaną infrastrukturą po stronie serwera bardziej elastycznej integracji z ARA, aby uwzględniać przypadki użycia, którymi trudno zarządzać wyłącznie po stronie klienta, przy jednoczesnym zachowaniu prywatności użytkowników. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.
Rejestracja w wielu domenach Potrzebuję wyjaśnień dotyczących ograniczeń i zastrzeżeń związanych z rejestracją wielu domen w usłudze ARA, zwłaszcza w przypadku usługi agregacji i atrybucji w wielu domenach. Poniżej znajdziesz najważniejsze ograniczenia związane z używaniem ARA w przypadku wielu domen:
• Atrybucja jest ograniczona do jednego źródła. Nie możesz dopasować kliknięcia w jednej ze swoich domen do konwersji w innej domenie. Atrybucja jest ograniczona do tego samego źródła zarówno w przypadku źródła, jak i wyzwalacza.
• Usługa do agregacji nie obsługuje przetwarzania wsadowego z wielu źródeł. Raporty z różnych źródeł muszą być przetwarzane w osobnych partiach. Pracujemy nad tym, aby w przyszłości było to możliwe.
W skrócie: w ramach jednego podmiotu można zarejestrować wiele domen, ale wszystkie funkcje ARA, takie jak atrybucja i agregacja, muszą być obecnie obsługiwane w przypadku każdej domeny.

Usługa do agregacji

W tym kwartale nie otrzymaliśmy żadnych opinii.

Interfejs Private Aggregation API

Motyw opinii Podsumowanie Odpowiedź Chrome
Limity i poziomy hałasu Obawy dotyczące ograniczeń rozmiarów kluczy agregacji i wartości agregacji w interfejsie Private Aggregation API. Rozmiary klucza i wartości agregacji zostały wybrane tak, aby zapewnić wysoką szczegółowość przy jednoczesnym ograniczeniu kosztów sieci i pamięci masowej. Aby zmaksymalizować elastyczność, zalecamy też używanie haszowania podczas przypisywania kluczy.
Chociaż istnieją inne czynniki chroniące dane użytkowników, dodawanie szumu jest ważnym elementem ochrony prywatności w interfejsie Private Aggregation API.
Bierzemy pod uwagę Twoje uwagi i będziemy nadal oceniać odpowiednie wybory parametrów, a także rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w świetle ogłoszonego przez Google w kwietniu 2025 r. oświadczenia, że obecne podejście do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm zostanie utrzymane.
Prywatność a użyteczność Podejście Piaskownicy prywatności może stawiać prywatność ponad użyteczność, co może utrudniać jej wdrożenie. Propozycja umożliwienia bardziej szczegółowego udostępniania danych za zgodą użytkownika w celu ulepszenia pomiarów i personalizacji reklam. Rozmiary klucza i wartości agregacji zostały wybrane tak, aby zapewnić wysoką szczegółowość przy jednoczesnym ograniczeniu kosztów sieci i pamięci masowej. Aby zmaksymalizować elastyczność, zalecamy też używanie haszowania podczas przypisywania kluczy.
Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. zamiaru utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.

Ograniczanie ukrytego śledzenia

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

Motyw opinii Podsumowanie Odpowiedź Chrome
Wykrywanie spamu Jeśli pierwsze żądanie ze strony internetowej, która korzysta z systemu wykrywania spamu, opiera się na wskazówkach klienta, system śledzenia lub wykrywania może nie rozpoznać żądania lub nieprawidłowo je sklasyfikować. W przypadkach użycia, które wymagają dostępu do wskazówek dotyczących klienta użytkownika (UA-CH) w pierwszym żądaniu, należy używać krytycznych wskazówek dotyczących klienta.
Opinie o interfejsie API Rozważ wycofanie nagłówka Sec-CH-USA-Wow64, ponieważ nie jest już istotny w przypadku współczesnego internetu. Rozpatrujemy tę prośbę i zachęcamy do przesyłania dodatkowych opinii tutaj. Otrzymaliśmy też opinie, że warto byłoby rozszerzyć wow64 poza system Windows.

Ochrona IP (wcześniej Gnatcatcher)

Motyw opinii Podsumowanie Odpowiedź Chrome
Opcje Prośba o przełącznik ochrony adresu IP dla witryn, które mają być używane selektywnie poza trybem incognito. Dziękujemy za opinię. Zachęcamy do przekazywania dodatkowych informacji na ten temat tutaj.
Niewłaściwe postępowanie Czy tokeny ujawniania probabilistycznego (PRT) zwracające wartość NULL uniemożliwią identyfikację sprawcy, gdy policja poprosi o ujawnienie adresu IP w przypadku wykroczenia na platformie? Jeśli domena jest używana wyłącznie do wykrywania oszustw i nadużyć, prawdopodobnie nie jest uwzględniona na liście zamaskowanych domen (MDL), a tym samym nie ma na nią wpływu ochrona adresu IP. W przypadku tych domen nie będą więc potrzebne PRT.
Jeśli domena jest uwzględniona na liście MDL, obecnie tylko PRT umożliwiają poznanie pierwotnego adresu IP w przypadku żądania przekazywanego przez serwer proxy. PRT zostały zaprojektowane specjalnie z myślą o analizie zbiorczej, a nie identyfikacji poszczególnych użytkowników, dlatego w większości przypadków nie zawierają adresu IP. Spodziewamy się, że w opisanym scenariuszu będzie to miało ograniczony wpływ, ponieważ ochrona adresu IP ma zastosowanie tylko w kontekście innych firm. Oznacza to, że wydawcy nadal będą otrzymywać nieprzekazywane przez serwer proxy adresy IP w przypadku interakcji z użytkownikami, np. gdy użytkownicy odwiedzają witrynę platformy online.
Przeciwdziałanie oszustwom Jakie są szczegóły środków zapobiegających oszustwom w przypadku ochrony adresu IP, w tym informacje o ograniczaniu dostępu do serwerów proxy i wydawaniu tokenów uwierzytelniających, oraz jakie są konkretne przypadki użycia PRT? Potwierdzamy, że ograniczenia liczby żądań i tokeny uwierzytelniania w usłudze IP Protection mają zapobiegać oszustwom reklamowym dokonywanym przez boty poprzez nadmierne korzystanie z serwerów proxy, zgodnie ze strategią przeciwdziałania oszustwom i spamowi. Więcej przypadków użycia PRT znajdziesz w dokumentacji wyjaśniającej PRT tutaj.
Tryb incognito Czy ochrona adresu IP w trybie incognito jest nadal planowana na III kwartał? Obecnie nie planujemy zmian w harmonogramie wprowadzenia ochrony adresu IP w trybie incognito w III kwartale.

Łagodzenie śledzenia przekierowań

Motyw opinii Podsumowanie Odpowiedź Chrome
Opinie o interfejsie API Chrome powinien blokować dostęp do plików cookie i pamięci, a nie je dzielić, gdy stosuje środki zapobiegające śledzeniu przez przekierowania. Jako powód podaje niezamierzone działanie i zamieszanie spowodowane przez metodę „dzielenia” stosowaną w Safari. Z zadowoleniem przyjmujemy tę sugestię. Obecnie BTM nie obejmuje partycjonowania plików cookie ani pamięci, ale usuwa je po okresie przejściowym. Jeśli w przyszłości pojawią się projekty BTM, które będą wymagać natychmiastowego działania w odniesieniu do plików cookie, zamierzamy blokować pliki cookie zamiast je dzielić.

Wzmocnienie granic prywatności w przypadku różnych witryn

W tym kwartale nie otrzymaliśmy żadnych opinii.

Fenced Frames API

W tym kwartale nie otrzymaliśmy żadnych opinii.

Interfejs Shared Storage API

Motyw opinii Podsumowanie Odpowiedź Chrome
Prośba o funkcję interfejsu API Prośba o dołączenie wyświetleń i kliknięć reklam w pamięci współdzielonej. Bierzemy pod uwagę te opinie, oceniając rolę, jaką interfejsy API Piaskownicy prywatności będą odgrywać w przyszłości, w kontekście ogłoszonego przez Google w kwietniu 2025 r. utrzymania obecnego podejścia do oferowania użytkownikom Chrome wyboru dotyczącego plików cookie innych firm.

CHIPS

Motyw opinii Podsumowanie Odpowiedź Chrome
Pytanie dotyczące interfejsu API Prośba o wyjaśnienie, jak ustawienia plików cookie innych firm w Chrome działają w przypadku CHIPS, a w szczególności, czy po wyłączeniu plików cookie innych firm niepodzielone pliki cookie są przekształcane w podzielone i czy podzielone pliki cookie pozostają aktywne. Gdy pliki cookie innych firm są wyłączone, niepodzielone pliki cookie nie będą przechowywane, pobierane ani wysyłane w kontekście innej firmy. Partycjonowane pliki cookie będą jednak nadal przechowywane, pobierane i wysyłane w kontekście zewnętrznym, ponieważ na ich działanie nie mają wpływu ustawienia przeglądarki, które wyłączają pliki cookie innych firm.
Kwestie dotyczące prywatności Obawa, że podmiot zewnętrzny z trwałym identyfikatorem, np. w przypadku logowania jednokrotnego, może nadal umożliwiać zarówno podmiotom umieszczającym, jak i umieszczonym uzyskanie globalnego identyfikatora cyfrowego, nawet w przypadku podzielonych plików cookie. Podmiot umieszczony może mieć trwały identyfikator, ale gdy jest on przechowywany w pliku cookie z podziałem na partycje, jest dostępny tylko w witrynie, w której został ustawiony przez umieszczony element. Łączenie tego identyfikatora w różnych witrynach wymagałoby zalogowania się, co już umożliwia wymianę identyfikatora w postaci tokena uwierzytelniającego, nawet bez użycia partycjonowanych plików cookie.

FedCM

Motyw opinii Podsumowanie Odpowiedź Chrome
Używanie API Ciche zapośredniczenie nie działa w przypadku użytkowników z wieloma kontami bez konkretnego błędu. Ciche zapośredniczenie to funkcja zaprojektowana z myślą o bardzo konkretnym przypadku, w którym dostępne jest tylko jedno konto. Zamiast tego zalecamy używanie „opcjonalnego” zapośredniczenia, w przypadku którego FedCM wraca do wyświetlania użytkownikowi selektora kont, jeśli ciche zapośredniczenie nie jest możliwe.
Używanie API navigator.credentials.get zwraca ogólne błędy, co uniemożliwia rejestrowanie konkretnych przyczyn odrzucenia, takich jak zamknięcie przez użytkownika lub okresy oczekiwania. Niemożność odróżnienia przez deweloperów sytuacji, w której użytkownik zamyka okno FedCM, od błędu sieci lub okresu „ochłaniania” FedCM spowodowanego wcześniejszym zamknięciem okna przez użytkownika jest również celowym rozwiązaniem, które ma chronić prywatność użytkownika. Obawy dotyczą tego, że taka funkcja umożliwiłaby witrynom wnioskowanie o stanie logowania użytkownika u różnych dostawców tożsamości.
Zaloguj się Zaobserwowano niespójne działanie wyboru konta w przypadku wielu zalogowanych kont. Nie wiadomo, czy sporadyczna niemożność wybrania konkretnego konta w przypadku wielu zalogowanych kont jest sporadycznym błędem w FedCM, czy problemem związanym z systemem testowym. Współpracujemy z osobą zgłaszającą problem, aby go rozwiązać. Poprosiliśmy ją o podanie dodatkowych informacji, aby lepiej zrozumieć sytuację.
Używanie API Jeśli użytkownik zamknie okno podczas autoryzacji za pomocą FedCM, fakt, że jest w stanie oczekiwania, nie jest zgłaszany za pomocą błędu, który można przechwycić. Tak, w takim przypadku pojawi się ogólny kod błędu, aby chronić prywatność użytkownika.
Używanie API Dlaczego po udanym „automatycznym ponownym uwierzytelnieniu” FedCM przechodzi w 10-minutowy okres ciszy? Automatyczne ponowne uwierzytelnianie odbywa się bez działania zainicjowanego przez użytkownika. Jeśli użytkownik chce wrócić do witryny, ale zalogować się na inne konto, potrzebuje czasu, w którym FedCM nie będzie automatycznie ponownie uwierzytelniać. „Okres ciszy” daje użytkownikom możliwość ręcznego zalogowania się przy użyciu innego konta. Więcej informacji o tym „okresie ciszy” znajdziesz w tym poście na blogu.
Uproszczona wersja FedCM Obawy, że propozycja Lightweight FedCM wprowadza dodatkowe komplikacje dla dostawców tożsamości ze względu na konieczność obsługi dwóch niezgodnych implementacji (FedCM i Lightweight FedCM). Lekka wersja FedCM jest zgodna z tradycyjną wersją FedCM. Dostawcy tożsamości mogą wybrać metodę implementacji, której chcą używać, i nie będą musieli obsługiwać obu metod.
Uproszczony interfejs FedCM to mechanizm push dla FedCM. Jeśli dostawca tożsamości zdecyduje się użyć tej funkcji, może przekazywać informacje o koncie do przeglądarki, gdy użytkownik się loguje. Dzięki temu, gdy strona zależna wywoła FedCM, konto zostanie pobrane z przeglądarki, a nie z punktu końcowego kont dostawcy tożsamości.
Uproszczona wersja FedCM Obawy dotyczące udostępniania danych osobowych użytkownika, takich jak imię i nazwisko, adres e-mail i zdjęcie profilowe, witrynie RP w propozycji Lightweight FedCM. Propozycja dotycząca uproszczonego FedCM została zaktualizowana po otrzymaniu tej opinii. Usunęliśmy z odpowiedzi metody imię i nazwisko, adres e-mail oraz zdjęcie profilowe.
Uproszczona wersja FedCM Zarządzanie wieloma zalogowanymi kontami wydaje się zbyt sztywne w propozycji Lightweight FedCM. Propozycja nie obsługuje obecnie indywidualnych okresów istnienia sesji ani zniuansowanych stanów logowania na poszczególnych kontach. Wygasanie jest obecnie powiązane z dostawcą tożsamości w obiekcie credentials. Odnotowaliśmy, że wygaśnięcie konta jest otwartą kwestią, i weźmiemy tę opinię pod uwagę w przyszłych pracach nad rozwojem usługi.
Uproszczona wersja FedCM Różnica między stanami „zalogowany” i „dostępny do wyboru” nie jest jasno określona, co może mieć wpływ na wygodę użytkownika w przypadku propozycji uproszczonego FedCM. Obecnie nie obsługujemy możliwości rozróżniania, czy konto jest zalogowane czy wylogowane w interfejsie FedCM. Konta, z których użytkownik się wylogował, nie powinny być widoczne na liście.
Jeśli konto jest wylogowane i wyświetlane na liście, a użytkownik wybierze konto, na którym nie jest aktywnie zalogowany, może użyć interfejsu Continuation API, aby ponownie się zalogować.
Używanie API Niespójność między polem given_name w getUserInfo a jego użyciem w interfejsie FedCM. Ten problem został omówiony z firmą Mozilla tutaj, aby uzgodnić, jak należy traktować given_name w getUserInfo.
Używanie API Nie wszystkie pola używane w interfejsie IdentityProviderAccount są dostępne w getUserInfo, w szczególności tel i username, co sugeruje potrzebę synchronizacji. Dyskusja z Mozillą i innymi członkami grupy społeczności FedID na temat uzgodnienia, które pola z IdentityProviderAccount są wysyłane do getUserInfo., jest w toku.
FedCM dla firm Prośba o obsługę FedCM w przypadkach użycia dostawcy tożsamości w firmie. Kluczową kwestią jest potrzeba zaufanego mechanizmu, za pomocą którego dostawcy tożsamości mogą sygnalizować przeglądarkom, że administratorzy wcześniej wyrazili zgodę na dostęp użytkownika do określonych dostawców usług, których nie można naśladować ani wykorzystywać w nieuczciwy sposób przez narzędzia śledzące w internecie. Omówiliśmy to na spotkaniu grupy FedID CG 22 kwietnia (notatki ze spotkania znajdziesz tutaj). Jako potencjalne rozwiązania zaproponowaliśmy kombinacje rozszerzeń przeglądarki i zasad przedsiębiorstwa (w przypadku urządzeń zarządzanych). Zachęcamy do przekazywania dodatkowych opinii na ten temat tutaj.

Walka ze spamem i oszustwami

Interfejs Private State Token API (i inne interfejsy API)

W tym kwartale nie otrzymaliśmy żadnych opinii.