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ń dotyczących CMA firma Google zobowiązała się publicznie udostępniać kwartalne raporty dotyczące procesu zaangażowania zainteresowanych osób w Piaskownicy prywatności (zapoznaj się z art. 12 i 17(c)(ii) Zobowiązania). Raporty z podsumowaniem opinii na temat Piaskownicy prywatności są generowane przez agregację danych opinie otrzymane w Chrome z różnych źródeł wymienionych w sekcji opinii omówienie, w tym m.in.: GitHub formularz opinii udostępniony privacysandbox.com, spotkania z branżą zainteresowanym i forami internetowymi. Chrome z przyjemnością przyjmuje opinie i aktywnie poszukują sposobów na włączenie decyzji projektowych.
Tematy opinii są uporządkowane według częstotliwości występowania według interfejsu API. Jest to możliwe dzięki ilość opinii otrzymanych od zespołu Chrome na temat dla danego tematu i organizowane w kolejności malejącej według ilości. Często spotykane opinie Tematy zostały określone przez zapoznanie się z tematami dyskusji podczas spotkań publicznych (W3C, PatCG, IETF), bezpośrednia opinia, GitHub i najczęstsze pytania które pojawiają się w wewnętrznych zespołach i publicznych formularzach Google.
Mówiąc dokładniej, protokoły ze standardowych spotkań organów internetowych były przeanalizowaliśmy i – w celach zaopiniowania – zapisy indywidualnych spotkań z zainteresowanymi osobami w Google, e-maili otrzymywanych przez poszczególnych inżynierów, z listy adresowej interfejsu API oraz publicznie został wzięty pod uwagę formularz opinii. Następnie firma Google koordynowała działania zaangażowanych w tego typu działania, by określić krewnych pojawiają się motywy pojawiające się w odniesieniu do poszczególnych interfejsów API.
Wyjaśnienia odpowiedzi Chrome na opinie pochodzą z opublikowanych odpowiedzi na najczęstsze pytania, rzeczywistych odpowiedzi zainteresowanych osób na problemy zwłaszcza na potrzeby tego zgłoszenia publicznego. Odzwierciedlają bieżący cel programowania i testowania, a także pytania i opinie. otrzymane w szczególności w kategoriach Topics, Protected Audience i Attribution, Interfejsy API do raportowania.
Opinie otrzymane po zakończeniu bieżącego okresu raportowania mogły jeszcze nie zostać jest uznawana za odpowiedź Chrome.
Słowniczek akronimów
- CHIPS
- Pliki cookie w niezależnym stanie partycjonowania
- (procesor) DSP
- Platforma DSP
- FedCM
- Sfederowane zarządzanie danymi logowania
- FPS
- Zestawy własne
- 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
- PatCG
- Prywatna grupa społeczności związanych z technologiami reklamowymi
- RP
- Strona uzależniona
- 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
- Ślepota na IP
Ogólna opinia, brak konkretnych interfejsów API/technologii
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zarządzanie danymi Zgodność z regulacjami | Wytyczne ekosystemu dotyczące korzystania z Piaskownicy prywatności zgodnie z wymaganiami prawnymi. | Tak jak w przypadku każdej nowej technologii, każda firma jest odpowiedzialna za to, aby korzystanie z Piaskownicy prywatności było zgodne z prawem. Google nie może udzielać porad prawnych innym osobom. Zdajemy sobie jednak sprawę, że jest to kluczowy obszar naszego ekosystemu. Dla każdego interfejsu API opublikowaliśmy obszerną dokumentację techniczną, która powinna stanowić podstawę do dokonywania niezbędnych ocen prawnych. Pracujemy nad udostępnieniem dodatkowych materiałów na potrzeby firm w celu zapewnienia zgodności z przepisami. |
| Propozycja testów ilościowych CMA | Więcej informacji o propozycji testów ilościowych CMA | Współpracujemy z CMA nad utworzeniem eksperymentów, które dadzą obraz wpływu wycofania plików cookie innych firm i wprowadzenia ofert z Piaskownicy prywatności na ekosystem. W kwietniu CMA opublikowało ogólne wytyczne dotyczące tego, czego można się spodziewać podczas okresu testowania i testowania, a w czerwcu przedstawiła szczegółowe wskazówki. Zachęcamy do przesyłania pytań i opinii na temat propozycji testów ilościowych CMA bezpośrednio do CMA. |
| Tryby testowania obsługiwane przez Chrome | Więcej informacji i wyjaśnienia dotyczące harmonogramów testów | 18 maja opublikowaliśmy posta na blogu, w którym przekazaliśmy więcej informacji na temat dwóch trybów testowania obsługiwanych przez Chrome. Te szczegóły nie są ostateczne. W miarę postępów w III kwartale 2023 r. opublikujemy dalsze wskazówki dotyczące implementacji. |
| Partycjonowana pamięć masowa | Czy podczas testów przeprowadzanych przez Chrome będzie używana partycjonowana pamięć masowa? | Partycjonowanie miejsca na dane będzie wysyłane do wszystkich użytkowników przed eksperymentem dotyczącym wycofania plików cookie innych firm. Dlatego zostanie ono włączone we wszystkich grupach eksperymentu. Witryny będą mogły włączyć okres próbny wycofywania, aby odzyskać w tym okresie miejsce na dane bez partycji. |
| Pomoc przy produkcji | W jaki sposób Chrome obsługuje problemy techniczne i eskalacje mające wpływ na ekosystem w Piaskownicy prywatności? | Google udostępnia wiele kanałów, które umożliwiają technikom reklamowym zgłaszanie problemów i eskalowanie problemów. Przeczytaj nasz post dla deweloperów, aby dowiedzieć się więcej o publicznych i prywatnych forach, na których można przesyłać opinie i przekazywać informacje. |
| Harmonogram rejestracji | Obecny termin rejestracji jest za krótki | Nadal rozważamy termin wprowadzenia tych zmian i chcemy wiedzieć, jaki termin będzie odpowiedni dla naszego ekosystemu. |
| Numer D-U-N-S | Więcej informacji o wymaganym numerze D-U-N-S na potrzeby rejestracji i atestu | Uczestnicy mogą zapoznać się z wymaganiami dotyczącymi uzyskania numeru DUNS na stronie Dun and Bradstreet. Wymagania różnią się w zależności od rynku, dlatego uczestnicy powinni sprawdzić witrynę pod kątem rynku, który ich interesuje. Ogólnie uczestnicy muszą jednak podać podstawowe informacje o swojej firmie, takie jak jej nazwa, adres i dane kontaktowe właściciela lub menedżera firmy. Uczestnicy mogą również zostać poproszeni o podanie informacji finansowych, takich jak roczne przychody firmy. Po wypełnieniu zgłoszenia D&B je sprawdzi i jeśli zostanie zatwierdzone, przyzna numer D-U-N-S. |
| Przejście z wersji próbnej na ogólną | Czy przejście z wersji próbnej origin na ogólną dostępność będzie miało wpływ na obecnych testerów wersji próbnej origin? | Od lipca testerzy będą mieli ogólnie dostęp do interfejsów API trafności i pomiarów. Spowoduje to pokrywanie się dostępności testowania origin i ogólnej dostępności. |
| Badanie AdExchanger | Więcej informacji o metodologii ankiet | W ankiecie poproszono użytkowników o oszacowanie współczynników synchronizacji oraz przychodów dla swoich firm. Użytkowników lecz z metodologii odpowiadania na indywidualne pytania sami. |
| 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 objaśnienie w usłudze GitHub określa ogólne zasady stojące za interfejsami API Piaskownicy prywatności. Wiele z nich jest nadal dopracowanych, więc chętnie poznamy opinie na ten temat. |
Pokaż trafne treści i Reklamy
Tematy
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ochrona prywatności | Badania nad interfejsem Topics API w zakresie ochrony prywatności | Aktywnie współpracujemy ze społecznością badaczy, prezentując nasze badania nad właściwościami prywatności interfejsu Topics API w publikacjach, raportach i prezentacjach warsztatowych. Cieszymy się, że więcej osób z zewnątrz społeczności badaczy interesuje się tym tematem. Interfejs Topics API chroni użytkowników przed ogólnym śledzeniem w internecie, utrudniając śledzenie użytkowników na dużą skalę. Z tych dokumentów wynika, że z powodzeniem korzystamy z interfejsu Topics API. Jest on bardziej prywatny niż pliki cookie innych firm i chroni użytkowników, a jednocześnie obsługuje witryny, które lubią odwiedzać. |
| Taksonomia tematów nie jest wystarczająco szczegółowa | Rozszerzona taksonomia tematów nie obejmuje bardziej szczegółowych tematów, w tym poszczególnych regionów. | W odpowiedzi na wcześniejsze opinie użytkowników opublikowaliśmy posta na blogu 15 czerwca. Opisaliśmy w nim nową zaktualizowaną taksonomię, w której wprowadziliśmy liczne ulepszenia wprowadzone na podstawie opinii użytkowników z ekosystemu. W ramach pracy nad nową taksonomią nawiązaliśmy współpracę z kilkoma firmami działającymi w całym ekosystemie, m.in. Raptive (dawniej CafeMedia) i Criteo. Zaktualizowana taksonomia usuwa kategorie, które naszym zdaniem są mniej przydatne. Zamiast nich zostaną wyświetlone kategorie lepiej dopasowane do zainteresowań reklamodawców, a jednocześnie nasze zobowiązanie do wykluczania potencjalnie kontrowersyjnych tematów. Zachęcamy ekosystem do sprawdzenia najnowszej taksonomii i przekazania opinii na temat zmian. |
| Proces aktualizowania taksonomii i klasyfikatorów | Dowiedz się więcej o taksonomii i częstotliwości udostępniania klasyfikatorów Topics oraz o tym, jak firmy mogą się na nie przygotować. | Jak pisaliśmy w niedawnym poście na blogu, spodziewamy się, że z czasem taksonomia będzie ewoluować, a taksonomia ostatecznie przejdzie na zewnętrzną firmę reprezentującą zainteresowane osoby z całej branży. Udostępniliśmy też plan zwiększenia wysokości w grupie topics-anulce. |
| Wpływ na sygnały własne | Wzrost liczby tematów w niedawnej aktualizacji taksonomii może być bardzo wartościowy, a w rezultacie dewaluuje inne własne sygnały oparte na zainteresowaniach. | W raporcie z I kwartału 2023 r. urzędnik CMA stwierdził: „Rozumiemy, że Google omawia proponowaną przez nas nową taksonomię z kilkoma uczestnikami rynku w łańcuchu dostaw technologii reklamowych. Kilku dużych wydawców twierdzi, że większa użyteczność tematów zwiększy presję konkurencyjną na ich rozwiązania oparte na danych własnych, ale nasze wstępne poglądy są takie, że większa użyteczność jest korzystniejsza dla ogólnej konkurencji – zwłaszcza jeśli mniejsze wydawcy mogą nadal zarabiać na swoich zasobach reklamowych po wycofaniu plików cookie innych firm”. Nasz punkt widzenia jest zgodny z komentarzem wydanym przez CMA. |
| Przydatność dla różnych typów zainteresowanych osób | Technologie reklamowe, które działają jako platformy SSP i DSP, mogą mieć znaczną przewagę nad innymi graczami w ekosystemie. | Nasza odpowiedź nie zmieniła się w porównaniu z poprzednimi kwartałami: „Firma Google zobowiązała się do zaprojektowania i wdrożenia ofert pakietowych Piaskownicy prywatności w sposób, który nie będzie zakłócać konkurencji przez traktowanie własnej firmy Google, oraz aby wziąć pod uwagę wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. Dalej ściśle współpracujemy z CMA, aby mieć pewność, że nasze działania są zgodne z tymi zobowiązaniami. Jedną z kluczowych kwestii, które będziemy oceniać w miarę postępów testowania Piaskownicy prywatności, będzie skuteczność nowych technologii w przypadku różnych zainteresowanych osób. Opinie są w tym przypadku bardzo ważne, zwłaszcza konkretne i praktyczne opinie, które pomogą nam w dalszym ulepszaniu projektów technicznych. Współpracujemy z CMA nad opracowaniem naszego podejścia do testów ilościowych i popieramy opublikowanie przez CMA notatki na temat projektu eksperymentu, aby udostępnić uczestnikom rynku więcej informacji i zapewnić możliwość skomentowania proponowanych metod”. |
| Tematy podrzędne | Jeśli kryterium wyboru tematu to częstotliwość wizyt w przeglądarce, czy fragmentacja segmentów spowoduje, że tematy podrzędne nigdy nie będą pojawiać się na samej górze? | Chrome analizuje obecnie inne metodologie rankingu i analizuje inne czynniki, które mogą poprawić pozycję witryny w rankingu. Później przekażemy informacje o naszych zmienionych planach całemu ekosystemowi. |
| Czułość | Celem interfejsu Topics API powinno być zapewnienie, że informacje o użytkownikach uzyskiwane lub pozyskiwane z niego nie powinny być poufne w stosunku do tych danych, które można by uzyskać przy użyciu współczesnych metod śledzenia. | Uważamy, że interfejs Topics API zapewnia znacznie większą prywatność niż obecne technologie, znacznie ogranicza możliwość ponownej identyfikacji użytkowników i jest przeznaczony do wykluczania tematów o charakterze kontrowersyjnym. Zdajemy sobie sprawę, że tematy można wiązać z danymi własnymi lub z nimi łączyć w celu tworzenia kategorii o charakterze kontrowersyjnym. Uważamy jednak, że interfejs Topics API stanowi krok naprzód w zakresie ochrony prywatności użytkowników, dlatego stale pracujemy nad ulepszaniem tego interfejsu. |
| Struktura taksonomii | Dodawanie identyfikatora, obsługi wersji i innej struktury metadanych do taksonomii tematów | Obecnie w odpowiedzi interfejsu API umieszczamy identyfikator taksonomii. Przystępując do długoterminowego zarządzania, warto sprawdzić obiekt Topics i w razie potrzeby dołączyć dodatkowe metadane dotyczące obsługi wersji. |
| Kontrola wydawcy | Wydawcy powinni mieć wpływ na to, do jakich tematów mają klasyfikować swoje witryny. | Błędna klasyfikacja witryn może sprawić, że sygnał z interfejsu Topics będzie nieco mniej przydatny jako sygnał ogólny, ale niewłaściwie sklasyfikowane witryny nie są przez to bardziej szkodliwe niż inne witryny. Wynika to z faktu, że informacje kontekstowe danej witryny będą zawsze dostępne na aukcjach tej witryny, co pozwoliłoby uzyskać informacje porównywalne z właściwym tematem, nawet w przypadku błędnej klasyfikacji. Chętnie poznamy Twoją opinię na ten temat. Zezwalanie wydawcom na kontrolowanie ich klasyfikacji wiąże się z ryzykiem. Witryny mogą celowo klasyfikować swoje witryny nieprawidłowo, zmniejszając przydatność dla wszystkich, lub kodować wrażliwe znaczenie 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 obecnie używane rozszerzenia do zarządzania plikami cookie | Powinno to być już możliwe, jak omówiliśmy na GitHubie, ale chętnie poznamy też dodatkowe opinie z ekosystemu. |
| Przejście do 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 przechodzący z wersji próbnej origin na Ogólną dostępność nie utracą żadnych danych. |
| Prywatność | Nazwy hostów mogą zawierać prywatne informacje, które mogą zostać ujawnione przez interfejs Topics API | Aby chronić prywatność, stosujemy szereg środków łagodzących, które opisano tutaj. |
| Oszustwa i nadużycia | Jak zapobiegać manipulacjom na platformie Topics przez fałszywe wizyty | Łagodzenie działań opisano tutaj. |
| Klasyfikator tematów | Czy witryny mogą prosić o zmianę klasyfikacji tematów? | Jesteśmy ciekawi, co mówią inni użytkownicy na ten temat. Czekamy na opinie tutaj. |
| Witryny dostawców tematów | Oznacz witryny zawierające treści wielu tematów jako „witryny dostawców tematów specjalnych”. i trenowanie klasyfikatorów na podstawie tagów dostarczonych na stronach internetowych. | Omawiamy tę propozycję tutaj i czekamy na dodatkowe opinie. |
Protected Audience API (wcześniej FLEDGE)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Natężenie ruchu | Wpływ na wydajność filtrowania opartego na SSP w celu optymalizacji wczytywania zapytań na sekundę (QPS) | Poświęciliśmy dużo czasu na analizę potencjalnych natężenia ruchu i zalecamy, aby platformy SSP korzystały z buforowania. |
| Testuję głośność | Testowanie Protected Audience API jest trudne, ponieważ platformy SSP i DSP mają trudności z uzyskaniem dużego natężenia ruchu. | Stale angażujemy partnerów platform SSP i DSP do wdrożenia i testowania funkcji Protected Audience API. Rozpoczęła się ogólnodostępna funkcja. Jesteśmy przekonani, że odsetek ruchu z reklamami spersonalizowanymi stanie się bardziej przyjazny dla partnerów. |
| złożoność | Wdrożenie rozwiązań z Protected Audience API wymaga znacznych nakładów pracy i kosztów. | Zdajemy sobie sprawę, że wdrażanie nowych technologii, w tym Piaskownicy prywatności, jest trudne. Zespół Piaskownicy prywatności ściśle współpracuje z szerokim gronem zainteresowanych osób, aby edukować i wspierać ich wysiłki. Nieustannie oceniamy też inne czynniki wspierające wdrażanie ekosystemu. |
| Zaufane środowiska wykonawcze | Obsługa zaufanych środowisk wykonawczych (TEE) w niepublicznych środowiskach chmurowych | Badamy potencjalne możliwości wykraczające poza rozwiązania działające w chmurze, ale obecnie nie możemy obsługiwać lokalnych systemów TEE ze względu na lokalne ograniczenia zabezpieczeń, które wymagałyby czasochłonnej oceny pod kątem Piaskownicy prywatności. Biorąc pod uwagę wymagania w zakresie bezpieczeństwa Piaskownicy prywatności i ważne wyzwania, jakie wiążą się z wdrożeniami lokalnymi, uważamy, że dalsze rozwijanie i ulepszanie wdrożeń w chmurze (np. obsługa GCP w uzupełnieniu AWS) jest najkorzystniejszym rozwiązaniem dla ekosystemu. Czekamy jednak na dodatkowe opinie na temat tego, dlaczego takie wymaganie jest konieczne. |
| Struktura kosztów | Określanie stawek W przypadku technologii reklamowych oferta pakietowa usług aukcyjnych zwiększy koszty i złożoność w porównaniu z modelami po stronie klienta. | Obecnie opracowujemy przewodnik po szacowaniu kosztów obsługi procesów związanych z określaniem stawek i aukcji serwera aukcji, który zostanie powiązany z wykorzystaniem technologii reklamowych i spełnia jeden z celów naszego projektu. |
| Osie czasu K-Anon | Kiedy planowane ograniczenia k-anonimowości będą egzekwowane w przypadku obiektu „renderUrl”? | Pracujemy nad wyjaśnieniem harmonogramu wprowadzenia tych zmian, który wkrótce opublikujemy. |
| Ograniczenia aukcji reklam | Czy Chrome może ograniczyć możliwość wywoływania trybu runAdAuction tylko z górnej strony? |
Nasz projekt w pełni obsługuje funkcję runAdAuction tak, aby można ją było wywoływać z górnej strony, ale uważamy, że dla wydawców bardziej szkodliwe byłoby ograniczenie jej wywoływania tylko z domeny najwyższego poziomu.Z całego ekosystemu dowiedzieliśmy się, że Piaskownica prywatności musi zminimalizować obciążenie wydawców i reklamodawców. Opinie te są zgodne z ogólną zasadą tworzenia stron internetowych, zgodnie z którą 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 sposobu działania wydawców i technologii reklamowych. Jesteśmy przekonani, że wydawcy mogą wybrać, kto i w jaki sposób ma używać usługi runAdAuction w swojej witrynie. Dlatego zapewniamy wydawcom elastyczność, dzięki czemu mogą oni wybrać sposób, który najlepiej spełni ich wymagania. |
| Pomoc we wdrożeniu | Czy Chrome może tworzyć aukcje dla wielu sprzedawców lub wnosić w niej udział w implementacji open source? | Piaskownica prywatności ma na celu opracowywanie technologii chroniących prywatność, które nie korzystają z plików cookie innych firm ani innych identyfikatorów w różnych witrynach. Chcemy budować zdrowy ekosystem bez konieczności określania, w jaki sposób mają działać technologie reklamowe. Opublikowaliśmy wskazówki dotyczące działania interfejsów API w naszym repozytorium GitHub i jesteśmy otwarci na odkrywanie rozwiązań z branży. Nie planujemy wprowadzania żadnych konkretnych implementacji, ponieważ naszym głównym zadaniem jest tworzenie technologii platform, a nie określanie strategii korzystania z tych technologii. Nasze technologie pomogą firmom z branży technologii reklamowych najlepiej obsługiwać klientów z zastosowaniem odpowiednich barier ochrony prywatności konsumentów. |
| Aukcje wielu sprzedawców | Czy Chrome wymusza udostępnianie „kontekstowych” w aukcji komponentów? | Interfejs Protected Audience API umożliwia stronom, które inicjują aukcję z wieloma sprzedawcami, przekazanie informacji do aukcji komponentów (uwaga: tylko przed jej zainicjowaniem). Nie widzimy jednak możliwości, by przeglądarka mogła stwierdzić, czy dana informacja jest korzystna w kontekście czy nie, dlatego nie możemy wymusić blokowania lub wymagać określonych informacji. |
| Preferencje użytkownika dotyczące śledzenia zgody użytkownika | Zespół AdTech pyta, jak prawidłowo wdrożyć śledzenie zgody użytkownika | Nasza odpowiedź zawiera to, co powiedzieliśmy w I kwartale: „W przypadku konkretnych reklam odpowiednia technologia reklamowa jest stroną najlepszą do zaoferowania kontroli nad tym, które kreacje są wyświetlane lub jak są wybierane”. Omówiliśmy kilka scenariuszy związanych z tym problemem podczas majowego majowego spotkania WICG Protected Audience Meeting. Zachęcamy do przekazywania dodatkowych opinii i dyskusji na ten temat. |
| Niestandardowe listy odbiorców | Czy interfejs Protected Audience API będzie obsługiwać przypadki użycia platformy SSP związane z tworzeniem niestandardowych list odbiorców? | Interfejs Protected Audience API umożliwia platformom SSP i innym dostawcom technologii reklamowych posiadanie niestandardowych list odbiorców i zarządzanie nimi. Przygotowujemy dalsze wskazówki dotyczące integracji platformy SSP z interfejsem PA API. Platforma ta zostanie udostępniona platformom SSP i innym dostawcom technologii reklamowych w celu wspierania działań związanych z integracją. |
| Formaty | Czy interfejs Protected Audience API obsługuje filmy? | Reklamy wideo są wyświetlane na jeden z dwóch sposobów: jako kod XML VAST lub HTML (reklamy Out-Stream, które mogą także wczytywać w odtwarzaczu kod XML VAST). Kupujący mogą zwracać oba formaty za pomocą renderURL. Specyfikacja VAST została niedawno zaktualizowana, aby obsługiwała Attribution Reporting API. Witryny wyświetlające reklamy wideo muszą przygotować się na sposób wyświetlania reklam przez interfejs Protected Audience API. Oznacza to, że tagi miejsc docelowych muszą przekazywać adres URL z elementu iframe z Protected Audience API do odtwarzacza wideo. W przypadku ramek chronionych zaspokoimy potrzeby związane z treściami, zanim wprowadzimy je nie wcześniej niż w 2026 roku. |
| Tempo | Jak zastosowanie tempa działa z interfejsem Protected Audience API? | Doceniamy tę opinię. Chcielibyśmy dowiedzieć się więcej o tej prośbie, podając więcej szczegółów od większej liczby partnerów SSP, ponieważ do tej pory ten problem dotyczył głównie platformy DSP. |
| Częstotliwość aktualizacji | Częstotliwość połączeń z firmy 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, które umożliwiają technikom reklamowym korzystanie z sygnałów odświeżanych w różnych cyklach, takich jak wyszukiwania słów kluczowych. |
| Kontrola jakości reklamy | Jak wydawcy wdrażają kontrolę jakości reklam? | Obecnie interfejs Protected Audience API oferuje wydawcom funkcję, która umożliwia wydawcom informowanie platform SSP o określonych ustawieniach, które mogą wprowadzić w ramach konfiguracji aukcji przed ustaleniem stawki (np. list odrzuconych utworzonych na podstawie etykiet powiązanych z reklamami). Chętnie poznamy opinie na temat dodatkowych funkcji, których może wymagać ten ekosystem. |
| Debugowanie | Kiedy funkcja forDebuggingOnly zostanie usunięta? |
Planujemy wycofanie forDebuggingOnly z powodu zdarzeń utraty spowodowanych wycofaniem plików cookie innych firm. Planujemy wycofać forDebuggingOnlyzwycięstwa najwcześniej w 2026 roku. |
| Grupy zainteresowań na różnych urządzeniach | Propozycja włączenia grup zainteresowań korzystających z różnych urządzeń w przypadku uwierzytelnionych klientów użytkownika | Sprawdzamy tę propozycję, ale duża precyzja kierowania na różne urządzenia może stwarzać poważne obawy o ochronę prywatności, co zostało omówione w tym zgłoszeniu na GitHubie. |
| Remarketing dynamiczny (raport dostępny też w I kwartale) | Czy po wycofaniu plików cookie innych firm remarketing dynamiczny będzie możliwy przy użyciu interfejsu Protected Audience API? | Uważamy, że taki przypadek użycia jest możliwy w przypadku Protected Audience API, co wyjaśniono tutaj. |
| Kliknij powiązane dane | Dodaj dane związane z kliknięciami do kampanii browserSignals. |
Prosimy obecnie o wyjaśnienie, kiedy miało miejsce kliknięcie w celu uzyskania wstępnej pozycji. |
| (też odnotowane w IV kwartale 2022 r.) Funkcje definiowane przez użytkowników w Protected Audience API | W jaki sposób funkcje zdefiniowane przez użytkownika (UDF) będą obsługiwane w interfejsie Protected Audience API? Są to funkcje, które użytkownicy mogą zaprogramować w celu zwiększenia funkcjonalności interfejsu API. | Specjaliści ds. technologii reklamowych, którzy wspomnieli o tym problemie, stwierdzili również, że wciąż analizują możliwości związane z UDF, więc nie ma jeszcze żadnych przydatnych opinii, na które można by zareagować, a przynajmniej do czasu ogólnej dostępności. |
| Waluta | Kwoty walut nie powinny być przedstawiane za pomocą punktów zmiennoprzecinkowych. | Omówiliśmy ten problem tutaj. |
| Funkcje wyboru reklam spoza platformy DSP | Jaką rolę odgrywają serwery reklam w aukcjach interfejsu Protect Audience API? | Zdajemy sobie sprawę z żądań serwerów reklam dotyczących dalszego oferowania usług wyboru reklam po ustaleniu stawki lub optymalizacji kreacji dynamicznych. Obecnie oceniamy szczegółową analizę rozbieżności między obecnym interfejsem Protected Audience API a tymi żądaniami. |
| GenerateBid | Pomoc Google Ads propozycja zwrotu więcej niż jednej reklamy kandydującej na grupę zainteresowań w grupie reklam generateBid i uzyskania przez te kandydaty wyniku w kategorii „scoreAd”. |
Trwa sprawdzanie. Zachęcamy do przesyłania dodatkowych opinii. |
| Zamówienie na aukcji | Czy aukcje interfejsu Protected Audience API muszą być ostatnimi uruchomionymi, aby mogły korzystać z wyników pozostałych aukcji? | Nie ma wymagań technicznych, które muszą kończyć się, gdy interfejs Protected Audience API będzie działać jak najdłużej. |
| Nawigacja niezainicjowana przez użytkownika | Udostępnij nawigację niezainicjowaną przez użytkownika | Rozpatrujemy tę prośbę i dyskutujemy ją tutaj . Zachęcamy też do przekazywania dodatkowych opinii. |
| Pamięć podręczna | W przypadku zmiany stanu użytkownika platformy SSP nie powinny budować sygnałów z pamięci podręcznej poszczególnych kupujących z danej platformy DSP. | Zdajemy sobie sprawę, że zapisywanie w pamięci podręcznej nie zawsze działa w przypadku poszczególnych kupujących, dlatego analizujemy dalsze możliwości. Jesteśmy otwarci na wszelkie dodatkowe opinie z ekosystemu na temat tego, czy buforowanie sprawdzi się w ich zastosowaniach. |
| Raporty atrybucji i Protected Audience API | W jaki sposób interfejs Attribution Reporting API i Protected Audience API współpracują ze sobą? | Obecnie dostępne są integracje interfejsu Protected Audience API zarówno w trybie Attribution Reporting API (na poziomie zdarzenia i w raportach podsumowujących). 1 czerwca udostępniliśmy więcej informacji o ulepszonej integracji interfejsu Protected Audience API i Attribution Reporting. Więcej informacji na ten 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 obsługiwany technicznie punkt końcowy, który jest niezależny od zaufanych serwerów agregacji używanych do przetwarzania zebranych i przekształconych raportów. Obecnie nie planujemy żadnych zmian w punkcie końcowym raportowania. Nowa wersja ma na celu zadbanie o to, aby same raporty agregowane (z zaszyfrowanymi ładunkami) nie wyciekły danych z innych witryn, więc zaufany punkt końcowy nie powinien być konieczny. Dodatkowym problemem jest to, że różni technologie reklamowe mogą stosować różne strategie grupowania. Zachęcamy do przesyłania dodatkowych opinii. |
| WebIDL | Obecna specyfikacja interfejsu Protected Audience API nie jest zgodna ze specyfikacją WebIDL. | Sprawdzamy tę opinię i dyskutujemy na ten temat tutaj. |
| Zarządzanie zgodą użytkowników | Jak będzie obsługiwane przekazywanie sygnałów dotyczących zgody w interfejsie Protected Audience API? | Informacje kontekstowe wykraczają poza zakres interfejsu Protected Audience API. Będziemy omawiać ten problem i chętnie poznamy dodatkowe opinie. |
| Marketing oparty na koncie | Czy przypadki użycia marketingu prowadzonego z wykorzystaniem konta są możliwe? | Protected Audience API obsługuje różne przypadki użycia marketingu opartego na odbiorcach. Nadal będziemy rozumieć, w jaki sposób interfejs Protected Audience API może najlepiej pomóc w tym konkretnym przypadku użycia, i chętnie poznamy dodatkowe opinie na temat tego problemu z ekosystemu. |
| Aukcja komponentów | Jakie wyniki uzyskują uczestnicy aukcji? | Aukcje komponentów nie oceniają bezpośrednio grup zainteresowań, a tylko reklamy i stawki przesyłane przez platformę DSP za pomocą funkcji generateBid. Funkcja generateBid() działa dla każdej grupy zainteresowań, a platforma DSP podczas wykonywania metody generateBid zwraca taką wartość:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Publikowane przez użytkowników treści | Prośba o wsparcie zewnętrznych darowizn do bazy kodu serwera kluczy i wartości na GitHubie. | Zamierzamy zaktualizować nasze odpowiednie procesy, aby umożliwić dodawanie treści do kodu na GitHubie z zewnątrz. |
| Wielkość grupy zainteresowań | Jaka jest maksymalna obsługiwana liczba kluczy, jaką może obsługiwać IG? | Obecny limit to 50 KB na jednym elemencie IG, do którego wliczają się 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. Na przykład może być przechowywany w pamięci podręcznej w ramach aukcji komponentów, 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 lub aukcji oraz raportowania). |
| Pamięć współdzielona | Obsługa tworzenia wiadomości do pamięci współdzielonej w ramach usług ustalania stawek i aukcji. | Obecnie funkcje ustalania stawek i usługi aukcyjne nie obsługują pamięci współdzielonej, ale zachęcamy do przekazywania opinii o tym, dlaczego takie przypadki użycia są ważne dla naszego ekosystemu. |
| Web-to-app | Obsługuj udostępnianie treści z internetu do aplikacji grupom o podobnych zainteresowaniach. | Integracja z internetem do aplikacji nie jest obecnie ograniczona do wdrożenia interfejsu Protected Audience API w Chrome i na Androidzie, ale chcemy poznać znaczenie tego przypadku użycia. |
| K-anonimowość | Obsługa kreacji zastępczych K-anonimowości | Będziemy omawiać ten problem i chętnie poznamy dodatkowe opinie. |
Pomiary reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Alternatywne konfiguracje raportu na poziomie zdarzenia konwersji po wyświetleniu | Opinia na temat konfiguracji raportów dotyczących alternatywnych konwersji po wyświetleniu angażującym na poziomie zdarzenia | Dotarły do nas opinie, że obecne konfiguracje na poziomie zdarzenia nie są optymalne, dlatego prosimy o opinię na temat optymalnych konfiguracji globalnych. Jesteśmy otwarci na dodatkowe opinie na ten temat i uważamy, że nasze elastyczne wyjaśnienie na poziomie zdarzenia również pomaga rozwiązać ten problem. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jaki jest stan funkcji elastycznych konfiguracji na poziomie zdarzenia? | Udostępniliśmy dokumentację na temat elastycznej konfiguracji na poziomie zdarzenia. Funkcja ta jest nadal w fazie składania oferty i oczekujemy dodatkowych opinii na temat jej przydatności dla naszego ekosystemu. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jak można uzgodnić sprzeczne raporty od różnych stron? | Większość scenariuszy raportowania jest rozpatrywana przy użyciu raportów zbiorczych, natomiast elastyczna propozycja konfiguracji na poziomie zdarzenia zapewnia dodatkową elastyczność w przypadku raportów na poziomie zdarzenia, które są najczęściej wykorzystywane w przypadkach optymalizacji. Czekamy na dodatkowe komentarze i opinie w ekosystemie na temat tego scenariusza. |
| Rejestracja źródła | Co się stanie, jeśli rejestracja źródła nastąpi po rejestracji wywołującej? | Obecnie, jeśli rejestracja źródła nastąpi po rejestracji wyzwalacza, nie będzie można przypisać do siebie źródła i wyzwalacza. Jest to scenariusz ekstremalny. Chętnie poznamy dodatkowe opinie na temat tego problemu. Postaramy się go rozwiązać, jeśli zmaga się z nim wiele firm zajmujących się technologiami reklamowymi. |
| 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, dlatego można z niego korzystać nawet wtedy, gdy reklamodawca współpracuje z wieloma agencjami reklamowymi. Obowiązują też pewne ograniczenia dotyczące przekierowań, aby mieć pewność, że interfejs API poprawia ochronę prywatności. Znaleźliśmy też potencjalne obejście związane z użyciem interfejsu Shared Storage API w konkretnym scenariuszu, jaki stwarza technologia reklamowa. Chętnie poznamy dodatkowe opinie na temat tego scenariusza i będziemy je dalej rozwijać na podstawie uzyskanych opinii. |
| Limity miejsc docelowych | Limity miejsc docelowych mogą wpływać na przypadki użycia automatycznie odświeżanych reklam. | Omówiliśmy ten problem na spotkaniu WICG 1 maja i chcemy poznać opinię na temat rozsądnego ograniczenia. Do raportu atrybucji z wyjaśnieniem raportów na poziomie zdarzenia dodaliśmy informację, że przeglądarka może ograniczać liczbę docelowych domen eTLD+1 reprezentowanych przez witryny źródłowe. Zobacz żądanie pull. |
| Raporty atrybucji i Protected Audience API | W jaki sposób interfejs Attribution Reporting API i Protected Audience API współpracują ze sobą? | Obecnie dostępne są integracje interfejsu Protected Audience API zarówno w trybie Attribution Reporting API (na poziomie zdarzenia i w raportach podsumowujących). 1 czerwca udostępniliśmy więcej informacji o ulepszonej integracji interfejsu Protected Audience API i Attribution Reporting. Więcej informacji na ten temat znajdziesz tutaj. |
| Elastyczne konfiguracje na poziomie zdarzenia | Podziel się sprawdzonymi metodami symulacji szumu, ponieważ parametry można konfigurować. | Udostępniliśmy na GitHubie kod, za pomocą którego każdy może ocenić wpływ wzmocnienia informacji i szumu w przypadku dowolnych elastycznych konfiguracji na poziomie zdarzenia, które chce przetestować. Chcielibyśmy uzyskać informacje od każdego, kto zdecyduje się przetestować kod i chce podzielić się opinią. |
| Pomiar atrybucji w różnych aplikacjach i internecie | Kiedy dostępny będzie pomiar atrybucji w różnych aplikacjach i w internecie? | 9 maja ogłosiliśmy eksperyment dotyczący pomiaru atrybucji w wielu aplikacjach i internecie za pomocą interfejsu Attribution Reporting API. Planujemy udostępnić ogólną dostępność dla interfejsów API trafności i pomiarów w Chrome 115, ale obecnie nie planujemy ogólnej dostępności funkcji pomiaru atrybucji w różnych aplikacjach i internecie w Chrome 115. |
| Usuwanie duplikatów konwersji | Jak można uzgodnić niezależne rozwiązania analityczne z interfejsem ARA? | Podobnie jak w przypadku obecnej standardowej praktyki, reklamodawcy współpracujący z niezależnym dostawcą usług pomiarowych w celu usuwania duplikatów danych o konwersjach Opublikowaliśmy materiały na temat usuwania duplikatów konwersji w raportach na poziomie zdarzenia. |
| Utrata danych podczas aktualizacji bazy danych Attribution Reporting | Czy po aktualizacji bazy danych Attribution Reporting Database zgodnie z zapowiedzią Chrome spowoduje utratę danych? | Począwszy od stabilnej wersji Chrome 115 zaczniemy domyślnie włączać interfejsy Trafność i pomiar API w przypadku części użytkowników Chrome. Dostępność tej funkcji będzie się zwiększać w miarę monitorowania pod kątem potencjalnych problemów. Celem jest osiągnięcie 100% dostępności w ciągu kilku tygodni, do III kwartału 2023 r. Zbiegnie się to z zakończeniem testowania źródła trafności i pomiarów. Od lipca testerzy będą mogli się zarejestrować, aby uzyskać ogólnodostępny dostęp do tych interfejsów API. W ten sposób dostępność w ramach testowania origin będzie się pokrywać z ogólną dostępnością w ramach rejestracji. Twój token wersji próbnej origin będzie ważny do 19 września, ale zalecamy zarejestrowanie się przed upływem tego terminu, aby płynnie wyjść z testu origin bez przerywania trwających testów. Jak wspomnieliśmy w tym ogłoszeniu, dane zarejestrowane w starszych wersjach (M113 i starszych) nie zostaną przeniesione po aktualizacji, co może spowodować utratę danych. Ta utrata danych nie będzie widoczna w raportach debugowania, a postaramy się uniknąć utraty danych między 114 a 115. |
| Płatności | Korzystanie z raportowania atrybucji do rozliczeń na podstawie kosztu konwersji | Zgodnie z opisem w tym artykule interfejs Attribution Reporting API może nie być odpowiednim rozwiązaniem do obsługi rozliczeń na podstawie kosztu konwersji z powodu szumu dodanego do raportów podsumowujących i na poziomie zdarzenia. Zachęcamy użytkowników ekosystemu do dzielenia się opiniami o wpływie interfejsu Attribution Reporting API w serwisie GitHub na różne modele płatności. |
Usługa do agregacji
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zmiana opóźnienia w raporcie agregowanym | Pozytywne reakcje na propozycję zmiany opóźnienia generowania raportów z [10–60 minut] na [0–10 minut] po otrzymaniu opinii ekosystemu | Cieszymy się z pozytywnej reakcji na proponowaną zmianę i zachęcamy ekosystem do dalszego przekazywania opinii na temat naszych propozycji. |
| Rozwiązanie lokalne | Czy usługę agregacji można wdrożyć w lokalnych centrach danych? | Badamy potencjalne możliwości wykraczające poza rozwiązania działające w chmurze, ale obecnie nie możemy obsługiwać lokalnych systemów TEE ze względu na lokalne ograniczenia zabezpieczeń, które wymagałyby czasochłonnej oceny pod kątem Piaskownicy prywatności. Biorąc pod uwagę wymagania w zakresie bezpieczeństwa Piaskownicy prywatności i ważne wyzwania, jakie wiążą się z wdrożeniami lokalnymi, uważamy, że dalsze rozwijanie i ulepszanie wdrożeń w chmurze (np. obsługa GCP w uzupełnieniu AWS) jest najkorzystniejszym rozwiązaniem dla ekosystemu. Czekamy jednak na dodatkowe opinie na temat tego, dlaczego takie wymaganie jest konieczne. |
| Ponowne przetwarzanie raportów dla różnych okresów | Możliwość ponownego przetwarzania raportów dla różnych okresów | Słyszeliśmy podobne prośby o możliwość podziału wsadów dla różnych zakresów dat. Jedną z propozycji jest umożliwienie rozszerzenia udostępnianego identyfikatora o etykietę zdefiniowaną przez technikę w reklamie, co umożliwi dzielenie raportów na kilka partii. Jesteśmy na wczesnym etapie oceny tego procesu i w miarę rozwoju tej propozycji będziemy na bieżąco aktualizować ekosystem. |
| Konsekwencje ochrony prywatności w zaufanym środowisku wykonawczym | Pozytywne nastawienie do wpływu zaufanych środowisk wykonawczych na ochronę prywatności | Z przyjemnością odbieramy pozytywne reakcje ekosystemu na nasze propozycje. Czekamy na dodatkowe opinie w miarę dalszego ulepszania i rozwijania naszych usług. |
| Warunki korzystania z usługi | Jaki jest termin zaakceptowania Warunków korzystania z usługi agregacji? | Nie wyznaczyliśmy jeszcze terminu, w jakim należy zaakceptować te warunki, ale zachęcamy firmy zajmujące się ekosystemem jak najszybsze zaakceptowanie warunków, aby uniknąć opóźnień w rejestrowaniu się w programie. Zachęcamy firmy do kontaktu w razie pytań. |
| Odkrywanie kluczy | Kluczowa funkcja wykrywania umożliwi testerom wysyłanie zapytań dotyczących raportów zbiorczych bez konieczności korzystania z wyraźnej listy możliwych kombinacji kluczy w celu przetwarzania raportów podsumowujących na potrzeby atrybucji międzysieciowej, co pozwoli zwiększyć skuteczność i dokładność. | Aktualnie szukamy możliwych rozwiązań i sposobów obejścia tego problemu, dlatego chętnie poznamy opinie użytkowników w ekosystemie. |
Interfejs Private Aggregation API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Źródło raportowania | Jak jest definiowane pochodzenie raportowania? | Źródło raportowania to zawsze źródło skryptu wywołującego agregację prywatną. |
| 128-bitowy obszar klawiszy | Przejrzystość ograniczenia 128-bitowego obszaru klawiszy | Zwiększymy to ograniczenie przestrzeni kluczy i wyeliminujemy niespójności między stronami. Zalecamy korzystanie ze strategii haszowania, aby pozostać w tej przestrzeni kluczy. |
| Maksymalny udział na raport | Obecny limit 20 opublikowanych treści na raport jest za niski. | Zamiast zwiększać maksymalną liczbę przekazanych danych, jesteśmy gotowi rozważyć podział raportów zamiast ograniczenia limitu. Będziemy angażować się w ten ekosystem w miarę rozwoju tej propozycji. |
| Raporty dotyczące zasięgu | Prośba o raportowanie zasięgu na wielu platformach i na różnych urządzeniach. Zasięg to podstawowy wskaźnik reklamowania marki. Aby analizować swoje kampanie i przydzielać wydatki, reklamodawcy korzystają z raportów zasięgu i częstotliwości wyświetlania reklam na różnych platformach i na różnych urządzeniach. Modele zasięgu wykorzystują pliki cookie innych firm jako sygnał do pomiaru reklam wyświetlanych w środowiskach zewnętrznych. Z tego powodu po wycofaniu plików cookie innych firm dostawcy technologii reklamowych zaczęli korzystać z alternatywnego rozwiązania. |
Zespół Piaskownicy prywatności bada funkcje obsługujące metodologie dotyczące zasięgu w wielu domenach po wycofaniu plików cookie innych firm. Czekamy na dodatkowe opinie z ekosystemu. |
Ogranicz ukrycie śledzenia
Redukcja klienta użytkownika/wskazówki dotyczące klienta
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (również w I kwartale 2023 r.) Wskazówki dotyczące dodatkowych formatów | Prośba o wskazówki dotyczące klienta użytkownika (UA-CH) dotyczące dodatkowych formatów, takich jak telewizja czy VR | Nadal pracujemy nad kluczowymi decyzjami projektowymi (na przykład o tym, czy należy podać jedną wartość, taką jak „TV” czy listę funkcji w przypadku poszczególnych formatów), ale pozostawiamy zainteresowani prototypowaniem tego pomysłu. |
| budżet na potrzeby prywatności | Ograniczenia budżetu związane z prywatnością mogą spowodować, że żądania UA-CH stają się niedeterministyczne, gdy zostanie wysłanych zbyt wiele takich żądań. | Na razie nie wprowadzamy żadnych nowych zmian w ofercie pakietowej dotyczącej budżetu prywatności, ale zobowiązaliśmy się nie ograniczać próśb o wskazówki dla klientów w UA przed wycofaniem plików cookie innych firm. |
| Zgodność witryn | Witryny używają marki UA-CH, by ograniczyć dostęp do witryn niektórym przeglądarkom. | Istnieją przypadki zastosowania listy marek, a jednym z nich jest dokładnie zgodność. W UA możesz mieć wiele marek, które pomogą Ci rozwiązać te problemy. |
IP Protection (dawniej Gnatcatcher)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Oszustwa i Nadużycia | W jaki sposób firmy mogą wdrożyć środki zapobiegające oszustwom dzięki ochronie IP? | Wiemy, jak ważne są przypadki użycia związane z przeciwdziałaniem oszustwom i ich możliwy wpływ na te przypadki użycia. Więcej informacji na temat walki z oszustwami planujemy opublikować pod koniec lata. Chcemy poznać opinie ekosystemu na temat tego, jak możemy lepiej wspierać przypadki użycia związane z przeciwdziałaniem oszustwom. |
| GeoIP | Więcej informacji o harmonogramie testowania i wdrażania GeoIP | Niedawno opublikowaliśmy w Chrome nowe informacje dotyczące naszych planów związanych z geoIP. Więcej informacji o harmonogramach wdrożenia planujemy opublikować w III kwartale. Na początku planujemy wprowadzić ochronę IP jako funkcję akceptowania przez użytkowników w niewielkim odsetku ruchu. Zdajemy sobie sprawę, że ta propozycja może wiązać się z istotnymi zmianami dla firm, dlatego chcemy dać ekosystemowi czas na dostosowanie się do tych zmian i przesłanie opinii, zanim funkcja zostanie szerzej udostępniona. |
| Uwierzytelnianie konta | Jak będzie dokładnie działać uwierzytelnianie kont na serwerze proxy? | Więcej informacji na temat uwierzytelniania konta planujemy opublikować pod koniec lata, ale udostępniliśmy już wstępne informacje na ten temat. |
Łagodzenie śledzenia przekierowań
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wskazówki dotyczące testowania | Informacje o sposobie testowania łagodzenia śledzenia przekierowań | W maju opublikowaliśmy posta na blogu, w którym znajdziesz więcej informacji na temat testowania łagodzenia śledzenia przekierowań. |
| Dokumentacja | Przejrzystość propozycji śledzenia przekierowań | Obecna propozycja jest w trakcie opracowywania. Chrome stale ją aktualizuje, aby zapewnić przejrzystość i informacje dla ekosystemu. Obecnie pracujemy nad udostępnieniem dodatkowych informacji. Zachęcamy do przekazywania dodatkowych opinii. |
| Usuwanie plików cookie | Czy łagodzenie śledzenia przekierowań spowoduje usunięcie wszystkich plików cookie w domenie? | Łagodzenie śledzenia przekierowań (BTM) usuwa całe miejsce na dane i całą pamięć podręczną, zgodnie z tym opisem. |
| Unikanie ograniczania śledzenia przekierowań | Klasyfikację tagu śledzenia przekierowań można pominąć, wykonując przekierowania z wyskakującymi okienkami lub nowymi kartami. | Specyfikacja ograniczania śledzenia przekierowań jest nadal w trakcie opracowywania. Do tej pory skupialiśmy się głównie na przekierowaniach na tej samej karcie, ale w przyszłości planujemy też to zrobić. Zachęcamy do przesyłania dodatkowych opinii. |
budżet na potrzeby prywatności
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Kierowanie zbliżone | Budżet prywatności może wpływać na przypadki użycia kierowania na zbliżony obszar. | Otrzymaliśmy opinie na ten temat i z chęcią dowiemy się więcej o potencjalnych skutkach naszego ekosystemu. |
Wzmocnij granice prywatności użytkowników w witrynach
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Limit domen (również raportowany w poprzednich kwartałach) | Prośba o zwiększenie liczby powiązanych domen | Chrome ocenia odpowiedni limit liczbowy dla powiązanego podzbioru, aby zrównoważyć prywatność i przydatność w wybranych przypadkach użycia. Od samego początku Chrome informuje, że dokładna liczba elementów powiązanych z podzbiorem nie jest jeszcze ostateczna. |
| Wbudowany przypadek użycia | Obsługa przypadków użycia osadzonych, które wymagają zestawów źródeł własnych, elementów CHIP i pamięci współdzielonej | Zespół Chrome otrzymał informację zwrotną na temat tego przypadku użycia. Nasz zespół analizuje informacje i chętnie prosi o dodatkowe opinie. |
| Zarządzanie repozytoriami | Informacje o zasadach usuwania zestawów źródeł własnych z repozytorium GitHub w przypadku rozbieżności lub zaniedbań | Chrome otrzymał opinię na temat tego przypadku użycia. Nasz zespół analizuje problem i chętnie prosi o dodatkowe opinie. |
| Edukacja użytkowników | Aby zwiększyć liczbę rozpowszechnienia, Chrome powinien zwiększyć znajomość zestawów źródeł własnych. | Celem Chrome jest edukowanie użytkowników o zestawach źródeł własnych. W tym celu opublikował artykuł w Centrum pomocy (dostępny w interfejsie Chrome). Nieustannie pracujemy też nad tym, jak najlepiej edukować użytkowników w odpowiednich kontekstach. |
| Po 3PCD | Po wycofaniu plików cookie innych firm pliki cookie innych firm będą nadal istnieć w zestawie. | Chociaż usługi requestStorageAccess i requestStorageAccessFor rzeczywiście udostępniają pliki cookie innych firm ponownie w określonych, jasno zdefiniowanych przypadkach użycia, teraz nie są one domyślnie dostępne, tak jak ma to miejsce w przypadku aktualnego stanu plików cookie innych firm (w Chrome), a nie są domyślnie dostępne.Chociaż to wywołanie w ramach jednego zestawu nie wymaga zatwierdzenia przez użytkownika, mogą oni temu zapobiec, rezygnując z tej funkcji w Ustawieniach. Więcej informacji jest dostępnych dla użytkowników w tym artykule w Centrum pomocy (link z poziomu interfejsu Chrome). W miarę zwiększania się liczby klatek na sekundę do 100% planujemy rozszerzyć obecny przewodnik dla programistów. |
| Przesłanie zestawów źródeł własnych | Zmień nazwę wymaganego elementu .well-known/first-party-set, aby uwzględnić rozszerzenie .json. |
Wprowadziliśmy tę zmianę, aby mieć pewność, że obsługiwane są niektóre abonamenty hostingu WWW. |
| Rejestracja IANA | Domena first_party_sets.JSON powinna być zarejestrowana w IANA |
Rozważamy tę propozycję i czekamy na dodatkowe uwagi. |
Interfejs Fenced Frames API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Blokowanie reklam | Chronione ramki mogą ułatwić blokowanie reklam. | Rozszerzenia mogą wchodzić w interakcje z chronionymi ramkami podobnie jak w przypadku elementów iframe. Rzeczywisty URL, do którego zostanie przekierowana ramka chroniona, będzie też widoczny dla rozszerzeń i dlatego mogą one stosować do blokowania dowolne reguły dopasowania adresu URL tak samo jak w elementach iframe. Bezwarunkowe zablokowanie wszystkich chronionych ramek może spowodować naruszenie funkcji chronionych ramek, które nie są związane z reklamami. |
Interfejs Shared Storage API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Szersze wdrożenie | Pamięć współdzielona powinna być standardem branżowym dostępnym w przeglądarkach. | Dziękujemy za przekazanie opinii. Chrome cały czas bierze udział w forach W3C, aby przedstawiać swoje propozycje, poznać opinie użytkowników i zachęcać ich do wdrażania rozwiązań. |
| Bramki wyjściowe | Bramki wyjściowe pamięci współdzielonej są zbyt ograniczone. | Bierzemy pod uwagę te opinie i z chęcią poznamy dodatkowe opinie w ekosystemie na temat tego, dlaczego kryteria wyjściowe są zbyt ograniczone. |
| Zgodność z regulacjami prawnymi | W jaki sposób pamięć współdzielona zapewni zgodność z przepisami, takimi jak zasady przechowywania danych? | Pamięć współdzielona umożliwia wdrożenie i dostosowanie logiki kontrolowania czasu przechowywania i upływu ważności 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 w przypadku współdzielonego miejsca na dane i interfejsu Protected Audience API? | Pracujemy nad udostępnieniem dodatkowych wskazówek w tej sprawie i zapewniamy więcej informacji w przyszłości. |
| Limit wspólnego miejsca na dane | Co się stanie po osiągnięciu limitu pamięci współdzielonej? | Po osiągnięciu limitu dane wejściowe nie będą zapisywane. |
| Wielokrotnego dostępu podczas tego samego wczytywania strony | Co się dzieje, gdy podczas tego samego wczytywania strony korzystasz wielokrotnie z pamięci współdzielonej? | Najlepszym sposobem na to jest użycie funkcji window.sharedStorage.append(key, value). Zamiast aktualizować wartości każdej reklamy, co mogłoby powodować konflikty w przypadku wielu reklam. Funkcja dołączania dodaje 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ą działać po wycofaniu plików cookie innych firm? | Po wycofaniu plików cookie innych firm pamięć lokalna w elementach iframe będzie partycjonowana przez witrynę najwyższego poziomu, ale same elementy iframe nie będą blokowane. Dane w pamięci lokalnej elementu iframe nie mogą być replikowane w wielu witrynach najwyższego poziomu, ale nadal można używać pamięci lokalnej w elemencie iframe. |
ELEMENTY
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Limit partycji | 10 KiB na partycjonowaną witrynę to nadal znaczna liczba, która powinna zostać obniżona. | Firefox ma już pozytywną pozycję w grupie CHIPS. W przypadku pomocy dotyczącej Webkit zachęcamy deweloperów, aby przekazywali swoje opinie bezpośrednio do Apple na temat tego problemu z GitHubem. Poinformujemy ich w sprawie ich przypadków użycia, w których preferowane są partycjonowane pliki cookie zamiast pamięci partycjonowanej. |
| Uwierzytelnione umieszczone elementy | Układy CHIP mogą wpływać na bieżący proces logowania jednokrotnego ze względu na różne partycjonowanie, które wpływają na uwierzytelnione umieszczanie. | Zamierzamy korzystać z interfejsu Storage Access API (z promptami użytkownika), aby obsługiwać przypadki użycia uwierzytelnionych umieszczenia na stronie. Niedawno przesłaliśmy wiadomość Intent-to-prototype. |
| Zasady bezterminowe | Czy do własnych plików cookie zostaną zastosowane potencjalne zasady dotyczące wartości od początku śledzenia? | Obecnie nie planujemy nakładać na własne pliki cookie limitów bezterminowych. |
FedCM
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Obsługa autoryzacji OAuth | Uzgodnij autoryzację zakresów OAuth niebędących profilami | Aktywnie zależy nam na opiniach członków społeczności Web Identity, które przedstawiają zespół W3C FedID CG, na temat najlepszych sposobów udzielania autoryzacji po wycofaniu plików cookie innych firm, a nie tylko podstawowego uwierzytelniania. |
| Obsługa SAML | Dostosowywanie wymagań dotyczących obsługi SAML | Po wycofaniu plików cookie innych firm zespół aktywnie zbiera opinie społeczności badawczych i edukacyjnych na temat potrzeb związanych z obsługą SAML (oprócz obsługi OpenID-connect). |
Walka ze spamem i oszustwami
Interfejs Private State Token API (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Analiza nowych sygnałów | Kilku partnerów wyraziło pozytywne nastawienie do analizowania dostarczanych przez przeglądarkę sygnałów dotyczących integralności urządzenia lub zaufania użytkowników. Ogólnie rzecz biorąc, zwracają uwagę na to, czy nowe sygnały służą do utrzymania obecnych poziomów wykrywania oszustw. | Cieszymy się, że możemy wspólnie analizować nowe propozycje w społeczności przeciwnej oszustwom i bezpieczeństwu w sieci. Przyjmujemy też do wiadomości i dzielimy się ich obawami – dlatego „zwalczamy spam i oszustwa”. jest jedną z podstawowych wartości Piaskownicy prywatności, dlatego nieustannie priorytetowo traktujemy kwestie bezpieczeństwa w internecie, dbając o ochronę prywatności użytkowników. |
| Pozytywna opinia o czasie PST | Kilku partnerów wyraziło zainteresowanie testowaniem lub używaniem plików PST w różnych przypadkach użycia związanych z ochroną przed oszustwami i bezpieczeństwem w internecie. | Cieszymy się, że możemy Ci pomóc, i chętnie poznamy nowe rozwiązania wykorzystujące pliki PST. Na stronie dla deweloperów Chrome znajdziesz materiały i przykładowy kod. Zachęcamy do przekazywania opinii. |
| Oszustwa i nadużycia | Wskazówki dotyczące zapobiegania oszustwom reklamowym / wykrywania w pomiarach po wycofaniu plików cookie innych firm, gdy identyfikatory nie są już dostępne. | Wprowadziliśmy narzędzia takie jak tokeny prywatności, które pomagają odzyskać niektóre sygnały utracone przez pliki cookie innych firm w celu zapobiegania oszustwom. Wprowadziliśmy jednak nowe ustawienia prywatności. Aktywnie inwestujemy w opracowywanie nowych propozycji związanych z przeciwdziałaniem oszustwom i nadużyciom, aby zachować możliwości wynikające z innych zmian w Piaskownicy prywatności. |
| Współczynnik informacji o wydawcy do punktu początkowego | Współczynnik informacji od wydawcy do źródła jest wystarczająco wysoki, aby zidentyfikować unikalnych użytkowników. | Zaktualizowaliśmy specyfikację, aby lepiej wyjaśnić, jakie dane użytkownika można przekazywać przy użyciu tokenów prywatności. Domyślnie może być używanych jednocześnie do 6 kluczy publicznych, które mogą reprezentować „stan”. dla konkretnego użytkownika. Te zestawy kluczy można aktualizować tylko co 60 dni (z wyjątkiem rzadkich przypadków, gdy konieczna jest rotacja klucza awaryjnego), co spowalnia możliwość łączenia dodatkowych danych użytkownika z upływem czasu. W przypadku każdego nowego internetowego interfejsu API dostępna jest równowaga między narzędziem a informacjami pochodzącymi od nowych użytkowników. Szacujemy, że pliki PST zachowują równowagę w zakresie ochrony prywatności użytkowników, a jednocześnie umożliwiają zapobieganie oszustwom w kluczowych przypadkach użycia związanych z wycofaniem plików cookie innych firm. |
| Pobierz integrację | Integracja z fetch jest skomplikowana i niepotrzebna. |
Stosowanie usługi fetch ma swoje wady i zalety i chcemy kontynuować prace nad ujednoliceniem w ekosystemie internetowym. Uważamy jednak, że byłoby za wcześnie na wprowadzenie tej zmiany, dopóki nie określimy, jak będzie wyglądał standard. Gdy tylko powstanie standard, zobowiązujemy się do odpowiedzialnego przenoszenia do niego programistów stron internetowych. |
| Lokalizacja zapisu | Konfiguracje kluczy tokenów prywatności powinny być przechowywane w tej samej lokalizacji co protokół PrivacyPass. | Podczas testowania wersji próbnej origin deweloperzy sygnalizowali, że wolą przechowywać klucze pod ogólnymi adresami URL, a nie w katalogu .well-known. Format kluczowego zobowiązania w PrivacyPass nie sprawdza się w wersji, w której zestawy kluczy mają umożliwiać domyślne „metadane publiczne”. . Jeśli odmiana usługi PrivacyPass w końcu stanie się ustandaryzowana pod kątem publicznych metadanych (jako POPRF, częściowe zaciemnianie RSA lub zestawy kluczy), możemy to uwzględnić w przyszłej wersji PST. |
| Implementacja nagłówka interfejsu API | Pytania dotyczące implementacji nagłówka interfejsu API | W miarę jak interfejs API stanie się ustandaryzowany, a jego wykorzystanie w ekosystemie będzie dopracowane, będziemy mogli obsługiwać zarówno jego standardową wersję bez nagłówka, jak i możliwe, że w końcu wycofamy wersję w nagłówku, jeśli wykorzystanie jest na tyle niewielkie, że będzie można korzystać z odpowiednich narzędzi dla programistów i standardowych sposobów łączenia żądań wystawiania lub wykorzystania z innymi danymi. Omawiamy ten problem tutaj. |
| Rejestracja | Czy zachęcenie wydawców do zarejestrowania się u dostawców przeglądarek jest praktyczne? | Zaktualizowaliśmy specyfikację, aby opisać proces rejestracji wydawcy tokenów prywatnego. Stosuje on własny proces, ale przypomina plany rejestracji w przypadku pozostałych działań Piaskownicy prywatności, w których prosimy wydawców o przedstawienie sposobu wykorzystania plików PST i poznanie ograniczeń technicznych chroniących prywatność użytkowników. |