Эта страница переведена с помощью Cloud Translation API.

Отчет об обратной связи - 4 квартал 2022 г.
bookmark_border Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Ежеквартальный отчет за четвертый квартал 2022 года, в котором суммируются отзывы экосистемы, полученные по предложениям Privacy Sandbox, и ответ Chrome.

В рамках своих обязательств перед CMA Google согласилась публично предоставлять ежеквартальные отчеты о процессе взаимодействия с заинтересованными сторонами для своих предложений Privacy Sandbox (см. пункты 12 и 17(c)(ii) Обязательств ). Эти сводные отчеты об отзывах Privacy Sandbox создаются путем объединения отзывов, полученных Chrome из различных источников, перечисленных в обзоре отзывов , включая, помимо прочего: «Проблемы GitHub», форму обратной связи, доступную на сайте Privacysandbox.com , встречи с заинтересованными сторонами отрасли и форумы по веб-стандартам. Chrome приветствует отзывы, полученные от экосистемы, и активно изучает способы интеграции полученных знаний в дизайнерские решения.

Темы отзывов ранжируются по распространенности каждого API. Это делается путем агрегирования количества отзывов, полученных командой Chrome по заданной теме, и их упорядочения в порядке убывания количества. Общие темы обратной связи были определены путем анализа тем обсуждений на публичных собраниях (W3C, PatCG, IETF), прямой обратной связи, GitHub и часто задаваемых вопросов, возникающих во внутренних группах Google и в общедоступных формах.

В частности, были проанализированы протоколы совещаний органов по веб-стандартам, а для прямой обратной связи были рассмотрены записи Google о встречах заинтересованных сторон один на один, электронные письма, полученные отдельными инженерами, список рассылки API и публичная форма обратной связи. Затем Google координировал действия команд, участвующих в различных информационно-просветительских мероприятиях, чтобы определить относительную распространенность тем, возникающих в отношении каждого API.

Объяснения ответов Chrome на отзывы были разработаны на основе опубликованных часто задаваемых вопросов, реальных ответов на вопросы, поднятые заинтересованными сторонами, и определения позиции специально для целей этой публичной отчетности. Отражая текущую направленность разработки и тестирования, были получены вопросы и отзывы, в частности, в отношении API-интерфейсов Topics, Fledge и Attribution Reporting.

На отзыв, полученный после окончания текущего отчетного периода, Chrome может еще не ответить.

Глоссарий сокращений

ЧИПСЫ: Файлы cookie, имеющие независимое разделенное состояние
ЦСП: Платформа спроса
ФедКМ: Федеративное управление учетными данными
ФПС: Наборы для первой вечеринки
IAB: Бюро интерактивной рекламы
ВПЛ: Поставщик удостоверений
IETF: Целевая группа по интернет-инжинирингу
ИП: Адрес интернет-протокола
openRTB: Ставки в реальном времени
ОТ: Исходная пробная версия
ПатКГ: Группа сообщества частных рекламных технологий
РП: Доверяющая сторона
ССП: Платформа предложения
ТРОЙНИК: Доверенная среда выполнения
UA: Строка пользовательского агента
UA-CH: Подсказки для клиента User-Agent
W3C: Консорциум Всемирной паутины
ВИПБ: Умышленная IP-слепота

Общий отзыв, без конкретного API/технологии

Тема обратной связи	Краткое содержание	Ответ Chrome
(Также сообщалось в третьем квартале) Полезность для разных типов заинтересованных сторон	Обеспокоенность тем, что технологии Privacy Sandbox отдают предпочтение более крупным разработчикам и что нишевые (меньшие) сайты приносят больший вклад, чем обычные (более крупные) сайты.	Наш ответ не изменился по сравнению с третьим вопросом: «Google обязалась перед CMA разработать и реализовать предложения Privacy Sandbox таким образом, чтобы не искажать конкуренцию за счет личного предпочтения собственного бизнеса Google, а также учитывать влияние на конкуренцию в цифровой рекламе, а также на издателей и рекламодателей, независимо от их размера. Мы продолжаем тесно сотрудничать с CMA, чтобы гарантировать, что наша работа соответствует этим обязательствам. По мере продвижения тестирования Privacy Sandbox одним из ключевых вопросов, которые мы будем оценивать, является то, как новые технологии работают для различных типов заинтересованных сторон. В этом отношении решающее значение имеет обратная связь, особенно конкретная и действенная обратная связь, которая может помочь нам в дальнейшем улучшать технические проекты. Мы работали с CMA над разработкой нашего подхода к количественному тестированию и поддерживаем публикацию CMA заметки о планировании эксперимента, чтобы предоставить участникам рынка больше информации и возможность прокомментировать предлагаемые подходы».
(Также сообщалось в третьем квартале) Запросы документации	Запросы на дополнительные ресурсы с подробным описанием управления тестированием, анализом и внедрением.	Обновление четвертого квартала: Мы ценим, что разработчики нашли наш текущий материал полезным, и продолжаем предоставлять больше материалов, чтобы разработчики могли понять, как новые технологии могут работать на них. За последний квартал мы добавили раздел «Новости и обновления» на сайт Privacysandbox.com и опубликовали обширный обзор того, как Privacy Sandbox может помочь повысить релевантность рекламы в будущем. Мы также проводили общедоступные рабочие встречи для разработчиков, чтобы поделиться лучшими практиками и демонстрациями, а также сеансы вопросов и ответов с руководителями продуктов и инженеров, чтобы обеспечить живое обсуждение/вопросы.
Основные веб-показатели	Как задержка Privacy Sandbox API влияет на основные веб-показатели?	Сведение задержки к минимуму — ключевая цель разработки API-интерфейсов Privacy Sandbox. В настоящее время мы ожидаем, что задержка API должна оказывать минимальное влияние на основные веб-показатели сайта, поскольку большинство API вызываются после первоначального рендеринга веб-сайта. Мы продолжаем отслеживать и вносить улучшения, чтобы еще больше сократить задержку для каждого из API, а также поощряем постоянное тестирование и обратную связь. Задержка в процессе торгов в реальном времени рассматривается в разделе FLEDGE в разделе «Производительность аукционов FLEDGE».
Совместимость	Опасения по поводу совместимости с другими потенциальными решениями	Цель Privacy Sandbox — защитить пользователей от межсайтового отслеживания, одновременно поддерживая потребности веб-экосистемы. Мы стремимся добиться этого, отходя от устаревших технологий браузера, которые позволяют такое межсайтовое отслеживание, таких как сторонние файлы cookie, и предоставляя вместо них новые технологии, специально созданные для поддержки конкретных случаев использования. Предложения Privacy Sandbox улучшают конфиденциальность, ограничивая данные, покидающие устройство пользователя. Предложения не накладывают технических ограничений на возможность веб-сайта делиться или иным образом обрабатывать данные, полученные из браузера. Таким образом, технологии не препятствуют компаниям заключать соглашения об «управлении данными» или любые другие подобные договорные отношения. Аналогичным образом, они не ограничивают возможность пользователей давать согласие на передачу своих данных другими способами. Для ясности: Google обязался применять технологии Privacy Sandbox одинаковым образом ко всем веб-сайтам, включая продукты и услуги Google. После того, как Chrome прекратит поддержку сторонних файлов cookie, в обязательствах также будет четко указано, что Google не будет использовать другие личные данные, такие как синхронизированная история посещений Chrome, для отслеживания пользователей с целью таргетинга или измерения цифровой рекламы.

Показывайте релевантный контент и рекламу

Темы

Тема обратной связи	Краткое содержание	Ответ Chrome
Влияние на рейтинг в поиске Google	Запрос о том, будет ли поддержка API тем веб-сайта использоваться в качестве потенциального сигнала для ранжирования в результатах поиска Google.	Некоторые веб-сайты могут отказаться от использования Topics API. Команда Privacy Sandbox не координировала и не просила поисковую организацию использовать рейтинг страниц в качестве стимула для веб-сайтов к внедрению API тем. Google подтвердил CMA, что Google Search не будет использовать решение сайта об отказе от API тем в качестве сигнала ранжирования.
Классификатор тем	Добавьте URL-адрес и содержимое страницы в дополнение к имени хоста, чтобы определить тему веб-страницы и повысить ее полезность для различных заинтересованных сторон.	История просмотров пользователя в настоящее время классифицируется по именам хостов веб-сайта. Chrome продолжает оценивать варианты учета метаданных уровня страницы (например, всех или некоторых компонентов URL-адреса страницы и/или контента) при классификации тем. Любые улучшения коммунальных услуг должны быть сопоставлены с рисками конфиденциальности и злоупотреблений. Например, что касается метаданных, в частности, некоторые риски включают в себя: - Сайты, изменяющие метаданные на уровне страницы как метод кодирования различных (и потенциально конфиденциальных) значений в темы; - Сайты, изменяющие метаданные на уровне страниц, чтобы искажать свои темы ради финансовой выгоды; – Сайты динамически изменяют метаданные на уровне страницы в качестве метода межсайтового отслеживания.
(Также сообщалось в третьем квартале) Влияние на собственные сигналы	Сигнал тем может быть очень ценным и в результате обесценивает другие сигналы, основанные на интересах.	Наш ответ не изменился по сравнению с третьим вопросом: «Мы считаем, что реклама на основе интересов является важным вариантом использования в Интернете, и Topics предназначен для поддержки этого варианта использования. Как описано [в нашем отчете за третий квартал], другие заинтересованные стороны экосистемы выразили обеспокоенность тем, что Topics может быть недостаточно полезным, чтобы обеспечить ценность. Во всех случаях улучшения таксономии являются постоянными усилиями, и мы ожидаем, что таксономия будет развиваться по мере тестирования экосистемы и ввода данных».
Обновление таксономии	Как будет обновляться список таксономий?	Мы активно ищем отзывы о таксономии , которая была бы наиболее полезна для экосистемы. Таксономия, включенная в первоначальное предложение Topics API, была разработана для обеспечения возможности функционального тестирования. Chrome активно рассматривает несколько подходов к обновлению таксономии. Например, Chrome может использовать понятие коммерческой ценности для каждой темы, чтобы определить, какую категорию включить в будущие итерации.
Производительность регионального классификатора тем	Классификатор тем плохо работает в региональных доменах	Улучшение классификатора является постоянной работой. Основываясь на полученных нами отзывах, мы рассматриваем одну из возможностей — расширить список переопределенных тем, что, как показывает наш анализ, увеличит глобальный охват и повысит точность. Поясним, что классификация Topics API состоит из двух важных компонентов: (1) список переопределения, содержащий 10 тысяч самых популярных сайтов и их темы, и (2) модель машинного обучения на устройстве, которая классифицирует имена хостов по темам. Расширяя список переопределений (1), мы можем улучшить производительность классификации для тех регионов, в которых классификатор может работать плохо.
Эпоха одной недели	Недельный период слишком длинный для пользователей, желающих принимать краткосрочные решения.	Мы активно изучаем, какой должна быть подходящая продолжительность эпохи, и приветствуем дальнейшие отзывы о том, какая эпоха будет лучшей для экосистемы.
Получение HTTP-заголовка	Обеспокоенность тем, что недостаточно информации о получении тем по HTTP-заголовку.	Ведётся работа над заголовками и fetch(). У нас также есть информация здесь . Мы также добавили в объяснитель информацию о пропуске наблюдения .
Темы предназначены только для помощи рекламодателям, а не пользователям.	Темы/Privacy Sandbox, похоже, представляют собой подход, ориентированный на отрасль. Выгода для пользователей не так очевидна, как выгода для промышленности.	Мы считаем, что преимущество для пользователей заключается в том, что Topics поддерживает рекламу на основе интересов, которая делает Интернет свободным и открытым, а также мы считаем, что это значительно улучшает конфиденциальность по сравнению со сторонними файлами cookie. Удаление сторонних файлов cookie без реальных альтернатив может негативно повлиять на издателей и привести к худшим подходам. которые менее конфиденциальны, непрозрачны и не могут быть сброшены или контролируемы пользователями. Многие компании активно тестируют API-интерфейсы Topics и Sandbox, и мы стремимся предоставить инструменты для повышения конфиденциальности и поддержки Интернета. Группа технической архитектуры W3C недавно опубликовала свое первоначальное мнение о Topics API, на которое мы будем публично отвечать. На данном этапе, поскольку Google получил вопросы от представителей экосистемы о том, что этот обзор может означать для разработки и запуска API Topics, мы хотели бы подтвердить наш план сделать его доступным в Chrome Stable в этом году. Хотя компания Google ценит вклад группы технической архитектуры W3C, она считает крайне важным продолжать усилия по разработке и тестированию тем в консультации с CMA и экосистемой.
Утечка данных	Обеспокоенность тем, что темы могут быть переданы на другие сайты без разрешения.	Конструкция API тем делает маловероятной утечку данных от одного издателя (и даже от небольшой группы издателей). Веб-сайты издателей также полностью контролируют API тем и могут запретить доступ к этому API с помощью политики разрешений.
Отсутствие рекламодателей для тестирования	Издатели обеспокоены тем, что в настоящее время они не могут продемонстрировать рекламодателям ценность тем.	Во второй половине 2023 года мы планируем предоставить все API, связанные с рекламой, для интеграционного тестирования и включить экосистемный анализ ценности тем для рекламодателей. Тестирование и публикация результатов будут контролироваться CMA, который рассмотрит данные, анализ и методологию. Экосистеме рекомендуется делиться отзывами с Google и CMA.
Темы и FLEDGE	Запросите дополнительную информацию об использовании тем в логике назначения ставок FLEDGE.	Темы можно использовать в логике торгов FLEDGE . Руководство по интеграции также находится в разработке и будет включать дополнительную информацию о реализации.
Пользовательский рейтинг для звонящего по темам	Разрешить настройку рейтинга в зависимости от звонящего	Проблема с пользовательским ранжированием тем или значениями для каждой рекламной технологии заключается в том, что это может стать механизмом, с помощью которого рекламная технология может влиять на возвращаемые темы, то есть вектором снятия отпечатков пальцев.
Список приоритетов звонящих по темам	Разрешить вызывающим абонентам предоставлять ранжированный список тем по приоритету, который API тем будет возвращать в зависимости от соответствия критериям.	В настоящее время мы обсуждаем эту идею дальше и будем рады дополнительным предложениям.

ФЛЕДЖ

Тема обратной связи	Краткое содержание	Ответ Chrome
Google Менеджер рекламы	Обеспокоенность тем, что Google Ad Manager является решающим фактором для аукционов FLEDGE и будет отдавать предпочтение Google Publisher Tag и Google Ad Manager.	FLEDGE позволяет каждому издателю выбирать структуру аукциона, включая выбор продавцов верхнего уровня и компонентов. Каждый покупатель и продавец на аукционе компонентов знает, кто является продавцом верхнего уровня, и может выбирать, делать ставку или нет.
Недостаточное количество участников, тестирующих FLEDGE	Просьба побудить больше компаний протестировать FLEDGE, например, улучшая функциональность API и препятствуя альтернативам, нарушающим конфиденциальность, таким как снятие отпечатков пальцев.	Privacy Sandbox создается поэтапно в тесном сотрудничестве с руководством CMA и ICO, а функциональное тестирование FLEDGE продемонстрировало необходимую стабильность и возможности. Google продолжает поощрять экосистему к тестированию API-интерфейсов «песочницы», недавно опубликовав документацию « Максимизация релевантности рекламы », чтобы продемонстрировать, как FLEDGE и другие API могут помочь в поддержке критически важных сценариев использования для рекламной индустрии после прекращения поддержки сторонних файлов cookie. Другие части Privacy Sandbox уже поддерживают меры по смягчению последствий отслеживания (см. UA-CH, защита IP и меры по снижению отслеживания отказов) и со временем будут продолжать улучшаться. Цель Google не состоит в том, чтобы сделать FLEDGE единственным жизнеспособным решением для таргетинга, а вместо этого по-прежнему привержена работе в партнерстве с отраслью и регулирующими органами для внедрения лучших рекламных технологий, сохраняющих конфиденциальность, в браузере Chrome.
Варианты использования машинного обучения	Дополнительные рекомендации о том, как варианты использования машинного обучения для обучения алгоритмам аукционных ставок будут поддерживаться в FLEDGE и отчетах по атрибуции.	Мы признаем необходимость помочь тестировщикам найти наиболее полезные способы применения технологий Privacy Sandbox. Мы начали публиковать рекомендации, посвященные использованию различных аспектов API Privacy Sandbox в качестве входных данных для машинного обучения. В самой последней статье «Максимизация релевантности рекламы » обсуждается, как рекламная индустрия может использовать эти сигналы для машинного обучения, и мы планируем продолжать публиковать такие рекомендации в будущем.
Запрос сервера ключевого значения (K/V) FLEDGE	Почему сервер K/V доступен для публичного запроса?	Целью сервера K/V является предоставление сигналов на аукционы FLEDGE в режиме реального времени. Таким образом, сервер K/V должен быть доступен там, где проводятся аукционы FLEDGE, то есть на пользовательских устройствах, что требует, чтобы он был общедоступным. Значение, хранящееся на сервере K/V, может быть получено только той стороной, у которой уже есть его ключ — поэтому, если рекламная технология предоставляет ключи только браузерам, входящим в группу интересов, и не использует ключи, которые можно угадать случайным образом, то только те браузеры, которым это значение необходимо для проведения аукциона, смогут получить его.
Как настроить таргетинг на дату/время?	Поддержка объектов даты в функции логики ставок.	Есть несколько способов сделать это. Покупатели могут попросить своего продавца предоставить текущую дату и время, и продавцам должно быть легко предоставить эту информацию всем покупателям. Покупатели также могут указать дату и время в своем ответе «ключ-значение» в режиме реального времени. Наконец, покупатели могут указать дату и время как часть своего контекстного ответа в per-buyer-signals , который продавец может передать в скрипт GenerateBid покупателя.
Пользовательские настройки	Возможность для пользователей блокировать креативы рекламодателя при их показе через FLEDGE или альтернативные решения.	Пользователи имеют возможность отказаться от использования рекламных API в Chrome. Для конкретных объявлений соответствующая рекламная технология лучше всего обеспечивает контроль над тем, какие креативы показываются и как они выбираются.
Более четкие сроки	Запросите дополнительную информацию о наличии средств защиты конфиденциальности в FLEDGE, таких как требование Fenced Frames.	Мы планируем опубликовать более подробные сроки в первом квартале.
Сообщение о путанице	Запросите дополнительную информацию о том, как отчеты FLEDGE будут работать с другими API, такими как Fenced Frames и Private Aggregation API.	В ближайшие недели мы планируем опубликовать объяснение взаимодействия API частного агрегирования, FLEDGE и Fenced Frames.
Ставки в реальном времени и FLEDGE	Руководство по интеграции FLEDGE со стандартными ставками в режиме реального времени.	Две основные вещи, которые усложняют способность рекламных технологий делать ставки в реальном времени, — это доступ к данным уровня событий и более простая интеграция в ARA. Мы планируем отправлять обновления и пояснения по обоим этим вопросам в первом квартале.
Результаты аукционов FLEDGE	Отчет тестировщиков о том, что аукционы FLEDGE имеют большую задержку	Мы ценим отчеты тестировщиков, которые делятся своими результатами и примерами использования, а также поделились некоторыми предложениями о том, как улучшить производительность FLEDGE . Параллельно мы добавили в браузер инструменты, позволяющие разработчикам лучше диагностировать причины замедления аукционов , и систематически устраняем основные причины наблюдаемых задержек. Недавние улучшения включают в себя тайм-ауты для медленных аукционов , технику быстрой фильтрации участников торгов , способ повторного использования рабочих модулей FLEDGE, чтобы избежать затрат на запуск , а также текущую работу, позволяющую запускать запрос контекстной рекламы параллельно со временем запуска FLEDGE и выборками сети. Мы ожидаем, что оптимизация задержки продолжится как постоянный диалог между разработчиками Chrome и тестировщиками FLEDGE, основанный на их реальном опыте использования API.
Ограничение памяти на размер группы по интересам	Просьба поднять лимит размера одной группы по интересам с 50Кб.	Мы активно рассматриваем запрос и ждем отзывов о том, какое значение лимита работает .
Объединение данных, обслуживаемых FLEDGE, с собственными файлами cookie	Будет ли FLEDGE поддерживать интеграцию с собственными данными рекламодателя?	FLEDGE был создан для поддержки рекламы с использованием собственных данных, которые уже есть у рекламодателя. Однако FLEDGE не намерен поддерживать рекламодателя в изучении поведения пользователя на каком-либо веб-сайте, кроме собственного сайта рекламодателя. Привязка поведения при просмотре за пределами сайта к собственным данным противоречит целям Privacy Sandbox. В ближайшие недели мы планируем поделиться руководствами по интеграции с более подробной информацией о том, как FLEDGE будет поддерживать интеграцию с собственными данными.
Значение K-анонимности	Как будет определяться соотношение «К» и «к-анон» и будет ли оно опубликовано?	Значение «K» все еще уточняется, и мы будем делиться дополнительной информацией по мере развития наших планов. Мы заинтересованы в получении дополнительной информации о том, как неизвестное значение k может препятствовать подготовке FLEDGE и определению объема обучения модели ML, и мы приветствуем дополнительные отзывы по этому вопросу.
Поддержка нескольких SSP	Как в FLEDGE будет поддерживаться несколько SSP?	FLEDGE поддерживает аукционы с участием нескольких продавцов, как указано в этом предложении .
Видимость логики назначения ставок	Обеспокоенность тем, что логика назначения ставок DSP будет раскрыта в JavaScript.	При нынешней логике назначения ставок по дизайну другие могут получить доступ к JavaScript, но мы приветствуем дополнительные отзывы о том, почему это может быть источником беспокойства для DSP.
prebid.js	Каковы сроки поддержки prebid.js в FLEDGE?	Только версии Prebid.js 7.14 и более поздние поддерживают модуль FLEDGE. Любые издатели, заинтересованные в тестировании, должны добавить модуль FLEDGE и обновить свой экземпляр Prebid.
Пользовательские функции в FLEDGE	Как в FLEDGE будут поддерживаться пользовательские функции (UDF)? Это функции, которые конечные пользователи могут запрограммировать для расширения функциональности API.	Объяснение доступно здесь . Этот вопрос все еще находится в разработке, поэтому мы приветствуем дополнительные отзывы о вариантах использования.
Ослабление ограничения одинакового происхождения для ресурсов группы по интересам	Просьба ослабить ограничение одного и того же происхождения для ресурсов групп по интересам, чтобы обеспечить определенные варианты использования рекламных технологий.	В текущей реализации FLEDGE `biddingLogicUrl` , `biddingWasmHelperUrl` , `dailyUpdateUrl` `trustedBiddingSignalsUrl` должны иметь то же происхождение, что и владелец группы интересов. Ограничение существует для предотвращения определенных эксплойтов злоумышленников, как описано здесь .
интересГрупповая собственность	Запрос на ограничение того, может ли рекламный технический специалист использовать joinInterestGroup для одних и тех же групп по интересам на разных сайтах.	Наше внимание сосредоточено на том, как используется аудитория, а не на том, как она формируется. Мы обсуждаем потенциальные подходы и приветствуем дополнительные предложения.
Срок действия ключа сервера значения ключа	Обсуждение удаления ключей сервера после истечения срока действия соответствующих групп интересов.	Мы изучаем способы решения проблемы истечения срока действия ключей и ждем отзывов .

Измерение цифровой рекламы

Отчеты по атрибуции (и другие API)

Тема обратной связи	Краткое содержание	Ответ Chrome
Пробный трафик Origin	Текущего трафика Origin Trial недостаточно для проведения тестирования утилиты.	Текущие пробные версии Origin предназначены для того, чтобы игроки экосистемы могли провести функциональное тестирование, чтобы убедиться, что API работает должным образом. Мы понимаем, что после того, как разработка различных API Privacy Sandbox станет более зрелой, для тестирования утилит потребуются большие объемы трафика. Текущий график тестирования предусматривает, что это произойдет к моменту общедоступности (т. е. когда технологии для вариантов использования будут запущены и доступны для 100 % трафика Chrome) в третьем квартале 2023 года (см. наш обновленный график на сайте Privacysandbox.com ). Мы приветствуем любые дополнительные отзывы о тестировании вариантов использования, требующих дополнительного трафика.
Перекрытие функций различных API измерения Privacy Sandbox	Опасения по поводу дублирования нескольких подходов к измерению в Privacy Sandbox усложнят работу, например, API отчетов по атрибуции и API частного агрегирования.	Мы работаем над улучшением документации, чтобы прояснить различные варианты использования API, и приветствуем дополнительные отзывы о том, в каких областях отсутствуют объяснения. Например, API Attribution Reporting предназначен специально для поддержки измерения конверсий, тогда как Private Aggregation API и Shared Storage — это API общего назначения, предназначенные для поддержки более широкого спектра вариантов использования межсайтового измерения.
Повторить неудачный запрос отчета	Разъяснение о том, сколько раз запрос отчета предпринимается в случае неудачи.	Мы опубликовали руководство по этому поводу . Подводя итог, отчеты отправляются только тогда, когда браузер работает/онлайн. После первой неудачной отправки отчет повторяется через 5 минут. После второго сбоя отчет повторяется через 15 минут. После этого отчет не отправляется.
Отчет о задержке	Какова ожидаемая задержка отчетности?	Мы надеемся услышать больше отзывов от экосистемы о любых задержках с отчетами, с которыми они сталкиваются, поскольку мы собираем данные для дальнейшей параллельной оценки этих задержек.
Страницы пререндера	Будет ли атрибуция ARA работать на страницах предварительной визуализации?	Регистрация атрибуции на страницах предварительной визуализации откладывается до момента активации (происходит фактическое нажатие или просмотр). Это означает, что мы отложим проверку связи с запросом attributionsrc.
Измерение роста конверсии	Как измерить рост конверсии с помощью AB-тестирования в том же домене	Веб-сайты могут измерять рост конверсии с помощью A/B-тестирования в том же домене с помощью отчетов атрибуции. Они могут кодировать свои параметры A/B в виде ключей с помощью агрегатного API, а затем получать сводные отчеты о значениях конверсий по этим ключевым сегментам.
(Также сообщалось в третьем квартале) Междоменные конверсии	Как отслеживать междоменные конверсии, например с двумя или более целевыми площадками	Обновление четвертого квартала: Мы опубликовали предложение снять ограничение на целевую страницу, которое позволяет отслеживать междоменные разговоры. Это предложение было реализовано.
(Также сообщалось в третьем квартале) Настройка срока действия в отчете о конверсиях	Запрос на поддержку фильтра отчетов / срок действия менее 24 часов	Обновление четвертого квартала: Мы поделились этим запросом на включение , который позволит разделить периоды истечения срока действия и окна отчетности, чтобы смягчить компромисс между задержкой отчетности и сроком действия конверсии. Теперь это запущено в M110.
Мошенничество и злоупотребления	Запросы от рекламодателей и маркетологов на возможность фрагментировать и агрегировать данные на основе сайтов издателей, на которых показывается их реклама, что также позволит лучше понять потенциальные мошеннические методы размещения рекламы.	Эта обратная связь активно обсуждается здесь, и мы приветствуем дополнительные мнения.
(Также сообщается в третьем квартале) Задержка отчетности на уровне событий	Задержка в 2–30 дней при предоставлении отчетов на уровне событий может оказаться слишком продолжительной для некоторых случаев использования.	Отчеты на уровне событий имеют окна отчетов по умолчанию, составляющие 2, 7 и 30 дней. Это можно изменить с помощью параметра «expiry». Специалисты по рекламе могут настроить срок действия минимум на 1 день, чтобы получать потенциальные отчеты менее чем за 2 дня. Мы ограничиваем детализацию срока действия до 1 дня в качестве механизма защиты конфиденциальности, поскольку более детальная отчетность может привести к атакам по времени. Кроме того, мы разрешаем устанавливать независимые параметры «срока действия» для уровня событий и сводных отчетов. Смотрите здесь . Кроме того, Google Ads не получит никаких специальных окон отчетности, которые другие рекламные технологии не получают через API отчетов по атрибуции.
То же требование к источнику отчетности	Запрос на удаление требования, чтобы источник регистрации источника совпадал с источником регистрации конверсии.	Мы предлагаем использовать перенаправление HTTP для делегирования регистрации, чтобы решить эту проблему. Мы приветствуем любые дополнительные отзывы о новом руководстве.
Отслеживание конверсий	Необходимо определить, произошла ли конверсия до или после определенных часов, установленных рекламодателем.	API отчетов об атрибуции поддерживает установку срока действия и приоритета для атрибуции источника. Используя оба варианта, технически можно будет отнести конверсию, произошедшую в течение Х дней, отдельно от конверсии, произошедшей после Х.
Имитация шума	Запросите возможность смоделировать различное количество конверсий в каждом сегменте, чтобы понять влияние на рекламодателей с меньшим количеством конверсий.	Мы планируем добавить способы симуляции этого в будущих версиях Noise Lab . Мы приветствуем любые дополнительные отзывы.
Отчетность на мобильном телефоне	Будет ли отчет по-прежнему отправляться, когда Chrome работает в фоновом режиме на мобильном устройстве?	На данный момент даже на мобильных устройствах отчет не будет отправлен, когда Chrome находится в фоновом режиме. Вероятно, ситуация изменится, когда API будет интегрирован с Android Privacy Sandbox. Смотрите здесь . Обратите внимание, что Android Privacy Sandbox не является частью Обязательств, принятых CMA.
Доступность данных	Опасения, что Google получит дополнительный доступ к данным через API Privacy Sandbox.	Во-первых, Google Реклама не получает какого-либо привилегированного доступа к данным из API отчетов об атрибуции или других API-интерфейсов Privacy Sandbox. Эта проблема также рассматривается в разделе «Общие отзывы» в разделе «Взаимодействие», где содержится более подробная информация об обязательствах Google. Во-вторых, говоря о разнице между большими и меньшими сайтами, Google признает, что защита конфиденциальности, основанная на шуме, может оказывать большее влияние на меньшие фрагменты данных. Однако есть некоторые возможные способы смягчения последствий: например, такие методы, как агрегирование за более длительные периоды времени, могли бы решить эту проблему. Тем не менее, остается неясным, имеют ли вообще смысл для рекламодателей выводы, основанные на очень небольших фрагментах данных (например, одной или двух покупках). Во время первоначального испытания Google призвал тестировщиков воспользоваться возможностью экспериментировать с широким диапазоном параметров конфиденциальности и шума, чтобы они могли предоставить более конкретную обратную связь по этой проблеме.

Ограничить скрытое отслеживание

Сокращение пользовательского агента

Тема обратной связи	Краткое содержание	Ответ Chrome
Отложить сокращение количества пользовательских агентов до тех пор, пока веб-экосистема не станет более готовой.	Недостаточно времени, чтобы адаптироваться к предстоящим изменениям в сокращении количества пользовательских агентов.	Мы рассматриваем этот отзыв в полном отчете в разделе «Проблемы заинтересованных сторон» в разделе «Взаимодействие Google с CMA».
Отложить сокращение количества пользовательских агентов до тех пор, пока веб-экосистема не станет более готовой.	Запрос на отсрочку развертывания User-Agent Reduction до тех пор, пока не будут развернуты структурированные пользовательские агенты (SUA).	Команда Google Ads предложила добавить в OpenRTB структурированный пользовательский агент (см. спецификацию ) в октябре 2021 года, и оно было включено в обновление спецификации 2.6, выпущенное в апреле 2022 года. У нас есть некоторые свидетельства того, что SUA развернут и доступен уже сегодня, о чем свидетельствует запись в блоге Scientia Mobile, демонстрирующая, как использовать UA-CH и WURFL API для создания SUA.

###

Подсказки для клиента User-Agent

Тема обратной связи	Краткое содержание	Ответ Chrome
Протестируйте UA-CH с другими методами защиты от скрытого отслеживания.	Руководство по тестированию всех API-интерфейсов Privacy Sandbox и методов снятия отпечатков пальцев, предлагаемых вместе, в комплексном подходе.	Наш план тестирования был разработан таким образом, чтобы отразить асинхронные сроки разработки некоторых мер по борьбе со сбором отпечатков пальцев, в отличие от остальных предложений «песочницы». Он учитывает тот факт, что некоторые меры по борьбе со сбором отпечатков пальцев (например, бюджет конфиденциальности, защита интеллектуальной собственности и смягчение последствий отслеживания отказов) будут полностью разработаны и готовы к общедоступному выпуску только после прекращения поддержки сторонних файлов cookie. Хотя эти меры по борьбе со сбором отпечатков пальцев не будут включены в количественные тесты, они будут подвергаться качественной оценке на основе фактов, доступных на момент остановки.
(Также сообщалось во втором квартале) Производительность	Опасения по поводу задержки получения подсказок через Critical-CH (при первой загрузке страницы).	См. специальный раздел UA-CH ниже.
Недостаточная обратная связь	Обратная связь от экосистемы об изменении UA-CH может быть недостаточной, что приводит к опасениям по поводу недостаточной осведомленности экосистемы.	Мы активно делились нашими планами, чтобы обеспечить тщательное развертывание и свести к минимуму сбои. Планы по сокращению числа пользовательских агентов и API UA-CH были представлены группе сообщества W3C по борьбе с мошенничеством 18 марта 2022 г., а также рабочей группе по веб-платежам и группе по вопросам безопасности веб-платежей 20 января 2022 г. Никаких серьезных опасений ни во время, ни после презентаций не возникло. Google активно сотрудничает с более чем 100 операторами сайтов, чтобы получить отзывы. Кроме того, Google также использовал каналы Blink-Dev для публичного информирования о сокращении количества пользовательских агентов на основе отзывов заинтересованных сторон экосистемы.
Тайминг	Высказаны опасения относительно сроков развертывания и готовности отрасли.	См. специальный раздел UA-CH ниже.
Статус платформы Chrome	Попросили обновить страницу Chromestatus для UA-CH	Запись Chromestatus была обновлена 19 декабря для «смешанных сигналов».

Защита от IP (ранее Gnatcatcher)

Тема обратной связи	Краткое содержание	Хромированный ответ
Выбирать или отказаться	Является ли IP -адрес конфиденциальности внедрять или отказаться?	Наша цель - обеспечить защиту от IP всем пользователям. Имея в виду эту цель, в настоящее время мы оцениваем варианты выбора пользователя для защиты от IP.
Использование IP-адреса для первых данных	Можно ли использовать IP-адреса для сшивания поездок пользователей в первых доменах после защиты от IP?	Как опубликовано ранее, защита IP изначально сосредоточена на отслеживании в стороннем контексте, что означает, что первые домены не будут затронуты.
Акции использования рекламных технологий	Как компании могут организовать меры по защите от мошенничества с защитой от ИС?	Мы признаем важность IP-адреса в качестве сигнала для усилий по борьбе с мошенничеством в современной сети. В рамках наших обязательств перед CMA (пункт 20) мы сказали, что не будем реализовать защиту от ИС, не прилагаем разумных усилий по поддержке способности веб-сайтов проводить усилия по борьбе с спамами и против мошенничества. Одним из наших главных приоритетов является понимание того, как защита от IP влияет на варианты использования против мошенничества и возможности обнаружения, чтобы мы могли дополнительно инвестировать в технологии сохранения конфиденциальности, которые помогают компаниям сохранить безопасность веб-сайта. Мы поощряем обратную связь и вклад в новые предложения, направленные на поддержку потребностей компаний безопасности и антизрели, даже когда сигналы меняются с течением времени.
Мошенничество и злоупотребление	Включает ли защита IP -защиты отказа в обслуживании (DOS) защиту?	Мы стремимся к повышению конфиденциальности при обеспечении безопасности Интернета, а защита от атак отказа в службе услуги является важным вариантом использования против злоупотребления для проектирования. Мы надеемся минимизировать влияние на защиту DOS как посредством проектирования самой защиты от IP, так и посредством новых решений по борьбе с злоупотреблением. Поскольку защита IP изначально ориентирована на сторонние встроенные услуги, некоторые заинтересованные стороны указали, что она должна оказывать ограниченное влияние на защиту DOS на участки первых. Тем не менее, мы продолжаем просить общедоступной обратной связи , чтобы оценить риск для вариантов использования DOS, особенно для сторонних встроенных услуг. Параллельно мы исследуем механизмы обратной связи и блокировки клиентов, которые позволят сайту или службе блокировать пользователя спам-спам, не идентифицируя пользователя.
Фильтрация контента	Фильтрация контента с защитой от IP	Различные компании имеют разные потребности в отношении фильтрации контента и настройки пользовательского опыта. Многие такие варианты использования в настоящее время не полагаются на IP -адреса и, следовательно, должны быть не влиять на защиту IP. Например, издатель, желающий адаптировать свой контент и привлечь больше участия, может использовать первые куки или сторонние куки-файлы (чипы), чтобы понять интересы пользователя и предыдущие взаимодействия с издателем. Или рекламный технологический партнер, сосредоточенный на доставке правильного объявления для правильного пользователя, может включать в себя Leled и темы, например, для обеспечения аналогичных результатов AD, как и сегодня со сторонними файлами cookie или другими технологиями отслеживания перекрестных сайтов. Мы также изучаем создание новых возможностей для обеспечения конфиденциальности в защиту IP, таких как грубая геолокация, для дальнейшей поддержки фильтрации контента, где существующие механизмы могут быть недостаточными. Мы приветствуем дополнительные отзывы о вариантах использования фильтрации контента, которые могут повлиять на защиту IP.
(Также сообщается в 3 -м квартале) Варианты использования геолокации	Защита от IP может предотвратить законные варианты использования геолокации в будущем, например, персонализация контента на основе геолокации.	Q4 Обновление: Мы работаем с заинтересованными сторонами, чтобы гарантировать, что Chrome продолжает поддерживать законные обработки использования для IP-адресов. Мы ищем обратную связь с экосистемой о гранулярности IP Geolocation здесь .

Бюджет конфиденциальности

Тема обратной связи	Краткое содержание	Хромированный ответ
Более четкая документация	Больше примеров, поэтому заинтересованные стороны могут предвидеть, как все может быть ограничено после реализации бюджета конфиденциальности	Предложение бюджета конфиденциальности все еще находится в активном обсуждении и не было реализовано ни одним браузером. Самая ранняя дата масштабированной доступности представляет собой самую раннюю дату, когда бюджет конфиденциальности может быть обеспечен. Этого не произойдет до удаления сторонних файлов cookie в 2024 году. У нас нет дополнительной документации, которой можно поделиться в данный момент. Мы поделимся дополнительной информацией о предложении, когда оно станет более завершенным. Тем временем мы приветствуем заинтересованные стороны, чтобы поделиться любыми отзывами , которые помогут в разработке предложения.

Укреплять границы конфиденциальности поперечного сайта

Первопартийные наборы

Тема обратной связи	Краткое содержание	Хромированный ответ
(Также сообщается в 3 -й квартале) предел домена	Запрос на расширение количества связанных доменов	Q4 Обновление: Мы выпустили FPS для локального тестирования, в том числе процесс отправки макета на GitHub и флаг для тестирования RSA и RSAFOR на местном уровне. Мы также организовали две открытые встречи для разработчиков на FPS, чтобы продолжать решать вопросы, касающиеся вариантов использования соответствующего подмножества. Мы призываем разработчиков проверить функциональность FPS, чтобы дать отзыв о том, как предел домена для связанного подмножества повлияет на удобство использования FPS для их вариантов использования. В WICG мы уточнили, что Chrome привержен предоставлению полезного решения, которое также рассматривает интересы пользователей. В этом духе мы будем признательны от обратной связи сообщества по конкретным вариантам использования, которые могут повлиять на предел домена, чтобы команда могла рассмотреть способы решения этих случаев использования при этом защищать конфиденциальность пользователей.
Запрос на более подробную информацию о мерах по смягчению злоупотреблений	Что произойдет, если домен добавлен в набор, на который они не согласились?	Мы опубликовали рекомендации по отправке для первых наборов здесь 2 декабря 2022 года. Как объяснено в руководящих принципах представления, любое управление настройкой изменений будет следовать и уважать процесс проверки на GitHub, включая проверку владения, что должно смягчить этот риск.
Смягчение злоупотреблений	Беспокоиться о том, что первые наборные формирования могут быть использованы	Мы рассмотрим способы расширения технических проверок для типов подмножества и активно ищем дополнительные вклад сообщества здесь .
Рекламные варианты использования	Вопросы о том, следует ли использовать наборы первых лиц для поддержки таргетинга рекламы	Мы не пытаемся поддерживать рекламу, нацеленные на использование для первых наборов, и мы рекомендуем использовать API-интерфейсы рекламы, доступные для таких вариантов использования.
(Также сообщается в третьем квартале) политика	Обеспокоенность тем, что FPS не согласуется с обязательствами CMA в отношении «применимого законодательства о защите данных» на том основании, что GDPR не налагает ограничения на количество сайтов в наборе, в то время как FPS предусматривает ограничение 3	Наш ответ неизменен с Q3: «Google продолжает принять участие в CMA для разработки и реализации предложений о песочнице конфиденциальности таким образом, чтобы не искажать конкуренцию, самостоятельно выравнивая свой бизнес Google и учитывая влияние на конкуренцию в цифровой рекламе, издателях и рекламодателях, а также влияет на конфиденциальность и соблюдение Ма, чтобы гарантировать, что наша работа соответствует этим обязательства ".
Альтернативное предложение	GDPR подтвержденные наборы	В дополнение к обратной связи, предоставленной экосистемой в предложении принять «проверенные наборы GDPR», Chrome имеет опасения по поводу следующих ограничений этого альтернативного предложения: «WARDPRADED SETS WALIDES» претендует на «соответствие» GDPR (хотя на самом деле неясно, что подразумевается под этим). Напротив, обязательства Google требуют, чтобы он учитывал «влияние на результаты конфиденциальности» в целом. В своем решении принять обязательства, CMA указывает на то, что это отличается от обязательства Google принимать во внимание «соответствие принципам защиты данных, как указано в применимом законодательстве о защите данных», что, как объясняет CMA, отражает тот факт, что Google связан применимым законодательством о защите данных, как в том виде, по мере оно применяется к обязательствам, и в целом. У нас есть проблемы с конфиденциальностью по поводу предложения, чтобы домены появлялись в нескольких наборах. Наборы первых сторон предназначены для поддержки конкретных вариантов использования, которые в настоящее время зависят от сторонних файлов cookie без обеспечения распространенного перекрестного отслеживания. Разрешение доменов присоединиться к нескольким наборам удалило бы ключевую защиту конфиденциальности, встроенную в предложение от первых сторон, без каких-либо других значимых ограничений. Valdated Set GDPR также предлагает «определить набор в качестве группы контроллеров и процессоров данных, которые имеют политику общего использования». Это аналогично требованию в нашем первоначальном предложении из первых сторонних наборов о том, что все стороны в наборе должны иметь общую политику конфиденциальности. С тех пор мы удалили это требование, основанное на сильной обратной связи от экосистемы, что выражает обеспокоенность по поводу требований, основанных на политике конфиденциальности. Например, мы слышали от издателей сайта, что поддержание общей политики конфиденциальности была невозможна из -за продукта и географических различий, среди прочих проблем, поднятых членами сообщества W3C ( 1 , 2 , 3 ). Мы считаем, что те же проблемы будут применяться к этому предложению. С тех пор, как эта альтернатива была поднята, Chrome обновил предложение первых наборов и опубликовал руководящие принципы для создания новых наборов.

О огороженные рамки API

Тема обратной связи	Краткое содержание	Хромированный ответ
Ограниченные ограничения кадров во время ОТ	Каковы текущие ограничения вокруг огороженных рам для периода испытания происхождения?	Мы работаем над документацией по ограничениям и статусу реализации и планируем поделиться им в течение первого квартала 2023 года.
Несколько объявлений в одном огороженном раме	Запрос на отображение нескольких рекламодателей в одном огороженном кадре на одном аукционе	В настоящее время этот запрос не развивается активно, но мы приветствуем дополнительные отзывы, если игроки экосистемы считают эту функцию важной.
Веб -пачки	Какие требования и поддержка запланированы для веб -пакетов с огороженными рамами?	В настоящее время у нас нет обновления о том, будет ли это требование в будущем. Любые изменения будут объявлены заранее и не будут соблюдены до выпуска сторонних печенья. Пожалуйста, смотрите этот объяснитель для текущего статуса.

Общий API хранилища

Тема обратной связи	Краткое содержание	Хромированный ответ
Общее хранилище для рекламных технологий	Неопределенность, связанная с использованием общего хранилища для сценариев использования рекламных технологий	Общее хранилище и частное API агрегации может использоваться для различных видов измерения, которые требуют измерения хранения поперечного сайта. Некоторые примеры перечислены здесь . Мы предвидим, что поставщики DSP и поставщиков решений измерения являются основным интегратором для вариантов использования рекламы.

Чипсы

Тема обратной связи	Краткое содержание	Хромированный ответ
(Также сообщается в третьем квартале) разделенное требование	Добавьте явное требование поведения для атрибута «разделенного» на первые куки.	Q4 Обновление: После обсуждений по вызовам GitHub и PrivacyCG, поведение, которое мы выровняли,-это то, что разделенные файлы cookie, установленные на первые личные файлы cookie, будут использовать ключ раздела (a, a), где «а» является сайтом верхнего уровня. Мы документируем это поведение на объяснении и спецификации.
Управление cookie	Существуют ли инструменты для управления/управления от первого или стороннего cookie?	Chrome Devtools и NetLog могут использоваться для тестирования сайтов с включенным блокировкой печенья стороннего печенья. Оба инструмента сообщают, когда файлы cookie заблокированы из -за конфигурации пользователя. Мы приветствуем отзывы о том, какие дополнительные аудиторские сайты хотели бы увидеть.

Fedcm

Тема обратной связи	Краткое содержание	Хромированный ответ
IDP требует знания RP, чтобы разрешить сеанс	Проблема, когда пользователь пытается войти в IDP Feide из двух разных RPS	Мы обсуждаем потенциальные решения этой проблемы.
Совместимость	Опасения относительно влияния FedCM на взаимосвязь между пользователями и веб -сайтами, которые они входят в использование FedCM, и «совместимость» между веб -сайтами	FedCM стремится продолжать поддержать услуги федеративной идентификации, которые в настоящее время полагаются на сторонние файлы cookie после того, как сторонние файлы cookie будут удалены из Chrome. Мы ожидаем, что FedCM будет лишь одним из вариантов, доступных для таких услуг; Поставщики идентификаций (ВПЛ) и полагаться на стороны (RPS) могут свободно использовать другие технологии, которые могут лучше соответствовать их потребностям. Похоже, что опасения в отношении отношений пользователя-RP и «совместимости» обязаны недопониманию предложения FEDCM. FedCM оставляет IDP, чтобы решить, какую информацию делиться с RP, и в какой форме, как только пользователь решил войти на сайт этого RP. FedCM не требует IDP для «создания уникального псевдонимы для каждого [RP], с которым пользователь аутентифицирует». Скорее, FEDCM открыт для каждого IDP, чтобы выбрать, обмениваться ли пользовательский идентификатор, версию этого идентификатора для каждого сайта или какую-то другую версию этой информации. (Спецификация FEDCM определяет перекрестную корреляцию как риск конфиденциальности, связанный с API, и обсуждает направленные (на сайт) идентификаторы в качестве возможного смягчения. Однако решение о том, следует ли использовать направленные идентификаторы, оставлено для ВПЛ, не навязываемое браузеру.) FedCM также уже предусматривает выбор пользователя в отношении идентификации. Например, если у пользователя есть несколько идентификаций с одним и тем же IDP (например, рабочий профиль и личный профиль), FedCM предоставляет пользователю возможность выбрать, какой из них они хотят использовать для входа на сайт RP. Помимо этого, каждый RP решает для себя, какой вагономородок поддерживает на своем сайте. Одним из аспектов этого решения является рассматриваемый механизм, на который опирается ВПЛ, будь то FedCM или другая технология. Опять же, браузер не диктует эти варианты для RPS или ВПЛ.

Борьба со спамом и мошенничеством

Токен частного государства API

Тема обратной связи	Краткое содержание	Хромированный ответ
Обработка ботов	Что произойдет, если эмитент обнаружит, что токены частного штата были выпущены ботам?	Чтобы избежать токенов, выпущенных ботам из оставшихся в экосистеме в течение длительного времени, эмитенты должны вращать ключи, которые они используют, чтобы регулярно подписывать токены, чтобы старые токены, выпущенные в соответствии с потенциально сломанной логикой выпуска, и истекают сайты, искажающие новые токены с обновленной логикой выдачи.
Использование формы одинакового сайта	Можно ли использовать токены частного состояния для представлений формы с тем же садом, которые включают полностраничную навигацию (т.е.	В настоящее время это не поддерживается в первой версии токенов частного штата. Мы приветствуем отзывы от экосистемы, если существует высокий спрос на этот случай использования.
Проверка на стороне сервера	Вопросы о том, могут ли токены частного состояния быть проверенной на стороне сервера	Токены выкупаются против эмитента, а затем эмитент создает запись искупления, которая может содержать сам токен или какое -то подписанное значение, полученное из токена, серверы могут использовать эту запись искупления, чтобы проверить подлинность токена, и мы ожидаем, что различные экосистемы эмизирующих будут придумывать различные стандарты для интерпретации их записей об отказе.

Ежеквартальный отчет за 2022 г. Q4, обобщающий обратную связь экосистемы, полученную по предложениям о песочнице конфиденциальности и ответе Chrome.

В рамках своих обязательств перед CMA, Google согласился публично предоставить ежеквартальные отчеты о процессе взаимодействия с заинтересованными сторонами для своих предложений о песочнице конфиденциальности (см. Пункты 12 и 17 (c) (ii) обязательств ). Эти отчеты об обратной связи с отчетами о песочнице конфиденциальности генерируются путем агрегирования обратной связи, полученной Chrome из различных источников, как указано в обзоре обратной связи , включая, помимо прочего, проблемы Github, форма обратной связи, предоставленная на PrivacysAndbox.com , встречи с заинтересованными сторонами отрасли и форумы веб -стандартов. Chrome приветствует обратную связь, полученную от экосистемы, и активно изучает способы интеграции обучения в дизайнерские решения.

Темы обратной связи ранжируются по распространенности на API. Это делается путем принятия совокупности количества обратной связи, которую команда Chrome получила вокруг данной темы и организации в порядке убывания. Общие темы обратной связи были определены путем рассмотрения тем обсуждения с публичных собраний (W3C, PATCG, IETF), прямой обратной связи, GitHub и обычно задаваемых вопросов, всплывших через внутренние команды Google и публичные формы.

В частности, были рассмотрены протоколы встреч для встреч в веб -стандартных органах, и, для прямой обратной связи, были рассмотрены записи Google на собраниях заинтересованных сторон 1: 1, электронные письма, полученные отдельными инженерами, списком рассылки API и публичной формы отзывов. Затем Google координировал между командами, участвующими в этих различных информационных работах, чтобы определить относительную распространенность тем, возникающих по отношению к каждому API.

Объяснения ответов Chrome на обратную связь были разработаны из опубликованных часто задаваемых вопросов, фактических ответов на вопросы, поднятые заинтересованными сторонами, и определение позиции специально для целей настоящих упражнений в общественной отчетности. Отражая текущую направленность разработки и тестирования, вопросов и обратной связи, в частности, по темам, API -интерфейсам отчетности и отчетности по атрибуции.

Обратная связь, полученная после окончания текущего отчетного периода, может еще не иметь рассмотренного хромированного ответа.

Глоссарий аббревиатуры

Чипсы: Куки
DSP: Платформа на стороне спроса
Fedcm: Федеративное управление полномочиями
Кадр: Первые вечеринки
IAB: Интерактивное рекламное бюро
ВИДП: Поставщик личности
IETF: Целевая группа по интернет -инженерии
ИП: Адрес интернет -протокола
openrtb: Торги в реальном времени
ОТ: Испытание происхождения
PATCG: Группа сообщества частных рекламных технологий
РП: Полагаться на вечеринку
ССП: Платформа для снабжения
Тройник: Доверенная среда исполнения
UA: Строка агента пользователя
Ua-ch: Пользовательский клиент подсказки
W3C: Всемирный консорциум паутины
WIPB: Умышленная IP -слепота

Общая обратная связь, нет конкретного API/технологии

Тема обратной связи	Краткое содержание	Хромированный ответ
(Также сообщается в 3 -м квартале) Полезность для разных типов заинтересованных сторон	Беспокойство о том, что технологии конфиденциальности песочниц предпочитают более крупные разработчики и что нишевые (меньшие) сайты вносят больше, чем общие (более крупные) сайты	Наш ответ неизменен с Q3: «Google посвятил себя CMA для разработки и реализации предложений с песочницей конфиденциальности таким образом, чтобы не искажать конкуренцию за счет самостоятельного привязки собственного бизнеса Google и учитывать влияние на конкуренцию в цифровой рекламе и на издатели и рекламодатели, независимо от их размера. Мы продолжаем тесно сотрудничать с CMA, чтобы обеспечить нашу работу с этими обязательствами. В ходе тестирования песочницей конфиденциальности, одним из ключевых вопросов, которые мы оцениваем, является то, как новые технологии работают для различных типов заинтересованных сторон. Обратная связь имеет решающее значение в этом отношении, особенно конкретная и действенная обратная связь, которая может помочь нам дополнительно улучшить технические проекты. Мы работали с CMA для разработки нашего подхода к количественному тестированию и поддерживаем CMA публикацию заметки о дизайне эксперимента, чтобы предоставить дополнительную информацию участникам рынка и возможность комментировать предлагаемые подходы ».
(Также сообщается в 3 -м квартале) Запросы на документацию	Запросы на дополнительные ресурсы подробно описывают, как управлять тестированием, анализом и реализацией	Q4 Обновление: Мы ценим, что разработчики нашли наш текущий материал полезным и продолжают стремиться к предоставлению большего количества материалов, чтобы разработчики могли понять, как новые технологии могут работать для них. За прошедший квартал мы добавили раздел «Новости и обновления» в PrivacySAndbox.com и опубликовали обширный обзор того, как песочница конфиденциальности может помочь повысить актуальность рекламы в будущем. Мы также провели сессии по часам рабочего застройка, чтобы поделиться лучшими практиками и демонстрациями, а также сессий по вопросам и ответам с участием продуктов и инженерии, чтобы разрешить живое обсуждение/вопросы.
Основные веб -жизненные силы	Как конфиденциальность Sandbox API задержка влияет на основные веб -сайты?	Поддержка задержки до минимума является ключевой целью дизайна APIS Sandbox Parcybox. Наше текущее ожидание состоит в том, что задержка API должна оказывать минимальное влияние на основные веб -жизненные отношения сайта, так как большинство API называются после первоначального рендеринга веб -сайта. Мы продолжаем контролировать и вносить улучшения для дальнейшего сокращения задержки для каждого из API, а также поощряем продолжение тестирования и обратную связь. Задержка в процессе ставок в реальном времени рассматривается в разделе Leleck в разделе «Производительность подкепких аукционов»
Совместимость	Опасения относительно совместимости с другими потенциальными решениями	Целью для конфиденциальности Sandbox является защита пользователей от перекрестного отслеживания при поддержке потребностей веб-экосистемы. Мы стремимся к этому, отказавшись от Legacy Browser Technologies, которые обеспечивают такое перекрестное отслеживание, такие как сторонние файлы cookie, и предоставляя на своем месте новые технологии, специально предназначенные для поддержки конкретных вариантов использования. Предложения по конфиденциальности песочницы улучшают конфиденциальность, ограничивая данные, которые оставляют устройство пользователя. Предложения не вкладывают технические ограничения на способность веб -сайта делиться или иным образом обрабатывать данные после собранного в браузере. Таким образом, технологии не мешают компаниям заключать соглашения «Управление данных» или любые другие аналогичные договорные отношения. Аналогичным образом, они не ограничивают способность пользователей согласиться на обмен своими данными другими способами. Для ясности Google решил применить технологии Sandbox Crivacy Sandbox одинаково на всех веб -сайтах, включая продукты и услуги Google. После того, как Chrome заканчивает поддержку сторонних файлов cookie, обязательства также ясно дают понять, что Google не будет использовать другие личные данные, такие как синхронизированная история просмотра хрома пользователей, для отслеживания пользователей для таргетирования или измерения цифровой рекламы.

Показать соответствующий контент и рекламу

Темы

Тема обратной связи	Краткое содержание	Хромированный ответ
Влияние на рейтинг поиска Google	Запрос о том, будет ли использоваться поддержка API веб -сайта в качестве потенциального сигнала для ранжирования результатов поиска Google	Некоторые веб-сайты могут выбрать отказ от API тем. Команда Sandbox Conficate Sandbox не координировала и не запросила от поисковой организации, которую они используют рейтинг страницы в качестве стимула для веб -сайтов принять API тем. Google подтвердил CMA, что Google Search не будет использовать решение сайта отказаться от API по темам в качестве сигнала ранжирования.
Темы Классификатор	Добавьте URL -адрес и контент страницы в дополнение к имени хоста, чтобы определить тему веб -страницы, чтобы улучшить утилиту для различных заинтересованных сторон.	История просмотра пользователя в настоящее время классифицируется с использованием имени хостов веб -сайта. Chrome продолжает оценивать варианты рассмотрения метаданных на уровне страниц (например, все или некоторые компоненты URL и/или содержания страницы) в классификации тем. Любые улучшения коммунального предприятия должны быть привлечены к рискам конфиденциальности и злоупотреблений. Например, в отношении метаданных, в частности, некоторые из рисков включают: - Сайты, изменяющие метаданные на уровне страницы как метод для кодирования различных (и потенциально чувствительных) значений в темы; - Сайты, изменяющие метаданные на уровне страниц, чтобы исказить свои темы для финансовой выгоды; -Сайты, изменяющие метаданные на уровне страниц динамически как метод перекрестного отслеживания
(Также сообщается в 3 -м квартале) Влияние на первоклассные сигналы	Сигнал темам может быть очень ценным, и в результате отклоняется другие первоклассные сигналы, основанные на интересах.	Наш ответ неизменен с Q3: «Мы считаем, что реклама, основанная на интересах, является важным вариантом использования для Интернета, и темы предназначены для поддержки этого варианта использования. Как описано [в нашем отчете Q3], другие заинтересованные стороны экосистемы выражают обеспокоенность тем, что темы могут быть недостаточно полезны для обеспечения ценности. Во всех случаях улучшения к таксономии являются постоянными усилиями, и мы ожидаем, что таксономия эволюционирует с тестированием Ecosystem и.
Обновление таксономии	Как будет обновлен список таксономии?	Мы активно ищем отзывы о таксономии , которая была бы наиболее полезна для экосистемы. Таксономия, включенная в первоначальное предложение API, была разработана для обеспечения функционального тестирования. Chrome активно рассматривает несколько подходов к обновлению таксономии. Например, Chrome может использовать понятие коммерческой ценности для каждой темы, чтобы определить, какую категорию включать в будущие итерации.
Темы Региональный классификатор	Темы Классификатор, работающий плохо в региональных областях	Улучшение классификатора является постоянным усилием. Основываясь на полученной нами отзывы, одна из рассматриваемых возможностей - расширить список переопределения тем, что, как показывает наш анализ, повысит глобальный охват и повысит точность. Чтобы объяснить, классификация API темы содержит два соответствующих компонента: (1) список переопределения, содержащий ведущие 10-километровые сайты и их темы, и (2) модель ML на устройстве, которая классифицирует имена хостов на темы. Расширяя список переопределения (1), мы можем повысить производительность классификации для тех регионов, в которых классификатор может работать плохо.
Одна неделя эпоха	Эпоха на одну неделю слишком длинная для пользователей, желающих принимать более короткие сроки.	Мы активно смотрим на то, что должна быть подходящая длина эпохи, и мы приветствуем дальнейшие отзывы о том, что будет лучшей эпохой для экосистемы.
Http -заголовок	Обеспокоенность тем, что не хватает информации о поиске заголовок HTTP.	Работа в процессе заголовков и Fetch (). У нас также есть информация, доступная здесь . Мы также добавили информацию о SkipobServation в объяснение.
Темы направлены только на то, чтобы помочь рекламодателям, а не пользователям	Темы/Песочница конфиденциальности, по -видимому, является подходом, ориентированным на отрасли. Преимущество для пользователей не так ясна, как выгода для промышленности.	Мы считаем, что польза для пользователей заключается в том, что темы поддерживают рекламу на основе интересов, которые сохраняют веб-сайт свободными и открытыми, и мы также считаем, что это значительно улучшает конфиденциальность по сравнению со сторонними куки. Удаление сторонних файлов cookie без жизнеспособных альтернатив может негативно повлиять на издателей и может привести к худшим подходам которые менее частны, не являются прозрачными и не являются реально переселенными или контролируемыми пользователями. Многие компании активно тестируют темы и API с песочницей, и мы стремимся предоставить инструменты для повышения конфиденциальности и поддержки Интернета. Группа технической архитектуры W3C недавно опубликовала свой первоначальный взгляд на API тем, на которые мы будем публично отвечать. На этом этапе, поскольку Google получил вопросы от экосистемы о том, что этот обзор может подразумевать для разработки и запуска API тем, мы хотели бы подтвердить наш план, чтобы сделать его доступным в Chrome в этом году. В то время как Googles ценит вклад в группу технической архитектуры W3C, он считает, что это имеет первостепенное значение для продолжения усилий по разработке и тестированию тем в консультации с CMA и экосистемой.
Утечка данных	Беспокоиться о том, что темы могут быть просочены на другие сайты без разрешения	Дизайн тем API тем делает довольно маловероятным, что данные от одного издателя (и даже меньшей группы издателей) могут быть просочены каким -либо образом. Веб -сайты издателей также полностью контролируются API тем, и они могут запретить доступ к этому API с помощью политики разрешения.
Отсутствие рекламодателей для тестирования	Издатели обеспокоены тем, что в настоящее время они не могут продемонстрировать ценность тем для рекламодателей.	Во второй половине 2023 года мы планируем иметь все API -интерфейсы, связанные с рекламой, доступны для тестирования интеграции и провести анализ экосистемы стоимости тем для рекламодателей. Тестирование и публикация результатов будет контролироваться CMA, которая рассмотрит данные, анализ и методологию. Экосистеме рекомендуется обмениваться обратной связью с Google и CMA.
Темы и закрой	Запрос на получение дополнительной информации о том, как использовать темы в рамках логики ставок Fledge	Можно использовать темы в рамках логики торгов Флед . Руководство по интеграции также находится в процессе и будет включать дополнительную информацию о реализации.
Пользовательский рейтинг для темам вызывающего	Разрешить рейтинги быть адаптированным вызывающим абонент	Задача с пользовательским рейтингом или ценностями для каждой технологии AD заключается в том, что это может стать механизм, с помощью которого AD -технология может влиять на возвращаемые темы, поэтому вектор снятия пальцев.
Темы Список приоритетных приоритетов	Позвольте вызывающим абонентам предоставить ранжированный список приоритетных тем, которые API -API вернется на основе права.	В настоящее время мы обсуждаем эту идею дальше и приветствуем дополнительные входные данные.

Оленей

Тема обратной связи	Краткое содержание	Хромированный ответ
Google Ad Manager	Беспокойство о том, что Google Ad Manager является конечным решателем для лесных аукционов и предпочитает теги Google Publisher и Google Ad Manager.	Flge позволяет каждому издателю выбирать структуру аукциона, включая выбор продавцов высшего уровня и компонентов. Каждый покупатель и продавец на аукционе компонентов знают, кто является продавцом высшего уровня, и может выбрать, стоит ли делать ставку.
Недостаточно участников, испытывающих лепешку	Запрос на поощрение большего количества компаний к тестированию подлеза, например, за счет улучшения функциональности API и обескураживания альтернативы, связанных с конфиденциальностью, таких как снятия пальцев	Песочница конфиденциальности работает поэтапно, в тесном партнерстве с руководством CMA и ICO, а функциональное тестирование на льры продемонстрировало необходимую стабильность и возможности. Google продолжает поощрять экосистему тестировать API-интерфейсы песочницы, недавно публикуя свою документацию « максимизировать актуальность AD », чтобы продемонстрировать, как Flegge и другие API могут помочь поддержать варианты критического использования для индустрии рекламы после снижения сторонних файлов cookie. Другие части песочницы конфиденциальности уже поддерживают смягчения для покрытия отслеживания (см. UA-CH, защита IP и отслеживание отслеживания) и будут продолжать улучшаться с течением времени. Цель Google не в том, чтобы сделать Fledge единственным жизнеспособным решением для таргетинга, а вместо этого остается приверженным сотрудничеству в партнерстве с промышленностью и регуляторами, чтобы стимулировать лучшие рекламные технологии, поддерживающие конфиденциальность в браузере Chrome.
Установки использования машинного обучения	Более подробные рекомендации о том, как будут поддерживаться варианты использования машинного обучения для обучения алгоритмов торгов на аукцион	Мы признаем необходимость помочь тестерам найти наиболее полезные способы применения технологий с песочницей конфиденциальности. Мы начали публиковать руководство, специально связанные с использованием различных аспектов APIS Sandbox Confication API в качестве входных данных для машинного обучения. В последней части, максимизирующей актуальность рекламы , обсуждается, как индустрия рекламы может использовать эти сигналы для машинного обучения, и мы планируем продолжить публиковать такие руководства в будущем.
Запрос о значении ключа подлегания (K/V) сервер	Почему сервер K/V публично запрашивается?	Сервер K/V направлен на то, чтобы предоставить сигналы в реальном времени для подвешенных аукционов. Таким образом, сервер K/V должен быть доступен от того, где проводятся эти подлезающие аукционы, которые находятся на пользовательских устройствах, требуя, чтобы он был общедоступным. Значение, хранящее на сервере K/V, может быть извлечено только стороной, которая уже имеет свой ключ, - поэтому, если рекламная технология дает только ключи для браузеров, которые находятся в группе интересов, и не использует ключи, которые можно догадаться, тогда только браузеры, которые нуждаются в значении для выполнения их аукциона.
Как сделать дату/время таргетинга?	Поддержка объектов даты в функции логики ставок.	There are multiple ways to do this. Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals , which a seller could pass to the buyer's generateBid script.
User preferences	Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions.	Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected.
Clearer timelines	Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames.	We plan to publish more detailed timelines in Q1.
Reporting confusion	Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API.	We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks.
Real-time bidding and FLEDGE	Guidance on how FLEDGE integrates with standard real-time bidding.	The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1.
Performance of FLEDGE Auctions	Report from testers that FLEDGE auctions have high latency	We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API.
Interest Group size memory limit	Request to raise the limit on the size of a single interest group from 50kB.	We are actively considering the request and are looking for feedback on what limit value works .
Combining the FLEDGE served data with first-party cookie	Will FLEDGE support integration with an advertiser's first-party data?	FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks.
K-anonymity value	How will the value "K" to "k-anon" be decided and will it be published?	The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject.
Supporting multiple SSPs	How will multiple SSPs be supported in FLEDGE?	FLEDGE supports multi-seller auctions as noted in this proposal .
Visibility of bidding logic	Concern that DSP bidding logic will be exposed in JavaScript	With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs.
prebid.js	What is the timeline in supporting prebid.js in FLEDGE?	Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance.
User defined functions in FLEDGE	How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API.	Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases.
Relaxing same-origin constraint on Interest Group resources	Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases	In the current implementation of FLEDGE, `biddingLogicUrl` , `biddingWasmHelperUrl` , `dailyUpdateUrl` and `trustedBiddingSignalsUrl` must have the same origin as the interest group owner. The constraint exists to prevent certain exploits by attackers, as explained here .
interestGroup Ownership	Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites	Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input.
Key Value Server Key Expiration	Discussion on removing server keys once the corresponding interest groups have expired	We are exploring ways to handle key expiration and are looking for feedback .

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme	Краткое содержание	Chrome Response
Origin Trial traffic	Current Origin Trial traffic is not enough to conduct utility testing.	The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic.
Overlap in functionality of different Privacy Sandbox measurement APIs	Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API.	We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases.
Retry failed report request	Clarification on how many times a report request is attempted if it fails.	We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent.
Reporting Delay	What is the expected reporting delay?	We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel.
Prerender pages	Will ARA attribution work on prerender pages?	Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping.
Measuring conversion lift	How to measure conversion lift with AB testing on the same domain	Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets.
(Also reported in Q3) Cross-domain conversions	How to track the conversions that are cross domain, such as with 2 or more destinations	Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented.
(Also reported in Q3) Expiry setting in conversion report	Request to support report filter / expiry for less than 24 hours	Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110.
Fraud and Abuse	Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices	This feedback is actively being discussed here and we welcome additional inputs.
(Also reported in Q3) Event level reporting delay	The delay of 2-30 days in event level reporting may be too long for certain use cases.	Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. See here . Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API.
Same reporting origin requirement	Request to remove requirement for source registration origin to be the same as the conversion registration origin	We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance.
Conversion tracking	Need to differentiate whether the conversion happened before/after certain hours set by the advertiser	Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X.
Noise simulation	Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions	We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback.
Reporting on mobile	Will the report still be sent when Chrome is running in the background on mobile?	At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. See here . Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA.
Data availability	Concerns that Google will have additional access to data via Privacy Sandbox APIs	First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue.

Limit Covert Tracking

User-Agent Reduction

Feedback Theme	Краткое содержание	Chrome Response
Delay User-Agent Reduction until web ecosystem is more ready	There is not sufficient time to adapt to the coming User-Agent Reduction changes.	We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA".
Delay User-Agent Reduction until web ecosystem is more ready	Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed	The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA.

###

User-Agent Client Hints

Feedback Theme	Краткое содержание	Chrome Response
Test UA-CH with other anti-covert tracking techniques	Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach	Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill.
(Also reported in Q2) Производительность	Concerns about the latency of getting hints via Critical-CH (on the first page load)	See dedicated UA-CH section below
Insufficient Feedback	Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem.	We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders.
Тайминг	Concerns raised regarding timing of rollout and industry preparedness	See dedicated UA-CH section below
Chrome Platform Status	Requested that the chromestatus page for UA-CH be updated	The chromestatus entry was updated on December 19 to "Mixed signals".

IP Protection (formerly Gnatcatcher)

Feedback Theme	Краткое содержание	Chrome Response
Opt in or Opt Out	Is IP Address Privacy Opt In or Opt Out?	Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection.
IP Address use case for first-party data	Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection?	As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted.
Ad Tech use cases	How can companies set up anti-fraud measures with IP Protection?	We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time.
Fraud and Abuse	Does IP protection include Denial of Service (DoS) Protection?	We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user.
Content Filtering	Content filtering with IP Protection	Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection.
(Also reported in Q3) Geolocation use cases	IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation.	Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here .

Privacy Budget

Feedback Theme	Краткое содержание	Chrome Response
Clearer documentation	More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented	The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal.

Strengthen cross-site privacy boundaries

First-Party Sets

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Domain limit	Request to expand the number of associated domains	Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy.
Request for more details about the abuse mitigation measures	What happens if a domain is added to a set they did not consent to?	We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk.
Abuse mitigation	Concern that First-Party Set formations can be exploited	We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here .
Ads use cases	Questions on whether First-Party Sets should be used to support Ad targeting	We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases.
(Also reported in Q3) Policy	Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3	Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments."
Alternative proposal	GDPR Validated Sets	In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames API

Feedback Theme	Краткое содержание	Chrome Response
Fenced Frames restrictions during OT	What are the current restrictions around Fenced Frames for the Origin Trial period?	We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023.
Multiple ads in a single Fenced Frame	Request to display multiple advertisers in one Fenced Frame in one auction	Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important.
Web Bundles	What are the requirements and support planned for Web Bundles with Fenced Frames?	We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status.

Shared Storage API

Feedback Theme	Краткое содержание	Chrome Response
Shared Storage for Ad Tech	Uncertainty surrounding the use of shared storage for Ad Tech use cases	Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases.

CHIPs

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Partitioned requirement	Add explicit behavior requirement for "Partitioned" attribute on first-party cookies.	Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification.
Cookie Management	Are there tools for managing/governing first-party or third-party cookies?	Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see.

FedCM

Feedback Theme	Краткое содержание	Chrome Response
IdP requires knowledge of RP to allow a session	Issue when a user is trying to log into the Feide IdP from two different RPs	We are discussing potential solutions to this issue.
Interoperability	Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites	FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs.

Fight spam and fraud

Private State Token API

Feedback Theme	Краткое содержание	Chrome Response
Handling Bots	What happens if the issuer discovers that Private State Tokens have been issued to bots?	To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic.
Same-site form submissions	Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs?	This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case.
Server-side verification	Questions on whether Private State Tokens can be verified server side	Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records.

Quarterly report for 2022 Q4 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.

As part of its commitments to the CMA, Google has agreed to publicly provide quarterly reports on the stakeholder engagement process for its Privacy Sandbox proposals (see paragraphs 12 and 17(c)(ii) of the Commitments ). These Privacy Sandbox feedback summary reports are generated by aggregating feedback received by Chrome from the various sources as listed in the feedback overview , including but not limited to: GitHub Issues, the feedback form made available on privacysandbox.com , meetings with industry stakeholders, and web standards forums. Chrome welcomes the feedback received from the ecosystem and is actively exploring ways to integrate learnings into design decisions.

Feedback themes are ranked by prevalence per API. This is done by taking an aggregation of the amount of feedback that the Chrome team has received around a given theme and organizing in descending order of quantity. The common feedback themes were identified by reviewing topics of discussion from public meetings (W3C, PatCG, IETF), direct feedback, GitHub, and commonly asked questions surfacing through Google's internal teams and public forms.

More specifically, meeting minutes for web standard bodies meetings were reviewed and, for direct feedback, Google's records of 1:1 stakeholder meetings, emails received by individual engineers, the API mailing list, and the public feedback form were considered. Google then coordinated between the teams involved in these various outreach activities to determine the relative prevalence of the themes emerging in relation to each API.

The explanations of Chrome's responses to feedback were developed from published FAQs, actual responses made to issues raised by stakeholders, and determining a position specifically for the purposes of this public reporting exercise. Reflecting the current focus of development and testing, questions and feedback were received in particular with respect to Topics, Fledge and Attribution Reporting APIs.

Feedback received after the end of the current reporting period may not yet have a considered Chrome response.

Glossary of acronyms

CHIPS: Cookies Having Independent Partitioned State
DSP: Demand-side Platform
FedCM: Federated Credential Management
Кадр: First Party Sets
IAB: Interactive Advertising Bureau
IDP: Identity Provider
IETF: Internet Engineering Task Force
ИП: Internet Protocol address
openRTB: Real-time bidding
ОТ: Origin Trial
PatCG: Private Advertising Technology Community Group
РП: Relying Party
ССП: Supply-side Platform
TEE: Trusted Execution Environment
UA: User Agent string
UA-CH: User-Agent Client Hints
W3C: World Wide Web Consortium
WIPB: Willful IP Blindness

General feedback, no specific API/Technology

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Usefulness for different types of stakeholders	Concerns that the Privacy Sandbox technologies favor larger developers and that niche (smaller) sites contribute more than generic (larger) sites	Our response is unchanged from Q3: "Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, regardless of their size. We continue to work closely with the CMA to ensure that our work complies with these commitments. As testing of the Privacy Sandbox progresses, one of the key questions we will assess is how the new technologies perform for different types of stakeholders. Feedback is critical in this respect, especially specific and actionable feedback that can help us further improve the technical designs. We have worked with the CMA to develop our approach to quantitative testing, and are supportive of the CMA publishing a note on experiment design to provide more information to market participants and an opportunity to comment on the proposed approaches."
(Also reported in Q3) Documentation requests	Requests for more resources detailing how to manage testing, analysis, and implementation	Q4 Update: We appreciate that developers have found our current material helpful, and continue to be committed to providing more material so developers can understand how the new technologies can work for them. Over the past quarter, we added a "News & Updates" section to privacysandbox.com and published an extensive review of how the Privacy Sandbox can help drive ad relevance in the future. We've also held public developer office hours sessions to share best practices and demos, along with Q&A sessions with product and engineering leads to allow for live discussion/questions.
Core Web Vitals	How does Privacy Sandbox API latency impact Core Web Vitals?	Keeping latency to a minimum is a key design goal of the Privacy Sandbox APIs. Our current expectation is that API latency should have minimal impact on a site's Core Web Vitals, as the majority of APIs are called after the initial rendering of the website. We continue to monitor and make improvements to reduce latency further for each of the APIs, and encourage continued testing and feedback. Latency in the real time bidding process is addressed in the FLEDGE section under "Performance of FLEDGE Auctions"
Interoperability	Concerns regarding interoperability with other potential solutions	The goal of Privacy Sandbox is to protect users against cross-site tracking while supporting the needs of the web ecosystem. We seek to accomplish this by moving away from legacy browser technologies that enable such cross-site tracking, like third-party cookies, and providing in their place new technologies purpose-built to support specific use cases. The Privacy Sandbox proposals improve privacy by limiting the data that leaves a user's device. The proposals do not place technical restrictions on a website's ability to share or otherwise process data once collected from the browser. The technologies therefore do not prevent companies from entering into "data stewardship" agreements or any other similar contractual relationship. Likewise, they do not restrict the ability of users to consent to sharing their data via other means. For clarity, Google has committed to apply the Privacy Sandbox technologies in the same way to all websites, including Google products and services. After Chrome ends support for third-party cookies, the commitments also make clear that Google will not use other personal data, such as users' synced Chrome browsing history, to track users for the targeting or measurement of digital advertising.

Show Relevant Content & Ads

Topics

Feedback Theme	Краткое содержание	Chrome Response
Impact on Google search ranking	Enquiry on whether a website's Topics API support will be used as a potential signal for Google Search results ranking	Some websites may choose to opt-out of the Topics API. The Privacy Sandbox team has not coordinated or requested from the Search organization that they use page ranking as an incentive for websites to adopt the Topics API. Google has confirmed to the CMA that Google Search will not use a site's decision to opt-out from the Topics API as a ranking signal.
Topics classifier	Add url and page content in addition to hostname to determine a webpage's Topic in order to improve utility for various stakeholders.	A user's browsing history is currently classified using a website's hostnames. Chrome continues to evaluate options for considering page level metadata (such as all or some components of the page URL and/or content) in Topics classification. Any utility improvements must be weighed against the privacy and abuse risks. For example, with respect to metadata in particular, a few of the risks include: - Sites modifying page-level metadata as a method to encode different (and potentially sensitive) meanings into topics; - Sites modifying page-level metadata to misrepresent their topics for financial gain; - Sites modifying page-level metadata dynamically as a method of cross-site tracking
(Also reported in Q3) Impact on first-party signals	Topics signal may be highly valuable and as a result devalues other first-party interest-based signals.	Our response is unchanged from Q3: "We believe interest-based advertising is an important use case for the web, and Topics is designed to support that use case. As described [in our Q3 report], other ecosystem stakeholders have expressed concerns that Topics may not be useful enough to provide value. In all cases, improvements to the taxonomy are an ongoing effort, and we expect the taxonomy to evolve with ecosystem testing and input."
Updating Taxonomy	How will the taxonomy list be updated?	We are actively seeking feedback on the taxonomy that would be most useful for the ecosystem. The taxonomy included in the initial Topics API proposal was designed to enable functional testing. Chrome is actively considering multiple approaches for updating the taxonomy. For example, Chrome may utilize a notion of commercial value for each topic to determine which category to include in future iterations.
Topics regional classifier performance	Topics classifier performing poorly in regional domains	Improvement to the classifier is an ongoing effort. Based on the feedback we have received, one possibility under consideration is to expand the Topics override list, which our analysis shows will increase global coverage and improve accuracy. To explain, the Topics API classification has two relevant components: (1) An override list containing the top 10k sites and their topics, and (2) an on-device ML model that classifies hostnames into topics. By expanding the override list (1), we can improve performance of classification for those regions in which the classifier may be performing poorly.
One week epoch	The one week epoch is too long for users looking to make shorter term decisions.	We are actively looking at what the suitable length of epoch should be and we welcome further feedback on what would be a better epoch for the ecosystem.
HTTP header retrieval	Concern that there is not enough information regarding the HTTP header retrieval of topics	Work is in progress for headers and fetch(). We also have information available here . We have also added skipObservation information to the explainer.
Topics only aims to help advertisers, not users	Topics/Privacy Sandbox appears to be an industry focused approach. Benefit for users is not as clear as benefit to industry.	We believe the benefit to users is that Topics supports interest-based ads that keep the web free and open, and we also believe it significantly improves privacy compared to third-party cookies. Removing third-party cookies without viable alternatives may negatively impact publishers, and could lead to worse approaches which are less private, are not transparent, and are not realistically resettable or controlled by users. Many companies are actively testing Topics and Sandbox APIs, and we're committed to providing the tools to advance privacy and support the web. The W3C Technical Architecture Group has recently published its initial view about the Topics API, which we will be responding to publicly. At this stage, since Google has received questions from the ecosystem about what this review may imply for the development and launch of the Topics API, we would like to reaffirm our plan to make it available in Chrome Stable this year. While Googles appreciates the input of the W3C Technical Architecture Group, it considers it of paramount importance to continue the efforts to develop and test Topics in consultation with the CMA and the ecosystem.
Data leakage	Concern that Topics may be leaked to other sites without permission	The design of the Topics API makes it quite unlikely that data from a single publisher (and even a smaller group of publishers) can be leaked in any way. Publisher websites are also in full control over the Topics API and they can prohibit access to this API via permission policy.
Lack of advertisers for testing	Publishers are concerned that they currently are unable to demonstrate the value of Topics to advertisers.	In the second half of 2023, we plan to have all the ads related APIs available for integration testing and enable ecosystem analysis of the value of Topics for advertisers. Testing and publication of the results will be supervised by the CMA, which will review the data, analysis and methodology. The ecosystem is encouraged to share feedback with Google and the CMA.
Topics and FLEDGE	Request for more information on how to use Topics within FLEDGE's bidding logic	It is possible to use Topics within FLEDGE's bidding logic. An integration guide is also in progress, and will include additional details on implementation.
Custom ranking for topics caller	Allow rankings to be tailored by caller	The challenge with custom topic ranking or values for each ad tech is that this could become a mechanism by which an ad tech can influence the topics that are returned, therefore a fingerprinting vector.
Topics caller priority list	Allow callers to provide a ranked priority list of topics that the Topics API will return based on eligibility.	We are currently discussing this idea further and welcome additional inputs.

FLEDGE

Feedback Theme	Краткое содержание	Chrome Response
Google Ad Manager	Concern that Google Ad Manager is the end decider for FLEDGE auctions and would favor Google Publisher Tags and Google Ad Manager.	FLEDGE allows each publisher to choose the structure of the auction, including the choice of top-level and component sellers. Each buyer and seller in a component auction knows who the top-level seller is, and can choose whether or not to bid.
Not enough participants testing FLEDGE	Request to encourage more companies to test FLEDGE, for example by improving the API's functionality and discouraging privacy-intrusive alternatives like fingerprinting	The Privacy Sandbox is proceeding in stages, in close partnership with the guidance of the CMA and ICO, and functional FLEDGE testing has demonstrated necessary stability and capability. Google continues to encourage the ecosystem to test the Sandbox APIs, recently publishing its " Maximize Ad Relevance " documentation to showcase how FLEDGE and other APIs can help support critical use cases for the ad industry after third-party cookie deprecation. Other parts of the Privacy Sandbox already support mitigations to cover tracking (see UA-CH, IP Protection, and Bounce Tracking Mitigations) and will continue to improve over time. Google's goal is not to make FLEDGE the only viable targeting solution, but instead remains committed to working in partnership with industry and regulators to drive the best privacy-preserving ad technologies in the Chrome browser.
Machine learning use cases	More guidance on how machine learning use cases to train auction bidding algorithms will be supported in FLEDGE and Attribution Reporting	We recognize the need to help testers find the most useful ways of applying the Privacy Sandbox technologies. We have begun to publish guidance specifically related to the use of the various aspects of the Privacy Sandbox APIs as inputs to machine learning. The most recent piece, Maximize Ad Relevance , discusses how the ads industry can use these signals for machine learning, and we plan to continue publishing such guidance going forward.
Querying FLEDGE Key Value (K/V) Server	Why is the K/V server publicly queryable?	The K/V server aims to provide real time signals to FLEDGE auctions. As such, the K/V server needs to be accessible from where those FLEDGE auctions execute, which is on user devices, requiring that it be publicly available. A value stored in the K/V server can only be retrieved by a party that already has its key — so if an ad tech only gives the keys to browsers that are in the Interest Group, and does not use keys that can be randomly guessed, then only browsers that need the Value to run their auction will be able to retrieve it.
How to do date/time targeting?	Support for date objects in the bidding logic function.	There are multiple ways to do this. Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals , which a seller could pass to the buyer's generateBid script.
User preferences	Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions.	Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected.
Clearer timelines	Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames.	We plan to publish more detailed timelines in Q1.
Reporting confusion	Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API.	We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks.
Real-time bidding and FLEDGE	Guidance on how FLEDGE integrates with standard real-time bidding.	The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1.
Performance of FLEDGE Auctions	Report from testers that FLEDGE auctions have high latency	We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API.
Interest Group size memory limit	Request to raise the limit on the size of a single interest group from 50kB.	We are actively considering the request and are looking for feedback on what limit value works .
Combining the FLEDGE served data with first-party cookie	Will FLEDGE support integration with an advertiser's first-party data?	FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks.
K-anonymity value	How will the value "K" to "k-anon" be decided and will it be published?	The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject.
Supporting multiple SSPs	How will multiple SSPs be supported in FLEDGE?	FLEDGE supports multi-seller auctions as noted in this proposal .
Visibility of bidding logic	Concern that DSP bidding logic will be exposed in JavaScript	With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs.
prebid.js	What is the timeline in supporting prebid.js in FLEDGE?	Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance.
User defined functions in FLEDGE	How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API.	Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases.
Relaxing same-origin constraint on Interest Group resources	Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases	In the current implementation of FLEDGE, `biddingLogicUrl` , `biddingWasmHelperUrl` , `dailyUpdateUrl` and `trustedBiddingSignalsUrl` must have the same origin as the interest group owner. The constraint exists to prevent certain exploits by attackers, as explained here .
interestGroup Ownership	Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites	Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input.
Key Value Server Key Expiration	Discussion on removing server keys once the corresponding interest groups have expired	We are exploring ways to handle key expiration and are looking for feedback .

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme	Краткое содержание	Chrome Response
Origin Trial traffic	Current Origin Trial traffic is not enough to conduct utility testing.	The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic.
Overlap in functionality of different Privacy Sandbox measurement APIs	Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API.	We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases.
Retry failed report request	Clarification on how many times a report request is attempted if it fails.	We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent.
Reporting Delay	What is the expected reporting delay?	We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel.
Prerender pages	Will ARA attribution work on prerender pages?	Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping.
Measuring conversion lift	How to measure conversion lift with AB testing on the same domain	Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets.
(Also reported in Q3) Cross-domain conversions	How to track the conversions that are cross domain, such as with 2 or more destinations	Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented.
(Also reported in Q3) Expiry setting in conversion report	Request to support report filter / expiry for less than 24 hours	Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110.
Fraud and Abuse	Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices	This feedback is actively being discussed here and we welcome additional inputs.
(Also reported in Q3) Event level reporting delay	The delay of 2-30 days in event level reporting may be too long for certain use cases.	Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. See here . Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API.
Same reporting origin requirement	Request to remove requirement for source registration origin to be the same as the conversion registration origin	We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance.
Conversion tracking	Need to differentiate whether the conversion happened before/after certain hours set by the advertiser	Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X.
Noise simulation	Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions	We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback.
Reporting on mobile	Will the report still be sent when Chrome is running in the background on mobile?	At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. See here . Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA.
Data availability	Concerns that Google will have additional access to data via Privacy Sandbox APIs	First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue.

Limit Covert Tracking

User-Agent Reduction

Feedback Theme	Краткое содержание	Chrome Response
Delay User-Agent Reduction until web ecosystem is more ready	There is not sufficient time to adapt to the coming User-Agent Reduction changes.	We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA".
Delay User-Agent Reduction until web ecosystem is more ready	Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed	The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA.

###

User-Agent Client Hints

Feedback Theme	Краткое содержание	Chrome Response
Test UA-CH with other anti-covert tracking techniques	Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach	Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill.
(Also reported in Q2) Производительность	Concerns about the latency of getting hints via Critical-CH (on the first page load)	See dedicated UA-CH section below
Insufficient Feedback	Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem.	We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders.
Тайминг	Concerns raised regarding timing of rollout and industry preparedness	See dedicated UA-CH section below
Chrome Platform Status	Requested that the chromestatus page for UA-CH be updated	The chromestatus entry was updated on December 19 to "Mixed signals".

IP Protection (formerly Gnatcatcher)

Feedback Theme	Краткое содержание	Chrome Response
Opt in or Opt Out	Is IP Address Privacy Opt In or Opt Out?	Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection.
IP Address use case for first-party data	Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection?	As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted.
Ad Tech use cases	How can companies set up anti-fraud measures with IP Protection?	We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time.
Fraud and Abuse	Does IP protection include Denial of Service (DoS) Protection?	We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user.
Content Filtering	Content filtering with IP Protection	Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection.
(Also reported in Q3) Geolocation use cases	IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation.	Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here .

Privacy Budget

Feedback Theme	Краткое содержание	Chrome Response
Clearer documentation	More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented	The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal.

Strengthen cross-site privacy boundaries

First-Party Sets

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Domain limit	Request to expand the number of associated domains	Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy.
Request for more details about the abuse mitigation measures	What happens if a domain is added to a set they did not consent to?	We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk.
Abuse mitigation	Concern that First-Party Set formations can be exploited	We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here .
Ads use cases	Questions on whether First-Party Sets should be used to support Ad targeting	We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases.
(Also reported in Q3) Policy	Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3	Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments."
Alternative proposal	GDPR Validated Sets	In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames API

Feedback Theme	Краткое содержание	Chrome Response
Fenced Frames restrictions during OT	What are the current restrictions around Fenced Frames for the Origin Trial period?	We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023.
Multiple ads in a single Fenced Frame	Request to display multiple advertisers in one Fenced Frame in one auction	Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important.
Web Bundles	What are the requirements and support planned for Web Bundles with Fenced Frames?	We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status.

Shared Storage API

Feedback Theme	Краткое содержание	Chrome Response
Shared Storage for Ad Tech	Uncertainty surrounding the use of shared storage for Ad Tech use cases	Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases.

CHIPs

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Partitioned requirement	Add explicit behavior requirement for "Partitioned" attribute on first-party cookies.	Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification.
Cookie Management	Are there tools for managing/governing first-party or third-party cookies?	Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see.

FedCM

Feedback Theme	Краткое содержание	Chrome Response
IdP requires knowledge of RP to allow a session	Issue when a user is trying to log into the Feide IdP from two different RPs	We are discussing potential solutions to this issue.
Interoperability	Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites	FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs.

Fight spam and fraud

Private State Token API

Feedback Theme	Краткое содержание	Chrome Response
Handling Bots	What happens if the issuer discovers that Private State Tokens have been issued to bots?	To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic.
Same-site form submissions	Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs?	This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case.
Server-side verification	Questions on whether Private State Tokens can be verified server side	Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records.

Quarterly report for 2022 Q4 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.

Feedback received after the end of the current reporting period may not yet have a considered Chrome response.

Glossary of acronyms

CHIPS: Cookies Having Independent Partitioned State
DSP: Demand-side Platform
FedCM: Federated Credential Management
Кадр: First Party Sets
IAB: Interactive Advertising Bureau
IDP: Identity Provider
IETF: Internet Engineering Task Force
ИП: Internet Protocol address
openRTB: Real-time bidding
ОТ: Origin Trial
PatCG: Private Advertising Technology Community Group
РП: Relying Party
ССП: Supply-side Platform
TEE: Trusted Execution Environment
UA: User Agent string
UA-CH: User-Agent Client Hints
W3C: World Wide Web Consortium
WIPB: Willful IP Blindness

General feedback, no specific API/Technology

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Usefulness for different types of stakeholders	Concerns that the Privacy Sandbox technologies favor larger developers and that niche (smaller) sites contribute more than generic (larger) sites	Our response is unchanged from Q3: "Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, regardless of their size. We continue to work closely with the CMA to ensure that our work complies with these commitments. As testing of the Privacy Sandbox progresses, one of the key questions we will assess is how the new technologies perform for different types of stakeholders. Feedback is critical in this respect, especially specific and actionable feedback that can help us further improve the technical designs. We have worked with the CMA to develop our approach to quantitative testing, and are supportive of the CMA publishing a note on experiment design to provide more information to market participants and an opportunity to comment on the proposed approaches."
(Also reported in Q3) Documentation requests	Requests for more resources detailing how to manage testing, analysis, and implementation	Q4 Update: We appreciate that developers have found our current material helpful, and continue to be committed to providing more material so developers can understand how the new technologies can work for them. Over the past quarter, we added a "News & Updates" section to privacysandbox.com and published an extensive review of how the Privacy Sandbox can help drive ad relevance in the future. We've also held public developer office hours sessions to share best practices and demos, along with Q&A sessions with product and engineering leads to allow for live discussion/questions.
Core Web Vitals	How does Privacy Sandbox API latency impact Core Web Vitals?	Keeping latency to a minimum is a key design goal of the Privacy Sandbox APIs. Our current expectation is that API latency should have minimal impact on a site's Core Web Vitals, as the majority of APIs are called after the initial rendering of the website. We continue to monitor and make improvements to reduce latency further for each of the APIs, and encourage continued testing and feedback. Latency in the real time bidding process is addressed in the FLEDGE section under "Performance of FLEDGE Auctions"
Interoperability	Concerns regarding interoperability with other potential solutions	The goal of Privacy Sandbox is to protect users against cross-site tracking while supporting the needs of the web ecosystem. We seek to accomplish this by moving away from legacy browser technologies that enable such cross-site tracking, like third-party cookies, and providing in their place new technologies purpose-built to support specific use cases. The Privacy Sandbox proposals improve privacy by limiting the data that leaves a user's device. The proposals do not place technical restrictions on a website's ability to share or otherwise process data once collected from the browser. The technologies therefore do not prevent companies from entering into "data stewardship" agreements or any other similar contractual relationship. Likewise, they do not restrict the ability of users to consent to sharing their data via other means. For clarity, Google has committed to apply the Privacy Sandbox technologies in the same way to all websites, including Google products and services. After Chrome ends support for third-party cookies, the commitments also make clear that Google will not use other personal data, such as users' synced Chrome browsing history, to track users for the targeting or measurement of digital advertising.

Show Relevant Content & Ads

Topics

Feedback Theme	Краткое содержание	Chrome Response
Impact on Google search ranking	Enquiry on whether a website's Topics API support will be used as a potential signal for Google Search results ranking	Some websites may choose to opt-out of the Topics API. The Privacy Sandbox team has not coordinated or requested from the Search organization that they use page ranking as an incentive for websites to adopt the Topics API. Google has confirmed to the CMA that Google Search will not use a site's decision to opt-out from the Topics API as a ranking signal.
Topics classifier	Add url and page content in addition to hostname to determine a webpage's Topic in order to improve utility for various stakeholders.	A user's browsing history is currently classified using a website's hostnames. Chrome continues to evaluate options for considering page level metadata (such as all or some components of the page URL and/or content) in Topics classification. Any utility improvements must be weighed against the privacy and abuse risks. For example, with respect to metadata in particular, a few of the risks include: - Sites modifying page-level metadata as a method to encode different (and potentially sensitive) meanings into topics; - Sites modifying page-level metadata to misrepresent their topics for financial gain; - Sites modifying page-level metadata dynamically as a method of cross-site tracking
(Also reported in Q3) Impact on first-party signals	Topics signal may be highly valuable and as a result devalues other first-party interest-based signals.	Our response is unchanged from Q3: "We believe interest-based advertising is an important use case for the web, and Topics is designed to support that use case. As described [in our Q3 report], other ecosystem stakeholders have expressed concerns that Topics may not be useful enough to provide value. In all cases, improvements to the taxonomy are an ongoing effort, and we expect the taxonomy to evolve with ecosystem testing and input."
Updating Taxonomy	How will the taxonomy list be updated?	We are actively seeking feedback on the taxonomy that would be most useful for the ecosystem. The taxonomy included in the initial Topics API proposal was designed to enable functional testing. Chrome is actively considering multiple approaches for updating the taxonomy. For example, Chrome may utilize a notion of commercial value for each topic to determine which category to include in future iterations.
Topics regional classifier performance	Topics classifier performing poorly in regional domains	Improvement to the classifier is an ongoing effort. Based on the feedback we have received, one possibility under consideration is to expand the Topics override list, which our analysis shows will increase global coverage and improve accuracy. To explain, the Topics API classification has two relevant components: (1) An override list containing the top 10k sites and their topics, and (2) an on-device ML model that classifies hostnames into topics. By expanding the override list (1), we can improve performance of classification for those regions in which the classifier may be performing poorly.
One week epoch	The one week epoch is too long for users looking to make shorter term decisions.	We are actively looking at what the suitable length of epoch should be and we welcome further feedback on what would be a better epoch for the ecosystem.
HTTP header retrieval	Concern that there is not enough information regarding the HTTP header retrieval of topics	Work is in progress for headers and fetch(). We also have information available here . We have also added skipObservation information to the explainer.
Topics only aims to help advertisers, not users	Topics/Privacy Sandbox appears to be an industry focused approach. Benefit for users is not as clear as benefit to industry.	We believe the benefit to users is that Topics supports interest-based ads that keep the web free and open, and we also believe it significantly improves privacy compared to third-party cookies. Removing third-party cookies without viable alternatives may negatively impact publishers, and could lead to worse approaches which are less private, are not transparent, and are not realistically resettable or controlled by users. Many companies are actively testing Topics and Sandbox APIs, and we're committed to providing the tools to advance privacy and support the web. The W3C Technical Architecture Group has recently published its initial view about the Topics API, which we will be responding to publicly. At this stage, since Google has received questions from the ecosystem about what this review may imply for the development and launch of the Topics API, we would like to reaffirm our plan to make it available in Chrome Stable this year. While Googles appreciates the input of the W3C Technical Architecture Group, it considers it of paramount importance to continue the efforts to develop and test Topics in consultation with the CMA and the ecosystem.
Data leakage	Concern that Topics may be leaked to other sites without permission	The design of the Topics API makes it quite unlikely that data from a single publisher (and even a smaller group of publishers) can be leaked in any way. Publisher websites are also in full control over the Topics API and they can prohibit access to this API via permission policy.
Lack of advertisers for testing	Publishers are concerned that they currently are unable to demonstrate the value of Topics to advertisers.	In the second half of 2023, we plan to have all the ads related APIs available for integration testing and enable ecosystem analysis of the value of Topics for advertisers. Testing and publication of the results will be supervised by the CMA, which will review the data, analysis and methodology. The ecosystem is encouraged to share feedback with Google and the CMA.
Topics and FLEDGE	Request for more information on how to use Topics within FLEDGE's bidding logic	It is possible to use Topics within FLEDGE's bidding logic. An integration guide is also in progress, and will include additional details on implementation.
Custom ranking for topics caller	Allow rankings to be tailored by caller	The challenge with custom topic ranking or values for each ad tech is that this could become a mechanism by which an ad tech can influence the topics that are returned, therefore a fingerprinting vector.
Topics caller priority list	Allow callers to provide a ranked priority list of topics that the Topics API will return based on eligibility.	We are currently discussing this idea further and welcome additional inputs.

FLEDGE

Feedback Theme	Краткое содержание	Chrome Response
Google Ad Manager	Concern that Google Ad Manager is the end decider for FLEDGE auctions and would favor Google Publisher Tags and Google Ad Manager.	FLEDGE allows each publisher to choose the structure of the auction, including the choice of top-level and component sellers. Each buyer and seller in a component auction knows who the top-level seller is, and can choose whether or not to bid.
Not enough participants testing FLEDGE	Request to encourage more companies to test FLEDGE, for example by improving the API's functionality and discouraging privacy-intrusive alternatives like fingerprinting	The Privacy Sandbox is proceeding in stages, in close partnership with the guidance of the CMA and ICO, and functional FLEDGE testing has demonstrated necessary stability and capability. Google continues to encourage the ecosystem to test the Sandbox APIs, recently publishing its " Maximize Ad Relevance " documentation to showcase how FLEDGE and other APIs can help support critical use cases for the ad industry after third-party cookie deprecation. Other parts of the Privacy Sandbox already support mitigations to cover tracking (see UA-CH, IP Protection, and Bounce Tracking Mitigations) and will continue to improve over time. Google's goal is not to make FLEDGE the only viable targeting solution, but instead remains committed to working in partnership with industry and regulators to drive the best privacy-preserving ad technologies in the Chrome browser.
Machine learning use cases	More guidance on how machine learning use cases to train auction bidding algorithms will be supported in FLEDGE and Attribution Reporting	We recognize the need to help testers find the most useful ways of applying the Privacy Sandbox technologies. We have begun to publish guidance specifically related to the use of the various aspects of the Privacy Sandbox APIs as inputs to machine learning. The most recent piece, Maximize Ad Relevance , discusses how the ads industry can use these signals for machine learning, and we plan to continue publishing such guidance going forward.
Querying FLEDGE Key Value (K/V) Server	Why is the K/V server publicly queryable?	The K/V server aims to provide real time signals to FLEDGE auctions. As such, the K/V server needs to be accessible from where those FLEDGE auctions execute, which is on user devices, requiring that it be publicly available. A value stored in the K/V server can only be retrieved by a party that already has its key — so if an ad tech only gives the keys to browsers that are in the Interest Group, and does not use keys that can be randomly guessed, then only browsers that need the Value to run their auction will be able to retrieve it.
How to do date/time targeting?	Support for date objects in the bidding logic function.	There are multiple ways to do this. Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals , which a seller could pass to the buyer's generateBid script.
User preferences	Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions.	Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected.
Clearer timelines	Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames.	We plan to publish more detailed timelines in Q1.
Reporting confusion	Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API.	We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks.
Real-time bidding and FLEDGE	Guidance on how FLEDGE integrates with standard real-time bidding.	The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1.
Performance of FLEDGE Auctions	Report from testers that FLEDGE auctions have high latency	We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE . In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow , and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions , a fast bidder filtering technique , a way to reuse FLEDGE worklets to avoid paying startup costs , and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API.
Interest Group size memory limit	Request to raise the limit on the size of a single interest group from 50kB.	We are actively considering the request and are looking for feedback on what limit value works .
Combining the FLEDGE served data with first-party cookie	Will FLEDGE support integration with an advertiser's first-party data?	FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks.
K-anonymity value	How will the value "K" to "k-anon" be decided and will it be published?	The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject.
Supporting multiple SSPs	How will multiple SSPs be supported in FLEDGE?	FLEDGE supports multi-seller auctions as noted in this proposal .
Visibility of bidding logic	Concern that DSP bidding logic will be exposed in JavaScript	With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs.
prebid.js	What is the timeline in supporting prebid.js in FLEDGE?	Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance.
User defined functions in FLEDGE	How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API.	Explainer available here . This is still being fleshed out so we welcome additional feedback on use cases.
Relaxing same-origin constraint on Interest Group resources	Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases	In the current implementation of FLEDGE, `biddingLogicUrl` , `biddingWasmHelperUrl` , `dailyUpdateUrl` and `trustedBiddingSignalsUrl` must have the same origin as the interest group owner. The constraint exists to prevent certain exploits by attackers, as explained here .
interestGroup Ownership	Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites	Our focus is on how audiences are used, not how they are built. We are discussing potential approaches and welcome additional input.
Key Value Server Key Expiration	Discussion on removing server keys once the corresponding interest groups have expired	We are exploring ways to handle key expiration and are looking for feedback .

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme	Краткое содержание	Chrome Response
Origin Trial traffic	Current Origin Trial traffic is not enough to conduct utility testing.	The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (ie when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com ).We welcome any additional feedback on use case testing that requires additional traffic.
Overlap in functionality of different Privacy Sandbox measurement APIs	Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API.	We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases.
Retry failed report request	Clarification on how many times a report request is attempted if it fails.	We have published guidance on this . To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent.
Reporting Delay	What is the expected reporting delay?	We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel.
Prerender pages	Will ARA attribution work on prerender pages?	Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping.
Measuring conversion lift	How to measure conversion lift with AB testing on the same domain	Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets.
(Also reported in Q3) Cross-domain conversions	How to track the conversions that are cross domain, such as with 2 or more destinations	Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented.
(Also reported in Q3) Expiry setting in conversion report	Request to support report filter / expiry for less than 24 hours	Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110.
Fraud and Abuse	Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices	This feedback is actively being discussed here and we welcome additional inputs.
(Also reported in Q3) Event level reporting delay	The delay of 2-30 days in event level reporting may be too long for certain use cases.	Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. See here . Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API.
Same reporting origin requirement	Request to remove requirement for source registration origin to be the same as the conversion registration origin	We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance.
Conversion tracking	Need to differentiate whether the conversion happened before/after certain hours set by the advertiser	Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X.
Noise simulation	Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions	We are looking to add ways to simulate this in future versions of Noise Lab . We welcome any additional feedback.
Reporting on mobile	Will the report still be sent when Chrome is running in the background on mobile?	At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. See here . Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA.
Data availability	Concerns that Google will have additional access to data via Privacy Sandbox APIs	First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue.

Limit Covert Tracking

User-Agent Reduction

Feedback Theme	Краткое содержание	Chrome Response
Delay User-Agent Reduction until web ecosystem is more ready	There is not sufficient time to adapt to the coming User-Agent Reduction changes.	We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA".
Delay User-Agent Reduction until web ecosystem is more ready	Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed	The Google Ads team proposed the Structured User-Agent addition (see specification ) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA.

###

User-Agent Client Hints

Feedback Theme	Краткое содержание	Chrome Response
Test UA-CH with other anti-covert tracking techniques	Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach	Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (ie Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill.
(Also reported in Q2) Производительность	Concerns about the latency of getting hints via Critical-CH (on the first page load)	See dedicated UA-CH section below
Insufficient Feedback	Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem.	We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders.
Тайминг	Concerns raised regarding timing of rollout and industry preparedness	See dedicated UA-CH section below
Chrome Platform Status	Requested that the chromestatus page for UA-CH be updated	The chromestatus entry was updated on December 19 to "Mixed signals".

IP Protection (formerly Gnatcatcher)

Feedback Theme	Краткое содержание	Chrome Response
Opt in or Opt Out	Is IP Address Privacy Opt In or Opt Out?	Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection.
IP Address use case for first-party data	Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection?	As previously published , IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted.
Ad Tech use cases	How can companies set up anti-fraud measures with IP Protection?	We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time.
Fraud and Abuse	Does IP protection include Denial of Service (DoS) Protection?	We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user.
Content Filtering	Content filtering with IP Protection	Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection.
(Also reported in Q3) Geolocation use cases	IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation.	Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here .

Privacy Budget

Feedback Theme	Краткое содержание	Chrome Response
Clearer documentation	More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented	The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal.

Strengthen cross-site privacy boundaries

First-Party Sets

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Domain limit	Request to expand the number of associated domains	Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy.
Request for more details about the abuse mitigation measures	What happens if a domain is added to a set they did not consent to?	We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk.
Abuse mitigation	Concern that First-Party Set formations can be exploited	We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here .
Ads use cases	Questions on whether First-Party Sets should be used to support Ad targeting	We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases.
(Also reported in Q3) Policy	Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3	Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments."
Alternative proposal	GDPR Validated Sets	In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal: "GDPR Validated Sets" claims to "align to" GDPR (although it is not really clear what is meant by that). In contrast, Google's commitments require it to take into account "impact on privacy outcomes" more generally. In its decision accepting the commitments the CMA points out that this is distinct from Google's obligation to take into account "compliance with data protection principles as set out in the Applicable Data Protection Legislation," which, as the CMA explains, reflects the fact that Google is bound by the Applicable Data Protection Legislation, both as it applies to the commitments and more generally. We have privacy concerns about the proposal to allow domains to appear in multiple sets. First-Party Sets are intended to support specific use cases that currently depend on third-party cookies without enabling pervasive cross-site tracking. Allowing domains to join multiple sets would remove a key privacy protection built into the First-Party Sets proposal, without introducing any other meaningful limitations. GDPR Validated Sets also proposes to "define a Set as a group of data controllers and processors that share a common use policy." This is similar to the requirement in our original First-Party Sets proposal that all parties in a set must share a common privacy policy. We have since removed that requirement based on strong feedback from the ecosystem raising concerns about privacy policy-based requirements. For example, we heard from site publishers that maintaining a common privacy policy was infeasible because of product and geographical variations, among other challenges raised by members of the W3C community ( 1 , 2 , 3 ). We believe that the same challenges would apply to this proposal. Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets.

Fenced Frames API

Feedback Theme	Краткое содержание	Chrome Response
Fenced Frames restrictions during OT	What are the current restrictions around Fenced Frames for the Origin Trial period?	We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023.
Multiple ads in a single Fenced Frame	Request to display multiple advertisers in one Fenced Frame in one auction	Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important.
Web Bundles	What are the requirements and support planned for Web Bundles with Fenced Frames?	We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status.

Shared Storage API

Feedback Theme	Краткое содержание	Chrome Response
Shared Storage for Ad Tech	Uncertainty surrounding the use of shared storage for Ad Tech use cases	Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here . We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases.

CHIPs

Feedback Theme	Краткое содержание	Chrome Response
(Also reported in Q3) Partitioned requirement	Add explicit behavior requirement for "Partitioned" attribute on first-party cookies.	Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification.
Cookie Management	Are there tools for managing/governing first-party or third-party cookies?	Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see.

FedCM

Feedback Theme	Краткое содержание	Chrome Response
IdP requires knowledge of RP to allow a session	Issue when a user is trying to log into the Feide IdP from two different RPs	We are discussing potential solutions to this issue.
Interoperability	Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites	FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (eg, a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs.

Fight spam and fraud

Private State Token API

Feedback Theme	Краткое содержание	Chrome Response
Handling Bots	What happens if the issuer discovers that Private State Tokens have been issued to bots?	To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic.
Same-site form submissions	Could Private State Tokens be used for same-site form submissions that involve full-page navigation (ie Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs?	This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case.
Server-side verification	Questions on whether Private State Tokens can be verified server side	Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records.

Отчет об обратной связи - 4 квартал 2022 г. bookmark_borderbookmark Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Глоссарий сокращений

Общий отзыв, без конкретного API/технологии

Показывайте релевантный контент и рекламу

Темы

ФЛЕДЖ

Измерение цифровой рекламы

Отчеты по атрибуции (и другие API)

Ограничить скрытое отслеживание

Сокращение пользовательского агента

Подсказки для клиента User-Agent

Защита от IP (ранее Gnatcatcher)

Бюджет конфиденциальности

Укреплять границы конфиденциальности поперечного сайта

Первопартийные наборы

О огороженные рамки API

Общий API хранилища

Чипсы

Fedcm

Борьба со спамом и мошенничеством

Токен частного государства API

Глоссарий аббревиатуры

Общая обратная связь, нет конкретного API/технологии

Показать соответствующий контент и рекламу

Темы

Оленей

Measuring Digital Ads

Attribution Reporting (and other APIs)

Limit Covert Tracking

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

Privacy Budget

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

Shared Storage API

CHIPs

FedCM

Fight spam and fraud

Private State Token API

Glossary of acronyms

General feedback, no specific API/Technology

Show Relevant Content & Ads

Topics

FLEDGE

Measuring Digital Ads

Attribution Reporting (and other APIs)

Limit Covert Tracking

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

Privacy Budget

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

Shared Storage API

CHIPs

FedCM

Fight spam and fraud

Private State Token API

Glossary of acronyms

General feedback, no specific API/Technology

Show Relevant Content & Ads

Topics

FLEDGE

Measuring Digital Ads

Attribution Reporting (and other APIs)

Limit Covert Tracking

User-Agent Reduction

User-Agent Client Hints

IP Protection (formerly Gnatcatcher)

Privacy Budget

Strengthen cross-site privacy boundaries

First-Party Sets

Fenced Frames API

Shared Storage API

CHIPs

FedCM

Fight spam and fraud

Отчет об обратной связи - 4 квартал 2022 г.
bookmark_border Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.