Czwarty raport kwartalny z 2023 r. podsumowujący opinie ekosystemu dotyczące propozycji Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wobec CMA Google zgodziło się na publikowanie kwartalnych raportów na temat procesu zaangażowania interesariuszy w przypadku propozycji dotyczących Piaskownicy prywatności (patrz punkty 12 i 17(c)(ii) zobowiązań). Te raporty zbiorcze opinii na temat Piaskownicy prywatności są generowane przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym m.in. z GitHub Issues, formularza opinii udostępnionego na privacysandbox.com, spotkań z osobami zainteresowanymi w branży oraz forów dotyczących standardów internetowych. Chrome z zadowoleniem przyjmuje opinie pochodzące z ekosystemu i aktywnie poszukuje sposobów na uwzględnienie wniosków w decyzji dotyczących projektowania.
Tematy opinii są klasyfikowane według częstotliwości występowania w przypadku poszczególnych interfejsów API. Polega to na zsumowaniu liczby opinii, które zespół Chrome otrzymał w danym temacie, i posortowaniu ich według malejącej się liczby. Najczęstsze tematy opinii zostały zidentyfikowane na podstawie przeglądu tematów dyskusji z publicznych spotkań (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz najczęściej zadawanych pytań, które pojawiają się w zespole wewnętrznym Google i w formularzach publicznych.
W szczególności zostały sprawdzone protokoły spotkań organizacji zajmujących się opracowywaniem standardów internetowych. W przypadku bezpośrednich opinii uwzględniono zapisy Google z indywidualnych spotkań z partnerami, e-maile otrzymane przez poszczególnych inżynierów, listę mailingową API oraz publiczny formularz opinii. Następnie Google skoordynowało działania zespołów biorących udział w różnych działaniach promocyjnych, aby określić względną częstotliwość występowania tematów związanych z poszczególnymi interfejsami API.
Wyjaśnienia dotyczące odpowiedzi Chrome na opinie zostały opracowane na podstawie opublikowanych najczęstszych pytań i odpowiedzi na nie, a także na podstawie rzeczywistych odpowiedzi na problemy zgłoszone przez zainteresowane strony i stanowiska przyjętego specjalnie na potrzeby tego publicznego raportu. W związku z obecnym kierunkiem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące przede wszystkim interfejsów API Topics, FLEDGE i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu sprawozdawczego mogą nie zostać jeszcze rozpatrzone przez zespół Chrome.
Słowniczek akronimów
- CHIPS
- Pliki cookie z niezależnym stanem partycji
- (procesor) DSP
- Platforma DSP
- FedCM
- Federated Credential Management
- FPS
- Zestawy źródeł własnych
- IAB
- Interactive Advertising Bureau
- IDP
- Dostawca tożsamości
- IETF
- Internet Engineering Task Force
- IP
- adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Testowanie wersji Origin
- PatCG
- Grupa społeczności technologii reklamowych
- RP
- Jednostka zależna
- 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
- Celowe ignorowanie adresów IP
Ogólna opinia, nie dotyczy konkretnego interfejsu API lub technologii
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Testowanie i testowanie wersji próbnej | trafność testów w celu poinformowania CMA, jeśli interfejsy API Piaskownicy prywatności nie zostaną ukończone przed rozpoczęciem testu; | Praca nad interfejsami API Piaskownicy prywatności postępuje bardzo szybko.
Są one już dostępne w wersji próbnej Origin do testowania i latem tego roku zostaną udostępnione do 100% ruchu. Dodatkowo wyjaśniliśmy harmonogramy dotyczące niektórych funkcji (takich jak raportowanie na poziomie zdarzenia FLEDGE czy renderowanie FLEDGE z elementami iframe), które nie zostaną zmienione przed 2026 rokiem. Zachęcamy do testowania interfejsów API i przesyłania opinii do CMA na temat tego, na czym testerzy oczekują, że będzie można polegać po wycofaniu plików cookie innych firm. Może to pomóc w ocenie prawdopodobnego wpływu wycofania plików cookie innych firm. |
| Kontrola użytkowników | jasne wskazówki dla całego ekosystemu dotyczące konsekwencji wprowadzenia elementów sterujących dla użytkowników w ramach interfejsów API Piaskownicy prywatności; | Nie możemy udzielić porady prawnej w zakresie tego, czego użytkownik może używać w ramach ekosystemu. Jednocześnie Chrome eksperymentuje z wyświetlaniem zaktualizowanych ustawień Piaskownicy prywatności („Ulepszony poziom prywatności reklam”) bardzo małej grupie użytkowników. Jest to część naszych ciągłych wysiłków na rzecz ulepszania technologii Piaskownicy prywatności. Wprowadziliśmy ułatwiające korzystanie z usługi czytelniejsze układy i teksty. Gdy Chrome oceni te ulepszenia i zdecyduje, czy wprowadzić je na szerszą skalę, może udostępnić więcej informacji ekosystemowi. |
| wyciek danych, | ryzyko wycieku danych własnych do Google i innych firm w przypadku naruszenia bezpieczeństwa przeglądarki; | Z naszego opracowania FLEDGE wynika, że dane jednej technologii reklamowej są udostępniane tylko tej samej technologii reklamowej (czyli jej modułom roboczym lub zaufanym serwerom) albo gdy są udostępniane przez tę technologię reklamową (np. gdy kupujący pokazuje sprzedawcy adres URL reklamy, którą chce wyświetlić). Jedynym wyjątkiem jest to, że weryfikacja anonimowości K musi być przeprowadzana przez globalny scentralizowany serwer, na który nadal przeznaczamy znaczne zasoby. Aby dowiedzieć się więcej o tym, jak podchodzimy do kwestii prywatności, zapoznaj się z wyjaśnieniem anonimowości K. Oprócz tego chętnie podamy więcej informacji o tym, jak działają zabezpieczenia adtech zastosowane w ramach serwera z k-anonimowością. |
| Dodatkowe forum dyskusyjne | Prośba o utworzenie dodatkowego forum W3C dla osób z ekosystemu, które nie są związane z technologią, aby mogły przekazywać opinie | Formularz opinii na temat prywatności w piaskownicy jest odpowiedni do ogólnych i szczególnych komentarzy, technicznych i nietechnicznych. Grupa biznesowa Improving Web Advertising to forum do dyskusji w ramach cotygodniowych rozmów telefonicznych i repozytorium GitHub. Na stronie Piaskownicy prywatności opinie znajdziesz inne sposoby przesyłania opinii i uczestniczenia w dyskusji. Chrome nadal organizuje też wydarzenia, takie jak publiczne godziny pracy, aby ułatwić zadawanie pytań i udostępnianie treści. Ponadto w ostatnim kwartale zespół Chrome był gospodarzem lub uczestnikiem ponad tuzina wydarzeń branżowych. |
| Wyjaśnienie dotyczące osi czasu | Wyjaśnienie dokładnej daty ogólnej dostępności w III kwartale 2023 r. | Zgodnie z harmonogramem opublikowanym na stronie PrivacySandbox.com ogólna dostępność ma zostać wprowadzona wraz z wydaniem wersji 115 Chrome. |
| reCAPTCHA | Wpływ interfejsów API Piaskownicy na wykrywanie spamu przez reCAPTCHA | Otrzymujemy od czasu do czasu opinie od reCAPTCHA, aby mieć pewność, że propozycje dotyczące piaskownicy prywatności nie mają znaczącego wpływu na bezpieczeństwo w internecie ani na oszustwa. Opracowują oni własny plan przygotowania się na wycofanie plików cookie innych firm i dostosowania się do tej zmiany, więc to oni najlepiej odpowiedzą na to pytanie. |
| Rozszerzenia do Chrome | Czy technologie Piaskownicy prywatności, takie jak środki zapobiegające ukrytemu śledzeniu, będą działać w przypadku rozszerzeń do Chrome? | Nie ogłosiliśmy, czy ACT może dotyczyć rozszerzeń Chrome. Jeśli jednak technologia zbiera informacje o użytkowniku w sposób ukryty, jest to niezgodne z naszymi zasadami dotyczącymi prywatności. |
wyświetlać odpowiednie treści i reklamy.
Tematy
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| TAG Design Review | TAG opublikował wstępną opinię na temat interfejsu Topics. | Nadal jesteśmy zaangażowani w tematy i opublikowaliśmy informacje na ten temat na stronie z najnowszymi informacjami oraz w tym wydaniu. Odpowiedzi na poszczególne punkty przeglądu TAG znajdziesz tutaj. Tutaj znajdziesz naszą ogólną wizję. Interfejs Topics API będzie nadal częścią kolekcji interfejsów API, które ekosystem reklamowy powinien przetestować w 2023 r. Mamy nadzieję, że uzyskane przez nas opinie o testach i doświadczenia w zakresie implementacji będą cennym wkładem w przyszłe prace nad standardami w tej dziedzinie. Z niecierpliwością czekamy na dalszą współpracę z ekosystemem nad tym, jak ułatwić możliwy proces przejścia, w którym interfejs Topics API mógłby stać się uzgodnionym standardem z kompatybilnością między przeglądarkami. |
| Podejście do tematów | Obsługa otwartego podejścia Chrome do tworzenia interfejsu Topics API | Dziękujemy za tę opinię i z niecierpliwością czekamy na dalszą współpracę z grupą branżową nad interfejsem Topics API, który przyniesie korzyści całemu ekosystemowi. |
| (Zgłoszono to również w 3 kwartale 2022 r.) Taksonomia tematów nie jest wystarczająco szczegółowa |
Taksonomia ogólnych tematów nie obejmuje bardziej szczegółowych tematów, w tym tych związanych z konkretnym regionem. | Aktualizacja z I kwartału: Stale pracujemy nad ulepszaniem taksonomii, a w II kwartale ogłosimy zaktualizowaną taksonomię interfejsu Topics API. Aby opracować nową taksonomię, ściśle współpracowaliśmy z firmami z całego ekosystemu. Aktywnie poszukujemy opinii na temat taksonomii, która byłaby najbardziej przydatna dla ekosystemu. Przy ocenie, czy zwiększyć liczbę tematów czy uwzględnić bardziej szczegółowe tematy, należy wziąć pod uwagę kilka kwestii, takich jak: 1) potencjalne konsekwencje dla prywatności (więcej tematów może zwiększać ryzyko tworzenia profilu użytkownika) i 2) możliwość odzyskiwania wcześniej obserwowanych tematów (np. przy większej liczbie tematów może być mniejsze prawdopodobieństwo, że technologia reklamowa widziała wybrany temat w przeszłości). |
| (również zgłoszone w IV kwartale 2022 r.) Wpływ na sygnały własne |
Sygnał dotyczący tematów może być bardzo wartościowy, przez co zmniejsza znaczenie innych sygnałów własnych opartych na zainteresowaniach. | Uważamy, że reklamy oparte na zainteresowaniach to ważny przypadek użycia internetu, a tematy zostały zaprojektowane z myślą o takim zastosowaniu. Z naszych informacji wynika, że niektórzy więksi wydawcy obawiają się, że Topics negatywnie wpłynie na ich strategie dotyczące danych własnych. Nie możemy się doczekać testów ekosystemu, które dostarczą nam informacji o tym, jak funkcja Tematy wpływa na wydawców. |
| Przypadki użycia tematów nie związanych z reklamami | Używanie tematów do celów innych niż wyświetlanie reklam opartych na zainteresowaniach | Topics zostało zaprojektowane z myślą o wyświetlaniu reklam opartych na zainteresowaniach, które naszym zdaniem jest kluczowym przypadkiem użycia w otwartym Internecie. Obecnie zbieramy opinie na temat innych przypadków użycia i je analizujemy. |
| Domyślny stan wyboru | wpływ domyślnych ustawień dotyczących zgody na tematy w ramach przepisów regionalnych, | Nie jesteśmy uprawnieni do wyrażania opinii prawnych. |
| (zgłaszane również w III kwartale 2022 r.) Nieprawidłowo sklasyfikowane witryny |
kierowanie reklam, gdy tematy są nieprawidłowo przypisane do danej witryny | Aktualizacja z I kwartału: W II kwartale ogłosimy zaktualizowany klasyfikator interfejsu Topics API i z niecierpliwością będziemy czekać na współpracę z ekosystemem. W odpowiedzi na obecne opinie, witryny są klasyfikowane na podstawie kombinacji listy zastąpień utworzonej przez człowieka, zawierającej najpopularniejsze witryny, oraz modelu ML na urządzeniu. Chrome nadal ocenia opcje witryn, aby ulepszać klasyfikację tematów. Wszelkie ulepszenia funkcji muszą być rozpatrywane pod kątem ryzyka związanego z prywatnością i nadużyciami. Do zagrożeń należą na przykład: witryny, które używają samooznaczenia jako metody kodowania różnych (i potencjalnie wrażliwych) znaczeń w tematach; witryny, które wprowadzają w błąd użytkowników, aby osiągnąć korzyści finansowe; witryny, które atakują tematy, aby zmniejszyć ich przydatność dla innych (np. spamowanie tematów użytkownika bezsensownym hałasem). Każdy może sprawdzić te komponenty, korzystając z narzędzi dostępnych w usłudze chrome://topics-internals lub w tym współdziale. Na podstawie testów oczekujemy, że klasyfikacja będzie się z czasem poprawiać. Czekamy na opinie na temat przykładów witryn, które mogą być nieprawidłowo sklasyfikowane. |
| Klasyfikator tematów | Prośba o zwrócenie dodatkowych informacji z wyjaśnieniem przyczyn, gdy wywoływanym parametrem jest „NoTopics” (do debugowania). | Zdajemy sobie sprawę, że narzędzia do debugowania są przydatne dla deweloperów, którzy chcą zintegrować interfejs Topics API ze swoimi systemami. Jednak poprzez ujawnienie dodatkowych informacji (takich jak powód, dla którego nie zwrócono tematów) możemy nieumyślnie udostępnić informacje, które umożliwiają stronom odkrycie dodatkowych szczegółów (np. jeśli użytkownik jest w trybie incognito, wyłączył interfejs API itp.), co narusza prywatność użytkownika. Obecnie nie planujemy udostępniać dodatkowych narzędzi do debugowania, ale chętnie poznamy Twoją opinię na temat tego, które narzędzia byłyby przydatne. |
| Private Information Retrieval (PIR) | Prośba o zastosowanie interfejsu Topics API do wyodrębniania prywatnych informacji | Wcześniej badaliśmy już wykorzystanie PIR i omówiliśmy kompromisy, jakie się z tym wiążą. |
| Strumień stawek | Czy w strumieniach stawek tematy będą wyraźnie odróżnione od list odbiorców zdefiniowanych przez sprzedawcę? | Interfejs Topics API to propozycja Piaskownicy prywatności opracowana przez Chrome, która różni się od propozycji Seller-defined Audiences IAB Tech Lab. Oczekujemy, że te 2 wartości będą wyraźnie reprezentowane w strumieniach reklam. Dowiedz się, jak tematy będą reprezentowane w żądaniach stawek OpenRTB. |
Protected Audience API (wcześniej FLEDGE)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Dostępność funkcji FLEDGE | wyjaśnienie harmonogramu testowania i wdrażania funkcji FLEDGE, takich jak egzekwowanie zasad dotyczących odizolowanego elementu, k-anonimowość itp.; | Stany udostępniania dotyczą różnych funkcji FLEDGE i określają, kiedy będą obsługiwane. Zapraszamy do dzielenia się opiniami na temat tego ogłoszenia, ponieważ nadal pracujemy nad FLEDGE. |
| Ograniczenia dotyczące renderowania produktu | Prośba o zmniejszenie ograniczeń dotyczących reklam złożonych z kilku elementów w przypadku ramek ograniczonych w ramach FLEDGE | Jak ogłosiliśmy w lutym, do 2026 roku można będzie stosować ramki ograniczone, a iframe’y będą obsługiwane przez urn-iframe’y. Zachęcamy do dalszej dyskusji na ten temat. |
| Problemy ze skalowalnością | Wydajność FLEDGE w zależności od skali wykorzystania | Aktywnie sprawdzamy opinie i staramy się uzyskać więcej informacji, abyśmy mogli zaproponować skuteczne rozwiązania. Pierwszym krokiem było podzielenie opinii na 2 kategorie:
|
| (również zgłoszone w III kwartale 2022 r.) Widoczność logiki ustalania stawek |
Obawa, że logika określania stawek przez DSP będzie widoczna w JavaScript | Aktualizacja z I kwartału: udostępniliśmy propozycję, która ograniczyłaby możliwość uzyskiwania przez przeciwników danych z serwera w ramach eksploracji (wymuszonego przeglądania). Zachęcamy graczy z ekosystemu do dzielenia się opiniami lub popieraniem tej propozycji. |
| Problemy z testowaniem | Możliwość testowania FLEDGE przez mniejsze platformy DSP i ograniczenie ryzyka, że reklamodawcy będą zainteresowani tylko testowaniem z większymi platformami DSP | W miarę wprowadzania FLEDGE do ogólnej dostępności zamierzamy współpracować z mniejszymi platformami DSP i bardzo zachęcamy do rozszerzenia testów o platformy DSP oraz reklamodawców o różnej wielkości. Chcielibyśmy dowiedzieć się, jak możemy najlepiej pomóc w testowaniu FLEDGE w tym ekosystemie. Zapraszamy też do dzielenia się pomysłami i działaniami podejmowanymi w branży, które zachęcają reklamodawców do testowania z mniejszymi platformami DSP. |
| Remarketing dynamiczny | Czy remarketing dynamiczny będzie nadal możliwy w ramach FLEDGE po wycofaniu plików cookie innych firm? | Rozważamy udzielenie odpowiedzi na to pytanie i zapraszamy przedstawicieli podmiotów z ekosystemu do podzielenia się dodatkowymi informacjami na temat tego, jak zamierzają korzystać z remarketingu dynamicznego. |
| Oszustwa/nadużycia | Jak system może ograniczyć ryzyko i zapobiec temu, aby nieuczciwi podmioty lub kupujący przedstawiali się jako pożądana grupa odbiorców? | Chętnie współpracujemy z uczestnikami ekosystemu w zakresie oszustw i nadużyć oraz chętnie poznamy opinie na ten temat. |
| Preferencje użytkownika | Proces zapisywania preferencji użytkownika i ich wykorzystywania do wyboru reklam | W przypadku konkretnych reklam odpowiednia technologia reklamowa jest stroną, która najlepiej nadaje się do oferowania kontroli nad tym, które kreacje są wyświetlane lub jak są wybierane. |
| Propozycja testów ilościowych | Aby testy ilościowe były wiarygodne, czy testy powinny być przeprowadzane na ruchu bez plików cookie innych firm czy z użyciem SSP, które korzystają tylko z FLEDGE? Jak uniknąć mieszania sygnałów z plików cookie innych firm? | Dziękujemy za tę opinię. Współpracujemy z CMA nad eksperymentami, które pozwolą uzyskać wiarygodny obraz wpływu wycofania plików cookie innych firm i wprowadzenia propozycji Piaskownicy prywatności na ekosystem. Zachęcamy do przesyłania dodatkowych opinii na temat propozycji CMA dotyczącej testów ilościowych bezpośrednio do CMA. |
| przejrzystszą dokumentację, | Prośba o bardziej przejrzystą dokumentację konfiguracji aukcji | W najbliższych tygodniach opublikujemy w blogu dodatkowy artykuł na temat raportowania aukcji FLEDGE. |
| równoległość | Czy usługa określania stawek i aukcja będzie obsługiwać paralelizację? | Technologia reklamowa korzystająca z serwerów ustalania stawek lub aukcji może uruchomić wiele serwerów, które mogą wyświetlać wyniki równolegle. |
| Zapobieganie nadużyciom | Czy serwer FLEDGE k-anonimowości korzystający z tokenów prywatności zapewni ochronę prywatności użytkowników? | K-anonimowość jest mniej związana z mikrotargetowaniem, a bardziej z zabezpieczeniem na czas przejściowy, w którym FLEDGE umożliwia raportowanie na poziomie zdarzenia. Udostępniliśmy więcej informacji i zapraszamy do przesyłania dodatkowych opinii. |
| Konflikt modułu ES | Prośba o usunięcie funkcji generateBid jako funkcji globalnej, ponieważ wchodzi ona w kolizję z modułem ES |
Rozpatrujemy tę prośbę i zapraszamy do dzielenia się opiniami. |
| Aukcja komponentów | Prośba o większą kontrolę wydawców nad projektami aukcji | Planowanie i przetargi będą obsługiwać aukcję komponentów, tak jak w przypadku Chrome na urządzeniu. |
| Osie czasu dotyczące pytań i odpowiedzi | Wyjaśnienie harmonogramu dla dostawców technologii reklamowych zainteresowanych testowaniem serwerów B&A | Właśnie zaktualizowaliśmy sekcję „Pytania i odpowiedzi” oraz sekcję „Harmonogram”, aby zawierała jasne definicje harmonogramów różnych faz testowania Chrome-B&A, zgodnie z wytycznymi CMA. |
| Schemat kontroli limitu czasu | Ulepszanie schematu kontroli limitu czasu dostępnego obecnie w FLEDGE | To ciekawa propozycja. Dodamy tę propozycję do kolejki i poinformujemy Cię o naszych postępach. |
| Strumienie danych kreacji | Możliwość sprawdzania i filtrowania zwycięskiej stawki na podstawie kreacji | To ciekawa propozycja. Dodamy tę propozycję do kolejki i poinformujemy Cię o naszych postępach. |
reportWin |
Propozycja dotycząca udostępniania dodatkowych informacji o ofercie z najwyższą liczbą punktów pochodzącej od innego właściciela grupy zainteresowań niż zwycięzca w funkcji reportWin |
To ciekawa propozycja. Rozważymy dodanie dodatkowych sygnałów w raportach zbiorczych i zapraszamy do dzielenia się opiniami tutaj. |
| Typy zdarzeń | Ujednolicenie typów zdarzeń w interfejsach API do pomiarów po zintegrowaniu z FLEDGE | To ciekawa propozycja. Dodamy tę propozycję do kolejki i poinformujemy Cię o naszych postępach. Wymaga to koordynacji z naszą szerszą działalnością w tej dziedzinie, ponieważ wpłynęłoby to na inne interfejsy API Piaskownicy prywatności niż FLEDGE. Tutaj możesz przesłać dodatkową opinię |
| Długoterminowe rozwiązania dotyczące raportowania na poziomie zdarzenia | zainteresowanie pozostawieniem dostępnych niektórych danych, np. highestScoringOtherBid, nawet po wycofaniu plików cookie innych firm; |
Jak informowaliśmy w poście na blogu z lutego, raportowanie wygranych aukcji na poziomie zdarzenia będzie obsługiwane „co najmniej do 2026 r.”. W tej chwili nie mamy więcej informacji, ale chętnie poznamy opinie na temat tego, dlaczego ważne jest, aby zachować dostępność niektórych danych po wycofaniu plików cookie innych firm. |
| Limit grup zainteresowań | Jaki jest limit liczby grup zainteresowań, do których źródło może dodać jedną przeglądarkę? | Chrome zezwala na maksymalnie 1000 grup zainteresowań na właściciela i maksymalnie 1000 właścicieli grup zainteresowań. Mają one pełnić funkcję barier ochronnych, a nie być osiągane podczas normalnej pracy. |
| Sygnały na poziomie zdarzenia | Wsparcie dla propozycji polegającej na udostępnieniu sygnałów na poziomie zdarzenia dotyczących generateBid i reportWin, które można wykorzystać do szkolenia systemów uczących się |
Udostępniliśmy tutaj naszą decyzję dotyczącą sygnałów z przeglądarki i sygnałów zdefiniowanych przez technologie reklamowe. Zachęcamy do przesyłania dodatkowych opinii. |
| Skrypt ustalania stawek | Uwzględnij identyfikator użytkownika w adresie URL skryptu ustalania stawek. | Nie będzie to możliwe, ponieważ FLEDGE ma dodatkowe wymaganie, że aby reklama mogła się wyświetlić, tuple właściciela grupy zainteresowań, adres URL skryptu ustalania stawek i renderowana kreacja muszą być k-anonimiczne. |
| Egzekwowanie k-anonimowości | Czy na parze (componentAd, size) jest wymuszana k-anonimowość? | Tak. Zapoznaj się z artykułem turtledove/issues/312. |
| Wymagania dotyczące usług określania stawek i aukcji | Jak usługi B&A obsługują uczestników integrujących się z FLEDGE na urządzeniu i innymi usługami B&A? | Nadal dopracowujemy wygląd. Tutaj możesz przesłać dodatkową opinię. |
| Atrybucja po obejrzeniu | Czy będzie obsługiwana atrybucja po obejrzeniu? | Obecnie nie mamy żadnej standardowej definicji widoczności, a oznaczenie zdarzenia wyświetlenia zależy od samej kreacji. Zapoznaj się z artykułem turtledove/issues/452. |
| Kierowanie na użytkowników podobnych | Czy Piaskownica prywatności obsługuje „docelowanie na podstawie podobnych odbiorców”? | Omawiamy przypadek użycia tutaj i zapraszamy do podzielenia się opinią. |
| Interfejs API do monitorowania w czasie rzeczywistym | Propozycja podejścia do monitorowania FLEDGE w czasie rzeczywistym | Rozważamy tę propozycję i zapraszamy do przesyłania dodatkowych opinii. |
| Raportowanie FLEDGE | reportWin i reportResult powinny być wykonywane w losowej kolejności, aby zapobiec nadmiernemu lub niewystarczającemu raportowaniu. |
reportResult() musi być wykonana przez sprzedawcę, a dopiero potem przez kupującego, aby sygnały sprzedawcy z reportResult() mogły być uwzględnione w reportWin().reportWin() Więcej informacji znajdziesz w tym artykule. |
| Serwery par klucz-wartość | Czy w przyszłości będą obsługiwane niestandardowe serwery K/V? | Tutaj omawiamy to pytanie i zapraszamy do podzielenia się dodatkowymi informacjami. |
| Aukcja najwyższego poziomu | Czy aby stosować mechanizmy aukcji na najwyższym poziomie, trzeba być serwerem reklam? | Interfejs FLEDGE API nie określa, która strona musi go wywołać. W ramach projektu FLEDGE nie ma żadnych wymagań w tym zakresie. Każdy może prowadzić aukcję FLEDGE (w tym aukcje z udziałem wielu sprzedawców). Jak wspomniano w raporcie z IV kwartału 2022 r., FLEDGE umożliwia każdemu wydawcy wybór struktury aukcji, w tym wybór sprzedawców na najwyższym poziomie i sprzedawców komponentów. |
| Zakres interfejsu API | Czy FLEDGE ma działać z danymi własnymi? | W II kwartale 2023 r. opublikujemy treści, które wyjaśnią, że dane własne można używać z FLEDGE na 2 cele: 1) jako logikę do określania przynależności do grupy zainteresowań oraz 2) jako sygnały dotyczące licytowania przez użytkownika na potrzeby dalszego generowania logiki ustalania stawek. |
| Grupy zainteresowań w wielu domenach | Możliwość tworzenia grup zainteresowań obejmujących wiele domen | Do informowania odbiorców można używać wszelkich informacji dostępnych w momencie dodawania przeglądarki do grupy zainteresowań. Gdy pliki cookie innych firm zostaną wycofane, dostępność danych z różnych witryn, które służą do tworzenia grup odbiorców, będzie ograniczona. |
| Logika określania stawek po stronie klienta | Przenoszenie dotychczasowej logiki określania stawek po stronie serwera na stronę klienta | Chcielibyśmy dowiedzieć się więcej o tym, które obszary są trudne lub w których obecnie brakuje nam informacji w procesie przenoszenia. Czekamy na dodatkowe opinie i wskazówki. |
| Wartości serwera K/V | Czy wartości na serwerze K/V muszą być typu string? | Wartość musi być ciągiem znaków, ale można w niej przechowywać obiekty w formacie JSON lub w buforze protokołu i zserializować je w ciągu. |
| Lista zablokowanych reklamodawców | Jakie sygnały należy przekazać kupującemu, aby znalazł się na liście blokowania reklamodawcy? | Odpowiednie miejsce znajduje się w auctionSignals lub w perBuyerSignals. |
| Jednostka określania stawek | Obsługa różnych jednostek ustalania stawek, np. CPI i CPM | Chcielibyśmy dowiedzieć się więcej o tym, dlaczego jest to konieczne w obecnej wersji, i uzyskać dodatkowe opinie. |
| Logika aukcji | Kto decyduje o zwycięzcy aukcji: przeglądarka czy serwer reklam? | Wybór zwycięzcy jest wykonywany w piaskownicy, a wszystkie decyzje podejmuje kod sprzedawcy. Przeglądarka udostępnia zamknięte, prywatne środowisko, w którym działa kod kupującego i sprzedawcy. |
| Permissions-Policy | Czy po zakończeniu testowania origin FLEDGE nadal będą obowiązywać zasady dotyczące uprawnień FLEDGE? | W przypadku wersji próbnej Origin obecne domyślne listy dozwolonych obu funkcji są tymczasowe i zostaną zmienione. Chcielibyśmy się dowiedzieć, ile czasu potrzebują specjaliści od reklam, aby przygotować się do wprowadzenia tej zmiany, zanim zaczniemy egzekwować te zasady. |
| Ograniczenie dotyczące rozmiaru sygnału | Żądania dotyczące zaufanych sygnałów ustalania stawek są scalane w ramach wielu grup zainteresowań o tym samym trustedBiddingSignalsUrl. Limit rozmiaru 2 MB jest ograniczeniem. |
Ograniczenie dotyczy wywołujących funkcji na urządzeniu, aby zapobiec przytłoczeniu zasobów na urządzeniu. Połączenia z serwera B&A będą podlegać mniej surowym ograniczeniom. |
| Sygnały związane z raportowaniem | Dodaj dodatkowy sygnał, script-errors, aby umożliwić pobieranie liczby błędów po stronie klienta na podstawie właściciela grupy zainteresowań i computeBid lub reportWin / reportResult. |
Rozważamy potencjalne obawy dotyczące prywatności związane z tą propozycją i zapraszamy przedstawicieli ekosystemu do podzielenia się dodatkowymi informacjami na temat tego, dlaczego jest to potrzebne. |
| Rozmiar okna K-Anon | Zwiększenie rozmiaru okna K-Anon z obecnego limitu 7-dniowego. | Rozważamy tę kwestię i czekamy na dodatkowe opinie z ekosystemu. |
| Wydajność urządzenia | Jak FLEDGE radzi sobie z wydajnością urządzenia, jeśli użytkownik należy do dużej liczby grup zainteresowań? | FLEDGE udostępnia kilka opcji limitowania, priorytetów i czasu oczekiwania w ramach SSP i DSP, które zapewniają specjalistom ds. reklam szczegółową kontrolę w sytuacjach, gdy wydajność urządzenia może być jednym z powodów ograniczenia udziału w aukcji, gdy urządzenie znajduje się w dużej liczbie grup zainteresowań. |
| Testowanie usług B&A | Poproś graczy w ekosystemie o używanie własnego serwera podczas fazy testowania, aby mieć więcej dzienników dostępnych do debugowania. | B&A umożliwia użytkownikom uruchamianie i skalowanie serwerów od zatwierdzonych dostawców usług w chmurze. Aby zapewnić ochronę prywatności użytkowników, wymagamy, aby wykonanie odbywało się w zaufanym środowisku wykonawczym (TEE). Wkrótce opublikujemy wyjaśnienie debugowania TEE w B&A i będziemy rozwijać funkcje, które to umożliwią. Chcemy uzyskać więcej opinii na ten temat. |
| Wymogi regulacyjne | Czy FLEDGE będzie współpracować z dostawcami usług w chmurze w różnych krajach, aby wspierać zgodność z lokalnymi wymaganiami regulacyjnymi? | Zawsze jesteśmy otwarci na sugestie dotyczące innych dostawców usług w chmurze, ale obecnie planujemy zapewnić obsługę co najmniej GCP i AWS, gdy wycofanie plików cookie innych firm zostanie wyegzekwowane. Więcej informacji znajdziesz w tym artykule. |
Pomiar skuteczności reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Analiza danych o wpływie szumu | Wskazówki dotyczące analizy danych dotyczących wpływu szumu | Udostępniliśmy dodatkową dokumentację dotyczącą szumu oraz decyzji dotyczących szumu i projektu, które mogą zmienić wpływ szumu na dane adtech. Dostępny jest też bardziej szczegółowy przewodnik. |
| Raportowanie wartości null | Więcej informacji o wdrażaniu raportów pustych | Obecnie pracujemy nad propozycją wdrożenia raportów z wartościami null i wkrótce podamy więcej informacji. Wdrożenie raportów pustych pozwoli nam zredukować opóźnienia w raportach bez naruszania prywatności. |
| Poziom hałasu | dostosowywanie poziomu szumów na podstawie długości okna atrybucji; | Zgadzamy się z tą propozycją i rozważamy dodanie jej do specyfikacji. Tutaj możesz przesłać dodatkową opinię. |
| Rozmiar danych wyzwalacza | Dlaczego rozmiar danych wyzwalacza jest ograniczony do 3 bitów? | Rozmiar jest ograniczony do 3 bitów i 8 różnych wartości, aby ograniczyć ilość informacji o użytkowniku w różnych witrynach i w różnych kontekstach. Zachęcamy uczestników ekosystemu do przesłaniania opinii na temat tego, czy obecna parametryzacja raportowania na poziomie zdarzenia jest sensowna. |
| Aktywatory raportowania na poziomie zdarzenia | Zezwalanie na ustalanie priorytetów w ramach klucza deduplikacji | Zbieramy informacje na temat tego problemu i zapraszamy do dzielenia się opiniami. |
| Pomoc dotycząca debugowania | Więcej informacji o debugowaniu po wycofaniu plików cookie innych firm | Chcemy ułatwić debugowanie po wycofaniu plików cookie innych firm i rozważamy różne opcje. Chcielibyśmy uzyskać dodatkowe opinie i sugestie. |
| Konwersje po kliknięciu – alternatywne sposoby liczenia | Prośba o dodatkowe wskazówki dotyczące alternatyw dla konwersji po kliknięciu | Zachęcamy uczestników ekosystemu do korzystania z interfejsu Attribution Reporting API jako trwałego prywatnego systemu pomiarowego w przypadku odpowiednich zastosowań pomiaru konwersji. Istnieją też inne alternatywy, a dostawcy technologii reklamowych będą musieli wybrać odpowiednie rozwiązanie na podstawie swoich potrzeb związanych z prywatnością i użytecznością. |
| Przykłady użycia płatności | Wyjaśnienie, w jakim zakresie raportowanie atrybucji będzie obsługiwać przypadki użycia rozliczeń na podstawie konwersji | Pracujemy nad opublikowaniem informacji, które wyjaśnią zakres stosowania interfejsu Attribution Reporting API do rozliczeń. Interfejs Attribution Reporting API nie był początkowo ograniczony w sposób, który bezpośrednio obsługuje rozliczenia CPA. Obsługuje on rozliczenia CPC i CPM, które są strukturą rozliczeniową stosowaną przez większość firm technologicznych zajmujących się reklamami. W przyszłości możemy dodać tę opcję, jeśli otrzymamy więcej opinii na ten temat. |
| Obsługa przypadków użycia | Dokumentacja dotyczące zastosowania interfejsu Measurement API | Pracujemy nad uszczegółowieniem dokumentacji dotyczącej wszystkich interfejsów raportowania w Piaskownicy prywatności. |
| Jakość kliknięcia | Prośba o dodanie sygnału umożliwiającego rozróżnienie celowych i przypadkowych kliknięć reklamy | Rozpatrujemy prośbę i zapraszamy do podzielenia się dodatkowymi informacjami. |
| Rozwiązanie analityczne | Obsługa rozwiązań pomiarowych w różnych systemach DSP | Dostawcy usług pomiarowych mogą używać interfejsu Attribution Reporting API do usuwania duplikatów między wieloma platformami DSP. Proponujemy też obsługę listy adresów URL w attributionsrc, co ułatwi dostawcom usług w zakresie reklamy obsługę żądań interfejsu Attribution Reporting API dostawcy pomiarów. Czekamy na każdą dodatkową opinię na temat tej propozycji. |
| Raportowanie na poziomie zdarzenia | Prośba o zwiększenie liczby dni przed wysłaniem raportu bezpośrednio do | Technika reklamowa może już obliczyć to żądanie, korzystając z dostępnych informacji. Nie otrzymaliśmy żadnych innych opinii na temat tej prośby, ale chętnie poznamy Wasze opinie. |
source_registration_time |
Dodaj source_registration_time w raportach atrybucji na poziomie zdarzenia. |
Rozważamy tę prośbę i zapraszamy do podzielenia się opinią na temat tego, czy gracze uważają, że jest to przydatna funkcja. |
| Tryb incognito | Czy rozwiązania do pomiarów będą dostępne, gdy użytkownik korzysta z trybu incognito? | Nie, rozwiązania do pomiarów nie będą dostępne, gdy użytkownik korzysta z trybu incognito. Pliki cookie innych firm są domyślnie wyłączone w trybie incognito. |
| Usługi data clean room | Czy interfejsy Measurement API będą kompatybilne z usługami data clean room? | Typowa usługa data clean room to środowisko, w którym dane identyfikacyjne z różnych źródeł są przesyłane do bazy danych w celu przeprowadzania analiz na podstawie złączenia tych danych. 2 ramy pomiarowe interfejsów API Piaskownicy prywatności to raporty na poziomie zdarzenia i raporty zbiorcze. Raporty na poziomie zdarzenia zawierają identyfikator zdarzenia podany przez dostawcę technologii reklamowej, który można wykorzystać w czystej sali danych, ale informacje powiązane z konwersją będą ograniczone i nieprecyzyjne. Zaszyfrowane raporty podlegające agregacji nie mogą być używane bezpośrednio w czystej sali, ale podsumowane wyniki udostępniane przez usługę agregującą mogą służyć jako dane wejściowe do przeprowadzanych przez Ciebie analiz lub jako informacje uzupełniające. |
Usługa do agregacji
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (Zgłoszone również w IV kwartale 2022 r.) Opóźnienia w raportowaniu |
Jakie jest oczekiwane opóźnienie raportowania? | Aktualizacja z I kwartału 2023 r.: Po uwzględnieniu opinii partnerów przedstawiliśmy propozycje zmniejszenia opóźnień i ograniczenia ich wpływu. Obie propozycje zostały poparte przez technologie reklamowe podczas rozmów w ramach WICG. |
| Reguła dotycząca braku duplikatów | Jak potraktować „opóźniony raport zbiorczy”, jeśli raporty zbiorcze, które mają ten sam wspólny identyfikator, zostały już przetworzone? | Udostępniliśmy propozycję dodania do udostępnianych informacji o zbiorczych raportach dodatkowego opóźnienia raportów oraz zdefiniowaliśmy udostępniany identyfikator dla usługi agregacji, aby częściowo rozwiązać problem utraty danych spowodowany opóźnieniem w przypadku zbiorczego interfejsu API. Czekamy na opinie na temat tej propozycji. |
| Przetwarzanie danych | Prośba o włączenie obsługi wielu przejść danych z zachowaniem prywatności różnicowej przy użyciu budżetu prywatności | Rozważamy możliwość użycia bardziej elastycznego sposobu wykorzystania budżetu na prywatność, aby umożliwić ten przypadek użycia. Zapraszamy do dodania opinii. |
| (również w II kwartale 2022 r.) Ergonomia zapytań | Włącz zapytania dotyczące agregacji kluczy. | Aktualizacja z I kwartału 2023 r.: Prośba o dodanie funkcji jest nadal rozpatrywana, ale obecnie nie mamy żadnych propozycji do udostępnienia. |
| Ograniczenia wersji próbnej Origin | wyjaśnienie zakresu usługi agregacji, np. reguły „bez duplikatów”, która nie jest obecnie stosowana w wersji próbnej źródła; | Zamierzamy zaktualizować naszą dokumentację, aby wyjaśnić, co będzie dostępne w wersji próbnej i w wersji GA. |
Interfejs Private Aggregation API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Budżet na potrzeby prywatnej agregacji | Budżet na udział w kampanii L1 jest zbyt restrykcyjny. | Każde wywołanie interfejsu Private Aggregation API jest nazywane udziałem. Aby chronić prywatność użytkowników, liczba treści, które mogą być zbierane od danej osoby, jest ograniczona. Jeśli zsumujesz wszystkie wartości podlegające agregacji we wszystkich kluczach agregacji, suma musi być mniejsza od budżetu udziału. W ramach obecnej architektury ustawiamy limit udziału w przypadku określonego źródła danych w ciągu ostatnich około 24 godzin (jako przedział cykliczny). Jest to budżet udziału w kampanii L1 wspomniany w opinii. Zalecamy deweloperom, aby skalowali wartości, które wnoszą, na podstawie oczekiwanej liczby (czyli nie tylko przy użyciu wartości 1). Dlatego warto użyć mniejszej wartości w przypadku częstszych zdarzeń, aby uniknąć wyczerpania budżetu. Szukamy obecnie opinii na temat budżetu na wkład w ramach prywatnego zbiorczego interfejsu API, zarówno w zakresie, jak i w ramach liczbowych. Rozważamy rozszerzenie zakresu z pojedynczego źródła na pojedynczą witrynę i zmianę obecnego limitu na 10-minutowy przedział z większym dziennym limitem. |
Ograniczanie śledzenia ukrytego
Redukcja klienta użytkownika/wskazówki dotyczące klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Przyjęcie UA-R | Spośród 10 tys. najpopularniejszych witryn w Wielkiej Brytanii tylko 1% witryn korzystających z reklam programmaticowych wysyła wskazówki HTTP dotyczące klienta. Platformy DSP, które nie zostały przeniesione, mogą mieć wpływ na funkcje zapobiegania oszustwom. | Po przeprowadzeniu analizy tego samego zbioru danych stwierdziliśmy, że jeśli weźmiesz pod uwagę użycie UA-CH za pomocą tagu HTML <meta> i interfejsów API JavaScript, liczba witryn korzystających z UA-CH jest znacznie większa niż podana w opinii wartość 1%. Na podstawie tych i innych faktów, w tym opinii z ekosystemu, czujemy się pewnie, że możemy rozpocząć stopniowe wdrażanie fazy 6 redukcji UA zgodnie z opublikowanym harmonogramem, jednocześnie informując o tym CMA. Pamiętaj, że na przygotowanie do tej zmiany masz prawie 2 lata. W przypadku witryn, które nie są jeszcze gotowe, nadal dostępna jest wersja próbna funkcji wycofywania. |
| Wskazówki dotyczące dodatkowych formatów | Prośba o dodanie przez UA-CH dodatkowych formatów, takich jak TV i VR | Ta propozycja jest dla nas korzystna i zamierzamy uwzględnić ją w naszym projekcie. Zachęcamy do przesłaniania dodatkowych opinii. |
| Testowanie automatyczne | Prośba o naprawienie błędu UA-CH w Chrome bez interfejsu graficznego przed wdrożeniem UAR w fazie 6 | Błąd został naprawiony. |
| Obsługa UA-CH w iOS | Witryna, która korzysta z szczegółowych informacji UA do celów reklamowych, informuje, że Chrome na iOS nie jest obsługiwany. | W przypadku przeglądarek na iOS innych niż Safari (w tym Chrome na iOS) przed włączeniem tych funkcji projekt WebKit musi dodać obsługę UA-CH (ponieważ kontrolują one warstwę sieciową). |
Ochrona IP (dawniej Gnatcatcher)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (zgłoszone również w IV kw.) Zastosowania lokalizacji geograficznej | Ochrona adresu IP może uniemożliwić działanie uzasadnionych zastosowań lokalizacji geograficznej, takich jak personalizacja treści na podstawie lokalizacji. | Nasza odpowiedź nie uległa zmianie od IV kwartału 2022 r.: „Współpracujemy z zainteresowanymi stronami, aby Chrome nadal obsługiwało uzasadnione przypadki użycia adresów IP. Chcielibyśmy uzyskać opinie dotyczące precyzji geolokalizacji adresów IP.” |
| Zgodność z przepisami | Jeśli w danym regionie mieszka mniej niż 1 mln mieszkańców, obecny próg ochrony adresów IP wynoszący 1 mln uniemożliwiłby witrynom korzystanie z adresów IP do celów zgodności z przepisami. | Współpracujemy z partnerami, aby zapewnić, że Chrome będzie nadal obsługiwać uzasadnione przypadki użycia adresów IP. Chcemy poznać opinie dotyczące zgodności z wymaganiami prawnymi w zakresie ochrony własności intelektualnej. |
| Zapobieganie nadużyciom | Strony mogą obejść ochronę adresów IP, udostępniając innym niezamaskowane adresy IP. | Zdajemy sobie sprawę, że obecna propozycja ochrony adresów IP może nie zapobiegać udostępnianiu niezamaskowanych adresów IP innym osobom. Pracujemy nad rozwiązaniami, które pozwolą uniknąć ryzyka nadużyć. Podczas ulepszania tej propozycji zachęcamy do przesyłania opinii i prowadzenia dyskusji. Chodzi nam konkretnie o przypadki, w których strony uważają, że muszą udostępnić innym stronom niezamaskowane adresy IP. |
| Blokowanie sieci | Strony mogą obejść blokowanie sieci, korzystając z serwerów proxy chroniących adres IP. | W tym scenariuszu podmiot wykonujący blokowanie musi wyłączyć ochronę IP. Odpowiedzieliśmy na to zgłoszenie i zapraszamy do przesyłania dodatkowych opinii. |
| Listy zablokowanych adresów IP, których dotyczy propozycja ochrony adresów IP | Wiele firm zajmujących się technologiami reklamowymi korzysta z podstawowej listy adresów IP, takiej jak lista adresów IP centrów danych TAG, aby zapobiegać ustalaniu stawek za zasoby reklamowe, które z dużą dozą prawdopodobieństwa są oszukańcze (lub przynajmniej nie można z nich zarabiać). Jeśli dostawca technologii reklamowej jest też narzędziem do śledzenia i może podlegać propozycji dotyczącą ochrony własności intelektualnej, może stracić możliwość wykonania podstawowej kontroli reklam przed zakupem zasobów reklamowych. | Zachęcamy do przesyłania opinii i dyskusji na temat propozycji ochrony własności intelektualnej oraz potencjalnych problemów i rozwiązań. Jedną z opcji jest zastosowanie podobnych list do ochrony adresów IP, aby nie przekierowywać klientów pochodzących z adresów IP oznaczonych wcześniej jako niebezpieczne. |
Wzmocnienie granic prywatności między witrynami
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (odnotowano również w IV kwartale) Limit domen | Prośba o zwiększenie liczby powiązanych domen | Nasza odpowiedź nie zmieniła się od IV kwartału 2022 r.: "Podczas rozmów z WICG wyjaśniliśmy, że Chrome jest zdeterminowane, aby zapewnić użyteczne rozwiązanie, które będzie uwzględniać również interesy użytkowników w zakresie prywatności. W związku z tym ocenimy opinie społeczności na temat konkretnych przypadków użycia, na które może mieć wpływ limit domen, abyśmy mogli rozważyć sposoby uwzględnienia tych przypadków przy jednoczesnym zachowaniu prywatności użytkowników”. |
| Przesyłanie alternatywnej liczby klatek na sekundę | Propozycja dotycząca alternatywnego sposobu przesyłania globalnych list do FPS | Obecnie przygotowujemy się do udostępnienia w Chrome zestawów źródeł własnych. Skonfigurowaliśmy scentralizowane repozytorium GitHub, aby przyjmować przesyłane zestawy. Mamy nadzieję, że FPS wypełni lukę w dotychczasowych rozwiązaniach platform internetowych w ramach przygotowań do wycofania plików cookie innych firm. Dlatego chcielibyśmy dowiedzieć się, jak autorzy witryn korzystają z FPS. Z upływem czasu lista zbiorów będzie się powiększać, a ekosystem będzie się dostosowywać do świata bez plików cookie innych firm. Możemy też doprowadzić proces do takiego punktu, w którym będziemy mogli rozważyć alternatywne zdecentralizowane schematy, takie jak ten, który został zaproponowany. W ramach obecnego procesu spodziewamy się wprowadzenia ograniczeń czasowych, które pozwolą nam ulepszać proces przyjmowania reklam. Możemy wrócić do tej propozycji, gdy proces przesyłania dojrzeje. |
| Moderowanie repozytorium | Wprowadzić moderację społeczności repozytorium przesyłania FPS, aby zapobiec nadużyciom. Osoby o złych zamiarach mogą łatwo przeciążyć proces, używając do proponowania zestawów adresów pochodzących z tymczasowych kont. Ogromna liczba żądań może wpływać na działanie prawdziwych propozycji zestawów. | Staramy się, aby kontrole były jak najbardziej obiektywne, dlatego polegamy na weryfikacji technicznej. Uważamy, że jest to najbardziej elastyczne podejście do procesu przesyłania. W związku z tym będziemy też dbać o to, aby proces był odporny na spam i fałszywe zgłoszenia. |
| Powiązane podzbiory | Czy FPS będzie obsługiwać przypadki użycia związane z zewnętrznych dostawców/usług SaaS za pomocą powiązanych podzbiorów? | Procesy dostawców zewnętrznych lub SaaS nie są przypadkiem użycia, które są obecnie uwzględniane w zakresie zestawów źródeł własnych. Zachęcamy do przesłaniania dodatkowych opinii na temat sposobu używania plików cookie w przypadku tych zastosowań. |
| Integracja FPS z CHIPS | Prośba o integrację FPS i CHIPS na potrzeby takich zastosowań jak testy A/B | Rozmawiamy o tym przypadku użycia i zastanawiamy się nad omówieniem go podczas spotkania WICG. Zachęcamy do dodania komentarza tutaj. |
| RODO | Propozycja dotycząca nowego podzbioru FPS, który ma być modelowany na podstawie koncepcji RODO | Omówiliśmy tę propozycję wewnętrznie i porównaliśmy ją z innymi otrzymanymi opiniami oraz naszymi celami w zakresie ochrony prywatności. Udostępniliśmy odpowiedź, w której wyjaśniamy, dlaczego nie będziemy realizować tej propozycji w danym momencie. |
| Pamięć | Przewidywana zmiana rozmiaru pamięci przeglądarki po uwzględnieniu listy FPS | W przypadku przeglądarek zdarzało się, że przechowywały one tego typu listy z minimalnym wpływem na pamięć, np. listę Disconnect Tracking Protection. Lista zestawów źródeł własnych zostanie skopiowana lokalnie do każdego klienta Chrome, ale będziemy nadal monitorować rozmiar plików i liczymy, że uda nam się zoptymalizować wykorzystanie pamięci. |
Fenced Frames API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ograniczenia ramek chronionych | wyjaśnienie ograniczeń nakładanych przez ramki ograniczone; | W marcu zaktualizowaliśmy artykuł na temat możliwości ramek ograniczonych. Zachęcamy do zapoznania się z nim. Czekamy też na dodatkowe opinie. |
| Rozwiń informacje o dostępie | Prośba o rozszerzenie dostępu do informacji o sąsiednich ramach | Chcemy lepiej zrozumieć, dlaczego jest to wymagane przez ekosystem, i zapraszamy do przesłania dodatkowych opinii. |
| Ramki chronione i iframe | Pytania dotyczące funkcji wspólnych dla odizolowanych ramek i iframe | Wszystkie dostępne interfejsy API i raporty Piaskownicy prywatności będą dostępne w ten sam sposób w przypadku iframe’ów i fencedFrame’ów. |
| Zmiana rozmiaru ramek chronionych | Ograniczenie zmian rozmiaru ramki ma wpływ na niektóre przypadki użycia. | Chcielibyśmy dowiedzieć się więcej o typach przypadków użycia, na które wpływają te ograniczenia, i otrzymać dodatkowe opinie. |
Interfejs Shared Storage API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Elementy zewnętrzne | Czy podmioty zewnętrzne mogą zapisywać dane w wspólnej pamięci, partycjonowanej według źródła? A może wywołać inne worklety do pomiarów zewnętrznych? | Pochodzenie kontekstu przeglądania, w którym kod jest wykonywany, określa, do czyjego współdzielonego magazynu danych są zapisywane dane. Gdy na stronie dodasz kod innej firmy, możesz go umieścić jako element iframe z własnym kontekstem przeglądania, co pozwoli mu zapisywać dane w swoim źródle. Kod innej firmy może być również umieszczony jako skrypt zamiast elementu iframe, co nie powoduje zmiany kontekstu przeglądania. Kod innej firmy może zapisywać dane w współdzielonej pamięci dostawcy. Pamiętaj, że tylko właściciel udostępnionego magazynu może odczytywać dane z tego magazynu. |
| Deduplikacja | W przypadku interakcji poza ekosystemem Chrome deduplikacja nie byłaby możliwa. | Udostępniona pamięć ma zapewniać unikalne wyniki w Chrome na podstawie przeglądarki. Chcemy współpracować z dostawcami technologii reklamowych, aby dowiedzieć się, jak te dane można wykorzystać w ramach szerszych modeli zasięgu. Rozumiemy, że same dane wyjściowe mogą dotyczyć tylko części interakcji, i chcielibyśmy współpracować z technologiami reklamowymi, aby zbadać dodatkowe metody modelowania, które można nałożyć na dane wyjściowe. |
| Okno konwersji | Prośba o okres ważności współczynnika konwersji, aby można było obserwować zmiany konwersji w czasie | Można to zaimplementować, przetwarzając różne ścieżki konwersji po stronie klienta za pomocą wspólnego magazynu, co zapewnia dodatkową elastyczność w przypadku zaawansowanych analiz w porównaniu z bezpiecznym niepartycjonowanym magazynem w przeglądarce. |
| Okres ważności produktu | Prośba o przedłużenie okresu ważności do 90 dni | Zasady przechowywania danych zostały zaktualizowane w listopadzie 2022 r. i określają, że każdy klucz jest usuwany po upływie 30 dni od ostatniej modyfikacji. Zapraszamy do dzielenia się opiniami, abyśmy mogli lepiej zrozumieć, czy nowa zasada sprawdzi się w ekosystemie. |
| Rotacja kreacji | Przypadki użycia rotacji kreacji nie odzwierciedlają rzeczywistych działań po aukcji. | Chcemy uzyskać informacje od większej liczby firm technologicznych po stronie kupującego, które pomogą nam ustalić, czy dokumentacja rotacji kreacji jest prawidłowa. |
CHIPs
W tym kwartale nie otrzymaliśmy żadnych opinii.
FedCM
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Punkt końcowy potwierdzenia tożsamości | Zezwalaj na dowolne żądania do punktu końcowego potwierdzenia tożsamości. | Współpracowaliśmy z firmą Mozilla nad tą propozycją pull request, aby ograniczyć możliwość wysyłania przez witryny żądań z użyciem poświadczeń w innych domenach bez wywoływania irytacji u użytkowników. Będziemy też nadal analizować inne opinie i na ich podstawie wprowadzać zmiany. |
| Wstępne wypełnianie tożsamości | Czy można używać FedCM do wstępnego wypełniania formularzy logowania za pomocą dostawcy tożsamości z listy FedCM? | W tym przypadku istnieje ryzyko wycieku informacji, ponieważ witryna, która nie ma kontaktu z użytkownikiem, może wysłać zapytanie do ostatniego dostawcy tożsamości internetowej użytego przez użytkownika. Rozmawiamy o tym problemie i zapraszamy do dzielenia się opiniami. |
| Wybór konta w kontekście | Propozycja dodania sygnałów kontekstowych do interfejsu wyboru konta | Rozważamy tę propozycję i zapraszamy do dalszych rozmów. |
Walka ze spamem i oszustwami
Interfejs Private State Token API (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ankieta dotycząca możliwości | Na początku pierwszego kwartału zakończyliśmy zbieranie wyników ankiety dotyczącej tego, jakie funkcje są potrzebne do różnych zastosowań zapobiegania oszustwom, i udostępniliśmy je publicznie (minutes, results). | Planujemy uwzględnić te opinie podczas opracowywania nowych propozycji i prototypów interfejsów API do ochrony prywatności, które mają służyć do zwalczania oszustw. Zamierzamy nadać priorytet rozwojowi tam, gdzie istnieje odpowiednia potrzeba i dostępna jest technologia, na której możemy budować, aby wprowadzić nowe funkcje do internetu, zachowując przy tym prywatność użytkowników. Na przykład integralność urządzenia i boota była wysoko oceniana, a wiele platform ma interfejsy API, które bezpiecznie udostępniają ocenę integralności urządzenia, więc jest to dobry kandydat do dalszego badania w grupach społeczności. |
| Opinia o PST dotyczącej przesyłki | W związku z zamiarem wprowadzenia tej funkcji otrzymaliśmy zgłoszenie dotyczące wątpliwości co do dalszych działań, ponieważ korzystamy ze starszej wersji Privacy Pass. Otrzymaliśmy też opinie, że specyfikacja jest niejasna w niektórych sekcjach i należy ją ulepszyć, aby ułatwić zgodność z przeglądarkami. | Planujemy wdrożenie wielu sugerowanych zmian specyfikacji przed udostępnieniem wersji GA, a także kilka zmian w interfejsie API. Opinia została przesłana pod koniec pierwszego kwartału, dlatego sprawdzamy problemy na GitHubie, aby uzyskać więcej informacji i zaktualizować nasz plan wprowadzania (w trakcie opracowywania w momencie publikacji tego raportu). Jeśli chodzi o większe zmiany w interfejsie API, jesteśmy gotowi je rozważyć, ale uważamy, że najlepszym rozwiązaniem jest wdrożenie tej funkcji w wersji ogólnodostępnej i uzyskanie opinii większej liczby deweloperów. Mamy nadzieję, że uda nam się kontynuować tę dyskusję i doprowadzić do ujednolicania przeglądarek. Jeśli pojawi się nowy standard, rozważymy jego wdrożenie i opracowanie planu, który pozwoli na jego płynne wdrożenie. |