Raport kwartalny za II kwartał 2023 r. podsumowujący opinie ekosystemu na temat ofert pakietowych Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wynikających z umowy CMA firma Google zobowiązała się do publicznego udostępniania kwartalnych raportów z procesu zaangażowania zainteresowanych osób w ramach propozycji Piaskownicy prywatności (zapoznaj się z art. 12 i 17(c)(ii) Zobowiązań). Te raporty z podsumowaniem Piaskownicy prywatności są generowane na podstawie opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym między innymi na temat problemów na GitHubie, formularza opinii dostępnego na stronie privacysandbox.com, spotkań z zainteresowanymi osobami z branży i forów standardów internetowych. Chrome z radością korzysta z opinii otrzymywanych od ekosystemu i aktywnie analizuje sposoby wykorzystywania zdobytych informacji na potrzeby podejmowania decyzji projektowych.
Tematy opinii są uporządkowane według częstości występowania w poszczególnych interfejsach API. Na podstawie zebranych przez zespół Chrome opinii na temat danego motywu są one uporządkowane w kolejności malejącej. Wspólne tematy opinii zostały zidentyfikowane przez przejrzenie tematów dyskusji ze spotkań publicznych (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz częstych pytań zadawanych przez wewnętrzne zespoły Google i formularze publiczne.
Dokładniej rzecz ujmując, przeanalizowano protokoły ze spotkań zebrań standardowych instytucji internetowych, a w przypadku bezpośrednich opinii – zapisy Google ze spotkań 1:1, e-maile otrzymane przez poszczególnych inżynierów, listę adresową interfejsu API oraz publiczny formularz opinii. Następnie zespół Google skoordynował zespoły zaangażowane w te działania informacyjne, aby określić względną popularność tematów pojawiających się w odniesieniu do poszczególnych interfejsów API.
Wyjaśnienia odpowiedzi Chrome na opinie opracowano na podstawie opublikowanych odpowiedzi na najczęstsze pytania, rzeczywistych odpowiedzi zgłoszonych przez zainteresowane osoby oraz określenia stanowiska na potrzeby tego publicznego raportowania. Biorąc pod uwagę obecny cel programowania i testowania, otrzymaliśmy pytania i opinie dotyczące interfejsów API Topics, Protected Audience i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu raportowania mogły jeszcze nie zostać uznane za odpowiedź Chrome.
Słowniczek akronimów
- ELEMENTY
- Pliki cookie z niezależnym trybem partycjonowania
- (procesor) DSP
- Platforma DSP
- FedCM
- Sfederowane zarządzanie danymi uwierzytelniającymi
- kl./s
- Zestawy własne
- IAB
- Interactive Advertising Bureau ,
- dostawca tożsamości
- Dostawca tożsamości
- IETF
- Internet Engineering Task Force
- IP
- Adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Wersja próbna
- PatCG
- Grupa społecznościowa Private Advertising Technology
- RP
- Grupa uzależniona
- platforma SSP
- Platforma dostawców reklam
- TEE
- Zaufane środowisko wykonawcze
- UA
- Ciąg znaków klienta użytkownika
- UA-CH
- Wskazówki dotyczące klienta użytkownika
- W3C
- World Wide Web Consortium
- WIPB
- Niewiarygodna ślepotyka na adresy IP
Ogólna opinia, brak konkretnego interfejsu API/technologii
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Zarządzanie danymi i zgodność z przepisami | Wskazówki dotyczące ekosystemu dotyczące korzystania z Piaskownicy prywatności zgodnie z wymaganiami prawnymi. | Podobnie jak w przypadku każdej nowej technologii, każda firma jest odpowiedzialna za korzystanie z Piaskownicy prywatności zgodnie z prawem. Google nie może udzielać porad prawnych innym podmiotom. Zdajemy sobie jednak sprawę, że jest to kluczowy obszar zainteresowań ekosystemu. W przypadku każdego interfejsu API opublikowaliśmy obszerną dokumentację techniczną, która powinna stanowić podstawę do przeprowadzenia niezbędnych ocen prawnych. Pracujemy też nad udostępnieniem dodatkowych materiałów, które pomogą firmom w spełnieniu wymagań prawnych. |
| Propozycja testowania ilościowego w ramach CMA | Więcej informacji o propozycji testów ilościowych w CMA | Współpracujemy z CMA nad opracowaniem eksperymentów, które dadzą obraz wpływu wycofania plików cookie innych firm i wprowadzenia ofert Piaskownicy prywatności na ekosystem. W kwietniu CMA opublikowało ogólne wytyczne dotyczące tego, czego można się spodziewać w okresie testowania i testowania, a w czerwcu (ze szczegółowymi wytycznymi). Zachęcamy do bezpośredniego przesyłania pytań lub opinii na temat propozycji CMA dotyczącej testów ilościowych. |
| Tryby testowe obsługiwane przez Chrome | Więcej informacji i objaśnień dotyczących harmonogramów testów | 18 maja opublikowaliśmy posta na blogu, w którym podajemy więcej informacji o 2 trybach testowania w Chrome. Szczegóły te nie są ostateczne, więc w miarę postępów w ich realizacji w III kwartale 2023 r. opublikujemy dalsze wskazówki dotyczące implementacji. |
| Partycjonowana pamięć masowa | Czy podczas testów obsługiwanych przez Chrome będzie używana partycjonowana pamięć masowa? | Partycjonowanie pamięci masowej zostanie wysłane do wszystkich użytkowników przed eksperymentem z wycofaniem plików cookie innych firm. Dlatego ten typ kampanii zostanie włączony we wszystkich grupach eksperymentu. Witryny będą mogły w tym czasie włączyć okres próbny wycofywania, aby odzyskać niezapisane miejsce na dane. |
| Pomoc przy produkcji | Jak Chrome obsługuje problemy techniczne i eskalacje problemów z Piaskownicą prywatności, które mają wpływ na ekosystem? | Google udostępnia wiele kanałów, które umożliwiają technikom reklamowym zgłaszanie problemów i umożliwiają przekazywanie odpowiednich spraw. Więcej informacji o publicznych i prywatnych forach dotyczących przesyłania opinii i zgłaszania problemów znajdziesz w naszym poście dla deweloperów. |
| Harmonogram rejestracji | Obecny czas na rejestrację jest za krótki | Cały czas analizujemy termin wprowadzenia zmian i chcielibyśmy dowiedzieć się od ekosystemu, jaki harmonogram będzie w tym przypadku najbardziej odpowiedni. |
| Numer DUNS | Więcej informacji o wymaganym numerze DUNS na potrzeby rejestracji i poświadczania | Wymagania dotyczące uzyskania numeru DUNS można znaleźć na stronie Dun and Bradstreet. Wymagania różnią się w zależności od rynku, więc uczestnicy powinni sprawdzić swoją stronę internetową pod kątem rynku, który ich interesuje. Uczestnicy muszą jednak podać podstawowe informacje o swojej firmie, takie jak nazwa, adres i dane kontaktowe jej właściciela lub menedżera. Uczestnicy mogą być też proszeni o podanie informacji finansowych, takich jak roczne przychody firmy. Po przesłaniu zgłoszenia D&B sprawdzi je i jeśli zostanie zatwierdzone, wyda numer DUNS. |
| Przejście z wersji próbnej origin na ogólną dostępność | Czy przejście z wersji próbnej origin na ogólną dostępność wpłynie na obecnych testerów wersji próbnej origin? | Od lipca testerzy będą mieli dostęp do interfejsów API trafności i pomiarów. Spowoduje to pokrywanie się dostępności wersji próbnej origin i ogólnej dostępności. |
| Badanie dotyczące AdExchanger | Więcej informacji o metodologii ankiet | Ankieta poproszono użytkowników o szacowanie częstotliwości synchronizacji i przychodów dla ich firm. Metodologia odpowiadania na poszczególne pytania użytkowników pozostawała tylko do nich. |
| Wartości parametrów | Jak określane są wartości parametrów, takie jak poziom szumu, progi anonimowości i budżet na potrzeby prywatności? | To wyjaśnienie na GitHubie przedstawia ogólne zasady działania interfejsów API Piaskownicy prywatności. Wiele wartości jest nadal dopracowanych, dlatego chętnie poznamy Twoją opinię na ten temat. |
Wyświetlaj trafne treści i reklamy
Tematy
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Ochrona prywatności | Badania oceniające interfejs Topics API w zakresie ochrony prywatności | Aktywnie angażujemy się w kontakty ze społecznością badaczy, prezentując wyniki naszych badań nad właściwościami prywatności interfejsu Topics API w publikacjach, raportach i prezentacjach podczas warsztatów. Cieszymy się, że coraz więcej osób zewnętrznych ze społeczności badaczy interesuje się tymi kwestiami. Interfejs Topics API chroni użytkowników przed ogólnym śledzeniem w internecie, utrudniając śledzenie wielu użytkowników na dużą skalę. Te dokumenty potwierdzają, że odnosimy do nich efekty za pomocą interfejsu Topics API. Zapewnia on większą prywatność niż pliki cookie innych firm i chroni użytkowników, jednocześnie umożliwiając im korzystanie z ulubionych stron. |
| Taksonomia tematów nie jest wystarczająco szczegółowa | Ogólna mapa kategorii nie uwzględnia bardziej szczegółowych tematów, także związanych z regionem. | W odpowiedzi na poprzednie opinie z ekosystemu 15 czerwca opublikowaliśmy posta na blogu, w którym opisujemy nową zaktualizowaną taksonomię, która obejmuje liczne ulepszenia wprowadzone na podstawie opinii z ekosystemu. W ramach prac nad poprawioną taksonomią nawiązaliśmy współpracę z kilkoma firmami z całego ekosystemu, takimi jak Raptive (dawniej CafeMedia) i Criteo. Zaktualizowana taksonomia usuwa kategorie, które naszym zdaniem są mniej przydatne, na rzecz kategorii, które lepiej pasują do zainteresowań reklamodawców. Jednocześnie zachowujemy nasze zobowiązanie do wykluczania potencjalnie kontrowersyjnych tematów. Zachęcamy do zapoznania się z najnowszą taksonomią i przekazania opinii na temat wprowadzanych zmian. |
| Proces aktualizowania taksonomii i klasyfikatora | Więcej informacji o taksonomii tematów i klasyfikatorach oraz o tym, jak firmy mogą się do nich przygotować. | Jak wspomnieliśmy w niedawnym poście na blogu, przewidujemy, że taksonomia będzie się z czasem zmieniać, a zarządzanie nią powinno w końcu zostać przekształcone w zewnętrzny podmiot reprezentujący zainteresowane osoby z całej branży. Udostępniliśmy też plan optymalizacyjny na grupie topics-ogłoszenia. |
| Wpływ na sygnały własne | Wzrost liczby tematów w niedawnej aktualizacji taksonomii może być bardzo cenny, ponieważ może obniżyć wartość innych własnych sygnałów opartych na zainteresowaniach. | W raporcie CMA za I kwartał 2023 r. dyrektorka CMA komentuje: „Zdajemy sobie sprawę, że Google omawia proponowaną nową taksonomię z kilkoma uczestnikami rynku w całym łańcuchu dostaw technologii reklamowych. Kilku dużych wydawców twierdzi, że większa przydatność tematów zwiększy presję na konkurencyjne rozwiązania oparte na danych własnych, jednak wstępnie twierdzimy, że większa użyteczność jest lepsza dla konkurencji – zwłaszcza wtedy, gdy mniejsze wydawcy mogą nadal zarabiać na swoich zasobach reklamowych po wycofaniu plików cookie innych firm”. Nasze stanowisko jest zgodne z komentarzem wygłoszonym przez CMA. |
| Przydatność dla różnych zainteresowanych osób | Technologie reklamowe, które działają jako platformy SSP i DSP, mogą mieć znaczną przewagę nad innymi podmiotami ekosystemu. | Nasza odpowiedź nie zmieniła się w porównaniu z poprzednimi kwartałami: „Firma Google zobowiązała się do opracowania i wdrożenia propozycji Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samo podawanie się przez własną firmę Google i uwzględniać wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszej pracy z tymi zobowiązaniami. W miarę postępów testów Piaskownicy prywatności jednym z najważniejszych pytań, jakie będziemy musieli ocenić, będzie skuteczność nowych technologii w przypadku różnych rodzajów zainteresowanych osób. Opinie użytkowników są w tym przypadku bardzo ważne – zwłaszcza konkretne i przydatne informacje, które mogą nam pomóc w ulepszaniu projektów technicznych. Współpracowaliśmy z CMA nad opracowaniem naszego podejścia do testów ilościowych i popieramy publikację przez CMA notatki na temat projektu eksperymentu, która zapewni uczestnikom rynku dodatkowe informacje i okazję do wypowiedzenia się na temat proponowanych metod”. |
| Tematy podrzędne | Czy przy założeniu, że kryterium wyboru tematów jest częstotliwość wizyt w przeglądarce, czy fragmentacja segmentu sprawi, że tematy podrzędne nigdy nie staną się u góry? | Chrome sprawdza obecnie inne metodologie ustalania rankingu i analizuje inne sygnały, które mogą ją poprawić. W przyszłości przekażemy informacje o naszych zmienionych planach ekosystemowi. |
| Poufność | Celem interfejsu Topics API jest zapewnienie, że informacje o użytkownikach uzyskane lub pobierane z tego interfejsu nie powinny być wrażliwe na twarz użytkownika bardziej wrażliwe niż dane, które można uzyskać przy użyciu współczesnych metod śledzenia. | Uważamy, że interfejs Topics API jest znacznie bardziej prywatny niż obecne technologie, znacznie ogranicza ponowną identyfikację użytkowników i ma na celu wykluczanie tematów o charakterze kontrowersyjnym. Zdajemy sobie sprawę, że tematy można skorelować z danymi własnymi lub łączyć je z danymi własnymi, aby tworzyć kategorie o charakterze kontrowersyjnym, ale uważamy, że interfejs Topics API stanowi krok naprzód w zakresie prywatności użytkowników i dokładamy wszelkich starań, aby go ulepszać. |
| Struktura taksonomii | Dodawanie identyfikatora, obsługi wersji i innej struktury metadanych do taksonomii tematów | Obecnie w odpowiedzi interfejsu API podajemy identyfikator taksonomii. W kierunku długofalowego zarządzania warto sprawdzić obiekt Topics i w razie potrzeby dołączyć dodatkowe metadane na temat obsługi wersji. |
| Kontrola wydawcy | Wydawcy powinni mieć wpływ na to, jakie tematy mają być klasyfikowane jako ich witryny. | Błędna klasyfikacja witryn może spowodować, że wskaźnik Topics będzie nieco mniej przydatny jako sygnał, ale niewłaściwie sklasyfikowane witryny nie są bardziej ani mniej szkodliwe niż inne witryny. Dzieje się tak, ponieważ w przypadku aukcji zawsze dostępne są informacje kontekstowe witryny, dzięki czemu informacje są porównywalne z prawidłowym tematem, nawet w przypadku błędnej klasyfikacji. Zachęcamy do przesyłania opinii na ten temat. Umożliwienie wydawcom kontrolowania klasyfikacji wiąże się z pewnym ryzykiem. Witryny mogą nieprawidłowo klasyfikować swoje witryny celowo, zmniejszając ich przydatność dla wszystkich użytkowników lub kodować treści wrażliwe w mniej powszechnych tematach, szkodząc prywatności użytkowników. |
| Rozszerzenia do Chrome | Zezwalaj rozszerzeniom do Chrome na zarządzanie tematami i ich filtrowanie, podobnie jak w przypadku obecnych rozszerzeń do zarządzania plikami cookie | Powinno to być już możliwe, co omówiliśmy na GitHubie, ale chętnie poznamy dodatkowe opinie z ekosystemu. |
| Przejście na tryb ogólnej dostępności | Czy przejście z wersji próbnej origin na ogólną dostępność będzie miało wpływ na interfejs Topics API? | Użytkownicy, którzy przejdą z wersji próbnej origin na ogólną dostępność, nie utracą danych. |
| Prywatność | Nazwy hostów mogą zawierać informacje prywatne, które mogą zostać ujawnione przez interfejs Topics API | Stosujemy szereg środków ograniczających ryzyko, które mają na celu zapewnienie prywatności, jak opisano tutaj. |
| Oszustwa i nadużycia | Jak zapobiegać manipulacji Topics przez fałszywe wizyty | Łagodzenie środków zostało wyjaśnione tutaj. |
| Klasyfikator tematów | Czy witryny mogą prosić o zmianę klasyfikacji tematów? | Chętnie poznamy opinie ekosystemu na ten temat i prosimy o opinie tutaj. |
| Witryny dostawców tematów | Określ witryny hostujące treści dotyczące wielu tematów jako „witryny dostawców tematów specjalnych” i trenuj klasyfikatory na podstawie tagów podanych na stronach internetowych. | Omawiamy ją tutaj. Chętnie poznamy też dodatkowe opinie. |
Protected Audience API (wcześniej FLEDGE)
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Kształtowanie natężenia ruchu | Wpływ filtrowania opartego na SSP na wydajność w celu optymalizacji obciążenia zapytań na sekundę (QPS) | Spędziliśmy sporo czasu na rozważaniu kształtowania ruchu i zalecamy korzystanie z pamięci podręcznej przez platformy SSP. |
| Ilość testowa | Testowanie Protected Audience API jest trudne, ponieważ platformy SSP i platformy DSP mają trudności z uzyskaniem dużego natężenia ruchu. | Nieustannie współpracujemy z partnerami SSP i DSP, aby wdrażali i testowali Chronione grupy odbiorców. Rozpoczęliśmy ogólną dostępność i mamy pewność, że odsetek ruchu z włączonymi reklamami PA sprawi, że partnerzy będą mogli je przetestować. |
| złożoność | Wdrożenie funkcji Protected Audience API wymaga znacznych nakładów pracy i kosztów. | Zdajemy sobie sprawę, że trudno jest wdrożyć nowe technologie, w tym Piaskownicę prywatności. Zespół Piaskownicy prywatności ściśle współpracuje z wieloma partnerami, aby edukować i wspierać ich wysiłki. Nieustannie ocenia też inne działania wspierające wdrażanie ekosystemu. |
| Zaufane środowiska wykonawcze | Obsługa zaufanych środowisk wykonawczych (TEE) w niepublicznych środowiskach chmurowych | Chociaż analizujemy potencjalne opcje pomocnicze wykraczające poza rozwiązania działające w chmurze, obecnie nie jest możliwe wsparcie lokalnych dostawców technologii reklamowych ze względu na lokalne ograniczenia zabezpieczeń, które wymagałyby czasochłonnej oceny Piaskownicy prywatności. Biorąc pod uwagę wymagania dotyczące bezpieczeństwa Piaskownicy prywatności i poważne wyzwania, jakie wiążą się z wdrożeniami lokalnymi, uważamy, że dalsze rozwijanie i ulepszanie wdrożeń działających w chmurze (np. wspieranie GCP oprócz AWS) przynosi największe korzyści dla ekosystemu. Potrzebujemy jednak dodatkowych informacji na temat tego, dlaczego takie wymaganie jest konieczne. |
| Struktura kosztów | Oferty pakietowe dotyczące ustalania stawek i usług aukcyjnych zwiększają koszty i złożoność technologii reklamowych w porównaniu z modelami po stronie klienta. | Obecnie pracujemy nad szacowaniem kosztów obsługi procesów związanych z ustalaniem stawek i aukcji na serwerze Ustalanie stawek i aukcji, który będzie powiązany z wykorzystaniem technologii reklamowych i będzie spełniać jeden z celów naszych projektów. |
| Osie czasu K-Anon | Kiedy planowane ograniczenia k-anonimowości będą egzekwowane w przypadku metody „renderUrl”? | Pracujemy nad wyjaśnieniem harmonogramu egzekwowania zasad, które wkrótce opublikujemy. |
| ograniczenia runAdAuction | Czy w Chrome można ograniczyć możliwość wywoływania elementu runAdAuction tylko z górnej strony? |
Chociaż nasz projekt w pełni obsługuje funkcję runAdAuction, którą można wywoływać z górnej strony, uważamy, że bardziej szkodliwe dla wydawców byłoby ograniczenie tej funkcji do wywoływania tylko z domeny najwyższego poziomu.Z ekosystemu wynika, że Piaskownica prywatności musi zminimalizować obciążenie wydawców i reklamodawców. Takie opinie są zgodne z ogólną zasadą tworzenia stron internetowych, zgodnie z którymi właściciele witryn mogą wykorzystywać do tego celu narzędzia innych firm. Celem Piaskownicy prywatności jest stworzenie zdrowego ekosystemu bez konieczności określania zasad działania wydawców i technologii reklamowych. Jesteśmy przekonani, że wydawcy mogą wybierać, kto i w jaki sposób wywołuje usługę runAdAuction w ich witrynie, dlatego dajemy wydawcom elastyczność w znalezieniu ścieżki dopasowanej do ich wymagań. |
| Pomoc przy wdrażaniu | Czy Chrome może tworzyć aukcje open source na aukcji dla wielu sprzedawców lub wnosić w nią swój wkład? | Celem Piaskownicy prywatności jest rozwijanie technologii chroniących prywatność, które nie korzystają z plików cookie innych firm ani innych identyfikatorów w różnych witrynach. Chcemy wspierać zdrowy ekosystem bez konieczności określania zasad działania technologii reklamowych. W naszym repozytorium GitHub opublikowaliśmy wskazówki na temat działania interfejsów API i jesteśmy otwarci na poznawanie rozwiązań z branży. Nie planujemy tworzyć żadnych konkretnych wdrożeń, ponieważ naszym głównym celem jest tworzenie technologii platform, a nie określanie strategii korzystania z tych technologii. Nasze technologie pomogą firmom z branży technologii reklamowych jak najlepiej obsługiwać klientów, zapewniając im odpowiednie zabezpieczenia. |
| Aukcje wielu sprzedawców | Czy Chrome będzie wymuszać udostępnianie „kontekstowego” zwycięzcy aukcji komponentów? | Protected Audience API umożliwia stronom inicjującym aukcję dla wielu sprzedawców przekazywanie informacji na aukcji składowej (uwaga: tylko przed zainicjowaniem aukcji). Nie widzimy jednak, w jaki sposób przeglądarka może określić, czy dana informacja jest najskuteczniejsza w kontekście, czy nie. Nie byliśmy więc w stanie egzekwować blokowania ani wymagać określonych informacji. |
| Preferencje użytkownika dotyczące śledzenia zgody | Adtech pyta do agencji PA, w jaki sposób prawidłowo wdrożyć śledzenie zgody użytkownika | Nasza odpowiedź zawiera to, co powiedzieliśmy w I kwartale: „W przypadku konkretnych reklam odpowiednie technologie reklamowe to najlepsza opcja do kontroli nad tym, jakie kreacje są wyświetlane i w jaki sposób są wybierane”. W majowym maju WICG Protected Audience Meet omówiliśmy kilka scenariuszy związanych z tym problemem i zachęcamy do dodatkowych opinii i dyskusji na ten temat. |
| Niestandardowe listy odbiorców | Czy interfejs Protected Audience API będzie obsługiwać przypadki użycia SSP związane z tworzeniem niestandardowych list odbiorców? | Protected Audience API umożliwia platformom SSP i innym dostawcom technologii reklamowych posiadanie niestandardowych list odbiorców i zarządzanie nimi. Pracujemy nad dalszą integracją platformy SSP z interfejsem API PA i będą dostępne dla platform SSP i innych dostawców technologii reklamowych, aby wspomóc ich działania w zakresie integracji. |
| Formaty | Czy interfejs Protected Audience API obsługuje filmy? | Reklamy wideo są dostarczane na jeden z dwóch sposobów: jako kod XML lub HTML VAST (reklama Out-Stream, która może też wczytywać kod XML VAST również w odtwarzaczu). Kupujący mogą zwracać każdy z tych formatów za pomocą adresu URL renderowania. Specyfikacja VAST została niedawno zaktualizowana w celu obsługi interfejsu Attribution Reporting API. Witryny wyświetlające reklamy wideo będą musiały przygotować się na sposób wyświetlania reklam przez Protected Audience API. Oznacza to, że tagi miejsc docelowych muszą przekazywać adres URL z elementu iframe w ramach Protected Audience API do odtwarzacza wideo. W przypadku ramek ogrodzonych postaramy się spełnić wymagania dotyczące filmów, zanim będzie można korzystać z ramek z zabezpieczeniem, co nastąpi nie wcześniej niż w 2026 roku. |
| Tempo | Jak działa przypadek użycia tempa z interfejsem Protected Audience API? | Doceniamy tę opinię. Zależy nam na otrzymaniu większej liczby takich zgłoszeń, w tym od większej liczby partnerów SSP, ponieważ do tej pory w większości dotyczy to platform DSP. |
| Częstotliwość aktualizacji | Częstotliwość połączeń z: dailyUpdate (do 1 na grupę zainteresowań dziennie) może nie być wystarczająca w niektórych przypadkach użycia, takich jak aktualizowanie informacji o produkcie. |
Doceniamy tę opinię. Istnieją też inne rozwiązania pozwalające technikom reklamowym używać sygnałów odświeżanych w różnych cyklach, takich jak wyszukiwania K/V. |
| Kontrola jakości reklamy | Jak wydawcy stosują kontrolę jakości reklam? | Obecnie interfejs Protected Audience API oferuje wydawcom funkcję informowania ich platform SSP o określonych ustawieniach, które mogą wprowadzić w ramach konfiguracji aukcji przed ustaleniem stawki (np. listy odrzuconych na podstawie etykiet powiązanych z reklamami). Chętnie poznamy Twoją opinię na temat dodatkowych funkcji, których może potrzebować ekosystem. |
| Debugowanie | Kiedy funkcja forDebuggingOnly zostanie usunięta? |
Planujemy wycofanie usługi forDebuggingOnly ze względu na zdarzenia straty spowodowane wycofaniem plików cookie innych firm. Planujemy wycofać usługę forDebuggingOnly z turniejów w 2026 roku najwcześniej. |
| Grupy zainteresowań – różne urządzenia | Propozycja włączenia grup zainteresowań korzystających z różnych urządzeń dla uwierzytelnionych klientów użytkownika | Sprawdzamy tę propozycję, ale ze względu na dużą szczegółowość kierowania na różne urządzenia stwarza ona istotne problemy z prywatnością, co zostało omówione w tym problemie na GitHubie. |
| (Również w I kwartale) Remarketing dynamiczny | Czy po wycofaniu plików cookie innych firm remarketing dynamiczny będzie nadal możliwy z użyciem interfejsu Protected Audience API? | Sądzimy, że ten przypadek użycia jest możliwy przy użyciu Protected Audience, co zostało wyjaśnione tutaj. |
| Dane związane z kliknięciami | Dodaj dane związane z kliknięciami do kampanii browserSignals. |
Obecnie prosimy o wyjaśnienie, kiedy nastąpiło kliknięcie, aby udzielić wstępnej pozycji. |
| Funkcje zdefiniowane przez użytkowników w Protected Audience (również w IV kwartale 2022 r.) | Jak funkcje zdefiniowane przez użytkownika (UDF) będą obsługiwane w interfejsie Protected Audience API? Są to funkcje, które użytkownicy mogą zaprogramować, aby zwiększyć funkcjonalność interfejsu API. | Specjaliści z zespołu technologii reklamowych, którzy zgłosili ten problem, wspomnieli, że nadal oceniają możliwości UDF, więc nie ma jeszcze żadnych praktycznych opinii, na które można by odpowiedzieć, a przynajmniej przynajmniej ogólna dostępność. |
| Waluta | Kwot walut nie należy podawać w formie liczb zmiennoprzecinkowych. | Omówiliśmy ten problem szczegółowo tutaj. |
| Funkcje wyboru reklam na platformach innych niż DSSP | Jaką rolę odgrywają serwery reklam w aukcjach interfejsu Protect Audience API? | Wiemy, że serwery reklam nadal chcą oferować usługi wyboru reklam po ustaleniu stawki i optymalizacja kreacji dynamicznych. Obecnie analizujemy szczegółową analizę luki między obecnym interfejsem Protected Audience API a tymi żądaniami. |
| GenerateBid | Obsługa propozycji Google Ads polegającej na zwróceniu więcej niż jednej reklamy kandydującej na grupę zainteresowań w grupie generateBid i uzyskaniu oceny tych kandydatów w wyniku `scoreAd`. |
Jest on obecnie sprawdzany. Zachęcamy do przesyłania dodatkowych opinii. |
| Zamówienie aukcji | Czy aukcje interfejsu Protected Audience API muszą być ostatnie, aby mogły uwzględniać wyniki wszystkich innych aukcji? | Nie ma wymagań technicznych, aby interfejs Protected Audience API działał jako ostatni. |
| Nawigacja niezainicjowana przez użytkownika | Udostępnij nawigację nieinicjowaną przez użytkownika | Analizujemy Twoją prośbę i rozpatrujemy ją tutaj . Prosimy o dodatkowe opinie. |
| Zapisywanie w pamięci podręcznej | Platforma SSP nie powinna tworzyć sygnałów perBuyerSignals danej platformy DSP z pamięci podręcznej, jeśli zmieni się stan użytkownika. | Zdajemy sobie sprawę, że buforowanie nie działa w każdym przypadku użycia sygnałów na kupującego, dlatego analizujemy dalsze opcje. Chętnie poznamy też opinie członków ekosystemu dotyczące tego, czy buforowanie sprawdza się w ich przypadkach. |
| Raportowanie atrybucji i chroniona grupa odbiorców | W jaki sposób interfejs Attribution Reporting API może współpracować z interfejsem Protected Audience API? | Integracje są obecnie dostępne w przypadku interfejsu Protected Audience API w obu trybach interfejsu Attribution Reporting API (na poziomie zdarzenia i w raportach podsumowujących). Więcej informacji o ulepszonej integracji interfejsu Protected Audience API i Attribution Reporting udostępniliśmy 1 czerwca. Więcej informacji na ich temat znajdziesz tutaj. |
| Punkt końcowy serwera | Czy w ostatecznym projekcie punkt końcowy serwera będzie zaufanym serwerem agregacji? | Punkt końcowy serwera to utrzymany w technologii reklam punkt końcowy, który jest niezależny od zaufanych serwerów agregacji używanych do przetwarzania zebranych i przekształconych raportów. W tej chwili nie planujemy żadnych zmian w punkcie końcowym raportowania. Obecny projekt ma na celu zagwarantowanie, że same raporty zbiorcze (z zaszyfrowanymi ładunkami) nie będą ujawniać danych z innych witryn, więc zaufany punkt końcowy nie powinien być potrzebny. Dodatkowy problem polega na tym, że różne technologie reklamowe będą prawdopodobnie miały odmienne strategie grupowania. Zachęcamy do przesyłania dodatkowych opinii. |
| WebIDL | Obecna specyfikacja interfejsu Protected Audience API jest niezgodna ze specyfikacją WebIDL. | Oceniamy te opinie i dyskutujemy na ten temat. |
| Zarządzanie zgodą użytkowników | Jak będzie obsługiwane przekazywanie sygnałów zgody w interfejsie Protected Audience API? | Interfejs Protected Audience API nie obejmuje informacji kontekstowych. Omawiamy ten problem. Chętnie poznamy też dodatkowe opinie. |
| Marketing na podstawie konta | Czy byłoby możliwe zastosowanie marketingu opartego na koncie? | Protected Audience API obsługuje różne przypadki użycia marketingowe w oparciu o odbiorców. Nadal wiemy, jak najlepiej wykorzystać interfejs Protected Audience API w tym konkretnym przypadku użycia. Dlatego prosimy o dodatkowe opinie z ekosystemu na ten problem. |
| Aukcja komponentów | Jakie wyniki otrzymują uczestnicy aukcji, która bierze udział w aukcji? | Aukcje komponentów nie oceniają bezpośrednio grup zainteresowań, ale oceniają reklamy i stawki przesyłane przez platformę DSP za pomocą funkcji generateBid. Funkcja generateBid() działa zgodnie z grupą zainteresowań, a DSP zwraca ten kod podczas wykonywania metody generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Publikowane treści | Prośba o obsługę zewnętrznych publikacji w bazie kodu GitHuba na serwerze kluczy/wartości. | Staramy się zaktualizować nasze odpowiednie procesy, aby umożliwić przekazywanie kodu na GitHubie przez osoby spoza organizacji. |
| Wielkość grupy zainteresowań | Jaka jest maksymalna liczba kluczy obsługiwana przez IG? | Obecny limit to 50 KB na 1 IG i liczą się do niego klucze. Zachęcamy do dalszej dyskusji na temat limitu rozmiaru. |
| Grupowanie | Jak można zmniejszyć liczbę wywołań serwera K/V? | Aby zmniejszyć liczbę wywołań K/V, możesz użyć nagłówków HTTP Cache-Control. Może na przykład być przechowywana w pamięci podręcznej w składowych aukcjach, a także w boksach reklamowych na jednej stronie. |
| Version control | Obsługa wielu wersji kodu technologii reklamowych | Usługi ustalania stawek i usługi aukcyjne będą obsługiwać wiele wersji kodu technologii reklamowych. W interfejsie API do określania stawek i aukcji żądanie SelectAd może określać wersję kodu używanego w żądaniu aukcji (np. na potrzeby ustalania stawek / aukcji czy też raportowania). |
| Pamięć współdzielona | Obsługa zapisu do pamięci współdzielonej w ramach usługi określania stawek i usługi aukcyjnej. | Obecnie Ustalanie stawek i usługi aukcyjne nie obsługują pamięci współdzielonej, ale chętnie poznamy dodatkowe opinie o tym, dlaczego takie przypadki użycia są ważne dla ekosystemu. |
| Przejście z witryny do aplikacji | Obsługa udostępniania między internetem a aplikacją grup zainteresowań. | Funkcja Web-to-app nie jest obecnie objęta wdrażaniem Protected Audience API w Chrome i na Androidzie, ale chętnie dowiemy się, jak ważny jest ten przypadek użycia w ekosystemie. |
| K-anonimowość | Obsługa wartości zastępczych K-anonimowości | Omawiamy ten problem i chętnie poznamy dodatkowe opinie. |
Pomiary reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Alternatywne konfiguracje raportu na poziomie zdarzenia konwersji po wyświetleniu | Opinia na temat alternatywnych konfiguracji raportu o konwersjach po wyświetleniu na poziomie zdarzenia | Dotarły do nas opinie, że obecne konfiguracje na poziomie zdarzenia nie są optymalne i prosimy o opinię na temat optymalnych konfiguracji globalnych. Jesteśmy otwarci na dodatkowe uwagi na ten temat i uważamy, że nasze elastyczne wyjaśnienie na poziomie zdarzenia może pomóc w rozwiązaniu tego problemu. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jaki jest stan funkcji elastycznych konfiguracji na poziomie zdarzenia? | Opublikowaliśmy dokumentację dotyczącą elastycznej konfiguracji na poziomie zdarzenia. Funkcja jest nadal na etapie składania oferty, więc chcielibyśmy dowiedzieć się więcej o tym, czy będzie przydatna dla ekosystemu. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jak można uzgodnić sprzeczne zgłoszenia od różnych stron? | Do większości scenariuszy raportowania służą raporty zbiorcze, natomiast elastyczna propozycja konfiguracji na poziomie zdarzenia zapewnia szczególną elastyczność raportów na poziomie zdarzenia, które są najczęściej używane do optymalizacji. Chętnie poznamy też dodatkowe komentarze i opinie dotyczące tego scenariusza. |
| Rejestracja źródła | Co się stanie, jeśli rejestracja źródła nastąpi po zarejestrowaniu aktywatora? | Obecnie, jeśli rejestracja źródła nastąpi po zarejestrowaniu reguły, nie będzie można przypisywać sobie nawzajem źródła i reguły. To chyba skrajny scenariusz. Chętnie poznamy Twoją opinię na temat tego problemu i postaramy się go rozwiązać, jeśli pojawi się ona w przypadku tej sytuacji wielu techników reklamowych. |
| Współpraca z wieloma agencjami reklamowymi | W jaki sposób platformy DSP mogą korzystać z interfejsu Attribution Reporting API, gdy reklamodawca współpracuje z wieloma agencjami reklamowymi? | Interfejs API obsługuje przekierowania, więc można go używać nawet wtedy, gdy reklamodawca współpracuje z wieloma agencjami reklamowymi. Istnieją też pewne ograniczenia dotyczące przekierowań, aby zapewnić lepszą ochronę prywatności w interfejsie API. Opracowaliśmy też potencjalne obejście problemu związanego z użyciem interfejsu API współdzielonego miejsca na dane w przypadku tej konkretnej sytuacji. Będziemy wdzięczni za wszelkie dodatkowe opinie na temat tego scenariusza i na podstawie tych opinii będziemy go powtarzać. |
| Limity miejsc docelowych | Na automatycznie odświeżane reklamy mogą mieć wpływ limity miejsc docelowych. | Omówiliśmy ten problem na spotkaniu WICG, które odbyło się 1 maja, i szukamy opinii na temat rozsądnego limitu. Do funkcji raportowania atrybucji z wyjaśnieniem raportów na poziomie zdarzenia dodaliśmy informację, że przeglądarka może ograniczać liczbę „docelowych” adresów eTLD+1 reprezentowanych przez witryny źródłowe. (Zobacz żądanie pobierania). |
| Raportowanie atrybucji i chroniona grupa odbiorców | W jaki sposób interfejs Attribution Reporting API może współpracować z interfejsem Protected Audience API? | Integracje są obecnie dostępne w przypadku interfejsu Protected Audience API w obu trybach interfejsu Attribution Reporting API (na poziomie zdarzenia i w raportach podsumowujących). Więcej informacji o ulepszonej integracji interfejsu Protected Audience API i Attribution Reporting udostępniliśmy 1 czerwca. Więcej informacji na ich temat znajdziesz tutaj. |
| Elastyczne konfiguracje na poziomie zdarzenia | Podziel się sprawdzonymi metodami dotyczącymi symulacji szumów, gdy parametry można już konfigurować. | Na GitHubie udostępniliśmy udostępniony kod, za pomocą którego każdy może ocenić ilość informacji i wpływ informacji na temat dowolnych elastycznych konfiguracji na poziomie zdarzenia, które chce przetestować. Chętnie poznamy opinie wszystkich osób, które zdecydujeją się przetestować kod, i podzielą się opinią. |
| Pomiar atrybucji w różnych aplikacjach i w internecie | Kiedy będzie dostępny pomiar atrybucji w aplikacjach i w internecie? | 9 maja ogłosiliśmy udostępnienie eksperymentu do pomiaru atrybucji w różnych aplikacjach i w internecie przy użyciu interfejsu Attribution Reporting API. Chociaż interfejsy API trafności i pomiarów dostępne w Chrome 115 są ogólnie dostępne, pomiar atrybucji w różnych aplikacjach i w internecie nie jest obecnie ogólnodostępny w Chrome 115. |
| Usuwanie duplikatów konwersji | W jaki sposób można uzgodnić niezależne rozwiązania analityczne z porównaniem ARA? | Tak jak w przypadku obecnej metody standardowej, reklamodawcy korzystają z zewnętrznych i niezależnych dostawców usług pomiarowych, aby usuwać duplikaty raportów o konwersjach. Opracowaliśmy materiały dotyczące usuwania duplikatów konwersji w raportach na poziomie zdarzenia. |
| Utrata danych podczas aktualizacji bazy danych raportu atrybucji | Czy zgodnie z ogłoszoną aktualizacją Chrome nastąpi utrata danych związanych z aktualizacją Bazy danych atrybucji? | Od wersji stabilnej Chrome 115 zaczniemy domyślnie włączać interfejsy Trafność i Pomiar skuteczności u części użytkowników Chrome. Ta ogólna dostępność wzrośnie, ponieważ będziemy monitorować potencjalne problemy. Osiągnięcie pełnej dostępności w ciągu kilku tygodni do III kwartału 2023 r. Zbiegnie się to w czasie testowania origin Trafność i Pomiar skuteczności. Od lipca testerzy będą mogli zarejestrować się, aby uzyskać ogólnodostępny dostęp do tych interfejsów API. Spowoduje to pokrywanie się dostępności wersji próbnej origin i ogólnej dostępności w trakcie rejestracji. Token próbny origin będzie ważny do 19 września, ale zalecamy zarejestrowanie się w interfejsach API przed jego wygaśnięciem, aby płynnie wyjść z testu origin bez przerywania trwających testów. Jak wspomnieliśmy w tym ogłoszeniu, dane zarejestrowane ze starszych wersji (M113 i starszych) nie zostaną przeniesione po aktualizacji, więc może to spowodować utratę danych. Ta utrata danych nie będzie widoczna w raportach debugowania. Postaramy się uniknąć utraty danych między 114 a 115. |
| Rozliczenia | Korzystanie z raportów atrybucji do rozliczeń kosztu konwersji | Jak wspomnieliśmy w tym artykule, interfejs Attribution Reporting API może nie być odpowiedni dla rozliczeń związanych z kosztem konwersji z powodu szumu do raportów podsumowujących i na poziomie zdarzenia. Zachęcamy użytkowników ekosystemu do dzielenia się opiniami na temat wpływu atrybucji na różne modele rozliczeniowe za pomocą interfejsu Attribution Reporting API w serwisie GitHub. |
Usługa agregacji
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Zbiorcza zmiana opóźnienia raportu | Reakcje pozytywne na propozycję zmiany opóźnienia w raporcie zbiorczym z [10–60 minut] na [0–10 minut] na podstawie opinii z ekosystemu | Z przyjemnością spotkamy się z pozytywną reakcją na proponowaną zmianę i zachęcamy członków ekosystemu do dalszego przekazywania opinii na temat naszych propozycji. |
| Rozwiązanie lokalne | Czy usługę agregacji można wdrożyć w lokalnych centrach danych? | Chociaż analizujemy potencjalne opcje pomocnicze wykraczające poza rozwiązania działające w chmurze, obecnie nie jest możliwe wsparcie lokalnych dostawców technologii reklamowych ze względu na lokalne ograniczenia zabezpieczeń, które wymagałyby czasochłonnej oceny Piaskownicy prywatności. Biorąc pod uwagę wymagania dotyczące bezpieczeństwa Piaskownicy prywatności i poważne wyzwania, jakie wiążą się z wdrożeniami lokalnymi, uważamy, że dalsze rozwijanie i ulepszanie wdrożeń działających w chmurze (np. wspieranie GCP oprócz AWS) przynosi największe korzyści dla ekosystemu. Potrzebujemy jednak dodatkowych informacji na temat tego, dlaczego takie wymaganie jest konieczne. |
| Ponowne przetwarzanie raportów w przypadku różnych okresów | Możliwość ponownego przetwarzania raportów dla różnych okresów | Dotarły do nas podobne prośby o możliwość podziału wsadów na różne zakresy dat. Jedną z możliwości jest umożliwienie rozszerzenia udostępnianego identyfikatora o etykietę zdefiniowaną technicznie w reklamie, co pozwoli na dzielenie raportów na różne porcje. Jesteśmy w trakcie oceny tego procesu i na bieżąco będziemy aktualizować ekosystem. |
| konsekwencje związane z ochroną prywatności dotyczące zaufanego środowiska wykonawczego | Pozytywne nastawienie do wpływu zaufanych środowisk wykonawczych na ochronę prywatności | Cieszymy się z pozytywnych reakcji ze strony ekosystemu na nasze propozycje i chętnie poznamy kolejne opinie na ich temat. |
| Warunki korzystania z usługi | Jaki jest termin zaakceptowania Warunków korzystania z usługi agregacji? | Nie określiliśmy jeszcze terminu zaakceptowania warunków korzystania z usługi, ale zachęcamy firmy ekologiczne do jak najszybszego zaakceptowania tych warunków, aby uniknąć opóźnień w rejestracji. Zachęcamy firmy do kontaktu w razie pytań. |
| Odkrywanie najważniejszych momentów | Funkcja wykrywania kluczy umożliwia testerom wykonywanie zapytań dotyczących raportów zbiorczych bez konieczności tworzenia listy możliwych kombinacji kluczy w celu przetwarzania raportów podsumowujących na potrzeby atrybucji międzysieciowej w celu zwiększenia skuteczności i dokładności. | Obecnie szukamy możliwych rozwiązań i obejść zabezpieczeń. Czekamy na dodatkowe opinie z ekosystemu. |
Interfejs Private Aggregation API
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Źródło raportowania | Jak jest definiowane źródło raportowania? | Źródło raportowania to zawsze źródło skryptu wywołującego agregację prywatną. |
| 128-bitowy obszar klucza | Przejrzystość ograniczenia przestrzeni kluczy 128-bitowych | Zrobimy to dokładniej i wyeliminujemy niespójności na różnych stronach. Zalecamy stosowanie strategii haszowania, by nie przekraczać tej przestrzeni kluczy. |
| Maksymalny wkład na raport | Obecny limit 20 elementów opublikowanych na raport jest za niski. | Zamiast zwiększać maksymalną liczbę publikowanych przez nas raportów, jesteśmy otwarci na podział raportów zamiast na obcinanie limitu. W miarę rozwoju tej oferty będziemy angażować się w ekosystem. |
| Raportowanie zasięgu | Prośba o raportowanie zasięgu na różnych platformach i na różnych urządzeniach. Zasięg to podstawowy wskaźnik reklam marki. Reklamodawcy korzystają z szacunków dotyczących zasięgu i częstotliwości na wielu platformach i na różnych urządzeniach, aby analizować swoje kampanie i rozdzielać wydatki. Modele zasięgu wykorzystują pliki cookie innych firm jako sygnały do pomiaru reklam wyświetlanych w środowiskach zewnętrznych. Z tego powodu po wycofaniu plików cookie innych firm nasi technicy ds. reklam poprosili o skorzystanie z alternatywnego rozwiązania. |
Zespół Piaskownicy prywatności bada funkcje obsługi metodologii zasięgu w wielu domenach po wycofaniu plików cookie innych firm. Czekamy na dodatkowe opinie z ekosystemu. |
Ogranicz ukrycie
Redukcja klienta użytkownika/wskazówki dotyczące klienta użytkownika
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| (w I kwartale 2023 r.) Wskazówki dotyczące dodatkowych formatów | Prośba o wskazówki dotyczące klienta użytkownika (UA-CH) w celu udostępnienia dodatkowych formatów, takich jak telewizja czy VR | Nadal pracujemy nad kluczowymi decyzjami projektowymi (czy podać jedną wartość, taką jak „telewizor” czy listę funkcji urządzeń), ale zależy nam na prototypowaniu tego pomysłu. |
| Budżet prywatności | Ograniczenia budżetu prywatności mogą spowodować, że żądania UA-CH staną się niedeterministyczne w przypadku wysyłania zbyt wielu żądań. | Na razie nie mamy żadnych nowych zmian w ofercie budżetu prywatności, ale zobowiązaliśmy się nie ograniczać próśb o wskazówki dla klientów UA, zanim pliki cookie innych firm zostaną wycofane. |
| Zgodność witryny | Witryny używają marki UA-CH, aby ograniczać dostęp określonym przeglądarkom do stron. | Istnieją przypadki użycia listy marek, a jednym z nich jest właśnie zgodność. W UA możesz bezpłatnie korzystać z wielu marek, aby rozwiązać te problemy. |
Ochrona IP (dawniej Gnatcatcher)
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Oszustwa i nadużycia | W jaki sposób firmy mogą skonfigurować zabezpieczenia przed oszustwami przy użyciu ochrony adresu IP? | Wiemy, jak ważna jest ochrona przed oszustwami i jaki ma na nie wpływ. Więcej szczegółów na temat zapobiegania oszustwom planujemy opublikować jeszcze tego lata. Chętnie poznamy opinie ekosystemu na temat tego, jak możemy lepiej obsługiwać przypadki użycia związane z zapobieganiem oszustwom. |
| GeoIP | Więcej informacji o harmonogramie testowania i wdrażania GeoIP | W Chrome opublikował(a) niedawno nowe informacje dotyczące naszych planów związanych z geoIP. Więcej informacji o harmonogramie wdrażania planujemy opublikować w III kwartale. Początkowo planujemy wprowadzić ochronę adresów IP jako funkcję włączaną przez użytkowników w przypadku niewielkiego odsetka ruchu. Zdajemy sobie sprawę, że ta propozycja może wiązać się z pewnymi istotnymi zmianami dla firm. Chcemy dać ekosystemowi czas na dostosowanie się do tych zmian i przekazanie opinii, zanim udostępnimy tę funkcję szerzej. |
| Uwierzytelnianie konta | Jak będzie działać uwierzytelnianie konta na serwerze proxy? | Planujemy opublikować więcej szczegółów na temat uwierzytelniania konta jeszcze tego lata, ale przedstawiliśmy już pewne wstępne uwagi. |
Łagodzenie śledzenia przekierowań
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Wskazówki dotyczące testowania | Informacje o testowaniu łagodzenia śledzenia przekierowań | W maju opublikowaliśmy posta na blogu, w którym podajemy więcej informacji o testowaniu łagodzenia śledzenia przekierowań. |
| Dokumentacja | Przejrzystość propozycji śledzenia przekierowań | Obecna propozycja jest w trakcie opracowywania, a Chrome stale ją aktualizuje, aby zapewnić przejrzystość i informacje ekosystemowi. Pracujemy nad dodatkowymi informacjami i chętnie poznamy dodatkowe opinie. |
| Usuwanie plików cookie | Czy łagodzenie śledzenia przekierowań spowoduje usunięcie wszystkich plików cookie w danej domenie? | Łagodzenie śledzenia przekierowań (BTM) powoduje wyczyszczenie całej pamięci podręcznej i całej pamięci podręcznej zgodnie z tym opisem. |
| Unikanie śledzenia przekierowań | Klasyfikację modułu do śledzenia odrzuceń można pominąć, przeprowadzając przekierowania z wyskakującymi okienkami lub nowymi kartami. | Nadal pracujemy nad specyfikacją łagodzenia śledzenia przekierowań. Do tej pory skupialiśmy się głównie na przekierowaniach na tej samej karcie, ale planujemy wprowadzić w przyszłości zmiany w wyskakujących okienkach. Zachęcamy do przesyłania dodatkowych opinii. |
Budżet prywatności
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Kierowanie zbliżone | Budżet na ochronę prywatności może mieć wpływ na przypadki użycia kierowania na zbliżony obszar. | Otrzymaliśmy opinię na temat tego problemu i chcielibyśmy dowiedzieć się więcej o potencjalnym wpływie ekosystemu. |
Wzmocnij granice prywatności między witrynami
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| (raportowano także w poprzednich kwartałach) Limit domen | Poproś o zwiększenie liczby powiązanych domen | Chrome ocenia odpowiedni limit liczbowy dla powiązanego podzbioru, aby zapewnić równowagę między prywatnością a przydatnością w wskazanych przypadkach użycia. Od samego początku informowaliśmy w Chrome, że dokładna liczba powiązanych podzbiorów nie została jeszcze sfinalizowana. |
| Wbudowany przypadek użycia | Obsługa wbudowanych przypadków użycia, które wymagają zestawów źródeł własnych, układów CHIP i pamięci współdzielonej. | Chrome otrzymał opinię na temat tego przypadku użycia. Nasz zespół je analizuje i chętnie pozna dodatkowe opinie. |
| Zarządzanie repozytorium | Informacje o zasadach dotyczących usuwania zestawów źródeł własnych z repozytorium GitHuba w przypadku rozbieżności lub zaniedbań | Chrome otrzymał opinię na temat tego przypadku użycia. Nasz zespół bada tę sprawę i chętnie pozna dodatkowe opinie. |
| Wykształcenie użytkownika | Aby zachęcić użytkowników do korzystania z zestawów źródeł własnych, należy zadbać o ich świadomość i poznanie ich w Chrome. | Celem Chrome jest informowanie użytkowników o zestawach źródeł własnych. Informacje na ten temat opublikowaliśmy w artykule w Centrum pomocy (dostępnym w interfejsie Chrome). Stale staramy się też uczyć, jak najlepiej edukować użytkowników w odpowiednich kontekstach. |
| Opublikuj 3PCD | Po wycofaniu plików cookie innych firm pliki cookie innych firm będą nadal istnieć w zestawie źródeł własnych. | Mimo że requestStorageAccess i requestStorageAccessFor rzeczywiście ponownie udostępniają pliki cookie innych firm w konkretnych, jasno określonych przypadkach użycia, teraz wymagają aktywnego wywołania przez witrynę, a nie domyślnie dostępu, jak w obecnym stanie plików cookie innych firm (w Chrome).Chociaż to wywołanie w jednym zestawie nie wymaga zatwierdzenia przez użytkownika, mogą temu zapobiec, rezygnując z tego działania w Ustawieniach. Więcej informacji dla użytkowników znajdziesz w artykule w Centrum pomocy (link znajdziesz w interfejsie Chrome). Planujemy rozbudować obecny przewodnik dla programistów w miarę zwiększania liczby klatek na sekundę do 100%. |
| Przesyłanie zestawów źródeł własnych | Zmień nazwę wymaganego elementu .well-known/first-party-set, aby uwzględnić w nim rozszerzenie .json. |
Wprowadziliśmy tę zmianę, aby mieć pewność, że niektóre plany hostingu WWW są obsługiwane. |
| Rejestracja IANA | Domena first_party_sets.JSON powinna być zarejestrowana w IANA |
Analizujemy tę propozycję i chętnie poznamy dodatkowe opinie. |
Interfejs Fenced Frames API
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Blokowanie reklam | Ogrodzone ramki mogą ułatwić blokadom reklam blokowanie reklam. | Rozszerzenia mogą wchodzić w interakcje z chronionymi ramkami tak samo jak z elementami iframe. Rzeczywisty adres URL, pod który ma zostać przekierowana ramka chroniona, będzie również widoczny dla rozszerzeń, więc mogą one stosować dowolne reguły dopasowania adresów URL do blokowania, tak jak w przypadku elementów iframe. Samo bezwarunkowe zablokowanie wszystkich chronionych ramek może zakłócić przypadki użycia takich ramek, które nie są reklamami. |
Interfejs API pamięci współdzielonej
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Szersze wdrożenie | Pamięć współdzielona powinna być standardem branżowym dostępnym w przypadku różnych przeglądarek. | Z przyjemnością przyjmujemy tę opinię. Chrome cały czas aktywnie uczestniczy w ramach forów W3C, aby kształtować ofertę, zbierać opinie o niej i wspierać wdrażanie. |
| Bramki wyjściowe | Bramki wyjściowe pamięci współdzielonej są zbyt ograniczone. | Bierzemy pod uwagę te opinie i chętnie poznamy dodatkowe informacje z ekosystemu na temat tego, dlaczego bramki wyjściowe są zbyt ograniczone. |
| Zgodność z regulacjami prawnymi | W jaki sposób pamięć współdzielona będzie radzić sobie z przestrzeganiem przepisów, takich jak zasady przechowywania danych? | Pamięć współdzielona umożliwia elastyczność we wdrożeniu i dostosowaniu funkcji logicznych, aby kontrolować okres ważności i wygaśnięcie wszystkich przechowywanych danych. Technologie reklamowe mogą aktualizować lub usuwać dane w pamięci współdzielonej na podstawie sygnatur czasowych zapisu. |
| Testy A/B | Jak można przeprowadzać testy A/B pamięci współdzielonej i interfejsu Protected Audience API? | Pracujemy nad opublikowaniem dodatkowych wskazówek w tej sprawie i mamy nadzieję, że w przyszłości udostępnimy więcej szczegółów. |
| Limit pamięci współdzielonej | Co się stanie po osiągnięciu limitu pamięci współdzielonej? | Po osiągnięciu limitu żadne dalsze dane wejściowe nie będą zapisywane. |
| Wiele uprawnień dostępu podczas tego samego wczytywania strony | Co się stanie w przypadku wielokrotnego korzystania z pamięci współdzielonej podczas jednego wczytywania strony? | Najlepszym sposobem na rozwiązanie tego problemu jest użycie funkcji window.sharedStorage.append(key, value). Zamiast aktualizować wartość każdej reklamy, w przypadku kilku reklam może to spowodować kolizje. Funkcja dołączenia po prostu doda nową wartość na końcu istniejącej wartości. |
| Funkcje elementu iframe | Czy pamięć współdzielona będzie obsługiwać określone funkcje elementów iframe, gdy przestaną one działać po wycofaniu plików cookie innych firm? | Po wycofaniu plików cookie innych firm lokalna pamięć masowa w elementach iframe będzie partycjonowana przez witrynę najwyższego poziomu, ale same elementy iframe nie będą blokowane. Dane w lokalnej pamięci elementu iframe nie mogą być replikowane w wielu witrynach najwyższego poziomu, ale pamięć lokalna może nadal być używana w ramach elementu iframe. |
ELEMENTY
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Limit partycji | 10 KiB na partycjonowaną witrynę to nadal spora ilość i chcemy ją zmniejszyć. | Firefox wskazał już pozytywną pozycję na ELEMENTACH. Jeśli potrzebujesz pomocy związanej z Webkit, zachęcamy deweloperów do przekazywania opinii bezpośrednio firmie Apple na temat tego problemu na GitHubie. Dotyczą one przypadków użycia, w których partycjonowane pliki cookie są preferowane zamiast partycjonowanych pamięci masowej. |
| Uwierzytelnione umieszczenia | Elementy CHIP mogą wpływać na bieżący proces logowania jednokrotnego z powodu różnych partycjonowania mających wpływ na uwierzytelnione elementy umieszczone na stronie. | Zamierzamy korzystać z interfejsu Storage Access API (z prośbami o zgodę na wykorzystanie danych przez użytkowników) w celu obsługi przypadków użycia uwierzytelnionych umieszczania. Niedawno wysłaliśmy do niego intencję Intent-to-prototype. |
| Zasady bezterminowe | Czy do własnych plików cookie będą miały zastosowanie zasady obowiązujące w ogóle? | Obecnie nie planujemy nakładać limitów na własne pliki cookie bezterminowo. |
FedCM
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Obsługa autoryzacji OAuth | uzgodnienie procesu autoryzowania zakresów OAuth niezwiązanych z profilem profilu; | Aktywnie poszukujemy opinii społeczności Web Identity za pośrednictwem organizacji W3C FedID CG na temat najlepszych sposobów obsługi autoryzacji poza podstawowym uwierzytelnianiem po wycofaniu plików cookie innych firm. |
| Obsługa SAML | Zgodność z wymaganiami dotyczącymi obsługi SAML | Cały czas szukamy w społecznościach badawczych i edukacyjnych opinii na temat potrzeb obsługi SAML (oprócz obsługi OpenID-connect) po wycofaniu plików cookie innych firm. |
Zwalczanie spamu i oszustw
Private State Token API (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Reakcja Chrome |
|---|---|---|
| Odkrywanie nowych sygnałów | Kilku partnerów wyraziło pozytywne nastawienie do korzystania z obsługiwanych przez przeglądarkę sygnałów dotyczących integralności urządzenia lub zaufania użytkowników. Zasadniczo pracownicy ochrony obawiają się też, że nowe, opracowane pod kątem określonych sygnałów są wystarczające do utrzymania obecnego poziomu wykrywania oszustw. | Z przyjemnością zapoznajemy się z nowymi propozycjami w ramach społeczności zajmującej się zwalczaniem oszustw i bezpieczeństwa w internecie. Chcemy też poinformować o ich obawach. Dlatego właśnie „zwalczanie spamu i oszustw” jest głównym elementem Piaskownicy prywatności i dlatego priorytetowo traktujemy kwestie bezpieczeństwa w internecie podczas ulepszania prywatności użytkowników. |
| Pozytywna opinia na temat PST | Kilku partnerów wyraziło zainteresowanie testowaniem lub wykorzystaniem plików PST w różnych przypadkach użycia związanych z zapobieganiem oszustwom i bezpieczeństwem w internecie. | Cieszymy się, gdy otrzymujemy pomoc i chętnie poznamy nowe rozwiązania wykorzystujące pliki PST. Na stronie dla programistów Chrome znajdziesz materiały i przykładowy kod. Zachęcamy do dalszego dzielenia się opiniami. |
| Oszustwa i nadużycia | Wskazówki dotyczące zapobiegania oszustwom reklamowym i wykrywania pomiarów po wycofaniu plików cookie innych firm, gdy identyfikatory nie są już dostępne. | Wprowadziliśmy takie narzędzia jak tokeny prywatności, które pomagają odzyskać część sygnałów utraconych przez pliki cookie innych firm z powodu przeciwdziałania oszustwom, ale wprowadziliśmy nowe ustawienia prywatności. Aktywnie inwestujemy w nowe propozycje dotyczące przeciwdziałania oszustwom i nadużyciom, aby zachować dotychczasowe możliwości po wprowadzeniu innych zmian w Piaskownicy prywatności. |
| Współczynnik wystawcy do informacji o punkcie początkowym | Wskaźnik informacji między wydawcami a źródłami jest wystarczająco wysoki, aby można było zidentyfikować unikalnych użytkowników. | Zaktualizowaliśmy specyfikację, aby lepiej wyjaśnić, jakie dane użytkownika można przekazywać za pomocą tokenów prywatności. Z założenia można używać jednocześnie maksymalnie 6 kluczy publicznych, które mogą reprezentować „stan” danego użytkownika. Te zestawy kluczy można aktualizować tylko co 60 dni (z wyjątkiem rzadkich przypadków, gdy konieczna jest rotacja klucza awaryjnego). Spowalnia to proces łączenia z upływem czasu dodatkowych danych użytkownika. Każdy nowy internetowy interfejs API zapewnia odpowiednią ilość narzędzi i informacji o nowych użytkownikach. Szacujemy, że pliki PST zapewniają odpowiednią równowagę w ochronie prywatności użytkowników, a jednocześnie pozwalają na kluczowe przypadki użycia związane z zapobieganiem oszustwom, na które miało wpływ wycofanie plików cookie innych firm. |
| Pobierz integrację | Integracja z usługą fetch jest skomplikowana i niepotrzebna. |
Korzystanie z usługi fetch ma swoje wady i zalety. Chcielibyśmy kontynuować standaryzację ekosystemu internetowego, ale uważamy, że jest jeszcze za wcześnie na wprowadzenie tej zmiany, dopóki nie będziemy lepiej zrozumieć, jak będzie wyglądać standard. Gdy tylko powstanie dany standard, będziemy też zobowiązani do odpowiedzialnego przejścia na ten standard. |
| Lokalizacja zapisu | Konfiguracje klucza Private State Tokens powinny być przechowywane w tym samym miejscu co protokół PrivacyPass. | Podczas testowania wersji próbnej Origin deweloperzy stwierdzili, że preferują elastyczność przechowywania kluczy pod ogólnymi adresami URL, a nie w katalogu .well-known. Format zobowiązania klucza w PrivacyPass nie najlepiej sprawdza się w wersji, w której zestawy kluczy mają umożliwiać podawanie niejawnej wartości „publicznych metadanych”. Jeśli jakaś wersja PrivacyPass zostanie ustandaryzowana za pomocą publicznych metadanych (np. POPRF, częściowego zaciemniania RSA lub zestawów kluczy), możemy przejść na przyszłą wersję pliku PST, która będzie to obsługiwać. |
| Implementacja interfejsu API w nagłówku | Pytania dotyczące implementacji interfejsu API w nagłówku | W miarę ustandaryzowanego interfejsu API i dostosowania jego wykorzystania w ekosystemie możemy zacząć obsługiwać zarówno standardową wersję tego interfejsu bez nagłówka, jak i ewentualne wycofanie jego wersji z nagłówkiem, jeśli wykorzystanie będzie wystarczające. Omawiamy ten problem tutaj. |
| Rejestracja | Czy rejestracja wydawców u dostawców przeglądarek jest praktyczna? | Zaktualizowaliśmy specyfikację, by opisać proces rejestracji wydawców w przypadku tokenów prywatności. Chociaż korzysta z własnych procesów, podobnie jak w przypadku planów rejestracji w przypadku pozostałych funkcji Piaskownicy prywatności prosimy wydawców o oświadczenie, w jaki sposób zamierzają korzystać z plików PST, oraz o zaakceptowanie ograniczeń technicznych chroniących prywatność użytkowników. |