Raport kwartalny za 3 kwartał 2022 r. zawierający podsumowanie opinii ekosystemu na temat ofert pakietowych Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wynikających z umowy CMA firma Google zobowiązała się do publicznego udostępniania kwartalnych raportów z procesu zaangażowania zainteresowanych osób w przypadku propozycji Piaskownicy prywatności (zob. art. 12 i 17(c)(ii) Zobowiązań). Te raporty z podsumowaniem Piaskownicy prywatności są generowane na podstawie opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym między innymi na temat problemów na GitHubie, formularza opinii dostępnego na stronie privacysandbox.com, spotkań z zainteresowanymi osobami z branży i forów standardów internetowych. Chrome z radością korzysta z opinii otrzymywanych od ekosystemu i aktywnie analizuje sposoby wykorzystywania zdobytych informacji na potrzeby podejmowania decyzji projektowych.
Tematy opinii są uporządkowane według częstości występowania w poszczególnych interfejsach API. Na podstawie zebranych przez zespół Chrome opinii na temat danego motywu są one uporządkowane w kolejności malejącej. Wspólne tematy opinii zostały zidentyfikowane przez przejrzenie tematów dyskusji ze spotkań publicznych (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz częstych pytań zadawanych przez wewnętrzne zespoły Google i formularze publiczne.
Dokładniej rzecz ujmując, przeanalizowano protokoły ze spotkań zebrań standardowych instytucji internetowych, a w przypadku bezpośrednich opinii – zapisy Google ze spotkań 1:1, e-maile otrzymane przez poszczególnych inżynierów, listę adresową interfejsu API oraz publiczny formularz opinii. Następnie zespół Google skoordynował zespoły zaangażowane w te działania informacyjne, aby określić względną popularność tematów pojawiających się w odniesieniu do poszczególnych interfejsów API.
Wyjaśnienia odpowiedzi Chrome na opinie opracowano na podstawie opublikowanych odpowiedzi na najczęstsze pytania, rzeczywistych odpowiedzi zgłoszonych przez zainteresowane osoby oraz określenia stanowiska na potrzeby tego publicznego raportowania. W związku z obecnym celem programowania i testowania otrzymaliśmy pytania i opinie dotyczące interfejsów API Topics, Fledge i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu raportowania mogły jeszcze nie zostać uznane za odpowiedź Chrome.
Słowniczek akronimów
- ELEMENTY
- Pliki cookie z niezależnym trybem partycjonowania
- (procesor) DSP
- Platforma DSP
- FedCM
- Sfederowane zarządzanie danymi uwierzytelniającymi
- kl./s
- Zestawy własne
- IAB
- Interactive Advertising Bureau ,
- dostawca tożsamości
- Dostawca tożsamości
- IETF
- Internet Engineering Task Force
- IP
- Adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Wersja próbna
- PatCG
- Grupa społecznościowa Private Advertising Technology
- RP
- Grupa uzależniona
- platforma SSP
- Platforma dostawców reklam
- TEE
- Zaufane środowisko wykonawcze
- UA
- Ciąg znaków klienta użytkownika
- UA-CH
- Wskazówki dotyczące klienta użytkownika
- W3C
- World Wide Web Consortium
- WIPB
- Niewiarygodna ślepotyka na adresy IP
Ogólna opinia, brak konkretnego interfejsu API/technologii
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| (również w II kwartale)
Przydatność dla różnych zainteresowanych osób |
Obawia się, że technologie Piaskownicy prywatności są faworyzowane przez większych deweloperów, a mniejsze witryny mają w ich przypadku większy udział niż ogólnikowe (większe) witryny. | Aktualizacja na III kwartał:
Firma Google zobowiązała się do opracowania i wdrożenia ofert Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samo podawanie się przez własną firmę Google i uwzględniać wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszej pracy z tymi zobowiązaniami. W miarę postępów testów Piaskownicy prywatności jednym z najważniejszych pytań, jakie będziemy musieli ocenić, będzie skuteczność nowych technologii w przypadku różnych rodzajów zainteresowanych osób. Opinie są w tym przypadku bardzo ważne – zwłaszcza konkretne i przydatne informacje, które mogą nam pomóc w ulepszaniu projektów technicznych. Współpracowaliśmy z organizacją CMA nad opracowaniem naszego podejścia do testów ilościowych i jesteśmy wspierającymi w jej obszerności publikowanej przez nią uwagi na temat projektu eksperymentu, która zapewni uczestnikom rynku dodatkowe informacje i okazję do wypowiedzenia się na temat proponowanych metod. |
| (również w II kwartale)
Prośby o dokumentację |
Prośby o dostęp do dodatkowych materiałów na temat zarządzania testowaniem, analizą i wdrażaniem | Aktualizacja na III kwartał:
Cieszymy się, że nasze obecne materiały okazały się dla deweloperów przydatne. W najbliższych tygodniach i miesiącach będziemy dodawać kolejne materiały, aby mogli nadal lepiej rozumieć, jak nowe technologie przydają się im do pracy. Organizowane są też publiczne sesje konsultacji dla programistów, podczas których dzielimy się sprawdzonymi metodami i prezentacjami, a także organizujemy sesje pytań i odpowiedzi z kierownikami ds. usług i inżynierów, podczas których można zadawać pytania i dyskutować na żywo. |
| Obsługa różnych przeglądarek | Inni dostawcy przeglądarek wdrażają interfejsy API Piaskownicy prywatności. | Inni dostawcy przeglądarek, np. Apple, Mozilla i Microsoft, są aktywnymi uczestnikami forów publicznych, na których omawiane są zasady ochrony prywatności i metody oparte na przeglądarkach. Zachęcamy do udziału w dyskusjach na forach, takich jak niedawne spotkanie W3C TPAC i trwałe fora W3C PATCG, podczas których obserwujemy oznaki zbieżności. |
| Różnice dotyczące platform | Poproś o w miarę możliwości ujednolicenie zestawów funkcji w internecie i na Androidzie, aby ograniczyć ilość zasobów potrzebnych do przejścia. | Staramy się ujednolicić nasze podejścia w przypadku Chrome i Androida, aby uniknąć nieporozumień i fragmentacji w branży. Wszelkie różnice w naszym podejściu będą głównie związane z niezbędnymi różnicami technicznymi między platformami internetowymi i aplikacjami mobilnymi, które deweloperzy już uwzględnią. |
| Zasoby do testowania interfejsów API Piaskownicy prywatności | Problemy z odpowiednim przydzielaniem
aby przetestować interfejsy API Piaskownicy prywatności w obecnych warunkach gospodarczych. |
Nieustannie ulepszamy dokumentację i pomoc dostępne dla testerów, by ułatwić ich wdrażanie i ułatwić im wdrażanie interfejsów API. Należą do nich: listy adresowe związane z interfejsami API, godziny pracy oraz bieżące aktualizacje na developers.chrome.com. |
| Sygnał rezygnacji z interfejsu Sandbox API | Żądanie przesłania sygnału „użytkownik zrezygnował z interfejsów API piaskownicy”, który może być używany przez technologie reklamowe i witryny. | W wielu historycznych przypadkach witryny internetowe reagują na wybory użytkownika, takie jak „wyłączenie plików cookie innych firm”, wymuszając go, aby zmienił ustawienia, a w niektórych przypadkach blokując dostęp do witryny. Sygnał rezygnacji może być też używany jako dodatkowy sygnał do pobrania odcisku cyfrowego. Obecnie Google nie planuje przesyłania sygnału rezygnacji |
| (również w II kwartale)
Bardziej przejrzyste ramy czasowe |
Bardziej przejrzyste i szczegółowe harmonogramy publikacji | Aktualizacja na III kwartał:
Jak wyjaśniliśmy poniżej w sekcji „Zmiany w odpowiedzi na opinie” w lipcu zaktualizowaliśmy harmonogram Piaskownicy prywatności, aby dać rynkowi dodatkowy czas na wstępne testy i opinie, a także więcej czasu na testy po pełnym wdrożeniu interfejsów API Piaskownicy prywatności, zanim wycofamy pliki cookie innych firm. |
| (również w II kwartale)
Harmonogram wycofywania plików cookie innych firm |
Prośby o uniknięcie dalszych opóźnień w wycofaniu plików cookie innych firm | Aktualizacja na III kwartał:
W lipcu przedstawiliśmy zaktualizowany harmonogram wycofywania plików cookie innych firm, który odzwierciedla nasze zobowiązanie do odpowiedzialnego działania ze względu na złożoność technologii i ich znaczenie dla ekosystemu. Przed tą zmianą wzięliśmy pod uwagę opinie organów regulacyjnych i branży, dlatego nadal ściśle współpracujemy ze wszystkimi zainteresowanymi osobami. |
| Własne pliki cookie | Czy planowane są również ograniczenia dotyczące własnych plików cookie? Jeśli tak, to obawy o długoterminową stabilność, ryzyko związane z dalszymi nieprzewidywalnymi zmianami w przeglądarce, a tym samym niepotrzebne nakłady pracy programistów. | Nie uwzględniliśmy żadnych ograniczeń dotyczących własnych plików cookie. Piaskownica prywatności koncentruje się na wycofaniu plików cookie innych firm. |
Wyświetlaj trafne treści i reklamy
Tematy
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| (również w II kwartale)
Przydatność dla różnych zainteresowanych osób |
Pojawiły się wątpliwości dotyczące przydatności witryn ze względu na intensywność ruchu oraz stopień szczegółowości treści. | Aktualizacja na III kwartał:
Przydatność interfejsu API będzie badana podczas testów. Zgodnie z wymogami art. 17.c.ii Zobowiązań Google udostępnia CMA wyniki takich testów. Chrome oczekuje, że taksonomia i inne parametry będą się zmieniać zależnie od wyników testów. Rozwój taksonomii lub parametrów nie może wymagać zmian niezgodnych wstecznie. Poza tym Chrome oczekuje, że po wycofaniu plików cookie innych firm opinie będą nadal wpływały na ewolucję interfejsu Topics API. |
| Prywatność/Polityka | Prośba o usunięcie wymogu filtrowania tematów według rozmówcy. | Biorąc pod uwagę opinie KOF-ów zajmujących się prywatnością, obrońców prywatności, ekspertów ds. bezpieczeństwa, grup zajmujących się prawami cyfrowymi i innych podmiotów w ekosystemie, Chrome wybrał ten projekt tak, aby dawać dostęp do informacji tylko tym osobom, które inaczej miały taki dostęp. Chodziło m.in. o ograniczenie przyrostowego wycieku danych z innych stron, zapewnienie przejrzystości i zrozumiałości, przyjęcie podejścia, które jest łatwe do wdrożenia i opisania oraz ograniczenie ryzyka związanego z odciskami cyfrowymi. Wydawcy i podmioty zewnętrzne otrzymujące interfejs Topics mogą sami zdecydować, jakie informacje będą udostępniać podmiotom w swojej witrynie. Jeśli inne firmy udostępniają te informacje, Chrome zdecydowanie zachęca ich do informowania użytkowników o udostępnianiu danych i zapewniania im kontroli. |
| Witryny błędnie skategoryzowane | Witryny są przypisane do niewłaściwego tematu, co może skutkować nieprawidłowym kierowaniem reklam. | Witryny są klasyfikowane na podstawie kombinacji listy zastąpień wyselekcjonowanej przez człowieka, zawierającej najpopularniejsze witryny, oraz modelu ML działającego na urządzeniu. Chrome cały czas ocenia opcje witryn, które mogą być uwzględniane w klasyfikacji Topics. Wszelkie ulepszenia należy wziąć pod uwagę w kontekście ryzyka związanego z prywatnością i nadużyciami. Oto niektóre zagrożenia:
Użytkownicy mogą sprawdzać te komponenty za pomocą narzędzi dostępnych na stronie chrome://topics-internals lub tej Colab. Oczekujemy, że dzięki testom klasyfikacja będzie się z czasem poprawić, dlatego Czekamy na opinie dotyczące przykładów witryn, które mogą zostać sklasyfikowane nieprawidłowo. |
| Wymagania dotyczące dostępu | Bieżące wymagania dotyczące Topics API w przypadku encji DOM na stronie jako skryptu lub elementu iframe w celu uzyskania dostępu mogą prowadzić do niepożądanych zachowań graczy w ekosystemie reklam. | Połączyliśmy zmianę w wyjaśnieniu GitHuba. Zamierzamy obsługiwać interfejs Topics w nagłówkach HTTP. |
| Taksonomia tematów nie jest wystarczająco szczegółowa | Bieżące klasyfikacje tematów są zbyt ogólne i nie obejmują bardziej szczegółowych tematów, takich jak tematy regionalne. | Stale pracujemy nad ulepszaniem taksonomii i spodziewamy się, że taksonomia będzie ewoluować w miarę testowania ekosystemu i danych wejściowych.
Aktywnie szukamy opinii na temat taksonomii, która byłaby najbardziej przydatna dla tego ekosystemu. Oceniając, czy warto rozszerzyć liczbę tematów czy uwzględnić bardziej szczegółowe tematy, weź pod uwagę 1) potencjalne konsekwencje naruszenia prywatności (np. większa liczba tematów może powodować ryzyko korzystania z odcisków cyfrowych) oraz 2) możliwość odzyskiwania zaobserwowanych wcześniej tematów (np. im więcej tematów, tym mniej prawdopodobne jest, że technologie reklamowe widziały wybrany temat w przeszłości). Rozwijając drugą kwestię, Google stara się zmaksymalizować możliwość pobierania wcześniej zaobserwowanych tematów przez rozmówców zgodnie z dotychczasowymi wymaganiami filtrowania, aby zapewnić zarówno użyteczność, jak i prywatność. |
| Limit tematów | Trzy tematy na witrynę to za mało informacji, aby reklamodawcy mogli wyświetlać reklamy. | Opinie z ekosystemu, a zwłaszcza wyniki testowania wersji próbnej, będą nadal wpływać na rozwój interfejsu API. Należy pamiętać, że interfejs Topics powinien uzupełniać inne sygnały, np. kontekstowe, aby ułatwić wyświetlanie reklamy odpowiedniej dla użytkownika. Dzięki temu reklamodawca może mieć dostęp do dodatkowych informacji poza tematami. |
| (również w II kwartale)
Kontrola użytkowników i bezpieczeństwo |
Niektóre tematy mogą stanowić serwery proxy grup wrażliwych, a użytkownicy potrzebują większej kontroli, aby zapobiec negatywnym skutkom. | Aktualizacja na III kwartał:
Tematy stanowią ważny krok naprzód w zakresie kontroli i przejrzystości dla użytkowników. Użytkownicy będą mogli zrezygnować z tematów, przeglądać tematy, które zostały im przypisane, usuwać je oraz sprawdzać, które firmy wchodzą w interakcję z ich tematami na danej stronie. Oprócz tego użytkownicy mogą też wyczyścić swoje Tematy, usuwając historię przeglądania, z których pochodzą tematy. Te ustawienia są obecnie zaimplementowane w przeglądarce Chrome na poziomie urządzenia. Zachęcamy do dalszego dyskusji na temat bardziej zaawansowanych opcji kontroli dla użytkowników, takich jak te sugerowane przez programistów. Musimy jednak zadbać o to, by nowe elementy były dobrze dostosowane do zgłoszonych wątpliwości i nie były wynikiem wprowadzania niewielkich zmian. |
| Wpływ na SEO | Wydawcy, którzy zmieniają nazwy hostów swoich witryn, aby lepiej odzwierciedlały interfejs Topics, mogą negatywnie wpływać na SEO. | Przestrzegamy witryn, aby nie zmieniali nazw hosta wyłącznie ze względu na Topics. To prawda, że witryna może wpływać na przypisane do niej tematy. Jednak korzyści z tego rozwiązania nie są jeszcze oczywiste, a gdy witryny spróbują oszukać model klasyfikacji, obniżą wartość interfejsu Topics w całym ekosystemie. Przypisywanie tematów nie jest stałe – oczekujemy, że taksonomia będzie ewoluować w miarę testowania i wprowadzania danych wejściowych. W związku z tym testem Zachęcamy do przesyłania opinii, w tym przesyłania wszelkich przykładów witryn, które mogą zostać sklasyfikowane nieprawidłowo. |
| Oszustwa i nadużycia | Upewnij się, że kupujący może sprawdzić, czy temat, który widzi, został wygenerowany przez przeglądarkę. | Doceniamy sugestię udostępnienia nabywcom technologii reklamowych mechanizmu weryfikacji tematów przekazywanych przez sprzedawców w zautomatyzowanych aukcjach reklam. Zachęcamy uczestników ekosystemu do wzięcia udziału w aktywnej dyskusji tutaj. Obecnie koncentrujemy się na innych ulepszeniach o wyższym priorytecie, ale zdajemy sobie sprawę, że mogą one mieć znaczenie w przyszłości. |
| Oszustwa i nadużycia | Umożliwienie publicznego przeglądania danych z interfejsu Topics przez podmioty, które są legalnymi użytkownikami danych z Topics, w ten sam sposób, w jaki podlegałyby zestawowi własnemu zestawowi działań. | Doceniamy tę sugestię i zgadzamy się, że odpowiedzialność publiczna jest ważnym narzędziem pomagającym osiągnąć cele Piaskownicy prywatności. Wywołania interfejsu Topics API są zasadniczo publiczne, ponieważ każdy może odwiedzić witrynę i obserwować wywołania interfejsu JavaScript API w domenie. Osoby fizyczne i organizacje mogą więc wyświetlać odpowiednie działania i oceniać, które witryny korzystają z interfejsu Topics i w jaki sposób. Naszym zdaniem jest to lepszy sposób niż ocenianie „wiarygodności” funkcji interfejsu Topics API witryny. |
| Wpływ na sygnały własne | Sygnał dotyczący tematów może być bardzo wartościowy, w związku z czym obniża wartość innych własnych sygnałów opartych na zainteresowaniach. | Uważamy, że reklamy oparte na zainteresowaniach to istotny przypadek użycia w internecie, a interfejs Topics ma je uwzględniać. Jak opisano powyżej, inne zainteresowane osoby w ekosystemie wyraziły obawy, że interfejs Topics może nie być wystarczająco przydatny, aby zapewnić wartość. We wszystkich przypadkach stale pracujemy nad ulepszaniem taksonomii i spodziewamy się, że taksonomia będzie ewoluować w miarę testowania ekosystemu i danych wejściowych. |
FLEDGE
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Aukcja FLEDGE | Jak platformy SSP mogą formatować dane wysyłane do Google Ads, aby ustalać stawki na aukcji FLEDGE. | Zachęcamy firmy, które biorą udział w testach, do publikowania dokumentacji dotyczącej planów testowania i współpracy w odpowiednich sytuacjach.
Współpracowaliśmy z organizacją CMA nad opracowaniem naszego podejścia do testów ilościowych i jesteśmy wspierającymi w jego publikacji sporządzeniu przez nią uwagi na temat projektu eksperymentu, której celem jest udostępnienie większej ilości informacji uczestnikom rynku, którzy planują wziąć udział w testach, oraz wypowiedzenie się na temat proponowanych metod. Zespół Ad Managera opublikował tutaj dokumentację dla sprzedawców, którzy są zainteresowani testowaniem FLEDGE u wydawców, którzy używają Ad Managera jako serwera reklam. Dodatkowe szczegóły techniczne są opisane tutaj. |
| FLEDGE w zagnieżdżonych chronionych ramkach | Chronione klatki umożliwiają mniej restrykcyjne testy, a w przyszłości – więcej. Ta nieznana oś czasu stanowi wyzwanie dla ekosystemu. | Firmy mogą już dziś przetestować FLEDGE z użyciem Fenced Frames. Aby ułatwić sobie wprowadzenie, firmy mogą najpierw wdrożyć FLEDGE. Po wdrożeniu FLEDGE pracownicy mogą przetestować Fenced Frames w projekcie FLEDGE. |
| Zasady obsługi danych | Jakie są zasady postępowania z danymi w przypadku grup zainteresowań / FLEDGE? | W projekcie FLEDGE wszystkie dane przechowywane w grupach zainteresowań, czyli o tym, do których grup zainteresowań należą użytkownicy, pozostają na urządzeniu. Żadne z tych danych nie są wysyłane na serwer Google.
Niektóre zabezpieczenia prywatności, które Chrome planuje dla FLEDGE, obejmują interakcję z obsługiwanym przez Google serwerem k-anonimowości. Interakcja ta została zaprojektowana tak, aby uniknąć udostępniania informacji o użytkownikach, a interakcja powinna działać w zaufanym środowisku wykonawczym (TEE), aby zapewnić spójność informacji w ekosystemie reklamowym. \ Firma Google zobowiązała się do opracowania i wdrożenia propozycji Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samopostrzeganie własnej firmy Google oraz uwzględniać wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszej pracy z tymi zobowiązaniami. |
| Zasady dotyczące wieku | W jaki sposób Chrome dba o to, aby listy odbiorców utworzone przez FLEDGE przestrzegały ograniczeń wiekowych? | W przypadku wydawców i reklamodawców najlepiej jest ocenić, czy listy odbiorców tworzone przez nich za pomocą FLEDGE są zgodne z obowiązującym prawem. Aby jeszcze lepiej chronić użytkowników, interfejsy API Piaskownicy prywatności nie będą aktywne u użytkowników zalogowanych w Chrome, jeśli wiek powiązany z ich kontem jest poniżej 18 lat – nawet w okresie testowania. W przypadku niezalogowanych użytkowników Chrome nie zbiera sygnałów z profilu, które pozwoliłyby przeglądarce określić wiek użytkownika. |
| Usługi kluczy/wartości FLEDGE | Bardziej przejrzyste informacje o tym, na co zezwala usługa klucz/wartość FLEDGE, na przykład liczba kluczy i częstotliwość ich aktualizowania. | Firmy korzystające z FLEDGE mogą mieć tyle kluczy, ile zmieści się w pamięci RAM. Więcej informacji znajdziesz tutaj.
Pracujemy nad umożliwieniem szybszej modyfikacji danych i sugestii dotyczących wszelkich wymagań. |
| Testowanie | Trudności z testowaniem FLEDGE w Google Ads | Aby dowiedzieć się, jak najlepiej wziąć udział w testowaniu origin i przeprowadzić testy, zapoznaj się z dokumentacją Google Ads. |
| Interfejs API usług określania stawek i usług aukcyjnych | Jaki jest kierunek Google w zakresie interfejsu API określania stawek i usług aukcyjnych? Czy w aukcjach na urządzeniach będzie miał wyższy czy niższy priorytet niż FLEDGE w przeglądarce Chrome? | Nadal przywiązujemy dużą wagę do obecnego modelu określania stawek FLEDGE na urządzeniu. Zaproponowaliśmy usługi z ustalania stawek i usługi aukcyjne, aby zbadać możliwe rozwiązania uwzględniające podzbiór przypadków użycia, w których moc obliczeniowa lub szybkość sieci urządzenia mogą być ograniczone. |
| Raporty zbiorcze | Poproś o obsługę raportów zbiorczych na podstawie wszystkich sygnałów dostępnych na potrzeby generowania stawki. | Planujemy wkrótce udostępnić publicznie więcej informacji na ten temat. |
| Reklamy kontekstowe | Wyświetlanie reklam kontekstowych z użyciem FLEDGE. | Wzięliśmy pod uwagę tę opcję i z powodów opisanych w tej dyskusji nie zalecamy obecnie używania FLEDGE w przypadku reklam kontekstowych. |
| Testowanie w rzeczywistości | Wskazówki dotyczące izolowania FLEDGE od plików cookie innych firm na potrzeby testów w świecie rzeczywistym. | Sprawdzamy, jak udostępnić populacji testowe.
Współpracowaliśmy z CMA nad opracowaniem naszego podejścia do testów ilościowych i popieramy publikację przez nią uwagi na temat projektu eksperymentu, aby zapewnić uczestnikom rynku więcej informacji i wyrazić opinię na temat proponowanych metod. |
| Testowanie FLEDGE i Attribution Reporting API | Jak najlepiej wdrożyć Attribution Reporting API za pomocą FLEDGE? Czy lepiej oddzielić FLEDGE od Atrybucji czy je przetestować razem z nimi? | W przyszłości będziemy obsługiwać testowanie zarówno FLEDGE, jak i Attribution Reporting API w ramach rozwiązania zintegrowanego, ale zachęcamy deweloperów do samodzielnego testowania interfejsu Attribution Reporting API, a następnie z FLEDGE po zakończeniu integracji. |
| Widoczność stawki | Poproś o ukrywanie stawek. | Możesz ustawić punkty przerwania w ramach funkcji „generateBid()” lub „scoreAd()”, aby uzyskać dostęp do wartości stawek z Narzędzi deweloperskich. Zespół Chrome wziął pod uwagę wąski wektor ataku zgłoszony w opinii dotyczącej FLEDGE. Jednak stosowane w Chrome modele zabezpieczeń i prywatności sprawiają, że użytkownicy mogą korzystać z informacji na swoich urządzeniach z zaufaniem. W związku z tym nie ma żadnego sensownego sposobu ukrycia danych o stawkach na prośbę użytkownika. |
| Prośby o dokumentację | Dokumentacja i przykłady do testowania w aktywnym ekosystemie. | Cieszymy się, że nasze obecne materiały okazały się dla deweloperów przydatne. W najbliższych tygodniach i miesiącach będziemy dodawać kolejne materiały, aby mogli nadal lepiej rozumieć, jak nowe technologie przydają się im do pracy.
Organizowane są też publiczne konsultacje dla programistów, podczas których można dzielić się sprawdzonymi metodami i prezentacjami, a także brać udział w sesjach pytań i odpowiedzi z udziałem przedstawicieli ds. usług i inżynierów, aby umożliwić dyskusję i zadawanie pytań na żywo. |
| Interfejs Private Aggregation API | Chcesz uzyskać więcej informacji o interfejsie Private Aggregation API? | Wraz z najnowszymi informacjami, jakie możemy obecnie udostępnić, dostępne jest publiczne wyjaśnienie. W miarę tworzenia i definiowania przypadków użycia tego interfejsu API będziemy udostępniać więcej dokumentacji. |
| Opóźnienie danych | Czy pobieranie danych z serwera klucz/wartość FLEDGE odbywa się w czasie rzeczywistym? | Zanim serwer będzie mógł zwrócić zaktualizowane dane dla zapytań w kolejności minut, a nie godzin, może wystąpić niewielki okres braku aktualizacji danych w kolejności minut, a nie godzin. Więcej informacji na ten temat znajdziesz w otwartym problemie na GitHubie. Chętnie poznamy też opinie deweloperów. |
| Usługi określania stawek i aukcji | Czy stawki będą ukryte, jeśli użytkownik korzysta z określania stawek i korzystania z usług aukcyjnych (B&A)? | W przypadku metody B&A po stronie serwera cena indywidualnej stawki nie jest widoczna dla użytkownika, ponieważ pytanie o stawkę jest wysyłane z usługi aukcji SSP bezpośrednio do usługi aukcji DSP i dlatego nie jest już dostępne w przeglądarce.
Jednak zwycięska stawka będzie nadal widoczna dla przeglądarki (omówiliśmy ją szczegółowo powyżej w związku z pytaniami o ukrywanie stawek). |
| Usługi określania stawek i aukcji | Jak możemy zrównoważyć obciążenie związane z określaniem stawek i usługami aukcyjnymi? | Obecnie nie mamy żadnych wskazówek dotyczących równoważenia obciążenia, ale jest to ważne z punktu widzenia zarówno wydajności, jak i prywatności. Więcej informacji podamy w przyszłości. |
| Limity FLEDGE | Poproś o zwiększenie limitu czasu trwania subskrypcji joinAdInterestGroup z 30 do 90 dni. | Uważamy, że 30-dniowy okres przechowywania danych jest zgodny z innymi interfejsami API Piaskownicy prywatności, takimi jak 30-dniowy limit w raportach atrybucji i 3-tygodniowe podsumowanie w Topics. Ten termin odpowiada zarówno na potrzeby technologii reklamowych, jak i oczekiwań użytkowników w zakresie prywatności.
Będziemy jednak wdzięczni za dalsze opinie, ponieważ omawiamy ten problem tutaj. |
| Pamięć współdzielona we FLEDGE | Czy w interfejsie FLEDGE można używać interfejsu Share Storage API? | Zamierzamy obsługiwać interfejs FLEDGE API w przyszłości i pracujemy nad udostępnieniem go w zbliżającej się wersji próbnej Origin. |
| Kontrola częstotliwości według kliknięć | Czy we FLEDGE można stosować ograniczenie liczby wyświetleń na podstawie kliknięć (a nie wygranych)? | FLEDGE wskazuje, że ramka chroniona może wywołać funkcję navigator.LeaveAdInterestGroup() (bez parametrów), która powoduje opuszczenie grupy zainteresowań, która spowodowała wyświetlenie reklamy. To wywołanie można wykonać przy pierwszym kliknięciu reklamy, co pozwala uniknąć określania stawek w przyszłości. Jest to forma ograniczenia liczby wyświetleń. Obecnie to rozwiązanie nie działa w przypadku ograniczenia liczby kliknięć po więcej niż jednym kliknięciu. |
| FLEDGE w zagnieżdżonych chronionych ramkach. | Nie można zgłaszać kliknięć za pomocą raportów o reklamach z zabezpieczonymi ramkami, jeśli występują w zagnieżdżonej ramce. | Opublikowaliśmy tutaj propozycję rozwiązania tego problemu. |
| Pomiary | Potrzebuję wskazówek, jak zbierać dane o czasie oczekiwania dotyczące licytujących w aukcji FLEDGE. | Pracujemy nad tym, aby wkrótce opublikować dokument dotyczący pomiaru wydajności. |
| Raportowanie | Jak będą obsługiwane raporty FLEDGE? | Raporty FLEDGE dotyczące wygranych, wyniku aukcji, zdarzenia np. kliknięć będą dostępne za pomocą interfejsów API FLEDGE, takich jak reportResult(). W przypadku raportowania konwersji z reklam integracja z interfejsem Attribution Reporting API będzie niezależna od FLEDGE, ale trwają dyskusje z ekosystemem na temat możliwych rozwiązań.
Interfejs Private Aggregation API może też służyć do raportowania wyników aukcji z izolowanych środowisk wykonawczych. Wyjaśnienie znajdziesz tutaj. |
| Rozmiar grupy zainteresowań | Czy technologie reklamowe mogą w jakiś sposób sprawdzić wielkość grupy zainteresowań (tj. liczbę użytkowników w grupie)? | Członkostwo w grupie zainteresowań jest przechowywane w przeglądarce na urządzeniu użytkownika i nie jest udostępniane dostawcy przeglądarki ani nikomu innemu.
Właściciel grupy zainteresowań może teoretycznie śledzić każde wywołanie navigator.joininterestgroup(...). Śledzenie tego wywołania nie gwarantuje dokładnego rozmiaru grupy zainteresowań (ponieważ użytkownicy mogą ją w każdej chwili opuścić), ale daje właścicielowi górny limit i przybliżony rozmiar. |
| Występy | Czy kod JS/WebAssembly ustalania stawek jest kompilowany podczas każdej aukcji? | Kod JS/WebAssembly ustalania stawek jest kompilowany raz podczas każdej aukcji. |
| Występy | Jaki jest zakres określania stawek DurationMsec? | Parametr bidDurationMsec uwzględnia czas kompilowania skryptu. Nie obejmuje czasu pobierania, czasu kompilacji wasm, czasu sieci, czasu pobierania z serwera klucz-wartość ani innych danych wyprzedzających kompilację JS. |
| Personalizacja | Czy można zaktualizować komponent adKomponent, aby dostosować go do użytkownika? | Element adKomponent można aktualizować, gdy grupy zainteresowań są aktualizowane przez element wywołujący w ramach wywołania joinInterestGroup lub po wywołaniu przez Chrome funkcji DailyUpdateURL. Dzięki temu wywołujący może aktualizować komponent adKomponent na podstawie wiedzy użytkownika z bieżącej witryny lub odpowiednio na podstawie k-anonimowych informacji.Pierwotną propozycję turtledove'a na poziomie produktu znajdziesz tutaj, która zawiera analizę wykonaną przez RTB House na podstawie wpływu na podstawowe dane w przypadku danego przypadku użycia rekomendacji. |
| Grupa zainteresowań | Czy właściciel grupy zainteresowań może warunkowo usuwać określonych użytkowników? | Członkostwo w grupie zainteresowań jest przechowywane tylko w przeglądarce użytkownika i może zostać usunięte tylko po jego stronie (np. przez wyczyszczenie danych witryny).
Właściciel grupy zainteresowań może jednak wywołać funkcję navigator.LeaveAdInterestGroup() (pokrywającą ją logiką warunkową), jeśli użytkownik wróci na stronę, która jest kontrolowana przez właściciela grupy zainteresowań. |
| Występy | Jak mierzyć skuteczność funkcji generateBid? | Czas kompilacji i wykonywania może być mierzony za pomocą funkcji bidDurationMsec. Czas pobierania można zmierzyć na stronie chrome://net-export. W najnowszych wersjach Chrome czas kompilowania i wykonywania jest wyświetlany na karcie Wydajność w Narzędziach deweloperskich. |
| Częstotliwość aktualizacji grup zainteresowań | Jak często będzie aktualizowana grupa zainteresowań przez przeglądarki? | W przypadku grup zainteresowań, które nie zostały zaktualizowane w ciągu ostatnich 24 godzin, Chrome próbuje je zaktualizować po wywołaniu funkcji navigator.updateAdInterestGroups() lub gdy miały one szansę brać udział w aukcji. Więcej informacji znajdziesz tutaj. |
| Dostawcy usług agregacji | Kiedy usługa agregacji zacznie obsługiwać innych dostawców chmury? | Obecnie nie możemy podać żadnych informacji o konkretnych terminach, ale przekażemy Ci więcej informacji, gdy tylko to zrobimy. W tej chwili tylko AWS spełnia wymagania dotyczące bezpieczeństwa usługi agregacji. |
| Oś czasu testowania FLEDGE | Jak długo FLEDGE będzie testować w przypadku BYOS? Czy będzie wystarczająco dużo czasu na przejście z modelu BYOS na model oparty na TEE? | Aby zapewnić ekosystemowi wystarczającą ilość czasu na testy, nie będziemy wymagać korzystania z technologii TEE do czasu wycofania plików cookie innych firm. Przed tym przeniesieniem deweloperzy otrzymają powiadomienie o możliwości rozpoczęcia testowania i wdrażania. Obecnie nie mamy żadnych dodatkowych informacji, ale przekażemy Ci więcej informacji. Najnowsze informacje znajdziesz tutaj. |
| Limit rozmiaru danych | Jaki jest limit rozmiaru danych dla Wasm w funkcji określania stawek? | Obowiązuje wymóg, aby zmiany dotyczące grup zainteresowań nie mogły prowadzić do utworzenia grupy zainteresowań przekraczającej 50 KB, co zostało omówione tutaj, ale limit rozmiaru danych dla Wasm nie został jeszcze zdefiniowany, dlatego dziękujemy za opinie na ten temat. |
| Sygnały aukcji | Czy będzie prowadzona ustandaryzowana struktura danych w przypadku sygnałów aukcji? | Nie zostało to jeszcze określone, ale jesteśmy otwarci na komentarze. |
| Wysyłanie zapytań do serwerów technologii reklamowych | Czy można wysyłać z serwera K/V zapytania do danych serwera technologii reklamowych w czasie rzeczywistym? | Nie. Serwer K/V działa w modelu zaufania, który wymusza zasadę „Brak sieci, dostępu do dysku, liczników czasu ani logowania”, aby zapobiec wyciekom danych użytkownika. Więcej informacji znajdziesz w objaśnieniu modelu zaufania. |
| Częstotliwość aktualizowania komponentów reklamy | Obecnie nie można zaktualizować pola adKomponenty (obecnie tylko w ustawieniu IG) według historii przeglądania użytkownika | Piaskownica prywatności ma zaspokajać potrzeby ekosystemu internetowego bez śledzenia w witrynach, co oznacza blokowanie dostępu do historii przeglądania. Zalecamy stosowanie alternatywnych rozwiązań, takich jak Topics. |
| Wyniki aukcji | Czy technologie reklamowe mogą w jakiś sposób poznać współczynniki wygranych aukcji? | Wynik aukcji jest raportowany przez wywołanie funkcji reportResult() i reportWin() w kodzie aukcji określonym przez sprzedawcę i kupującego, dzięki czemu każdy z nich może rejestrować i raportować wyniki aukcji. |
| (również w II kwartale)
Obsługa kierowania na wykluczające grupy zainteresowań |
Interfejs API umożliwiający obsługę kierowania na wykluczające grupy zainteresowań: wyświetlanie reklam tylko wtedy, gdy użytkownik nie należy do grupy zainteresowań. | Aktualizacja na III kwartał:
Przekazaliśmy nową ofertę i chcemy poznać opinię. |
Pomiary reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Wymagania dotyczące dogr. | Usuń ograniczenia dotyczące uprawnień i zasad tylko w czasie trwania sesji dobiegającej końca. | Podczas testów zapoznaj się z ogłoszonymi zmianami w zasadach dotyczących uprawnień. Głównym problemem zainteresowanych osób, które rozwiązała ta zmiana, jest umożliwienie platformom DSP testowania interfejsu API na większej liczbie elementów iframe z innych domen. Dawniej platformy DSP musiały skoordynować działania z wydawcami i platformami SSP, aby ustalić odpowiednie zasady dotyczące uprawnień, aby przetestować interfejs API w elementach iframe z innych domen. Jednak po tej zmianie platformy DSP będą mogły domyślnie wywoływać ten interfejs API, a platformy SSP i wydawcy w razie potrzeby mogą go wyłączyć w ramach testowania origin. |
| Szum | Opinia, że poziom szumu jest zbyt wysoki i wpływa na przydatność raportu. | Czekamy na opinie dotyczące szumu, które pomogą nam ustalić, jak ustawić określone parametry związane z hałasem. Chcemy też opublikować więcej zasobów, narzędzi i innych dokumentów, które ułatwią testerom. |
| Konwersje w wielu domenach | Jak śledzić konwersje w wielu domenach, np. z co najmniej 2 miejscami docelowymi? | Obecnie omawiamy ten problem i prosimy o opinię na jego temat. |
| Wymagania dotyczące debugowania | Chcesz umożliwić deweloperom sprawdzenie pozostałego budżetu na potrzeby prywatności podczas wdrażania lub testowania raportu podsumowującego? | Tutaj możesz śledzić prośbę o dodanie funkcji. |
| Zasady użytkowania interfejsu API | Opinie sugerujące, kto może używać danego interfejsu API, na podstawie ograniczeń dotyczących m.in. odcisków cyfrowych | To bardzo ciekawy pomysł i chętnie będziemy współpracować zarówno z innymi dostawcami przeglądarek, jak i z całym ekosystemem internetowym. |
| Ustawienie wygaśnięcia w raporcie konwersji | Poproś o obsługę filtra raportu lub o wygaśnięcie jeszcze krócej niż 24 godziny. | Wygaśnięcie na poziomie godzin rodzi obawy o ochronę prywatności, ponieważ dzięki niemu technologie reklamowe wiedzą dokładnie, o której godzinie użytkownik odwiedza stronę reklamodawcy. Wygaśnięcie na poziomie dnia pozwala technologii reklamowych odfiltrowywać nieprawidłowe wyświetlenia bez określania godziny, w której użytkownik odwiedził witrynę. |
| Wygaśnięcie tokena OT | Poproś o przedłużenie ważności istniejących tokenów OT, aby zmniejszyć koszty operacyjne. | Zdajemy sobie sprawę, że tokeny muszą zostać odnowione. Pracujemy nad uproszczeniem procesów dla deweloperów i powiadomimy o tym dodatkowe powiadomienie. |
| Pomoc regionalna | Usługa agregacji nie obsługuje obecnie wszystkich regionów. | To obecne ograniczenie w wersji beta. Spodziewamy się, że w miarę postępów testów będą one obsługiwane w kolejnych regionach, ale nie jesteśmy jeszcze w stanie to zrobić. |
| Opóźnienie raportowania na poziomie zdarzenia | Opóźnienie 2–30 dni w raportowaniu na poziomie zdarzenia może być za długie w niektórych przypadkach. | Opublikowaliśmy tutaj propozycję, aby umożliwić technikom reklamowym kontrolowanie, kiedy raporty na poziomie zdarzenia mają być wysyłane po wygaśnięciu. Wartość domyślna to 30 dni, ale można ustawić ją na krótszą. |
| (również w II kwartale)
Atrybucja uwzględniająca różne interakcje |
Zezwalaj na atrybucję uwzględniającą różne interakcje, np. na różnych urządzeniach lub w różnych aplikacjach. | Aktualizacja na III kwartał:
Obecne metody atrybucji uwzględniającej różne interakcje wymagają trwałego powiązania wyświetleń (a tym samym tożsamości) użytkownika z różnych witryn. W efekcie ta funkcja w obecnej formie jest niezgodna z celami Piaskownicy prywatności, która ma na celu obsługę kluczowych przypadków użycia reklam bez śledzenia w witrynach. |
| Harmonogram integracji FLEDGE z raportami atrybucji | Jaki jest harmonogram integracji FLEDGE z interfejsem Attribution Reporting API? | Obecnie nie mamy żadnych informacji na ten temat, ale przekażemy więcej informacji, gdy tylko będzie to możliwe. |
| Wiele typów aktywatorów | Poproś o większą elastyczność rejestracji aktywatorów. | Zaproponowaliśmy system usuwania duplikatów danych zagregowanych w interfejsie API, który zapewni technikom reklamowym większą elastyczność w zakresie kontrolowania raportów na poziomie zdarzenia i raportów zbiorczych. |
| Pomiary | Poproś o dostęp do danych pomiarowych dotyczących skuteczności zasobów reklamowych. | Dziękujemy za tę opinię i prosimy o wyjaśnienie przypadków użycia tego zgłoszenia. |
| Wygaśnięcie konwersji | Poproś o obsługę wygaśnięcia konwersji w tagu reguły, a nie tylko w tagu źródłowym. | Dziękujemy za tę opinię i prosimy o wyjaśnienie przypadków użycia tego zgłoszenia. |
| Raportowanie zbiorcze | Poproś o dodatkowe pomiary w raportach zbiorczych. | Jesteśmy wdzięczni za wszystkie opinie, ponieważ nadal pracujemy nad wpływem na usługę agregacji. Chętnie dowiemy się, co myślą o zespołach raportów i jaka jest ich przewidywana częstotliwość, a także jakie są Wasze opinie na temat zmian strategii grupowania w ciągu roku. |
| Epsilon | Kiedy zostanie określona wartość epsilonu? | Aktywnie współpracujemy z testerami ekosystemu, aby sfinalizować wartość epsilonu i sposób jej implementacji w Google Analytics. Wartość będzie widoczna publicznie. Objaśnienie, które doprowadziło do podjęcia decyzji o tej wartości, będzie widoczne publicznie. Wszelkie uwagi prosimy przekazywać w ramach tego problemu z GH. |
Ogranicz ukrycie
Redukcja klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Zależności wdrożenia | Problem związany z zależnościami wdrożenia uporządkowanego klienta użytkownika (SUA). | W wersji 101 i nowszych przeprowadziliśmy „fazę 4” – zmniejszenie wersji podrzędnej u 100% użytkowników Chrome. Sprawdź aktualizację tutaj. |
| Testowanie | Żądanie przedłużenia okresu próbnego redukcji klienta użytkownika z Meta. | Przedłużyliśmy okres próbny Origin i uzyskaliśmy pozwolenie na usunięcie ograniczeń ruchu, aby umożliwić obsługę większych witryn. Takie ograniczenia obowiązują w każdej witrynie, niezależnie od jej wielkości. |
Wskazówki dotyczące klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| (również w II kwartale)
Obawy dotyczące przeciwdziałania oszustwom i nadużyciom |
Niektóre funkcje, które mogą zostać utracone przez UA-CH, to tag śledzenia przekierowań kliknięć oraz fałszywe kliknięcia. | Aktualizacja na III kwartał:
Otrzymaliśmy od firm zgłoszenia, że nie zaobserwowały one żadnego niekorzystnego wpływu na swoje potoki zwalczania oszustw (wyniki znajdziesz tutaj i tutaj). Nasz zespół nadal pracuje nad rozwiązaniem tych potencjalnych problemów we współpracy z innymi osobami zajmującymi się kwestiami związanymi z oszustwami i pomiarami. |
| Zasada uprawnień | Czy zasada uprawnień jest przechowywana w pamięci podręcznej? | Zasada Permission-Policy nie jest przechowywana w pamięci podręcznej zgodnie z opisem tego problemu w GitHubie. |
Gnatcatcher (WIP)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Przypadki użycia geolokalizacji | Gnatcatcher może zapobiec wykorzystaniu w przyszłości legalnych przypadków użycia geolokalizacji, np. personalizacji treści na podstawie geolokalizacji. | Współpracujemy z zainteresowanymi osobami, aby przeglądarka Chrome nadal obsługiwała uzasadnione przypadki użycia adresów IP. |
Wzmocnij granice prywatności między witrynami
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Zasada | Wątpliwość, że systemy FPS są niezgodne z postanowieniami ustawy CMA dotyczącymi „Obowiązującego ustawodawstwa dotyczącego ochrony danych”, ponieważ RODO nie nakłada limitu na liczbę witryn w zestawie, chociaż w przypadku FPS obowiązuje limit 3 witryn. | Firma Google zobowiązała się do opracowania i wdrożenia propozycji Piaskownicy prywatności w taki sposób, aby nie zakłócać konkurencji przez samopostrzeganie własnej działalności Google oraz uwzględniać wpływ na konkurencję w reklamie cyfrowej, wydawców i reklamodawców, a także wpływ na wyniki związane z prywatnością i zgodność z zasadami ochrony danych określonymi w Obowiązującym ustawodawstwie dotyczącym ochrony danych. Wyrażone obawy nie wskazują na brak zgodności z RODO. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszej pracy z tymi zobowiązaniami. Więcej informacji znajdziesz poniżej w sekcji „Zmiany w odpowiedzi na opinie”. |
| Dokumentacja | Poproś o dodatkowe przykłady i zaktualizuj obecne wyjaśnienia. | Przykłady w naszych objaśnieniach są w trakcie sprawdzania i w razie potrzeby doprecyzujemy je lub usuniemy. |
| Udostępnianie preferencji | Propozycja określania preferencji dotyczących tych samych zestawów partii. | Czekamy na opinie i aktywnie omawiamy pomysł tutaj. |
| Egzekwowanie zasad | Przejrzyste procesy egzekwowania zasad wiążą się z ryzykiem nadużycia ze strony nieuczciwych podmiotów. | Doceniamy te opinie i aktywnie aktywnie uczestniczymy w rozmowach z zainteresowanymi osobami na GitHubie (rozważamy kwestie poruszone w tym problemie i postaramy się uwzględnić sugestie podane w tym problemie) oraz na innych forach, aby ocenić to ryzyko i określić potencjalne środki zaradcze. |
| Wspólne prawo własności | Propozycja czytelnej dla komputera deklaracji wspólnego właściciela. | Zachęcamy do zapoznania się z naszą propozycją. |
| Własność subdomen | Czy różne subdomeny z różnymi administratorami danych, różne zasady prywatności lub obsługiwane przez różne podmioty powinny należeć do tego samego zestawu źródeł własnych? | Na podstawie opinii planujemy usunąć typowy przypadek użycia eTLD. |
| Łagodzenie nadużyć | Prośba o więcej informacji na temat środków zmniejszających ryzyko nadużyć. | Obecnie rozważamy zarządzanie procesem. W najbliższych miesiącach przekażemy Ci więcej szczegółów. |
| Wektor potencjalnego ataku | Oszukańczy zestaw powiązanych ze sobą stron, które można łatwo znaleźć, może służyć do kierowania ruchu na inne strony, które zwodnicze są przedstawione jako niezależne. | Aktywnie zbieramy opinie użytkowników i badamy możliwe sposoby rozwiązania tego problemu. |
| Ustaw weryfikację | Weryfikuję zestaw, korzystając z wspólnych zasad, na które użytkownicy wyrazili zgodę. | Różni członkowie społeczności standardów internetowych i rozległy ekosystem uważały, że nie jest to możliwe. |
| Limit domen | Prośba o zwiększenie liczby powiązanych domen. | Aktywnie dyskutujemy o limicie liczby domen w FPS i chcielibyśmy poznać więcej opinii społeczności na temat liczby powiązanych domen, które są wymagane w przypadku określonych zastosowań. |
| Interakcja z usługą podzbioru | Wątpliwość dotycząca usługi i powiązanej interakcji z podzbiorem. | Doceniamy Twoją opinię. W przyszłych specyfikacjach postaramy się lepiej wyjaśnić tę kwestię. |
| (również w II kwartale)
Poprawa prywatności |
Zbyt wiele witryn w tym samym zestawie może skutkować podobnymi wynikami jak w przypadku plików cookie innych firm. | Aktualizacja na III kwartał:
Najnowsze propozycje zalecają limit 3 domen dla podzbioru „powiązanych” domen (nie obejmuje on domen ccTLD ani domen usług). Chrome aktywnie wchodzi w interakcje z ekosystemem, aby ustalić, czy ten limit jest odpowiedni. |
| (również w II kwartale)
Wspólne wymagania dotyczące polityki prywatności |
Nie jest możliwe utrzymanie wspólnej polityki prywatności dla wszystkich usług i jurysdykcji, które muszą należeć do tego samego zestawu. | Aktualizacja na III kwartał:
Wspólna polityka prywatności nie jest już wymagana dla wszystkich produktów i usług. |
Interfejs Fenced Frames API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Dlaczego nowy element zamiast atrybutów w elementach iframe? | Pytanie o ofertę pakietową Frenced Frame zamiast dotychczasowych propozycji iFrame. | Chętnie poznamy Twoją opinię i jesteśmy otwarci na pomysły na uporządkowanie obecnego stanu rzeczy, o których rozmawiamy tutaj. |
| Obserwator skrzyżowań w chronionych ramkach | Pytania dotyczące widoczności informacji w chronionej ramce. | Ten dokument jest obecnie przedmiotem dyskusji i jest widoczny w komentarzach w tym dokumencie i w serwisie GitHub. Zachęcamy partnerów, aby dzielili się z nami przypadkami użycia, co pozwala lepiej zrozumieć, jak udzielić pomocy. |
| Obsługa zasobów reklamowych wideo i natywnych | Czy chronione ramki obsługują zasoby reklamowe wideo i natywne? | Pod względem możliwości odtwarzania filmów ramki ogrodzone ramki nie różnią się od elementów iframe i dlatego nie są wyraźnie wymienione w żadnej publicznej dokumentacji. Jeśli zauważysz problemy z reklamami wideo, prześlij opinię, żebyśmy mogli dokładniej zbadać tę sprawę. |
| Pakiety internetowe | Czy wyświetlanie / renderowanie reklam w ramach pakietów internetowych będzie w przyszłości wymagało korzystania z technologii Fenced Frame x FLEDGE? | Długoterminowym celem jest umożliwienie obsługi pakietów internetowych w celu renderowania treści reklamy w ogrodzonej ramce. Jednak obecna implementacja FLEDGE tego nie obsługuje i wymaga renderowania zasobu HTML pobranego z renderUrl. |
| Wymiary zasobu | Żądanie dotyczące render_url obsługi makra dla wysokości i szerokości boksu, umożliwiające nam udzielenie odpowiedzi z reklamą w odpowiednim rozmiarze. | Dokument ten jest obecnie omówiony tutaj. |
Interfejs API pamięci współdzielonej
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Integracja z FLEDGE | W jaki sposób zostanie zintegrowana pamięć współdzielona i FLEDGE? | Obecnie nie zajmujemy się tą kwestią, ale jesteśmy ciekawi, czy będziemy w stanie zapewnić ochronę prywatności. Zachęcamy zainteresowane osoby, aby zgłaszały sugestie dotyczące potencjalnych przypadków użycia, do których ta oferta mogłaby przysługiwać. Można ją znaleźć w repozytorium GitHub współdzielonej lub repozytorium FLEDGE. . |
| Przechowywanie danych | Wyczyszczenie pamięci współdzielonej zmniejsza przydatność. Czy istnieje możliwość wydłużenia okresu przechowywania lub możliwości usuwania poszczególnych par klucz-wartość? | Zawsze staramy się znaleźć równowagę między prywatnością użytkowników a ograniczeniami dotyczącymi użyteczności. Jesteśmy otwarci na uwagi i zachęcamy partnerów do przekazywania dodatkowych opinii i szczegółów podczas testowania współdzielonego miejsca na dane. |
| Sygnał negatywny | Negatywny sygnał od Mozilli dotyczący oferty pamięci współdzielonej. | Dziękujemy firmie Mozilla za dokładne zapoznanie się z naszą propozycją. W najbliższej przyszłości odpowiemy na ich opinie. |
ELEMENTY
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Wymagania partycjonowane | Dodaj wymagania dotyczące działania atrybutu „Partitioned” (przydzielone) w przypadku własnych plików cookie. | Omówiliśmy tę kwestię podczas rozmowy dotyczącej PrivacyCG, a następnie przekazaliśmy te informacje do problemu z GitHubem , dodając uwagi. Cały czas współpracujemy z przeglądarkami, programistami i społecznością zajmującą się ochroną prywatności, aby ustalić pewne zachowania. |
| Uwierzytelnione umieszczenia | CHIPS mogą mieć wpływ na bieżący proces logowania jednokrotnego z powodu różnych partycjonowania, które wpływają na uwierzytelnione elementy umieszczone na stronie. | Zdajemy sobie sprawę z przypadków użycia uwierzytelnionych umiejscowienia i pracujemy nad rozwiązaniami. |
| Limit partycji pliku cookie | Pamiętaj, że aktualny limit 10 plików cookie może nie być wystarczający w niektórych przypadkach. | Odchodzimy od limitu liczby plików cookie do 12 KB. Dzięki temu będziemy mogli rozwiązać problemy z limitem plików cookie, a jednocześnie zapewnić, że nie będzie to negatywnie wpływać na wydajność i wykorzystanie pamięci przeglądarki. |
| Oś czasu wersji próbnej origin | Rozszerzenie OT jest po usunięciu wymogu ograniczenia nazwy hosta. | Przedłużyliśmy termin testowania origin na podstawie opinii z ekosystemu. |
| Ograniczenia testowania w Chrome | Ze względu na bieżące ograniczenia w Chrome możliwość przetestowania CHIPS w przeglądarce Firefox. | Implementacja przeglądarki Firefox jest w przybliżeniu inna: Chrome ma mniejszy limit plików cookie, a CHIPS to mechanizm akceptacji, ale przeglądarka Firefox jest partycjonowana domyślnie. |
| (również w II kwartale)
Uwierzytelnione umieszczenia |
Czy stan logowania jest zachowywany przy użyciu CHIPS? | Aktualizacja na III kwartał:
Stan zalogowania nie jest obecnie zachowywany, ale nie jest odpowiednim przypadkiem użycia CHIPS. Zdajemy sobie sprawę z przypadków użycia uwierzytelnionych umiejscowienia i pracujemy nad rozwiązaniami. |
FedCM
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| (również w II kwartale)
Potencjalne wektory ataku |
Potencjalne wektory ataku przez ozdoby linków i ataki wyczuwalne. | Aktualizacja na III kwartał:
Wspólnie z firmą Mozilla doszliśmy do wypracowania ogólnodostępnego rozwiązania problemu z atakem czasowym. Szczegóły znajdziesz tutaj. Obecnie tworzymy prototyp tej zmiany architektonicznej i zamierzamy uruchomić eksperymenty w najbliższych kwartałach. |
| Dostawcy tożsamości | Selektor konta: jeden dostawca tożsamości. Prośba o zezwolenie na dostęp do wielu dostawców tożsamości. | Wspólnie z dostawcami przeglądarek i organizacją CG FedID popracowaliśmy nad tym, jak umożliwić korzystanie z wielu dostawców tożsamości, i opracowaliśmy formułę, która wydaje się warta spróbowania. Opis tej oferty znajduje się tutaj. Przewidujemy, że w najbliższych kwartałach będziemy opracowywać prototypy i przeprowadzać eksperymenty. |
| Znane problemy z federacją | Poproś o wytypowanie przypadków, w których federacja może napotkać problemy z wycofaniem plików cookie innych firm. | FedID CG ma element roboczy, który wskazuje sposoby uszkodzenia federacji tutaj i tutaj. Firma opracowuje również macierz decyzyjny, która pozwoli zmapować awarie na interfejsy API platform internetowych (tutaj). |
| Parametr nazwy | Czy parametr Nounce może wpływać na przepływ logowania? | Można to uznać za śledzenie w witrynach, ale wciąż gromadzimy opinie i analizujemy, jak postępować w takich przypadkach. |
| Zgoda użytkownika | Łączenie różnych stron uzależnionych i zgód użytkownika w przypadku każdego źródła. | Ta specyfikacja nie może kontrolować sposobu udostępniania plików cookie przez źródła w tej samej domenie. Specyfikacja zezwala na stosowanie identyfikatora idtoken od źródła dostawcy tożsamości do punktu początkowego RP, ale to od grupy RP zależy, czy stan logowania użytkownika ma być przechowywany w pliku cookie zablokowanym na tym źródle czy w pliku cookie udostępnianym źródłom w tej samej domenie. |
| Konto dostawcy tożsamości
przenośność |
Opcja migracji dostawców tożsamości, jeśli zostanie wybrana podczas przenoszenia między 2 dostawcami tożsamości. | Wygląda to na to, że użytkownik będzie musiał zrobić bezpośrednio na stronie rejestracji nowego dostawcy tożsamości, a nie w interfejsie FedCM API. |
| Usuwanie konta | Odwołanie dostawcy tożsamości uwzględnia usunięcie konta u dostawcy tożsamości. | Ta prośba o dodanie funkcji jest otwarta na potrzeby wprowadzania i sprawdzania. |
| Deklaracja interfejsu | Twierdzenia dotyczące aspektów interfejsu związanych z przeglądarką. | Rozwiązanie tego problemu znajdziesz w sekcji dotyczącej żądań pull. |
| Weryfikacja rekomendacji dostawcy tożsamości | IDP szuka strony odsyłającej RP. | Dodaliśmy do specyfikacji obowiązkowe sprawdzanie strony odsyłającej dostawcy tożsamości. Zobacz żądanie pobierania. |
| Proces logowania | Poproś o dostosowanie procesów logowania pod kątem preferencji w grupie objętej ograniczeniami. | Cieszymy się z tej propozycji i aktywnie ją omawiamy. |
Zwalczanie spamu i oszustw
Interfejs Trust Tokens API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
| Oszustwa i nadużycia | Jakie narzędzia mają zapewnić, że bot nie nakłonić wystawcy do podania tokena, nie przejął tokena wydanego rzeczywistemu użytkownikowi i zapobiec wystawianiu złośliwych tokenów przez boty? | Choć boty mogą uzyskać tokeny od wydawcy, zachęcamy wydawców do ograniczenia częstotliwości wystawiania tokenów i niezawodnych metod wystawiania tokenów oraz aktualizowania logiki wystawiania, gdy złośliwe podmioty próbują je ominąć. Wystawcy bez wystarczającej logiki w wystawianiu tokenów mogą stać się mniej zaufane w ekosystemie, ponieważ witryny traktują priorytetowo zależnie od bardziej rzetelnych wydawców. |
| Oszustwa i nadużycia | Czy osoba korzystająca z tokena zaufania może określić, że akceptuje tylko tokeny zaufania pochodzące od konkretnych encji? | Tak, jest to możliwe. Sposób korzystania z tokena zaufania opisano w sekcji Wykorzystanie tokena zaufania w objaśnieniu. |
| Oszustwa i nadużycia | Czy wydawca tokena zaufania może zdefiniować listę osób uprawnionych i uniemożliwiać jego wykorzystanie innym osobom? | Obecnie nie, ale zespół bada ten przypadek użycia. |
| Oś czasu | Kiedy interfejs Trust Token API będzie ogólnodostępny? | Więcej informacji przekażemy publicznie, gdy tylko będziemy mogli ustalić harmonogram. |
| (również w II kwartale)
Koszty konserwacji |
Nie wiadomo, jak długie wersje protokołów będą obsługiwane. | Aktualizacja na III kwartał:
Dodajemy dodatkową obsługę interfejsów API w celu obsługi wielu wersji równoczesnych, aby umożliwić płynne przejście między wersjami, choć nie zostały jeszcze ustalone terminy takiej obsługi i wycofywania. |