Czwarty raport kwartalny z 2023 r. podsumowujący opinie ekosystemu dotyczące propozycji dotyczących 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 celem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące głównie interfejsów API Topics, Protected Audience 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 |
|---|---|---|
| Zarządzanie danymi i zgodność z regulacjami | wskazówki dotyczące korzystania z Piaskownicy prywatności zgodnie z wymaganiami prawnymi; | Podobnie jak w przypadku każdej nowej technologii, każda firma jest odpowiedzialna za to, aby jej korzystanie z Piaskownicy prywatności było zgodne z prawem. Google nie może udzielać porad prawnych. Zdajemy sobie jednak sprawę, że jest to kluczowa kwestia dla całego ekosystemu. W przypadku każdego interfejsu API opublikowaliśmy obszerną dokumentację techniczną, która powinna stanowić podstawę do dokonania niezbędnych ocen prawnych. Pracujemy też nad udostępnieniem dodatkowych materiałów, które pomogą firmom w spełnianiu wymagań regulacyjnych. |
| Propozycja testów ilościowych CMA | Więcej informacji o propozycji testów ilościowych CMA | Wspólnie z CMA opracowujemy eksperymenty, które pozwolą nam ocenić wpływ wycofania plików cookie innych firm i wprowadzenia propozycji Piaskownicy prywatności na ekosystem. W kwietniu CMA opublikował ogólne wskazówki dotyczące tego, czego można się spodziewać w okresie testowania i próbnego wdrażania, a w czerwcu – szczegółowe wskazówki. Zachęcamy do zgłaszania pytań i opinii na temat propozycji CMA dotyczącej testów ilościowych bezpośrednio do CMA. |
| Tryby testowania obsługiwane przez Chrome | Więcej informacji i wyjaśnień dotyczących harmonogramów testowania | 18 maja opublikowaliśmy post na blogu, w którym podaliśmy więcej informacji o 2 trybach testowania obsługiwanego przez Chrome. Te informacje nie są ostateczne. W III kwartale 2023 r. opublikujemy dalsze wskazówki dotyczące wdrażania. |
| Partycjonowana pamięć masowa | Czy podczas testów przeprowadzanych przy użyciu Chrome będzie używana partycjonowana pamięć masowa? | Podział pamięci zostanie udostępniony wszystkim użytkownikom przed eksperymentem dotyczącym wycofania plików cookie innych firm. Dlatego zostanie ona włączona we wszystkich grupach porównywanych w eksperymencie. W tym czasie witryny będą mogły włączyć okres próbny wycofywania, aby odzyskać nieprzydzielone miejsce na dane. |
| Pomoc w produkcji | Jakie procesy w Chrome obsługują problemy techniczne związane z Piaskownicą prywatności i ich eskalację w ekosystemie? | Google udostępnia różne kanały, aby umożliwić specjalistom ds. technologii reklamowych zgłaszanie problemów i przekazywanie ich do dalszego rozpatrzenia. Więcej informacji o publicznych i prywatnych forach przeznaczonych do przekazywania opinii i zgłaszania problemów znajdziesz w omówieniu opinii. |
| Oś czasu rejestracji | Obecny termin rejestracji jest za krótki | Nadal analizujemy termin wdrożenia i chcielibyśmy poznać opinię ekosystemu na temat tego, jaki termin byłby najbardziej odpowiedni. |
| Numer DUNS | Więcej informacji o wymaganiu dotyczącym numeru DUNS w przypadku rejestracji i certyfikacji | Wymagania dotyczące uzyskania numeru DUNS można znaleźć na stronie Dun and Bradstreet. Wymagania różnią się w zależności od rynku, dlatego uczestnicy powinni sprawdzić stronę internetową poświęconą interesującemu ich rynkowi. Uczestnicy muszą jednak podać podstawowe informacje o swojej firmie, takie jak nazwa firmy, adres i dane kontaktowe właściciela lub menedżera firmy. Uczestnicy mogą też zostać poproszeni o podanie informacji finansowych, takich jak roczny przychód firmy. Gdy zgłoszenie zostanie wypełnione, firma Dun& Bradstreet sprawdzi je i wyda numer DUNS, jeśli zgłoszenie zostanie zatwierdzone. |
| Przejście z testowania origin do ogólnej dostępności | Czy przejście z testów wersji Origin na wersję ogólnie dostępną wpłynie na obecnych testerów wersji Origin? | Od lipca testerzy będą mogli korzystać z interfejsów API dopasowania i pomiarów w wersji ogólnodostępnej. Dzięki temu okres próbny wersji źródłowej będzie się pokrywać z okresem dostępności wersji ogólnej. |
| Badanie AdExchanger | Więcej informacji o metodologii ankiety | W ankiecie poprosiliśmy respondentów o oszacowanie współczynników synchronizacji i przychodów swoich firm. Metoda odpowiedzi na poszczególne pytania była wybrana przez respondentów. |
| Wartości parametrów | Jak określane są wartości parametrów, takich jak poziom szumu, progi anonimowości i budżet prywatności? | Na tej stronie na GitHubie znajdziesz bardziej ogólne zasady dotyczące interfejsów API Piaskownicy prywatności. Wiele wartości jest jeszcze w trakcie opracowywania i zapraszamy do dzielenia się opiniami na ten temat. |
Wyświetlanie odpowiednich treści i reklam
Tematy
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ochrona prywatności | Badania dotyczące wpływu interfejsu Topics API na ochronę prywatności | Aktywnie współpracujemy z środowiskiem naukowym, prezentując wyniki badań nad funkcjami dotyczącymi prywatności w interfejsie Topics API w artykułach, raportach i prezentacjach na warsztatach. Cieszymy się, że w tej dziedzinie działa coraz więcej osób z zewnętrznej społeczności badawczej. Interfejs Topics API chroni użytkowników przed ogólnym śledzeniem w internecie, utrudniając śledzenie użytkowników na dużą skalę. Te dokumenty pokazują, że udało nam się to osiągnąć dzięki interfejsowi Topics API. Zapewnia większą prywatność niż pliki cookie innych firm i chroni użytkowników, jednocześnie wspierając witryny, które lubią odwiedzać. |
| 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. | W odpowiedzi na wcześniejsze opinie z ekosystemu 15 czerwca opublikowaliśmy post na blogu, w którym szczegółowo opisaliśmy nową zaktualizowaną taksonomię, która zawiera liczne ulepszenia wprowadzone na podstawie opinii z ekosystemu. W ramach prac nad zaktualizowaną taksonomią współpracowaliśmy z kilkoma firmami z różnych części ekosystemu, takimi jak Raptive (dawniej CafeMedia) i Criteo. Zaktualizowana taksonomia usuwa kategorie, które według opinii użytkowników są mniej przydatne, na rzecz kategorii lepiej pasujących do zainteresowań reklamodawców, przy jednoczesnym zachowaniu naszego zobowiązania do wykluczania potencjalnie kontrowersyjnych tematów. Zapraszamy do zapoznania się z najnowszą wersją taksonomii i przesłania opinii na temat wprowadzonych zmian. |
| Proces aktualizacji taksonomii i klasyfikatora | Więcej informacji o taksonomii Topics i tempie wydawania klasyfikatorów oraz o tym, jak firmy mogą się przygotować do takich aktualizacji. | Jak pisaliśmy w niedawnym poście na blogu, oczekujemy, że taksonomia będzie się z czasem rozwijać, a jej zarządzanie zostanie ostatecznie przekazane podmiotowi zewnętrznemu reprezentującemu zainteresowane strony z całego sektora. Udostępniliśmy też plan wprowadzania w grupie topics-announce. |
| Wpływ na sygnały własne | Zwiększenie liczby tematów w ostatniej aktualizacji taksonomii może być bardzo przydatne i w konsekwencji zmniejszać wartość innych sygnałów własnych opartych na zainteresowaniach. | W raporcie za I kwartał 2023 r. CMA stwierdził: „Z tego, co wiemy, Google omawiało proponowaną nową taksonomię z kilkoma uczestnikami rynku w łańcuchu dostawy technologii reklamowych. Chociaż kilku dużych wydawców stwierdziło, że większa przydatność tematów zwiększy konkurencję o ich rozwiązania oparte na danych własnych, naszym zdaniem większa przydatność jest korzystna dla konkurencji ogólnie – zwłaszcza dla mniejszych wydawców, którzy chcą nadal zarabiać na swoim asortymencie po wycofaniu plików cookie innych firm”. Nasz pogląd jest zgodny z tym komentarzem CMA. |
| Przydatność dla różnych grup zainteresowanych | Platformy technologiczne do obsługi reklam, które działają jako SSP i DSP, mogą mieć znaczące przewagi nad innymi uczestnikami ekosystemu. | Nasze stanowisko nie zmieniło się od poprzednich kwartałów: „Google zobowiązało się do opracowania i wdrożenia propozycji dotyczących Piaskownicy prywatności w sposób, który nie zakłóca konkurencji przez preferowanie własnych usług, oraz do uwzględnienia wpływu na konkurencję w reklamie internetowej oraz na wydawców i reklamodawców, niezależnie od ich wielkości. Nadal ściśle współpracujemy z CMA, aby zapewnić zgodność naszych działań z tymi zobowiązaniami. W miarę postępów testowania Piaskownicy prywatności będziemy oceniać m.in., jak nowe technologie sprawdzają się w przypadku różnych grup zainteresowanych osób. W tym zakresie bardzo ważne są opinie, zwłaszcza konkretne i możliwe do wdrożenia, które pomogą nam ulepszać rozwiązania techniczne. Współpracowaliśmy z CMA nad naszym podejściem do testów ilościowych i popieramy opublikowanie przez CMA notatki na temat projektowania eksperymentów, aby zapewnić uczestnikom rynku więcej informacji i możliwość komentowania proponowanych podejść”. |
| Tematy potomne | Czy kryteria wyboru tematu, czyli częstotliwość wizyt w przeglądarce, spowodują, że tematy potomne nigdy nie będą się pojawiać na szczycie? | Obecnie Chrome testuje inne metody rankingu i sprawdza inne sygnały, które mogą poprawić ranking. W odpowiednim czasie poinformujemy o zmienionych planach. |
| Czułość | Celem interfejsu Topics API powinno być zapewnienie, że informacje o użytkownikach uzyskane lub wyprowadzone z interfejsu Topics API są mniej poufne niż te, które można uzyskać za pomocą obecnych metod śledzenia. | Uważamy, że interfejs Topics API zapewnia znacznie większą prywatność niż obecne technologie, znacznie ogranicza możliwość ponownego zidentyfikowania użytkowników i jest zaprojektowany tak, aby wykluczać tematy drażliwe. Zdajemy sobie sprawę, że tematy można korelować lub łączyć z danymi własnymi, aby tworzyć kategorie wrażliwe, ale uważamy, że interfejs Topics API to krok w kierunku ochrony prywatności użytkowników. Będziemy nadal ulepszać ten interfejs API. |
| Struktura taksonomii | Dodawanie identyfikatorów, wersji i innej struktury metadanych do mapy kategorii tematów | Obecnie w odpowiedzi interfejsu API uwzględniamy identyfikator taksonomii. W ramach długoterminowego zarządzania warto przejrzeć obiekt Topics i w razie potrzeby dodać dodatkowe metadanych dotyczące wersji. |
| Kontrola wydawcy | Wydawcy powinni mieć wpływ na to, jakie tematy powinny być przypisane ich witrynom. | Niewłaściwe zaklasyfikowanie witryn może sprawić, że sygnał Topics będzie nieco mniej przydatny, ale konkretne witryny, które zostały nieprawidłowo zaklasyfikowane, nie są w żaden sposób bardziej narażone na szkody niż inne witryny. Dzieje się tak, ponieważ informacje kontekstowe witryny będą zawsze dostępne w ramach aukcji w niej, co zapewni porównywalne informacje o właściwym temacie nawet w przypadku błędnej klasyfikacji. Opinie na ten temat możesz przesłać tutaj. Pozwolenie wydawcom na kontrolowanie klasyfikacji wiąże się z pewnymi zagrożeniami. Witryny mogą celowo być nieprawidłowo klasyfikowane, co zmniejsza ich przydatność dla wszystkich użytkowników, lub mogą zawierać treści o charakterze poufnym w mniej popularnych tematach, co narusza prywatność użytkowników. |
| Rozszerzenia do Chrome | Zezwalanie rozszerzeniom Chrome na zarządzanie tematami i ich filtrowanie, podobnie jak w przypadku obecnych rozszerzeń do zarządzania plikami cookie | Powinna to być już możliwa opcja, jak opisano na GitHubie, ale chętnie poznamy opinie innych użytkowników ekosystemu. |
| Przejście na ogólną dostępność | Czy przejście z testowania origin interfejsu Topics API do udostępnienia publicznego będzie miało jakikolwiek wpływ na ten interfejs? | Użytkownicy, którzy przejdą z wersji próbnej Origin do wersji ogólnodostępnej, nie stracą żadnych danych. |
| Prywatność | Nazwy hostów mogą zawierać informacje prywatne, które mogą zostać ujawnione przez interfejs Topics API. | Stosujemy wiele rozwiązań, które mają na celu zapewnienie prywatności, jak opisano tutaj. |
| Oszustwa i nadużycia | Jak zapobiegać manipulowaniu tematami za pomocą fałszywych wizyt | Tutaj znajdziesz informacje o środkach zaradczych. |
| Klasyfikator tematów | Czy witryny mogą poprosić o zmianę klasyfikacji tematów? | Chętnie poznamy opinie na ten temat. Tutaj możesz się podzielić swoimi uwagami. |
| Witryny dostawców tematów | Oznacz niektóre witryny, które zawierają treści dotyczące wielu tematów, jako „witryny dostawców specjalnych tematów” i trenowanie klasyfikatorów na podstawie tagów podanych na stronach internetowych. | Tutaj omawiamy tę propozycję i zapraszamy do dzielenia się opiniami. |
Protected Audience API (wcześniej FLEDGE)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| kształtowanie ruchu, | Wpływ filtrowania sterowanego przez SSP na wydajność w celu optymalizacji obciążenia związanego z liczbą zapytań na sekundę (QPS) | Poświęciliśmy sporo czasu na zastanowienie się nad kształtowaniem ruchu i zalecamy, aby SSP korzystały z przechowywania w pamięci podręcznej. |
| Liczba testów | Testowanie interfejsu Protected Audience jest trudne, ponieważ platformy SSP i DSP mają problemy z pozyskiwaniem dużych ilości ruchu. | Współpracujemy stale z partnerami SSP i DSP, aby wdrażać i testować listy odbiorców chronionych. Udostępnienie tej funkcji na skalę ogólną już się rozpoczęło i jestem przekonany, że odsetek ruchu z włączoną ochroną danych osobowych sprawi, że partnerzy chętniej będą ją testować. |
| złożoność | Wdrożenie rozwiązań Protected Audience wymaga znacznego wysiłku i kosztów. | Zdajemy sobie sprawę, że wdrażanie nowych technologii, w tym Piaskownicy prywatności, jest trudne. Zespół Piaskownicy prywatności ściśle współpracuje z wielu interesariuszami, aby edukować ich i wspierać w ich działaniach. Stale też ocenia inne przyspieszacze, które mogłyby ułatwić wdrażanie ekosystemu. |
| Zaufane środowisko wykonawcze | Obsługa zaufanych środowisk wykonawczych (TEE) w niepublicznych środowiskach chmurowych | Chociaż badamy możliwości obsługi opcji innych niż rozwiązania oparte na chmurze, obecnie nie możemy obsługiwać TEE na potrzeby lokalnych ograniczeń bezpieczeństwa, które wymagają czasochłonnej oceny w ramach Piaskownicy prywatności. Ze względu na wymagania dotyczące bezpieczeństwa w Piaskownicy prywatności i znaczące problemy związane z wdrożeniami lokalnymi uważamy, że dalsze rozszerzanie i ulepszanie wdrożeń w chmurze (np. obsługa GCP oprócz AWS) jest najbardziej korzystne dla ekosystemu. Czekamy jednak na dodatkowe opinie na temat tego, dlaczego takie wymagania są konieczne. |
| Struktura kosztów | W porównaniu z modelami po stronie klienta propozycja dotycząca określania stawek i usług aukcji spowoduje wzrost kosztów i zwiększy złożoność dla dostawców technologii reklamowych. | Obecnie opracowujemy przewodnik po szacowaniu kosztów obsługi procesów określania stawek i aukcji na serwerze określania stawek i aukcji, który będzie skorelowany z korzystaniem z technologii reklamowych. Pozwoli to nam zrealizować jeden z naszych celów. |
| Osie czasu K-Anon | Kiedy planowane ograniczenia k-anonimowości zostaną zastosowane w funkcji renderUrl? | Pracujemy nad wyjaśnieniem harmonogramu egzekwowania zasad, które wkrótce opublikujemy. |
| ograniczenia dotyczące wykonywania aukcji reklamowych, | Czy Chrome może ograniczyć runAdAuction do wywołania tylko z poziomu strony głównej? |
Nasze rozwiązanie umożliwia wywoływanie runAdAuction z poziomu strony najwyższej, ale uważamy, że ograniczenie tej funkcji tylko do domeny najwyższego poziomu byłoby bardziej szkodliwe dla wydawców.Z opinii uzyskanych od przedstawicieli ekosystemu wynika, że Piaskownica prywatności musi minimalizować obciążenia dla wydawców i reklamodawców. Ta opinia jest zgodna z ogólnymi zasadami tworzenia stron internetowych, zgodnie z którymi właściciele witryn mogą używać narzędzi innych firm do obsługi swoich witryn. Celem Piaskownicy prywatności było zachęcenie do tworzenia zdrowego ekosystemu bez konieczności określania sposobu działania wydawców i technologii reklamowych. Ponieważ pozwalamy wydawcom wybrać, jak i kto ma wywoływać funkcję runAdAuction na ich stronie, uważamy, że zapewniamy im elastyczność, dzięki której mogą znaleźć najlepszą ścieżkę dopasowaną do ich potrzeb. |
| Pomoc dotycząca implementacji | Czy Chrome może tworzyć implementacje open source aukcji dla wielu sprzedawców lub przyczyniać się do ich tworzenia? | Piaskownica prywatności ma na celu opracowanie technologii chroniących prywatność, które nie opierają się na plikach cookie innych firm ani innych identyfikatorach międzywitrynowych. Chcemy zachęcać do tworzenia zdrowego ekosystemu bez konieczności określania, jak powinny działać technologie reklamowe. W naszym repozytorium GitHub opublikowaliśmy wskazówki dotyczące działania interfejsów API. Chętnie zapoznamy się z rozwiązaniami innych firm. Nie planujemy tworzyć żadnej konkretnej implementacji, ponieważ naszym głównym zadaniem jest tworzenie technologii platformy, a nie narzucanie strategii ich wykorzystania. Nasze technologie pomogą firmom z branży technologii reklamowych w najlepszy sposób obsługiwać klientów, zapewniając konsumentom odpowiednie zabezpieczenia prywatności. |
| Aukcje z wieloma sprzedawcami | Czy Chrome będzie zmuszać do udostępniania „kontekstowego” zwycięzcy w aukcjach komponentów? | Interfejs Protected Audience API umożliwia stronom inicjującym aukcję wielosprzedawców przekazywanie informacji do aukcji komponentów (uwaga: tylko przed rozpoczęciem aukcji). Nie widzimy jednak sposobu, aby przeglądarka mogła odróżnić, czy dana informacja jest zwycięzcą kontekstowym, czy nie, więc nie możemy narzucić blokowania lub wymagania określonych informacji. |
| Ustawienie użytkownika dotyczące śledzenia z uzyskaniem zgody | Firma z branży AdTech pyta partnera analitycznego, jak prawidłowo śledzić zgodę użytkownika | Nasz komentarz zawiera informacje podane w pierwszym pytaniu: „W przypadku konkretnych reklam odpowiednia technologia reklamowa jest stroną, która najlepiej nadaje się do oferowania opcji kontroli wyświetlania kreacji lub ich wybierania”. Podczas spotkania WICG dotyczącego chronionych odbiorców omówiliśmy kilka scenariuszy związanych z tym problemem. Zachęcamy do dzielenia się opiniami i prowadzenia dyskusji na ten temat. |
| Niestandardowe listy odbiorców | Czy interfejs Protected Audience API będzie obsługiwać przypadki użycia platformy SSP związane z tworzeniem niestandardowych list odbiorców? | Interfejs Protected Audience API umożliwia platformom SSP i innym dostawcom technologii reklamowych posiadanie niestandardowych list odbiorców i zarządzanie nimi. Opracowujemy dodatkowe wskazówki dotyczące integracji platformy SSP z interfejsem PA API. Będą one dostępne dla platform SSP i innych dostawców technologii reklamowych, aby ułatwić im integrację. |
| Formaty | Czy interfejs Protected Audience API obsługuje filmy? | Reklamy wideo są dostarczane na 2 sposoby: jako kod XML VAST lub kod HTML (reklama out-stream, która może też wczytywać kod XML VAST do odtwarzacza). Kupujący mogą zwracać dowolny format za pomocą adresu renderURL. Specyfikacja VAST została niedawno zaktualizowana, aby obsługiwać interfejs Attribution Reporting API. Witryny wyświetlające reklamy wideo muszą się przygotować na sposób wyświetlania reklam za pomocą interfejsu Protected Audience API. Oznacza to, że tagi miejsc docelowych mogą przekazywać adres URL z ramki iframe Protected Audience do odtwarzacza wideo. W przypadku wydzielonych ramek będziemy pracować nad zaspokojeniem potrzeb związanych z filmami przed wprowadzeniem wymogu ich używania, co nastąpi najwcześniej w 2026 r. |
| Tempo | Jak działa stosowanie funkcji Pacing w interfejsie Protected Audience API? | Doceniamy tę opinię. Chcielibyśmy, aby więcej żądań o dostęp do danych zostało wysłanych z większą liczbą szczegółów przez większą liczbę partnerów SSP, ponieważ do tej pory problemy tego typu dotyczyły głównie platform DSP. |
| Częstotliwość aktualizacji | Częstotliwość wywołań z dailyUpdate (do 1 na grupę zainteresowań dziennie) może nie wystarczyć w pewnych przypadkach, np. podczas aktualizowania informacji o produkcie. |
Doceniamy tę opinię. Istnieją też inne rozwiązania umożliwiające dostawcom technologii reklamowych korzystanie z sygnałów, które są odświeżane w różnych odstępach czasowych, np. wyszukiwania w tablicy klucz-wartość. |
| Kontrola jakości reklam | Jak wydawcy implementują kontrolę jakości reklam? | Obecnie interfejs Protected Audience API umożliwia wydawcom informowanie platform SSP o określonych ustawieniach, które mogą ustalić w ramach konfiguracji aukcji przed ustaleniem stawki (np. listy wykluczeń na podstawie etykiet powiązanych z reklamami). Chętnie poznamy Twoją opinię na temat dodatkowych funkcji, których potrzebuje ekosystem. |
| Debugowanie | Kiedy funkcja forDebuggingOnly zostanie usunięta? |
Planujemy wycofać forDebuggingOnly w przypadku zdarzeń utraty spowodowanych wycofaniem plików cookie innych firm. Planujemy wycofać forDebuggingOnly w przypadku wydarzeń z wygrywaniem najpóźniej w 2026 roku. |
| Grupy zainteresowań na różnych urządzeniach | Propozycja włączenia grup zainteresowań na różnych urządzeniach dla uwierzytelnionych klientów użytkownika | Rozważamy tę propozycję, ale wysoka specyficzność kierowania na wiele urządzeń powoduje poważne obawy dotyczące prywatności, o których mowa w tym problemie na GitHub. |
| (również w raporcie za I kwartał) Remarketing dynamiczny | Czy po wycofaniu plików cookie innych firm remarketing dynamiczny będzie nadal możliwy za pomocą interfejsu Protected Audience API? | Uważamy, że ten przypadek użycia jest możliwy dzięki użyciu Protected Audience, jak wyjaśniono tutaj. |
| Kliknij „Powiązane dane”. | Dodawanie do browserSignals. danych związanych z kliknięciami |
Obecnie prosimy o wyjaśnienie, kiedy nastąpiło kliknięcie, aby podać wstępną pozycję. |
| (również zgłoszone w IV kwartale 2022 r.) Funkcje zdefiniowane przez użytkownika w przypadku listy odbiorców chronionych | Jak funkcje zdefiniowane przez użytkownika (UDF) będą obsługiwane w interfejsie Protected Audience API? Są to funkcje, które użytkownicy mogą zaprogramować, aby rozszerzyć funkcjonalność interfejsu API. | Osoba, która zgłosiła ten problem, wspomniała też, że nadal analizuje możliwości wykorzystania UDF, więc nie ma jeszcze informacji zwrotnych, na które można by było zareagować, przynajmniej do czasu udostępnienia tej funkcji na skalę ogólną. |
| Waluta | Wartości walutowe nie powinny być wyrażane za pomocą liczb zmiennoprzecinkowych. | Tutaj omawiamy ten problem szczegółowo. |
| Możliwości wyboru reklam bez systemu DSP | Jaką rolę pełnią serwery reklam w ramach aukcji Protected Audience API? | Jesteśmy świadomi próśb o to, aby serwery reklam nadal oferowały usługi wyboru reklam po ustaleniu stawki i optymalizacji kreacji dynamicznych. Obecnie analizujemy szczegółowo różnice między obecnym interfejsem Protected Audience API a tymi żądaniami. |
| GenerateBid | Obsługa propozycji Google Ads polegająca na zwracaniu z generateBid więcej niż 1 reklamy kandydata na grupę zainteresowań reklamy i przypisywaniu tym reklamom wartości w polu „scoreAd”. |
Obecnie jest to oceniane. Tutaj możesz przesłać dodatkową opinię. |
| Zamówienie reklamowe | Czy aukcje Protected Audience API muszą być przeprowadzane jako ostatnie, aby mogły uwzględniać wyniki wszystkich innych aukcji? | Nie ma technicznego wymogu, aby interfejs Protected Audience API był wykonywany jako ostatni. |
| Nawigacja inicjowana przez inne osoby niż użytkownik | Wyświetlanie nawigacji inicjowanej przez inne osoby niż użytkownik | Rozpatrujemy tę prośbę i omawiamy ją tutaj . Zachęcamy do przesyłania dodatkowych opinii. |
| Pamięć podręczna | Jeśli stan użytkownika ulegnie zmianie, SSP nie powinien tworzyć sygnałów perBuyerSignals danego DSP z poziomu pamięci podręcznej. | Zdajemy sobie sprawę, że buforowanie nie działa w przypadku każdego zastosowania sygnałów perBuyer, dlatego rozważamy inne opcje. Zachęcamy do przekazywania opinii o tym, czy buforowanie sprawdzi się w przypadku ich zastosowań. |
| Raportowanie atrybucji i Protected Audience | Jak interfejs Attribution Reporting API może współpracować z interfejsem Protected Audience API? | Integracje z Protected Audience API są obecnie dostępne w obu trybach Attribution Reporting API (raporty na poziomie zdarzenia i raporty zbiorcze). 1 czerwca udostępniliśmy więcej informacji o ulepszonej integracji interfejsu Protected Audience API i raportowania atrybucji. Więcej informacji znajdziesz tutaj. |
| Punkt końcowy serwera | Czy w ostatecznej wersji punkt końcowy serwera będzie zaufanym serwerem agregacji? | Punkt końcowy serwera to punkt końcowy obsługiwany przez dostawcę technologii reklamowych, który jest niezależny od zaufanych serwerów agregacji służących do przetwarzania zebranych i przekształconych raportów. Obecnie nie planujemy żadnych zmian w punkcie końcowym raportowania. Obecna architektura ma na celu zapewnienie, że same raporty podlegające agregacji (z zaszyfrowanymi ładunkami) nie będą zawierać danych z różnych witryn, więc zaufany punkt końcowy nie powinien być potrzebny. Dodatkowym utrudnieniem jest to, że różne technologie reklamowe będą prawdopodobnie miały różne preferowane strategie grupowania. Tutaj możesz przesłać dodatkową opinię. |
| WebIDL | Obecna specyfikacja interfejsu Protected Audience API nie jest zgodna ze specyfikacją WebIDL. | Oceniamy te opinie i omawiamy ten problem tutaj. |
| Zarządzanie zgodą użytkowników | Jak będzie wyglądać przekazywanie sygnałów dotyczących zgody w interfejsie Protected Audience API? | Informacje kontekstowe nie są objęte zakresem interfejsu Protected Audience API. Rozmawiamy o tym problemie i zapraszamy do dzielenia się opiniami. |
| Marketing oparty na kontach | Czy możliwe są przypadki użycia marketingu opartego na kontach? | Interfejs Protected Audience API obsługuje różne przypadki użycia marketingu opartego na danych o odbiorcach. Nadal staramy się zrozumieć, jak interfejs Protected Audience API może najlepiej obsługiwać ten konkretny przypadek użycia. Zapraszamy do podzielenia się z nami opinią na temat tego problemu. |
| Aukcja komponentów | Jakie punkty zdobywają uczestnicy aukcji komponentów? | Aukcji komponentów nie ocenia się bezpośrednio na podstawie grup zainteresowań, lecz na podstawie reklam i stawek przesłanych przez DSP za pomocą funkcji generateBid. Funkcja generateBid() jest wykonywana dla każdej grupy zainteresowań, a platforma DSP zwraca podczas wykonywania funkcji generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Wkład zewnętrzny | Prośba o wsparcie zewnętrznych wkładów w bazie kodu Key/Value Server na GitHubie. | Chcemy zaktualizować odpowiednie procesy, aby umożliwić zewnętrznym użytkownikom publikowanie kodu na GitHubie. |
| Rozmiar grupy zainteresowań | Jaka jest maksymalna liczba kluczy obsługiwanych przez IG? | Obecny limit rozmiaru jednego IG to 50 KB, a klucze są wliczane do tego limitu. Zachęcamy do dalszej dyskusji na temat limitu rozmiaru. |
| Grupowanie | Jak można zmniejszyć liczbę wywołań serwera K/V? | Aby zmniejszyć liczbę wywołań K/V, możesz użyć nagłówków HTTP Cache-Control. Może ona być na przykład zapisana w pamięci podręcznej w ramach aukcji komponentów, a także w ramach boksów reklamowych na jednej stronie. |
| Version control | Obsługa wielu wersji kodu technologii reklamowych | Usługi określania stawek i aukcje będą obsługiwać wiele wersji kodu technologii reklamowych. W interfejsie API określania stawek i aukcji żądanie SelectAd może określać wersję kodu używaną do żądania aukcji (np. do określania stawek / aukcji i także do raportowania). |
| Pamięć współdzielona | Obsługa zapisu do pamięci współdzielonej w usłudze określania stawek i aukcji. | Obecnie usługi określania stawek i aukcji nie obsługują wspólnego miejsca na dane, ale chętnie poznamy opinie na temat tego, dlaczego takie przypadki użycia są ważne dla ekosystemu. |
| Przekierowanie z sieci do aplikacji | Obsługa udostępniania grup zainteresowań z internetu do aplikacji. | Przesyłanie danych z internetu do aplikacji nie jest obecnie objęte wdrażaniem interfejsu Protected Audience API w Chrome i na Androidzie, ale chcielibyśmy poznać opinie użytkowników ekosystemu na temat znaczenia tego zastosowania. |
| K-anonimowość | Zastępcze wyświetlane ścieżki w przypadku k-anonimowości | Rozmawiamy o tym problemie i chętnie poznamy Twoją opinię. |
Pomiar skuteczności reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Alternatywy konfiguracji raportów na poziomie zdarzenia VTC | Opinia na temat alternatywnych konfiguracji raportów na poziomie zdarzenia VTC | Otrzymaliśmy opinie, że obecne konfiguracje na poziomie zdarzenia nie są optymalne. Prosimy o opinie na temat optymalnych konfiguracji globalnych. Chętnie poznamy Twoją opinię na ten temat. Nasze omówienie elastycznego wydarzenia może Ci w tym pomóc. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jaki jest stan funkcji elastycznej konfiguracji na poziomie zdarzenia? | Udostępniliśmy dokumentację dotyczącą elastycznej konfiguracji na poziomie wydarzenia. Ta funkcja jest nadal na etapie propozycji i chcielibyśmy poznać Twoją opinię na temat tego, czy będzie ona przydatna dla całego ekosystemu. |
| Elastyczne konfiguracje na poziomie zdarzenia | Jak można uzgodnić sprzeczne raporty pochodzące od różnych stron? | Większość scenariuszy raportowania jest realizowana za pomocą raportów zbiorczych, natomiast elastyczna konfiguracja na poziomie zdarzenia jest przeznaczona do zwiększenia elastyczności raportów na poziomie zdarzenia, które są najczęściej używane do celów optymalizacji. Zachęcamy do dzielenia się komentarzami i opiniami na temat tego scenariusza. |
| Rejestracja źródła | Co się stanie, jeśli rejestracja źródła nastąpi po rejestracji reguły? | Obecnie, jeśli rejestracja źródła nastąpi po rejestracji reguły, źródło i reguła nie będą mogły być przypisane do siebie nawzajem. Wygląda na to, że jest to przypadek szczególny. Zachęcamy do przesyłania dodatkowych opinii na temat tego problemu. Postaramy się go rozwiązać, jeśli dotyczy on wielu dostawców technologii reklamowych. |
| Współpraca z wieloma agencjami reklamowymi | Jak platformy DSP mogą korzystać z interfejsu Attribution Reporting API, gdy reklamodawca współpracuje z kilkoma agencjami reklamowymi? | Interfejs API obsługuje przekierowania, dzięki czemu może być używany nawet wtedy, gdy reklamodawca współpracuje z kilkoma agencjami reklamowymi. Dodatkowo obowiązują pewne ograniczenia dotyczące przekierowań, aby zapewnić, że interfejs API zwiększa prywatność. Zidentyfikowaliśmy też potencjalne obejście problemu, które wykorzystuje interfejs Shared Storage API w przypadku konkretnego scenariusza zgłoszonego przez firmę zajmującą się technologią reklamową. Będziemy wdzięczni za wszelkie dodatkowe opinie na temat tego scenariusza. Będziemy na bieżąco ulepszać tę funkcję. |
| Limity miejsca docelowego | Na sposób działania reklam automatycznie odświeżających może mieć wpływ ograniczenie liczby miejsc docelowych. | Rozmawialiśmy o tym problemie podczas spotkania WICG w dniu 1 maja i chcielibyśmy poznać Twoją opinię na temat rozsądnego limitu. Dodaliśmy do raportów atrybucji z tłumaczeniem raportów na poziomie zdarzenia informację, że przeglądarka może ograniczyć liczbę docelowych domen eTLD+1 reprezentowanych przez witryny źródłowe. (zobacz pull request). |
| Raportowanie atrybucji i Protected Audience | Jak interfejs Attribution Reporting API może współpracować z interfejsem Protected Audience API? | Integracje z Protected Audience API są obecnie dostępne w obu trybach Attribution Reporting API (raporty na poziomie zdarzenia i raporty zbiorcze). 1 czerwca udostępniliśmy więcej informacji o ulepszonej integracji interfejsu Protected Audience API i raportowania atrybucji. Więcej informacji znajdziesz tutaj. |
| Elastyczne konfiguracje na poziomie zdarzenia | Udostępniaj sprawdzone metody symulacji szumu, ponieważ teraz można konfigurować parametry. | Udostępniliśmy kod na GitHubie, którego każdy może użyć do oceny zysku z informacji i wpływu szumu na dowolne konfiguracje elastyczne na poziomie zdarzenia, które chce przetestować. Chętnie poznamy opinie osób, które zdecydują się przetestować kod. |
| Atrybucja w aplikacji i internecie | Kiedy będzie dostępna usługa pomiaru atrybucji obejmująca aplikacje i witryny? | 9 maja ogłosiliśmy eksperyment dotyczący pomiaru atrybucji w witrynach i aplikacjach za pomocą interfejsu Attribution Reporting API. W przypadku interfejsów API do pomiaru trafności i pomiaru w Chrome 115 planujemy udostępnienie wersji ogólnodostępnej, ale nie planujemy udostępnienia wersji ogólnodostępnej pomiaru atrybucji w aplikacjach i w internecie w Chrome 115. |
| usuwanie duplikatów konwersji, | Jak można dopasować niezależne rozwiązania analityczne do ARA? | Zgodnie ze standardową praktyką reklamodawcy współpracują z zewnętrznym niezależnym dostawcą usług pomiarowych, aby usuwać duplikaty w raportach o konwersjach. Udostępniliśmy materiały dotyczące usuwania duplikatów konwersji na potrzeby raportowania na poziomie zdarzenia. |
| Utrata danych podczas aktualizacji bazy danych raportowania atrybucji | Czy po aktualizacji bazy danych raportowania atrybucji w Chrome, zgodnie z ogłoszeniem, dojdzie do utraty danych? | Od wersji Chrome 115 stabilnej zaczniemy domyślnie włączać interfejsy API Relevance i Measurement w przypadku części użytkowników Chrome. Ogólna dostępność będzie się zwiększać, gdy będziemy monitorować potencjalne problemy. Naszym celem jest osiągnięcie 100% dostępności w ciągu kilku tygodni, do końca III kwartału 2023 r. Zbiegnie się to z zakończeniem wersji próbnej dotyczącej trafności i źródła pomiaru. Od lipca testerzy będą mogli zarejestrować się w celu uzyskania dostępu do tych interfejsów API w wersji ogólnodostępnej. Dzięki temu będzie można nakładać okres próbny wersji źródłowej i ogólną dostępność poprzez rejestrację. Twój token okresu próbnego wersji oryginalnej będzie ważny do 19 września, ale zalecamy, aby zarejestrować się w przypadku interfejsów API przed jego wygaśnięciem. Dzięki temu możesz płynnie przejść z wersji oryginalnej na wersję płatną bez przerywania trwających testów. Jak wspomniano w tym ogłoszeniu, dane zarejestrowane ze starszych wersji (M113 i starszych) nie zostaną przeniesione po aktualizacji, więc może dojść do utraty danych. Ta utrata danych nie będzie widoczna w raportach debugowania, a my postaramy się uniknąć utraty danych z wersji 114 do 115. |
| Płatności | Korzystanie z raportowania atrybucji na potrzeby rozliczeń według kosztu konwersji | Jak wspomniano w tym artykule, interfejs Attribution Reporting API może nie nadawać się do rozliczeń na podstawie kosztu konwersji z powodu zakłóceń w raportach na poziomie zdarzenia i raportach podsumowujących. Zachęcamy uczestników ekosystemu do dzielenia się na GitHubie opiniami na temat wpływu interfejsu Attribution Reporting API na różne modele rozliczeń. |
Usługa do agregacji
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zbiorczy raport o opóźnieniach | pozytywne reakcje na propozycję zmiany opóźnienia raportowania danych agregowalnych z [10–60 minut] na [0–10 minut] zgodnie z opiniami z ekosystemu | Cieszymy się, że nasza propozycja zmiany została pozytywnie przyjęta. Zachęcamy do dalszego przesyłania opinii na temat naszych propozycji. |
| Rozwiązanie lokalne | Czy usługę agregacji można wdrożyć w lokalnych centrach danych? | Chociaż badamy możliwości obsługi opcji innych niż rozwiązania oparte na chmurze, obecnie nie możemy obsługiwać TEE na potrzeby lokalnych ograniczeń bezpieczeństwa, które wymagają czasochłonnej oceny w ramach Piaskownicy prywatności. Ze względu na wymagania dotyczące bezpieczeństwa w Piaskownicy prywatności i znaczące problemy związane z wdrożeniami lokalnymi uważamy, że dalsze rozszerzanie i ulepszanie wdrożeń w chmurze (np. obsługa GCP oprócz AWS) jest najbardziej korzystne dla ekosystemu. Czekamy jednak na dodatkowe opinie na temat tego, dlaczego takie wymagania są konieczne. |
| Ponowne przetwarzanie raportów z różnych okresów | Możliwość ponownego przetworzenia raportów z różnych okresów | Otrzymaliśmy podobne prośby o możliwość dzielenia partii na różne zakresy dat. Jedną z propozycji jest umożliwienie rozszerzenia wspólnego identyfikatora o etykietę zdefiniowaną przez technologię reklamową, aby można było dzielić raporty na różne partie. Jesteśmy na wczesnym etapie oceny tego procesu i w miarę rozwoju tej propozycji będziemy informować ekosystem o jego postępach. |
| Wpływ środowiska Trusted Execution Environment na prywatność | pozytywne nastawienie do kwestii prywatności w zaufanych środowiskach wykonawczych; | Cieszymy się, że nasze propozycje spotkały się z pozytywnym odbiorem w ekosystemie. Zapraszamy do dalszego dzielenia się opiniami, ponieważ wciąż wprowadzamy zmiany i ulepszamy nasze usługi. |
| Warunki korzystania z usługi | Do kiedy należy zaakceptować Warunki korzystania z usługi agregacji? | Nie określiliśmy jeszcze terminu zaakceptowania warunków, ale zachęcamy firmy z ekosystemu, aby jak najszybciej zaakceptowały warunki, aby uniknąć opóźnień w rejestracji. Zachęcamy firmy do kontaktu w razie pytań. |
| Odnajdywanie kluczy | Funkcja wykrywania kluczy umożliwi testerom wyszukiwanie danych w raportach zbiorczych bez konieczności korzystania z wyraźnej listy możliwych kombinacji kluczy w celu przetwarzania raportów zbiorczych na potrzeby atrybucji w wielu sieciach, co ma poprawić skuteczność i zwiększyć dokładność. | Obecnie szukamy możliwych rozwiązań i obejść. Chętnie poznamy opinie na temat tego ekosystemu. |
Interfejs Private Aggregation API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Źródło raportu | Jak definiuje się pochodzenie raportu? | Źródło raportowania to zawsze skrypt wywołujący prywatne agregacje. |
| 128-bitowy klucz | Wyjaśnienie ograniczenia przestrzeni klucza 128-bitowego | Uściślimy to ograniczenie przestrzeni kluczy i usuniemy niespójności na stronach. Zalecamy stosowanie strategii szyfrowania, aby zachować ten obszar kluczy. |
| Maksymalny udział w raporcie | Obecny limit 20 wkładów na raport jest za niski. | Zamiast zwiększać maksymalną liczbę źródeł, rozważamy możliwość dzielenia raportów zamiast ich obcinania w miejscu limitu. W miarę rozwoju tej propozycji będziemy angażować ekosystem. |
| Raportowanie zasięgu | Poproś o raportowanie zasięgu na różnych platformach i urządzeniach. Zasięg to podstawowy wskaźnik reklamy marki. Reklamodawcy polegają na przybliżonych danych dotyczących zasięgu i częstotliwości na różnych platformach i urządzeniach, aby analizować swoje kampanie i przydzielać wydatki. Modele zasięgu używają plików cookie innych firm jako sygnału do pomiaru reklam wyświetlanych w środowiskach zewnętrznych, dlatego po wycofaniu plików cookie innych firm dostawcy technologii reklamowych poprosili o alternatywne rozwiązanie. |
Zespół Piaskownicy prywatności bada funkcje, które będą wspierać metody pomiaru zasięgu w wielu domenach po wycofaniu plików cookie innych firm. Chętnie poznamy opinie na temat tego ekosystemu. |
Ograniczanie śledzenia ukrytego
Redukcja klienta użytkownika/Wskazówki dotyczące klienta użytkownika
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (także w I kwartale 2023 r.) Wskazówki dotyczące dodatkowych formatów | Prośba o użycie wskazówek dotyczących klienta w user-agentach (UA-CH) w celu obsługi dodatkowych formatów, takich jak telewizory czy urządzenia VR | Nadal podejmujemy kluczowe decyzje projektowe (czy podać jedną wartość, np. „TV”, czy listę możliwości związanych z formą), ale nadal interesuje nas prototypowanie tej koncepcji. |
| Budżet na potrzeby prywatności | Ograniczenia budżetu na prywatność mogą spowodować, że żądania UA-CH staną się niedeterministyczne, jeśli zostanie wysłanych zbyt wiele żądań. | Obecnie nie mamy żadnych nowych informacji na temat propozycji budżetu na prywatność, ale zobowiązujemy się nie ograniczać próśb o wskazówki klienta UA przed wycofaniem plików cookie innych firm. |
| Zgodność z witryną | Witryny używają marki UA-CH, aby ograniczyć dostęp do nich w przypadku niektórych przeglądarek. | Lista marek ma swoje uzasadnienie, a jednym z nich jest właśnie zgodność. UA może mieć dowolną liczbę marek, aby obejść te problemy. |
Ochrona IP (dawniej Gnatcatcher)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Oszustwa i nadużycia | Jak firmy mogą skonfigurować środki zapobiegające oszustwom za pomocą ochrony IP? | Zdajemy sobie sprawę z ważności zastosowań zapobiegania oszustwom i ich wpływu na te zastosowania. Więcej informacji o wspieraniu zapobiegania oszustwom opublikujemy jeszcze w tym roku. Chcemy poznać opinie dotyczące tego, jak możemy lepiej wspierać przypadki użycia związanych z zapobieganiem oszustwom. |
| GeoIP | Więcej informacji o harmonogramie testowania i wdrażania funkcji GeoIP | Niedawno opublikowaliśmy nowe informacje na temat naszych planów dotyczących geolokalizacji. W III kwartale planujemy opublikować więcej informacji o harmonogramie wdrażania. Oczekujemy, że ochrona adresów IP zostanie wprowadzona jako funkcja, do której użytkownicy będą musieli się zadeklarować, początkowo w przypadku niewielkiego odsetka ruchu. Zdajemy sobie sprawę, że ta propozycja może spowodować znaczne zmiany dla firm, dlatego chcemy dać ekosystemowi czas na dostosowanie się i przekazanie opinii, zanim wprowadzimy tę funkcję na większą skalę. |
| Uwierzytelnianie konta | Jak dokładnie będzie wyglądać uwierzytelnianie konta na serwerze proxy? | Więcej informacji o uwierzytelnianiu kont planujemy opublikować jeszcze w tym roku, ale już teraz udostępniliśmy wstępne informacje. |
Łagodzenie śledzenia przekierowań
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wskazówki dotyczące testowania | Informacje o testowaniu łagodzenia śledzenia przekierowań | W maju opublikowaliśmy post na blogu, w którym podaliśmy więcej informacji o testowaniu funkcji łagodzenia wskaźnika odrzuceń. |
| Dokumentacja | Jasność propozycji dotyczącej śledzenia przekierowań | Obecna propozycja jest w trakcie opracowywania, a Chrome nadal ją aktualizuje, aby zapewnić przejrzystość i dokładne informacje dla całego ekosystemu. Pracujemy nad udostępnieniem dodatkowych informacji i chętnie poznamy Twoją opinię. |
| Usuwanie plików cookie | Czy zapobieganie powrotom spowoduje usunięcie wszystkich plików cookie w domenie? | Funkcja łagodzenia śledzenia powrotów spowoduje wyczyszczenie całej pamięci i pamięci podręcznej (jak opisano tutaj). |
| Omijanie łagodzenia śledzenia przekierowań | Klasyfikację śledzenia powrotów można obejść, wykonując przekierowania za pomocą wyskakujących okienek lub nowych kart. | Specyfikacja łagodzenia śledzenia przekierowań jest wciąż opracowywana. Do tej pory skupialiśmy się głównie na przekierowaniach na tym samym karcie, ale w przyszłości planujemy pracować nad procesami otwierania wyskakujących okienek. Tutaj możesz przesłać dodatkową opinię. |
Budżet na potrzeby prywatności
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Kierowanie zbliżone | Budżet prywatności może mieć wpływ na przypadki użycia związane z kierowaniem na odbiorców w pobliżu. | Otrzymaliśmy opinie na temat tego problemu i chcielibyśmy dowiedzieć się więcej o potencjalnym wpływie na ekosystem. |
Wzmocnienie granic prywatności między witrynami
Zestawy źródeł własnych
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (raportowane również w poprzednich kwartałach) Limit domen | Prośba o zwiększenie liczby powiązanych domen | Chrome analizuje odpowiedni limit liczbowy dla powiązanego podzbioru, który zapewni równowagę między prywatnością a użytecznością w wybranych przypadkach użycia. Od samego początku Chrome podawał, że dokładna liczba elementów w podzbiorze powiązanym nie została jeszcze ustalona. |
| Wbudowany przypadek użycia | Obsługa osadzonych przypadków użycia, które wymagają zestawów źródeł własnych, CHIP-ów i pamięci współdzielonej | Zespół Chrome otrzymał opinię na temat tego przypadku użycia. Sprawdza on tę kwestię i zaprasza do dodania dodatkowych opinii. |
| Zarządzanie repozytorium | informacje o zasadach usuwania zestawów źródeł własnych z repozytorium GitHuba w przypadku rozbieżności lub zaniedbania; | Chrome otrzymał opinię na temat tego zastosowania. Nasz zespół bada sprawę i zaprasza do dodania komentarza. |
| Edukacja użytkowników | Chrome powinien zwiększać świadomość użytkowników i ich zrozumienie zestawów danych własnych, aby zwiększyć ich stosowanie. | Chrome edukuje użytkowników na temat zestawów źródeł własnych. W tym celu opublikowaliśmy artykuł w Centrum pomocy (dostępny z interfejsu Chrome). W Chrome stale pracujemy nad tym, aby jak najlepiej edukować użytkowników w odpowiednich kontekstach. |
| Post 3PCD | Po wycofaniu z użycia plików cookie innych firm będą one nadal występować w ramach zestawu własnych plików cookie. | Chociaż requestStorageAccess i requestStorageAccessFor rzeczywiście umożliwiają ponowne korzystanie z plików cookie innych firm w przypadku określonych, jasno zdefiniowanych zastosowań, wymagają one teraz aktywnego wywołania przez witrynę, zamiast być dostępne domyślnie, jak to ma miejsce w przypadku plików cookie innych firm (w Chrome).Nawet jeśli wywołanie w ramach jednego zestawu nie wymaga zgody użytkownika, może on temu zapobiec, wyłączając tę opcję w Ustawieniach. Więcej informacji jest dostępnych dla użytkowników w artykule w Centrum pomocy (link do niego znajduje się w interfejsie Chrome). Planujemy rozszerzyć istniejący przewodnik dla deweloperów, gdy liczba klatek na sekundę wzrośnie do 100%. |
| Przesyłanie zestawów źródeł własnych | Zmień nazwę wymaganego pliku .well-known/first-party-set, aby zawierała rozszerzenie .json. |
Wprowadziliśmy tę zmianę, aby zapewnić obsługę niektórych pakietów hostingu internetowego. |
| Rejestracja w IANA | first_party_sets.JSON powinien być zarejestrowany w IANA. |
Rozważamy tę propozycję i zapraszamy do przesłania dodatkowych opinii. |
Fenced Frames API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Blokowanie reklam | Ramki ograniczone mogą ułatwiać blokowanie reklam przez blokady reklam. | Rozszerzenia mogą wchodzić w interakcje z odizolowanymi ramkami w podobny sposób jak z ramkami iframe. Adres URL, do którego ma przejść zablokowana ramka, będzie też widoczny dla rozszerzeń, dzięki czemu mogą one stosować do blokowania dowolne reguły dopasowywania adresów URL, tak jak w przypadku ramek iframe. Proste zablokowanie wszystkich ujętych ramek bez wyjątków może spowodować nieprawidłowe działanie ujętych ramek w przypadku innych niż reklamy zastosowań. |
Interfejs Shared Storage API
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Szersze zastosowanie | Pamięć współdzielona powinna być standardem branżowym dostępnym w różnych przeglądarkach. | Dziękujemy za opinię. Chrome nadal aktywnie uczestniczy w forach W3C, aby promować propozycję, zbierać opinie i zachęcać do stosowania. |
| Bramki wyjściowe | Bramki wyjściowe Shared Storage są zbyt ograniczone. | Rozważamy tę opinię i zapraszamy do podzielenia się opinią na temat tego, dlaczego bramki wyjściowe są zbyt ograniczone. |
| Zgodność z regulacjami prawnymi | Jak Storage Shared będzie obsługiwać zgodność z przepisami, np. zasadami przechowywania danych? | Pamięć współdzielona zapewnia elastyczność w wdrażaniu i dostosowywaniu logiki, aby kontrolować czas trwania i wygaśnięcia przechowywanych danych. Specjaliści ds. technologii reklamowych mogą aktualizować lub usuwać dane z usług współdzielonego miejsca na dane na podstawie sygnatur czasowych zapisu. |
| Testy A/B | Jak przeprowadzić testy A/B interfejsów Shared Storage i Protected Audience API? | Pracujemy nad opublikowaniem dodatkowych wskazówek na ten temat i mamy nadzieję, że w przyszłości będziemy mogli podać więcej szczegółów. |
| Limit miejsca współdzielonego | Co się stanie, gdy zostanie osiągnięty limit miejsca na dane współdzielone? | Jeśli limit zostanie osiągnięty, żadne dodatkowe dane wejściowe nie zostaną zapisane. |
| Wiele dostępów podczas jednego wczytywania strony | Co się dzieje, gdy podczas wczytywania tej samej strony uzyskuje się dostęp do pamięci współdzielonej wielokrotnie? | Najlepszym sposobem na rozwiązanie tego problemu jest użycie funkcji window.sharedStorage.append(key, value). Zamiast aktualizować wartość dla każdej reklamy, co może spowodować kolizje, jeśli masz wiele reklam. Funkcja append doda nową wartość na końcu istniejącej wartości. |
| Funkcje elementu iframe | Czy pamięć współdzielona będzie obsługiwać niektóre funkcje iframe, gdy przestaną one działać po wycofaniu plików cookie innych firm? | Po wycofaniu plików cookie innych firm pamięć lokalna w elementach iframe zostanie podzielona według witryn najwyższego poziomu, ale same elementy iframe nie zostaną zablokowane. Dane w pamięci lokalnej elementu iframe nie mogą być powielane w wielu witrynach najwyższego poziomu, ale można z niej korzystać w ramach iframe. |
CHIPs
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Limit partycji | 10 KiB na stronę z podziałem to nadal dużo i chcielibyśmy, aby to zmniejszyć. | Firefox już wskazał dobrą pozycję w programie CHIPS. Jeśli chodzi o obsługę Webkit, zachęcamy deweloperów do przekazywania opinii bezpośrednio do Apple w tym zgłoszeniu na GitHubie dotyczącym przypadków użycia, w których preferowane są pliki cookie z partycjami nad partycjami pamięci. |
| Umieszczanie na stronie z uwierzytelnieniem | CHIPS może wpływać na bieżący proces logowania jednokrotnego ze względu na różne partycjonowanie wpływające na uwierzytelnione treści osadzonego. | Zamierzamy wykorzystać interfejs Storage Access API (z prośbami kierowanymi do użytkownika) do obsługi przypadku użycia uwierzytelnionego osadzenia. Niedawno wysłaliśmy prototyp. |
| Zasady dotyczące Lifetime | Czy potencjalne zasady dotyczące czasu trwania będą dotyczyć własnych plików cookie? | Obecnie nie planujemy nakładać limitów czasowych na własne pliki cookie. |
FedCM
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Obsługa autoryzacji OAuth | Ujednolicenie autoryzacji zakresów OAuth innych niż profil | W ramach grupy roboczej W3C FedID CG aktywnie zbieramy opinie społeczności dotyczące tożsamości w internecie na temat najlepszych sposobów na autoryzację poza podstawową autentyfikacją po wycofaniu plików cookie innych firm. |
| Obsługa SAML | Wymagania dotyczące obsługi SAML | Zespół aktywnie poszukuje opinii społeczności naukowej i edukacyjnej na temat potrzeb związanych z obsługą protokołu SAML (oprócz obsługi OpenID-connect) po wycofaniu plików cookie innych firm. |
Walka ze spamem i oszustwami
Interfejs Private State Token API (i inne interfejsy API)
| Motyw opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Nowe sygnały | Kilku partnerów wyraziło pozytywne nastawienie do korzystania z sygnałów dotyczących integralności urządzenia lub zaufania użytkowników, które są przekazywane przez przeglądarkę. Ogólnie są też ostrożni, jeśli chodzi o nowe sygnały skonstruowane na potrzeby konkretnego celu, które mają zapewnić dotychczasowy poziom wykrywania oszustw. | Cieszymy się, że możemy wspólnie z osobami z grupy zajmującej się zapobieganiem oszustwom i zapewniania bezpieczeństwa w internecie omawiać nowe propozycje. Zdajemy sobie sprawę z obaw tych osób i wspieramy je. To właśnie dlatego walka ze spamem i oszustwami była głównym obszarem prac w ramach Piaskownicy prywatności. Nadal też kładziemy nacisk na inwestycje w zapewnienie bezpieczeństwa w internecie, przy jednoczesnym zwiększaniu prywatności użytkowników. |
| Pozytywna opinia na temat PST | Kilku partnerów wyraziło zainteresowanie testowaniem lub wykorzystaniem PST w różnych przypadkach użycia związanych z zapobieganiem oszustwom lub bezpieczeństwem w internecie. | Cieszymy się, że chcesz poznać nowe rozwiązania wykorzystujące pliki PST. Na stronie dla programistów Chrome znajdziesz materiały i przykładowy kod. Zachęcamy do przesyłania opinii. |
| Oszustwa i nadużycia | Wskazówki dotyczące zapobiegania oszustwom związanym z reklamami lub ich wykrywania w ramach pomiarów po wycofaniu plików cookie innych firm, gdy identyfikatory nie są już dostępne. | Wprowadziliśmy narzędzia, takie jak tokeny stanu prywatnego, które pomagają odzyskać część sygnałów utraconej przez pliki cookie innych firm na potrzeby zapobiegania oszustwom, ale z nowymi ustawieniami ochrony prywatności. Aktywnie inwestujemy w nowe propozycje dotyczące zapobiegania oszustwom i nadużyciom, aby zachować możliwości w ramach innych zmian w Piaskownicy prywatności. |
| współczynnik informacji wydawcy do źródła, | współczynnik informacji „wydawca–źródło” jest wystarczająco wysoki, aby można było zidentyfikować unikalnych użytkowników; | Zaktualizowaliśmy specyfikację, aby dokładniej określała, jakie dane użytkownika można przekazywać za pomocą tokenów stanu prywatnego. Zgodnie z założeniami można jednocześnie używać maksymalnie 6 kluczy publicznych, które mogą reprezentować „stan” danego użytkownika. Te zestawy kluczy można aktualizować tylko co 60 dni (z wyjątkiem rzadkich przypadków, gdy konieczna jest nagła zmiana klucza), co spowalnia tempo łączenia dodatkowych danych użytkowników. W przypadku każdego nowego interfejsu API w internecie należy zachować równowagę między użytecznością a ilością nowych informacji o użytkownikach. Szacujemy, że PST zapewniają odpowiednią równowagę między ochroną prywatności użytkowników a możliwościami stosowania kluczowych rozwiązań zapobiegających oszustwom, na które wycofanie plików cookie innych firm ma wpływ. |
| Pobieranie integracji | Integracja z fetch jest skomplikowana i niepotrzebna. |
Korzystanie z fetch ma swoje zalety i wady. Chcielibyśmy wprowadzić dalszą standaryzację w ekosystemie sieci, ale uważamy, że jest za wcześnie na wprowadzenie tej zmiany, dopóki nie będziemy mieć wyraźniejszego pojęcia, jak ten standard powinien wyglądać. Jeśli i gdy pojawi się standard, będziemy też odpowiedzialnie pomagać twórcom stron internetowych w przechodzeniu na ten standard. |
| Lokalizacja zapisu | Konfiguracje kluczy tokenów stanu prywatnego powinny być przechowywane w tej samej lokalizacji co protokół PrivacyPass. | Podczas testów w ramach próbnego wdrożenia Origin deweloperzy wskazali, że wolą mieć możliwość przechowywania kluczy w ogólnych adresach URL zamiast w znanym katalogu. Format zobowiązania klucza w PrivacyPass nie jest szczególnie odpowiedni w przypadku wersji, w której zestawy kluczy mają umożliwiać użycie domyślnej wartości „publiczne metadane”. Jeśli wariant PrivacyPass zostanie znormalizowany z publicznymi metadanymi (jako POPRF, częściowe zaciemnianie RSA lub zestawy kluczy), możemy przejść na przyszłą wersję PST, aby to umożliwić. |
| Implementacja interfejsu API w nagłówku | Pytania dotyczące implementacji nagłówka interfejsu API | W miarę standaryzacji interfejsu API i rozwoju ekosystemu, w którym jest on używany, będziemy mogli obsługiwać standardową wersję bez nagłówka i potencjalnie wycofać wersję z nagłówkiem, jeśli jej użycie będzie rzadkie lub jeśli dostępne będą wystarczające narzędzia dla deweloperów i wsparcie dla standardowych sposobów korelacji żądań emisji i realizacji z innymi danymi. Tutaj omawiamy ten problem. |
| Rejestracja | Czy żądanie od emitentów rejestracji u dostawców przeglądarek jest praktyczne? | Zaktualizowaliśmy specyfikację, aby opisać proces rejestracji wydawcy tokenów prywatności. Chociaż ma on swój własny proces, jest podobny do planów rejestracji w przypadku pozostałych elementów Piaskownicy prywatności. W ramach tych planów prosimy podmioty wydające o upublicznieniu informacji o tym, jak zamierzają używać PST, oraz o zaakceptowanie ograniczeń technicznych, które chronią prywatność użytkowników. |