Ежеквартальный отчет за второй и третий кварталы 2024 года, в котором суммируются отзывы экосистемы, полученные по предложениям Privacy Sandbox, и ответ Chrome.
В рамках своих обязательств перед CMA Google согласилась публично предоставлять ежеквартальные отчеты о процессе взаимодействия с заинтересованными сторонами для своих предложений Privacy Sandbox (см. пункты 12 и 17(c)(ii) Обязательств ). 22 июля 2024 года Google объявил, что не будет прекращать поддержку сторонних файлов cookie (3PC) в Chrome, и вместо этого предложил внедрить обновленный подход для расширения возможностей выбора для пользователей. Таким образом, с согласия CMA Google не представила CMA публичный отчет за второй квартал 2024 года, чтобы дать Google и CMA достаточно времени для принятия во внимание последствий объявления Google.
Эти сводные отчеты об отзывах Privacy Sandbox создаются путем объединения отзывов, полученных Chrome из различных источников, перечисленных в обзоре отзывов , включая, помимо прочего: «Проблемы GitHub», форму обратной связи, доступную на сайте Privacysandbox.com , встречи с заинтересованными сторонами отрасли и форумы по веб-стандартам. Chrome приветствует отзывы, полученные от экосистемы, и активно изучает способы интеграции полученных знаний в дизайнерские решения.
Темы отзывов ранжируются по распространенности каждого API. Это делается путем агрегирования количества отзывов, полученных командой Chrome по заданной теме, и упорядочения их в порядке убывания количества. Общие темы отзывов были определены путем анализа тем обсуждений на публичных собраниях (W3C, PatCG, IETF), прямой обратной связи, GitHub и часто задаваемых вопросов, возникающих во внутренних группах Google и в общедоступных формах.
В частности, были проверены протоколы совещаний органов по веб-стандартам, а для прямой обратной связи были рассмотрены записи Google о встречах заинтересованных сторон один на один, электронные письма, полученные отдельными инженерами, список рассылки API и публичная форма обратной связи. Затем Google координировал действия команд, участвующих в различных информационно-просветительских мероприятиях, чтобы определить относительную распространенность тем, возникающих в отношении каждого API.
Объяснения ответов Chrome на отзывы были разработаны на основе опубликованных часто задаваемых вопросов, реальных ответов на вопросы, поднятые заинтересованными сторонами, и определения позиции специально для целей этой публичной отчетности. Отражая текущую направленность разработки и тестирования, были получены вопросы и отзывы, в частности, в отношении тем, защищенной аудитории и API отчетов по атрибуции.
На отзыв, полученный после окончания текущего отчетного периода, Chrome может еще не ответить.
Глоссарий сокращений
- АРА
- API отчетов по атрибуции
- ЧИПСЫ
- Файлы cookie, имеющие независимое разделенное состояние
- ЦСП
- Платформа спроса
- ФедКМ
- Федеративное управление учетными данными
- ФПС
- Наборы для первой вечеринки
- IAB
- Бюро интерактивной рекламы
- ВПЛ
- Поставщик удостоверений
- IETF
- Целевая группа по интернет-инжинирингу
- ИП
- Адрес интернет-протокола
- openRTB
- Ставки в реальном времени
- ОТ
- Исходная пробная версия
- ПАТ API
- API защищенной аудитории (ранее FLEDGE)
- ПатКГ
- Группа сообщества частных рекламных технологий
- РП
- Доверяющая сторона
- РВС
- Сопутствующие наборы веб-сайтов (ранее — собственные наборы)
- ССП
- Платформа предложения
- ТРОЙНИК
- Доверенная среда выполнения
- UA
- Строка пользовательского агента
- UA-CH
- Подсказки для клиента User-Agent
- W3C
- Консорциум Всемирной паутины
- ВИПБ
- Умышленная IP-слепота
Общий отзыв, без конкретного API/технологии
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Прекращение поддержки сторонних файлов cookie (3PCD) | Каковы планы Google в отношении 3PCD и оценены ли долгосрочные последствия для индустрии цифровой рекламы? | Мы предлагаем обновленный подход, который расширяет возможности выбора для пользователей. Как указано здесь , вместо прекращения поддержки 3PC мы добавим в Chrome новый интерфейс, который позволит людям делать осознанный выбор, применимый к просмотру веб-страниц, и они смогут изменить этот выбор в любое время. Мы обсуждаем этот новый путь с регулирующими органами и будем взаимодействовать с отраслью перед его внедрением. |
| Выбор пользователя | Объявление о выборе пользователя повлияло на интерес экосистемы к внедрению решений Privacy Sandbox. Отзывы относительно объявления о выборе пользователя неоднозначны, включая запросы на такие функции, как возможности мониторинга. | Благодаря обновленному подходу, расширяющему выбор пользователей, для разработчиков по-прежнему важно иметь альтернативы межсайтовым идентификаторам, повышающие конфиденциальность. Хотя у нас пока нет подробностей о том, как будет выглядеть новый интерфейс, мы ожидаем значительного увеличения трафика без файлов cookie в Chrome. Это означает, что API-интерфейсы Privacy Sandbox остаются критически важными для бизнеса. Мы продолжим инвестировать в технологии Privacy Sandbox для дальнейшего улучшения конфиденциальности и полезности. |
| Пользовательский интерфейс выбора | Вопросы о сроках реализации функций отказа/согласия, типе рассматриваемой пользовательской опции и о том, как пользовательский интерфейс повлияет на среды автоматического тестирования. | В настоящее время у нас нет обновлений временной шкалы, которыми можно было бы поделиться. Когда мы решили не использовать 3PCD, мы хотели как можно скорее предоставить обновление экосистемы. Мы поделимся обновленной информацией о сроках по выбору пользователей, как только она у нас появится. |
| Тестирование Chrome | Запрос на постоянную доступность тестовых этикеток с поддержкой Chrome для оценки рыночного внедрения и экономического воздействия 3PCD после первого полугодия 2024 года. | Мы понимаем, что тестировщики захотят продолжать использовать помеченные группы браузеров для тестирования и координации, даже несмотря на то, что первое тестирование с поддержкой Chrome в 2024 году подошло к концу. Мы рассматриваем следующие шаги в отношении ярлыков с учетом объявления о выборе пользователей . Тем временем команда Chrome опубликовала намерение расширить поддержку помеченных групп браузеров посредством Chrome Milestone 132, который продлится до января 2025 года. |
| Песочница конфиденциальности на Android | Privacy Sandbox на Android и Privacy Sandbox на Chrome неразрывно связаны между собой, и мы не можем должным образом оценить Privacy Sandbox без Android. Типичный путь клиента, включающий аспекты взаимодействия между устройствами и мультитач, имеет решающее значение как для Privacy Sandbox в Chrome, так и для Privacy Sandbox на Android. | Обратите внимание, что Privacy Sandbox на Android не подпадает под действие обязательств Google перед CMA. Если отзывы касаются сроков и развертывания Android, на данный момент у нас нет никаких обновлений, которыми мы могли бы поделиться, кроме того, что мы продолжаем работать над Android, который мы рассматриваем как независимый рабочий поток по улучшению конфиденциальности. Как мы уже отмечали ранее, доступность API Privacy Sandbox на Android также будет определяться скоростью, с которой пользователи обновляют свои устройства, что не находится под контролем Google. |
| Режим B. Трафик ограничен. | Трафик рекламного аукциона, доступный в режиме B, оказался ниже ожидаемого. | Существует несколько причин, по которым объемы аукционов для Protected Audience API (PA API) могут оказаться ниже ожидаемых, например: - Известные нам компании, интегрировавшие PA API, включили только форматы баннеров. - Платформы продавцов не всегда могут начать аукцион. - В браузере может не быть групп по интересам (IG). - Ставок может не быть. Однако нам неизвестно ни о ком, кто пытался протестировать PA API и не получил трафика. |
| Видимость сбоев | Видимость сбоев и проблем, влияющих на API-интерфейсы Privacy Sandbox. | Существует общедоступная страница состояния API-интерфейсов Privacy Sandbox, которые предоставляют услуги вне браузера. Команда Chrome уделяет первостепенное внимание надежности нашей платформы и всех критически важных API-интерфейсов, используемых основными сайтами и сервисами в Интернете, включая технологии Privacy Sandbox. Пока произошел только один сбой. Это было связано с временной конфигурацией для тестирования на уровне 1%. Вскоре экспериментальная конфигурация, связанная с этим сбоем, больше не понадобится, поэтому мы уверены, что эта проблема не возникнет, как только API-интерфейсы будут включены в Chrome обычным способом. |
| Исследование графа файлов cookie | Какова точка зрения Chrome на метод CookieGraph, описанный в этом документе, в рамках Privacy Sandbox? | В документе поднимаются некоторые интересные моменты, связанные с обнаружением и распространенностью основных файлов cookie (1P), установленных доменами, отличными от тех, которые посещает пользователь. Как отмечается в документе, эти файлы cookie чрезвычайно полезны для сбора аналитики и информации о том, как пользователи взаимодействуют с веб-сайтом. Эти данные имеют решающее значение для разработчиков, чтобы предоставить пользователям лучший опыт просмотра. Основной аргумент статьи ошибочен, поскольку в ней куки-файлы 1P рассматриваются как вектор межсайтового отслеживания. Однако это верно только при очень агрессивных предположениях, изложенных в статье:
Обратите внимание, что это векторы повторной идентификации, которые можно использовать без использования файлов cookie 1P (например, посредством обмена данными на стороне сервера), и их необходимо решать отдельно от наших текущих усилий, которые сосредоточены на механизмах отслеживания на основе состояния. вроде 3шт. Наконец, мы хотим отметить, что в документе аналитические и рекламные файлы cookie приравниваются к файлам cookie отслеживания, а строго необходимые файлы cookie — к неотслеживающим файлам cookie, что не обязательно так. Действительно, 1P-аналитика или службы поставщиков, разделенные на сайты, такие как виджеты поиска магазинов, виджеты чата или файлы cookie балансировки нагрузки, часто могут быть ограничены только одним доменом, и, наоборот, некоторые строго необходимые файлы cookie могут использоваться для межсайтового отслеживания для борьбы с мошенничеством. целей. |
| UX-изменения | Изменения UX в Chrome 112, которые помещают элементы управления файлами cookie 1P в раздел «данные сайта на устройстве» настроек Chrome, могут затруднить пользователям блокировку всех файлов cookie. | Это изменение было внесено в рамках попытки отделить и повысить уровень управления 3PC (или неразделенным хранилищем) от всех других типов данных сайта. Элементы управления 3PC находятся на панели «Конфиденциальность и безопасность»; в то время как элементы управления файлами cookie 1P и всеми другими видами данных сайта, от которых обычно зависит критически важная функциональность сайта, объединены в раздел «Данные сайта на устройстве». Мы продолжим следить за отзывами по этой теме, но считаем, что нынешнее разделение обеспечивает хороший баланс между возможностью обнаружения значимых элементов управления конфиденциальностью и сохранением функционального опыта просмотра. |
| Счета и оплата | Счета и платежи не тестируются полностью, поскольку тестировщики больше внимания уделяют тестированию других областей API-интерфейсов Privacy Sandbox. | Когда и что разработчики и компании решат тестировать — это их выбор. API-интерфейсы, как правило, доступны для тестирования с сентября 2023 года . |
| Тестирование | Не весь экспериментальный трафик, который DSP получает от SSP, маркируется. Некоторые DSP заявили, что доля немаркированных экспериментальных показов может быть разной в экспериментальной и контрольной группах. | Chrome не может контролировать, будут ли компании отправлять ярлыки в запросах ставок. Мы предоставляем метод получения метки из браузера. Тогда экосистема должна передать метки партнерам, если их партнеры не могут прочитать эти метки напрямую. |
| 3PCD на Android WebView | Запрос рекомендаций по включению флага «Проверка отказа от сторонних файлов cookie» в Android WebView для тестирования прекращения поддержки. | По умолчанию в Android WebView блокируются 3 компьютера. |
| Дифференциальная конфиденциальность для снижения рисков при обучении модели | Почему дифференциальная конфиденциальность используется при обучении модели? | Дифференциальная конфиденциальность в сочетании с доверенными средами выполнения (TEE) необходима при обучении моделей для предотвращения утечки данных и защиты конфиденциальной информации от угроз. Такой подход гарантирует, что веса модели не смогут раскрыть данные отдельных пользователей. |
Регистрация и аттестация
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Регистрация | Запросить разъяснения о том, как работает аттестация регистрации между зарегистрированным источником и источником рекламной технологии с субдоменом www. | Рекламной технологии необходимо будет подключить только на https://example.com . Когда они размещают свое подтверждение в https://example.com/.well-known/privacy-sandbox-attestations.json , https://www.example.com распространяется, поскольку это субдомен. |
| Спецификация API | Предложение добавить в репозиторий схему JSON для файла аттестации. | Мы рассматриваем это предложение и приветствуем дополнительные отзывы здесь . |
Показывайте релевантный контент и рекламу
Темы
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Взвешивание тем | Самое важное, что нужно понимать в Темах, — это редкость данного сигнала. Текущая структура должна развиваться, чтобы можно было добавлять значение веса рядом с каждой наблюдаемой темой. Вес будет относительным весом данной темы для браузера по сравнению со всеми браузерами, использующими эту тему. | Нам хотелось бы дальше понять, почему редкость сигнала является наиболее важным сигналом. Мы приветствуем дополнительные отзывы от экосистемы о полезности этого варианта использования здесь . |
| Темы Надежность | Google необходимо со временем предоставить более строгие гарантии надежности тем. | Изменения в наши API будут по-прежнему вноситься на основе отзывов экосистемы и будут публично обсуждаться до внесения изменений. Наше предложение о пересмотренной структуре управления обеспечит дополнительные гарантии. |
| Классификатор | Сайты издателей часто неправильно классифицируются или им назначаются темы слишком высокого уровня, чтобы служить каким-либо значимым целям. | Как указано в нашем пояснении по классификации тем , сайты классифицируются с помощью комбинации переопределенного списка, составленного человеком, содержащего наиболее популярные сайты, и модели машинного обучения на устройстве. Chrome продолжает оценивать возможности сайтов, которые могут внести свой вклад в классификацию тем. Любые улучшения коммунальных услуг должны быть сопоставлены с рисками конфиденциальности и злоупотреблений. Например, некоторые из рисков включают в себя: - сайты, использующие самомаркировку как метод кодирования различных (и потенциально конфиденциальных) значений тем; и - сайты, атакующие темы с целью притупить их полезность для других (например, рассылая спам в темы пользователя бессмысленным шумом). Публика может проверить эти компоненты с помощью инструментов, доступных на chrome://topics-internals или в этой совместной работе . Мы ожидаем, что в ходе тестирования со временем классификация улучшится, и мы приветствуем отзывы о примерах сайтов, которые могут быть неправильно категоризированы. |
| Вопрос по API | Обеспокоенность тем, что API Topics дает постоянные и антиконкурентные преимущества SSP, которые монетизируют плохой контент. | Как и в случае с 3PC, браузер не зависит от того, кому он возвращает темы, если этот объект зарегистрирован и подтвержден. |
| (Также сообщалось в предыдущих кварталах) Полезность для различные типы заинтересованные стороны | Поскольку классификатор тем в настоящее время использует только имя хоста страницы для определения соответствующих тем, крупные сайты с разнообразным контентом предоставляют общие темы, в то время как небольшие сайты предоставляют нишевые темы с большей рекламной ценностью. | Наш ответ аналогичен предыдущим кварталам: Как и в случае с 3PC, существует разница в ценности информации, предоставляемой разными сайтами. Нишевые сайты непоследовательны в своем ценностном вкладе: не все нишевые сайты имеют коммерчески ценный контекст и, следовательно, приносят меньшую ценность. Это сайты, которым будет полезен API Topics. Мы рассмотрели возможность классификации на уровне страницы, а не на уровне сайта, однако такая классификация сопряжена с рядом серьезных проблем с конфиденциальностью и безопасностью. |
| Классификатор | Небольшим объектам часто присваивается неточная классификация или вообще не присваивается классификация, поэтому они не могут участвовать в обмене ценностями. | Что касается предполагаемого вреда, то конкретные сайты, которые потенциально неправильно классифицированы, страдают от этого не больше, чем другие сайты, учитывая, что контекстная информация сайта всегда будет доступна для аукционов на их сайте, что предоставит информацию, сопоставимую с правильной темой, даже в случае ошибочной классификации. Темы обычно используются для сбора потенциально полезной рекламной информации с внешних веб-сайтов, а не с собственных сайтов. |
| Версия таксономии | Как мы можем получить доступ к версии таксономии, чтобы обеспечить обратную совместимость? | Версия таксономии является частью заголовка запроса, отправляемого с запросом на выборку с включенной темой. Например, если заголовок «(1 2);v=chrome.1:2:5, ();p=P000000000», то версия — chrome.1:1:2. Где chrome.1 — это версия конфигурации, 2 — версия таксономии, а 5 — версия модели. Это описано в спецификации и также добавлено в объяснитель . |
| Данные тем | Запросить разъяснения по поводу обновления данных Тем. | Обновление таксономии не указано. Это обеспечивает производителям браузеров гибкость в реализации. Сказав это, вот эвристика обновления таксономии Chrome с V1 до V2: - Для тем из V1 и V2 поддерживается единое дерево таксономии. - Один и тот же идентификатор темы имеет одно и то же значение. - Дерево только растет – добавляя новые темы или связи, но никогда не уменьшаясь. - Однако некоторые темы или ссылки могут быть «неактивными» в версии, что может создать впечатление удаления или реорганизации. Примеры: - «Пикапы» теперь имеют «Грузовики, фургоны и внедорожники» в качестве промежуточного родительского элемента. - «Изучение иностранного языка» теперь имеет «Образование» в качестве второго родительского элемента, а его исходный родительский элемент «Справочник» становится неактивным. Влияние «неактивных» тем: эти темы не будут использоваться для новой классификации. Однако они по-прежнему учитываются при принудительной блокировке пользователей: если пользователь заблокировал тему в версии 1, его дочерние темы останутся заблокированными в версии 2 (даже если дочерняя тема отображается под другим родительским элементом в версии 2). |
| Классификатор | Стремление понять причины и возможные варианты исправления ошибочных классификаций. | Во-первых, мы хотели бы отметить, что определение Chrome тем сайта должно использоваться просто в качестве входных данных для его алгоритма тем для определения интересов пользователя в рекламных целях. Он не разработан для других, более общих целей классификации. Мы заинтересованы в общей точности нашей модели классификации и стараемся улучшить ее точность/напомнимость, где это возможно, но на глобальном уровне, а не на уровне классификации отдельных сайтов. Это связано с тем, что неправильная классификация, если она все же происходит, не наносит вреда отдельному сайту, который был неправильно классифицирован, а скорее снижает качество сигнала Темы при выборе рекламы на других сайтах. При выборе рекламы на неправильно классифицированном сайте реальные темы сайта уже известны этому сайту и могут использоваться в качестве входных данных для рекламных запросов. Мы приветствуем дополнительные отзывы здесь . |
| API-тестирование | Можно ли тестировать темы и API-интерфейсы Privacy Sandbox с помощью Chromium? | API Topics не поставляется с Chromium, он поставляется с Chrome. |
| Темы звонящего | Запрос на повышение дополнительной ценности тем с использованием сервисов TEE для рекламных технологий, чтобы поддержать затраты на расширенный анализ с соблюдением требований конфиденциальности. | Мы ответили на аналогичный отзыв здесь . Мы рассмотрели обратную частоту, и в конечном итоге после моделирования обратной частоты мы обнаружили, что она плохо коррелирует с ценностью темы, как в зависимости от ценности, предоставляемой покупателями и продавцами. Мы приветствуем дополнительные отзывы здесь . |
| Спецификации API | Могут ли настройки когорты интересов браузера блокировать API Topics? | Мы ответили на этот отзыв здесь . API тем является развитием FLoC и учитывает политику разрешений FLoC. Как указано в пояснении : «Примечание: старая политика разрешений:interest-cohort=() из FLoC также запрещает вычисление тем». |
| Рейтинг тем | Получая «5 самых популярных тем», будем ли мы учитывать частоту посещений веб-сайта на основе каждого подходящего звонящего или всегда учитывать всю историю посещений браузера? Кроме того, ранжируются ли темы для каждого звонящего отдельно? | Он основан на частоте подмножества историй посещений. Запись истории просмотров (страница) имеет право участвовать только в том случае, если на странице был хотя бы один абонент в Темах. Более подробную информацию о хранении истории тем можно найти здесь . Как указано в нашем объявлении об улучшениях API тем , рейтинг зависит от частоты, а также от двоичного уровня приоритета (более подробную информацию см. здесь и здесь ). Однако это не зависит от частоты звонков. Обратите внимание, что это не означает, что все абоненты смогут получить все 5 лучших тем в следующей эпохе. Как указано в пояснении: «Эту тему могут получить только абоненты, которые наблюдали, как пользователь посещал сайт по рассматриваемой теме в течение последних трех недель». Браузеру необходимо отслеживать, какой абонент просматривал топ-5 тем (что соответствует 5-ти топ-темам с доменами вызывающего абонента в спецификации). Мы приветствуем дополнительные отзывы по этому вопросу здесь . |
API защищенной аудитории (ранее FLEDGE)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| (Также сообщалось в предыдущих кварталах) Затраты | Запускать TEE в публичных облаках дороже, чем в локальных центрах обработки данных рекламных технологий? | Наша текущая модель безопасности TEE опирается на практику реализации общедоступных облаков (подробнее см. в пояснении требований к общедоступному облаку TEE ). Например, современные аппаратные TEE не защищают от всех физических атак. Наши существующие поддерживаемые поставщики общедоступных облаков, AWS и GCP, разработали и внедрили средства снижения рисков физического доступа, в том числе со стороны сотрудников. Хотя некоторые рекламные специалисты упомянули нам, что использование облачных сервисов обходится дороже, чем локальные центры обработки данных рекламных технологий, другие рекламные технологии работают в общедоступных облаках, будь то из-за затрат или других преимуществ. Мы продолжаем рассматривать варианты расширения нашей поддержки TEE, в том числе за пределами публичных облаков. В рамках этого мы исследуем локальные центры обработки данных и взаимодействуем с экосистемой, чтобы изучить потенциальные решения для предоставления такой поддержки. На данном этапе исследований мы не можем гарантировать, что это приведет к работоспособному решению для экосистемы. |
| PA API и Google Ad Manager (GAM) | GAM не может добиться справедливого рыночного результата. GAM не может своевременно показывать рекламу, сообщать, сколько объявлений было показано с помощью PA API, и не предлагает возможности настройки того, какой метод будет выбран для показа рекламы, например, путем отключения PA API для определенных рекламных мест. | Ответ Менеджера рекламы Google: GAM работала и продолжает работать над оптимизацией задержки при показе рекламы через API PA, чтобы дополнительный доход издателя от спроса на API PA перевешивал любые затраты, понесенные из-за дополнительной задержки на аукционе PA API. Наше первоначальное тестирование показывает, что издатели видят чистую выгоду от PA API от трафика без 3PC, указывая на то, что дополнительный спрос на PA API перевешивает любые затраты из-за задержки. Более подробную информацию о нашем подходе можно найти в разделе часто задаваемых вопросов . Кроме того, GAM предоставляет издателям отчеты о рекламе, показываемой через API PA. Сюда входят объявления, показываемые, когда GAM является продавцом компонентов, и объявления, показываемые другими продавцами компонентов, когда GAM является продавцом верхнего уровня. Более подробную информацию об отчетах можно найти в нашем Справочном центре . Наконец, GAM позволяет издателям включать или отключать использование API PA для своего трафика с помощью элемента управления в пользовательском интерфейсе (подробности см. в нашем Справочном центре ). Мы открыты для рассмотрения отзывов о дополнительных средствах управления, которые могут пожелать издатели, и будем определять приоритетность любых запросов на функции в соответствии с нашим стандартным процессом определения приоритетов функций. |
| PA API и GAM/AdX | Похоже, что Google занял позицию: он просто не будет покупать показы PA API, по которым GAM не принимает окончательное решение о продаже, подобно тому, как AdWords покупает только у себя. Это выглядит просто злоупотреблением рыночным положением, поскольку GAM/AdX может отправить конфигурацию аукциона компонентов альтернативному продавцу верхнего уровня, как и любая другая биржа. | Ответ менеджера платформы Google Рекламы: Это не позиция Google. Платформы покупателя Google (Google Реклама и DV360) покупают показы на биржах, не принадлежащих Google. Это справедливо как для показов API PA, так и для показов API без PA. |
| Реакция рынка | Опасения Mozilla: Защищенная аудитория Google защищает рекламодателей (и Google) больше, чем вас . | Мы ценим оценку Mozilla и продолжим учитывать отзывы Mozilla на форумах по общедоступным стандартам. Темой их оценки является то, что текущая реализация PA API еще не обеспечивает все запланированные меры защиты . Наш подход к выходу на рынок с использованием PA API направлен на то, чтобы найти правильный баланс между поощрением внедрения и внедрением защиты конфиденциальности как можно скорее. В рамках этого мы разработали план постепенного введения ограничений конфиденциальности, чтобы лучше облегчить интеграцию с API, а также дать нам время для сбора большего количества отзывов, которые мы можем включить в будущие средства защиты (например, функции VAST в Огороженные рамы). Мы также приветствуем недавние сообщения Mozilla о ее собственном подходе к конфиденциальности и цифровой рекламе: « Свободный и открытый Интернет не должен осуществляться в ущерб конфиденциальности » и « Улучшение онлайн-рекламы с помощью продуктов и инфраструктуры ». |
| (Также сообщалось в предыдущих кварталах) Результаты аукциона | Запросите единый аукцион, чтобы вернуть несколько URL-адресов рендеринга с соответствующими оценками, что упрощает дедупликацию встроенной рекламы и позволяет избежать проблем с пользовательским интерфейсом и задержек. | Наш ответ аналогичен предыдущим кварталам: Мы рассматривали возможность совместного использования нескольких URL-адресов renderURL и их соответствующих оценок на одном аукционе API PA, но не реализовали это из соображений конфиденциальности. Мы понимаем желание избежать многократного показа одного и того же объявления пользователю на одной странице и рассматриваем этот запрос. Мы приветствуем дополнительные отзывы от экосистемы о том , какая дополнительная поддержка необходима в PA API для оптимальной поддержки варианта использования нативной рекламы. |
| Производительность | Опасения по поводу задержки, влияющей на PA API. | Мы слышали опасения по поводу задержки, и это одна из причин того, что мы разработали ряд функций в рамках API PA, которые позволят SSP как устанавливать ограничения на задержку DSP, так и вносить улучшения, которые могут уменьшить задержку. . Недавно мы обновили наше руководство по лучшим практикам работы с задержкой , которое включает дополнительную информацию о том, как воспользоваться преимуществами этих функций. Мы также продолжаем разрабатывать новые улучшения задержки, некоторые из которых можно увидеть здесь . |
| Продавцы высшего уровня | Google должен предоставить издателям возможность выбирать альтернативных продавцов на аукционах PA API верхнего уровня. | PA API не зависит от того, кто инициирует аукцион как в случае с одним продавцом, так и в случае с несколькими продавцами. Отдельные компании сами решают, поддерживать ли аукционы PA API и если да, то как. |
| (Также сообщалось в предыдущих кварталах) Негативный таргетинг | Запрос решения случая использования, когда рекламодатель не хочет показывать рекламу определенной аудитории. | Мы поддерживаем негативный таргетинг на IG посредством дополнительных (контекстных) ставок, что решает проблемы, когда рекламодатель не хочет показывать рекламу определенной аудитории. Подробности можно найти в этом объяснителе и в этом выпуске GitHub . Мы также изучаем решения для поддержки негативного таргетинга IG для ставок PA API и будем рады получить дополнительные отзывы здесь . |
| (Также сообщалось в предыдущих кварталах) Нативная реклама | Запрос на поддержку Fenced Frame для нативной рекламы. | Мы рассматриваем возможность поддержки этого варианта использования и обсуждаем возможные обходные пути и решения здесь . |
| Веб-представление | Запрос разъяснений по поводу сценария, в котором IG присоединился к Chrome, был недоступен для аукциона, проводимого в WebView. | Мы хотим поддерживать эти варианты использования, как только будет доступна достаточная инфраструктура конфиденциальности. На данный момент у нас нет никаких дополнительных объявлений, но мы приветствуем дополнительные отзывы здесь . |
| Отрицательные ИГ | Запрос на обновление обработки URL для поддержки отрицательных IG через зарождающуюся функцию заголовка. | Мы рассматриваем этот запрос и приветствуем дополнительные отзывы здесь . |
| Фильтрация разнообразия | Запрос руководства о том, как реализовать фильтрацию разнообразия при запуске собственной рекламы в PA API с несколькими продавцами и несколькими аукционами. | Мы обсуждаем этот запрос здесь и будем рады дополнительным отзывам. |
| (Также сообщалось в предыдущих кварталах) Блокирующие фильтры | Запрос рекомендаций о том, как обеспечить соблюдение правил «блокировки издателей» (фильтров) при запуске собственной рекламы в PA API с несколькими продавцами. | Мы поделились здесь рекомендациями и будем рады дополнительным отзывам. |
| Ограничения | Запрос на разрешение ограничений на уровне домена, а не на уровне поддомена. | Ограничения на уровне субдомена или источника соответствуют базовой модели безопасности Интернета, поэтому это наш дизайн по умолчанию. Более подробно мы обсуждали это здесь и здесь . |
| Доверенное назначение ставок | Запрос пользовательского агента и связанных с ним клиентских подсказок в запросах доверенных сигналов назначения ставок. | Мы отслеживаем этот запрос на добавление функции и будем рады получить дополнительные отзывы здесь . |
| (Также сообщалось в предыдущих кварталах) Несколько ИГ | Используйте несколько IG в одной ставке. | Сегодня это не поддерживается в PA API, поскольку это приведет к изменению базовой модели конфиденциальности. Мы приветствуем дополнительное обсуждение здесь . |
| (Также сообщалось в предыдущих кварталах) Производительность | Перенос большего количества логики на клиент может ухудшить производительность страницы и UX, что потенциально ухудшит показатели SEO веб-сайта. | Мы обсуждаем этот вопрос и приветствуем дополнительные отзывы здесь . |
| Динамика аукциона | PA API уменьшает информацию о динамике аукционов (например, кто участвует, кто выигрывает каждый проданный на аукционе компонент и т. д.), что снижает возможности отслеживания издателей и затрудняет определение того, выполняются ли сделки. | Решение по отслеживанию сделок мы предложили здесь . Мы планируем изменить некоторые существующие поля и создать несколько новых полей в объекте IG для хранения идентификаторов DealID и SeatID, а также разрешить им распространяться из генерирования Bid в ScoreAd или выходить через отчеты на уровне событий. Это должно обеспечить адекватную поддержку варианта использования сделки. Мы приветствуем отзывы о других метаданных, которые рекламные специалисты считают критически важными для динамики аукционов и для сохранения возможности отслеживания для издателей. Мы призываем специалистов по рекламе предоставить конкретные примеры метаданных, на которые они ссылаются, и указать, от какой стороны к какой стороне они должны передаваться. |
| ГАМ | Обеспокоенность по поводу требования использовать GAM в качестве рекламного сервера издателя для доступа к спросу AdX. | Ответ Google Ad Manager: GAM не требует, чтобы издатели использовали функции своего рекламного сервера для доступа к функциям обмена. |
| (Также сообщалось в предыдущих кварталах) Аукцион компонентов | Победители аукциона компонентов PA API будут видны GAM, что вызывает обеспокоенность по поводу неравного доступа к информации. | Наш ответ остается неизменным по сравнению с предыдущими кварталами: Ответ Google Ad Manager: «В течение многих лет мы уделяем пристальное внимание справедливости аукционов, включая наше обещание, что никакая цена из любого из негарантированных рекламных источников издателя, включая цены негарантированных позиций, не будет передана другому покупателю до того, как он сделает ставку на аукционе. , что мы позже подтвердили в наших обязательствах перед Французским антимонопольным органом. Что касается аукционов PA API, мы намерены сдержать свое обещание и не делиться ставкой любого участника аукциона с любым другим участником аукциона до завершения аукциона с участием нескольких продавцов. Чтобы внести ясность: мы не будем делиться ценой контекстного аукциона с каким-либо компонентным аукционом, включая наш собственный, как объясняется в этом обновлении. Более того, мы не используем информацию о конфигурациях аукционов компонентов, включая сигналы, предоставляемые покупателями SSP, в рамках нашего собственного аукциона. Фактически, мы приветствовали бы изменения в API PA, которые позволят продавцам компонентов указывать конфигурации своих аукционов компонентов таким образом, чтобы это было скрыто от продавца верхнего уровня». |
| ГАМ | Будет ли GAM запрашивать долю дохода за проведение аукционов верхнего уровня или отчетность по ним, если GAM не участвовал ни в создании аукционов компонентов API IG, ни в PA? | Ответ Google Ad Manager: Когда издатели решили использовать GAM в качестве своего рекламного сервера, GAM запустит аукцион верхнего уровня и взимает плату за объявление AD за функциональность Ad Server (ту же плату за обслуживание AD, которая применяется за пределами аукционов PA API). Однако, если выигрышная реклама поступает от продавца не GAM, что означает, что GAM не участвовал ни в создании аукциона IG или PA API, - GAM не обрабатывает выставление счетов и не взимает процентный платеж на медиа. |
| Кличок | Придерживается ли регистрация событий Click. | В настоящее время эта функция не планируется подвергать ограничениям «k-anon», поскольку «количество кликов» будет доступно только в качестве браузернала внутри функции generateBid() ; Он не доступен в качестве нового атрибута в отчетности на уровне событий. |
| Производительность | Высокие выходные затраты из -за безусловного ответа на запросы на контекстуальные заявки. | Мы не можем напрямую предоставить информацию, о которой DSP имеют IGS из -за проблем с конфиденциальностью. Тем не менее, мы исследуем альтернативные решения, которые могут дать понимание при сохранении конфиденциальности. |
| Нативная и внешняя реклама | Запрос об обновлениях о перспективе Chrome относительно местной и внешней рекламы. | Позиция Chrome зависит от рассматриваемого варианта использования. На видео позиция Chrome заключается в том, что наша задача состоит в том, чтобы поощрять экосистему сходиться на жизнеспособных видео -решениях с использованием наших API. До сих пор единственное конкретное предложение, о котором мы знаем, - это предложение GAM . На родном мы активно собираем обратную связь здесь и планируем привлечь рекламные технологии с большим количеством шагов обнаружения в ближайшее время. |
| Мониторинг в реальном времени (RTM) | Маркированный трафик не отправляет отчеты RTM. | Мы знаем об этом пробеге и работаем над тем, чтобы обеспечить решение. Мы поделимся обновлением, когда будут доступны здесь . |
| Поддержка расширения аудитории | Запрос об обновлении поддержки для аудитории/продавших аудиториев в PA API. | Мы работаем, чтобы обеспечить решение этого варианта использования. Мы собираем отзывы от экосистемы о том, что мы должны создавать и поддержать. Мы поделимся обновлением, когда доступно, и мы приветствуем дополнительные отзывы здесь . |
| Отладка | В инструменте разработчика Chrome нет панели для контроля подробной производительности PA API. Например, на общую производительность может повлиять количество IG или количество покупателей. | Хотя эта конкретная обратная связь связана с возможностями пользовательского интерфейса Developer Chrome для помощи в мониторинге, 7 октября мы представили возможность AD Techs настраивать пользовательские события, которые можно использовать в качестве основы для мониторинга и оповещения. Здесь доступны более подробная информация, и мы надеемся, что это обновление будет рассмотрено материалом этой обратной связи. Мы приветствуем какие -либо дополнительные отзывы об этой функции, будь то связанные с поддерживаемыми точками данных или опытом разработчика в соответствующем обсуждении GitHub здесь . |
| Сигналы | Опасения относительно того, могут ли DSP обеспечить отправку Perbuyersignals SSP независимы от результатов контекстуального аукциона. | Предполагается, что контекстный аукцион имеет только одну победную заявку от одного DSP, или, лучше, сказала одна попытка победить с последующим аукционом PA API. Для потока PA API SSP решает пригласить все DSP, которые они хотят увидеть, есть ли у них требование (в форме IG на устройстве). Вполне возможно и на самом деле очень вероятно, что DSP, который проиграл контекстуальный аукцион, «повторно вводится» для участия в аукционе PA API. В этом «повторном заводе» DSP, если он решит принять, будет направлено на SSP любые сигналы, которые проверка рекламы захочет убедиться, что DSP рассматривает, если существует, если существует для этой кампании. Другими словами, на аукционе PA API всегда есть способ представить PerbuyerSignals SSP независимо от того, что произошло на контекстуальном аукционе. |
| Сигналы | Запрос на добавление PrevClicks в объект BrowserSignals, переданный в generatedBid() . | Этот запрос может быть разрешен с помощью нашего предложения для поддержки сигналов клика. Мы объявили эту функцию в нашем недавнем сообщении в блоге и соответствующем объяснении . Мы приветствуем дополнительные отзывы об этом предложении здесь . |
| (Также сообщается в предыдущих кварталах) Моделирование сигналов | Запрос на увеличение количества бит моделирования сигналов с 12 бит до 30 бит. | Мы ответили на этот отзыв с помощью встречного предложения здесь . Мы активно взаимодействуем с отраслью, чтобы понять их мнение о нашем предложении, и в настоящее время даем преимущества для отрасли от влияния на пользователей Chrome и других заинтересованных сторон. |
| Документация | Запрос на руководство о том, как использовать ключ/значение (K/V) серверы и футболки. | Руководство по использованию TEE в контексте K/V доступно в деталях проектирования модели Trust Service Service . |
| Время отрицательных IG | Запрос о продлении срока службы отрицательных IG до 365 дней. | Негативные IG используются для предотвращения показы рекламы, но плохие участники все еще могут использовать ее для раскрытия информации о пользователях, что приводит к рискам повторной идентификации (например, один из способов атаки-это просто нанести высокие предложения с отрицательными IG. Узнайте, есть ли пользователь или не посещал определенные сайты). Если мы сохраним 365-дневный TTL, то у плохих актеров будет гораздо больше данных о отрицательных IG, что приведет к значительно большим рискам конфиденциальности. Поэтому мы не можем поддержать этот запрос, чтобы защитить конфиденциальность пользователей. |
| API спецификации | Что можно вставить в качестве значений, которые должны быть переданы как часть Perbuyersignals? Может ли это быть произвольно определено продавцом? | Perbuyersignals - это место для продавцов, чтобы предоставить покупателям любую информацию, которую они хотят предоставить на аукционе. Для экосистемы решать, что они хотят вставить там, но мы приветствуем здесь дополнительную дискуссию. |
| Macro Macro Size | Поиск руководства вокруг макро -замены размера рекламы не работает. | Мы скоро поделимся более подробной информацией в ближайшее время. |
| POST BID SSP MACRO замена: URL -адреса на верхнем уровне. | Какие механизмы могут представить Chrome, чтобы позволить поставщикам проверки проверить URL верхнего уровня в рамках песочницы конфиденциальности? Существуют ли альтернативные точки данных или сигналы, которые можно использовать в огороженных рамах, чтобы обеспечить точность URL-адреса верхнего уровня, предоставленного SSP? | В настоящее время мы обсуждаем этот приветственный дополнительные отзывы здесь . |
| Запрос функции | Запрос о предоставлении низкопроизводительной UACH при извлечениях обновлений и отправке отчетов в режиме реального времени. | Эти запросы обсуждаются здесь , и мы приветствуем дополнительные отзывы здесь и здесь . |
| Запрос функции | Запрос на то, чтобы доверенный сервер согласился на то, чтобы активировать дизайн отладки, когда был запускается данный клиент для отправки отчетов по уровню событий forDebuggingOnly.reportAdAuctionWin() forDebuggingOnly.reportAdAuctionLoss() | Это активный запрос, который мы в настоящее время отслеживаем, и предоставим обновление экосистемы, когда она доступна. Мы приветствуем здесь дополнительные отзывы. |
| Использование API | Запрос на руководство о том, как считать уникальный охват пользователей и охват впечатлений. | Мы обсуждаем предложение о том, как прочитать IGS из рабочей диплома общей хранилища, о которой вы можете отправить частные совокупные отчеты. Здесь доступны более подробная информация, и мы приветствуем отзывы о предложении и его полезности для экосистемы. |
| Использование API | Отсутствие ясности в отношении того, что издатели должны проверить, какие API важны, что следует включить и что должно произойти. | Предпринимаются усилия, направленные на то, чтобы лучше поддержать издателей и их роли в экосистеме. |
| Использование API | Можно ли добавить слушателей событий к аукционным мероприятиям? | Это невозможно с помощью нормальных событий, но события протокола Chrome Devtools частично будут обращаться к этому варианту использования. Обратите внимание, что регулярные события могут влиять на свойства изоляции/конфиденциальности, но здесь доступны подробности. |
| К-анонимность | Поиск разъяснения по требованиям vendering (например, не менее 50 человек видели бы объявление, если бы ему было разрешено показать). | Документация разработчика предоставляет обзор наших ожиданий в отношении будущих событий. В частности, это объясняет, что начальный порог K-анонимности составляет K = 10 человек. Список рассылки Blink-Dev содержит обновления о том, что происходит вживую в Chrome. Как указано в потоке списка рассылки K-анонимности , в настоящее время мы экспериментально обеспечиваем требование K-анонимности примерно на 1% от хромированного стабильного трафика и никогда не применяем его на явно помеченном («режим A» и «режим B») срезы. |
| Багажник | Можно ли временно удалить или уменьшить пониженную крах | Эти типы запросов обрабатываются только для непроизводственных экземпляров, где баловка может контролироваться. Для производственных экземпляров хлокинг все еще требуется. Мы можем оценить ситуацию, как только получим отзыв от использования не сбыта. |
| Багажник | Запрос добавить флаг, чтобы отключить бахринг от дать отладости/не продлите бинарную. | Этот флаг предоставлен релизом 1.0.0 . |
| API ошибка | API перестал работать после обновления до Chrome 126, хотя API был включен в настройках. | Было установлено, что эта проблема связана с хромированным флагами «включенные рамы», который был включен пользователями в целях разработки. Сброс этого флага по умолчанию решит проблему. |
| Отчетность | Запрос на то, чтобы сделать API отчетности в режиме реального времени, не зависит от продавца для покупателей. | Этот запрос рассматривается здесь . Решение RTM было выпущено недавно, и мы приветствуем обратную связь, в частности, от тех рекламных технологий, которые уже наградились на эту функцию. |
| Отчетность | Запрос на 3P отчетность; В то время как DSP и SSP получают уведомления от впечатлений от Chrome, технические поставщики среднего уровня по умолчанию не делают. | Мы обсуждаем этот запрос и приветствуем здесь дополнительные отзывы. |
Защищенные аукционные услуги
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Футболки | Требование Google о вручении в соответствии с техническими стандартами является сильным ограничением выбора облачного поставщика. Применяемые технические стандарты можно следовать без посещения Бюро облачных провайдеров, как это имеет в виду Google. Поздняя задержка альтернативных поставщиков в 2025 году (самое раннее) неприемлема, поскольку она будет вводить сетевые эффекты, поощряющие опрокидывание решений Google. | Служба агрегации-единственная услуга, необходимая для запуска в службе TEE для решения некоторых вариантов использования AD-технологий. Служба агрегации поддерживает как Amazon Web Services (AWS), так и Google Cloud Platform (GCP). Основываясь на обратной связи от AD Techs, мы считаем, что такая поддержка адекватна на этом этапе. На дополнительных облачных провайдерах - Google опубликовал подробные критерии для тройников на общественных облачных провайдерах. Они предназначены для обеспечения того, чтобы решение TEE соответствовало конфиденциальности и целям безопасности песочницей конфиденциальности. В частности, конфиденциальность Sandbox Tee-серверы обрабатывают незашифрованные пользовательские данные по перекрестному сайту (например, данные из издателей и сайтов рекламодателей для службы агрегации). Они должны быть в безопасности, чтобы соответствовать целям конфиденциальности пользователей API. Безопасная среда также необходима для обеспечения того, чтобы API продолжали защищать конфиденциальную деловую информацию компаний (например, не позволяя другим участникам API API добраться до собственных бизнес -данных покупателя). Насколько нам известно, в настоящее время нет технологии TEE, которая полностью защищает пользовательские данные от потенциально состязательного оператора. Поэтому мы включаем несколько требований для проверки достоверности облачного провайдера. Мы не уверены, что относится «Бюро облачных поставщиков», и это не является частью требований. Мы приветствуем любые отзывы о требованиях. Мы также продолжаем оценивать поддержку новых поставщиков, в том числе на основе запросов на представленные с использованием процесса, определенного в объяснении . До сих пор мы получили только запрос на поддержку Azure, который мы оцениваем. |
| B & A. | Трудно оценить техническую сложность и выполнимость сервиса B & A, поскольку проект продолжает развиваться. | Чтобы решить эти проблемы, мы предоставили подробные объяснения GitHub , объясняющие дизайн B & A, опубликованные сроки доступности и дорожную карту функций, поддерживающих PA API. Мы поддерживаем рекламные технологии, которые стремятся развернуть B & A и собирать отзывы от экосистемы на GitHub . |
| B & A. | Поиск руководства и лучшего способа вычисления стоимости использования TEE для B & A, чтобы начать использовать его или мигрировать, чтобы использовать его с настройки. | Недавно мы опубликовали Руководство по размеру экземпляра k/V сервера , которое включает в себя инструменты для более точного измерения затрат. |
| K/v сервер | AD-проверки, с просьбой иметь возможность использовать полный URL-адрес на сервере K/V для выполнения проверки рекламы. | В настоящее время мы оцениваем возможность предоставления полного URL -адреса страницы для сервера K/V, работающего в TEE в целях проверки рекламы. Полный URL -адрес страницы не будет доступен в K/V BYOS. |
| Аукционная безопасность | Поиск функций безопасности аукциона, чтобы гарантировать, что плохие субъекты не получают доступ к конфиденциальным данным и не действуют как подражатели - какие функции защищают аукцион от атак повторного воспроизведения и как можно реализовать меры безопасности? | Текущая модель безопасности B & A может защитить целостность аукциона. B & A работает в футболке , которая защищает конфиденциальность сигналов AD Techs и кода от вредоносных актеров. В архитектуре B & A, зашифрованная полезная нагрузка на запрос B & A течет от клиента через ненадежный рекламный сервер для SellerFrontend Service (SFE, запуская SSP в TEE). Запрос Ciphertext содержит идентификатор генерации на основе TimeStamp. SFE изучит метку времени запроса и отклонит любые воспроизводимые запросы, не в течение +/- N секунд времени сервера. В дополнение к этому, B & A может вернуть полезную полезную нагрузку ответа с фиксированным размером для сервера для сервера. Эти решения могут помочь смягчить атаки воспроизведения через систему, когда вредоносный актер пытается воспроизвести ту же полезную нагрузку, чтобы узнать больше о ее содержании. B & A находится в процессе документирования и обновления моделей безопасности в объяснениях. |
| Сигналы через K/v сервер | Запрос включить Perbuyersignals, отправленные через услугу K/V в рамках запроса о доверенных сигналах по торгам от Chrome. | Мы оцениваем осуществимость включения информации из PerbuyerSignals, перенесенной на K/V -сервер, работающий в футболке, включая полный URL -адрес страницы. |
| K/v сервер | Запрос на более поэтапный график принятия для ограничений конфиденциальности в K/V и B & A. | Мы понимаем стремление к более поэтапному подходу к принятию TKV и ценим ваши конкретные запросы относительно K/V и B & A. Однако после тщательной оценки мы решили не ослаблять защиту конфиденциальности в этих API в настоящее время. Мы считаем, что эти меры, такие как бахроны, имеют решающее значение для защиты конфиденциальности пользователей и поддержания доверия к песочнице конфиденциальности. |
| K/v сервер | Поиск руководства о том, как масштабировать хранилище K/V через совместимую конфигурацию. | Недавно опубликованное руководство по определению размеров экземпляра K/V может помочь здесь. Инструмент предоставит QP (отмеченные как «RPS» в объяснении ) при каждой комбинации параметров. |
| K/v сервер | Добавьте информацию о продавцах в запросе сервера K/V. | Мы обсуждаем это и приветствуем дополнительные отзывы здесь . |
| K/V + B & A Службы | Запрос, чтобы уточнить временную шкалу выпуска или дорожную карту для K/V и B & A. | Как для K/V, так и для B & A, у нас есть этапы и сроки: Для сервера K/V в сочетании с аукционами PA API On-Device (VS B & A) Общественная временная шкала доступна здесь . С точки зрения того, как «общая доступность» определяется для K/V, см. Раздел дорожного карты , который определяет набор функций для бета и GA. Для B & A см. Общественную временную шкалу здесь и дорожную карту здесь . Мы определяем тестирование масштаба как «полное стабильное тестирование масштабирования производства» - см. Здесь для конкретного набора функций на этом этапе. B & A также имеет альфа и бета -этапы, поэтому тестирование в масштабе будет включать в себя супер-набор функций предыдущих этапов. Как для K/V, так и для B & A, дайте нам знать, если эти определения этапа помогут дать ясность относительно того, что будет доступно, когда. Если есть еще пробелы, пожалуйста, дайте нам знать. Мы рады сделать их более конкретными, чтобы помочь информировать планирование. |
Измерение цифровой рекламы
Отчет о атрибуции (и другие API)
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Рыночный ответ | Требование о конкурирующих системах атрибуции использовать только отчетность на уровне событий и сводную/совокупную отчетность в условиях жестких границ, является произвольным ограничением конкуренции. Он предотвращает ретаргетинг и атрибуцию в реальном времени на уровне событий, даже если введены гарантии для обеспечения соответствия защите данных (например, де-идентификация). | Упомянутый дизайн основан на целях конфиденциальности API - например, защиты межсайтовой информации, передаваемой с одного сайта на другой. Например, ARA поддерживает атрибуцию на уровне событий через отчеты о событиях. Отчеты о событиях отложены как минимум один час, что необходимо, чтобы затруднить связь отчета об уровне событий с идентичностью пользователя на сайте рекламодателя, используя атаки по боковым каналам, как задокументировано здесь . Кроме того, существуют другие способы сделать атрибуцию, кроме ARA, такие как непосредственное сбор информации от пользователей, которые сознательно предоставляют идентифицирующие данные. Мы открыты для отзывов о вариантах использования, которые не могут быть достигнуты с текущими границами конфиденциальности APIS Sandbox Confication. |
| Многоповерхностная | Запрос на подтверждение о том, поддерживают ли API API API ARA и Shared Multi-APIS и где это свидетельствует. | В настоящее время ARA и Shared Storage не поддерживают атрибуцию многоповерхностного (Cross Device). Поддерживается Cross App и веб -атрибуция на том же устройстве (через ARA). |
| (Также сообщается в предыдущих кварталах) Межсетевая | Поддерживает ли ARA преобразования перекрестных устройств? | Наш ответ похож на предыдущие кварталы: Cross-Device представляет новые проблемы конфиденциальности поверх 3PC, а также добавляет проблемы с распространением технологий, учитывая диапазон устройств и платформ, которые может использовать пользователь. Мы исследуем потенциальные решения, но мы сосредоточены на критических вариантах использования, в настоящее время поддерживаемых ARA, и в настоящее время не имеют графиков для поддержки межсетевого происхождения. |
| Масштабирование | Опасения по поводу того, настроен ли в настоящее время настройка API отчета о атрибуции (ARA) и может быть надежно развернут и масштабируется для обслуживания всех пользователей Chrome. | ARA в настоящее время доступна для всех пользователей Chrome и работает как ожидалось. Кроме того, мы продолжаем проверять и контролировать его надежность и масштабируемость, так как число тестирования AD -технологических компаний, тестирующих ARA, продолжает увеличиваться. Мы приветствуем дополнительные отзывы экосистемы относительно этого здесь . |
| (Также сообщается в предыдущих кварталах) Дедупликация | Опасения относительно того, как ARA предлагает ограничить механизм атрибуции на устройствах, так что издатели не могут эффективно выполнять логику после атрибуции для сводных отчетов, включая вывод нескольких конверсий одинакового типа для одного и того же щелчка рекламы. | Наш ответ остается неизменным из предыдущих кварталов: Дедупликация между устройствами и измерениями - это известная и текущая задача, с которой AD Techs также сталкиваются сегодня с 3PC. С помощью ARA AD -технологии могут решить, когда регистрировать конкретные преобразования, и добавить конкретные метаданные, чтобы указать, какие трубопроводы измерения они использовали для отслеживания конверсий (то есть часть ключа агрегации), которые можно сравнить с другими трубопроводами измерения. Мы приветствуем дополнительные отзывы экосистемы относительно этого здесь . |
| Отслеживание конверсий | Запрос на возможность работы с преобразованием из нескольких доменов. | Мы обсуждаем этот запрос здесь и приветствуем дополнительные отзывы экосистемы. |
| Отчетность | Браузер ждет не менее двух дней, но до 30 дней, чтобы отправить конверсию, которое может быть причиной для беспокойства, учитывая, что большинство рекламодателей заинтересованных сторон являются рекламодателями производительности, которые работают почти в режиме реального времени. | Настройки по умолчанию для отчетов на уровне событий имеют следующие окна отчетности по умолчанию: 2 дня, 7 дней и 30 дней. С гибкой отчетной рекламой на уровне событий Techs могут изменить число и продолжительность отчетности Windows из значений по умолчанию. Отчетность Windows может быть изменена как минимум 1 час, что может помочь при использовании рекламодателя производительности. Мы приветствуем дополнительные отзывы экосистемы относительно этого здесь . |
| Атрибуция онлайн-к-офф | Будут ли какие-либо варианты реализации для онлайн-к-офф-линии в ARA, или есть какие-либо другие предложения для измерения атрибуции в автономном режиме? | В настоящее время нет планов для поддержки вариантов использования измерений в Интернете до Offline в ARA. Существуют значительные проблемы конфиденциальности и безопасности, которые необходимо учитывать для такого типа поддержки. Мы приветствуем дополнительные отзывы экосистемы относительно вариантов использования этой поддержки здесь . |
| Отчеты отладки | Как хранить и/или извлекать ADID таким образом, чтобы он был доступен для доступа к регистрации Chrome (Source/Trigger) для атрибуции приложения к WEB? | Чтобы включить отчеты отладки, рекламная технология должна доказать нам, что они уже могут присоединиться к пользователю в приложении и в Интернете, и это сделано для обеспечения того, чтобы в отчетах отладки не было обнаружено никакой новой информации. Ad Tech может доказать соединение, предоставив ключ Join, который является уникальным для каждого пользователя. Этот ключ соединения может быть Adid или может быть ключом соединения 1p. Если AD Tech использует ADID, Chrome не национально поддерживает доступ к Adid из браузера, и API ожидает, что каждая технология AD будет иметь свой собственный метод передачи ADID во время регистрации в Интернете. |
| Ковша гранулярность | Можно ли использовать разные стратегии ведра для каждого рекламодателя? | Мы рекомендуем экспериментировать с различными подходами масштабирования бюджета, чтобы найти тот, который лучше всего подходит для ваших вариантов использования. ARA была сделана с намерением быть гибким и настраиваемым для удовлетворения различных вариантов использования AD-технологий. Поэтому мы рекомендуем экспериментировать с различными стратегиями ведения на одного рекламодателя или на вертикали. Использование различных стратегий ведения может быть полезно, когда у рекламодателей есть различия в значениях измерения, которые они заинтересованы в отслеживании и объеме значений измерения. |
| Документация | Запрос на дополнительную документацию для реализации приложения <> Web для ARA. | Мы выпустили документацию по приложению <> Web для ARA здесь . |
| Производительность | Количество запросов, связанных с ARA, потенциально может быть тяжелой нагрузкой на сервере издателя по сравнению с количеством запросов Keepalive, которые необходимы для питания указанного сайта. Окрашенное исходное событие в одном запросе может помочь уменьшить загрузку на сервере. Одна потенциальная идея состоит в том, чтобы разрешить массив кодируемых JSON объектов | Совместное использование источников, основанных на конкретной логике, возможна в определенной степени, используя логику JavaScript в комбинации с API. В настоящее время мы оцениваем этот запрос и приветствуем дополнительные отзывы от экосистемы здесь . |
| Запрос функции | Предложение об обходном предложении из-за отсутствия поддержки интеграции сервера к серверу. | В настоящее время мы не планируем реализовать поддержку интеграции сервера к серверу в ARA. Существует множество проблем с конфиденциальностью, которые необходимо дополнительно рассмотреть возможность для поддержки интеграции сервера к серверу. Мы приветствуем отзывы от экосистемы в отношении дополнительных вариантов использования для поддержки сервера к серверу здесь . |
| Документация | Запрос на «быстрое» руководство, которое объясняет ключевые части ARA/Как встать и работать с несколькими простыми вариантами использования. | Руководство для быстрого начала для ARA доступно здесь . В этом году мы работаем над улучшением этой документации и приветствуем дополнительные отзывы о конкретных вариантах использования или сценариях, которые требуют дополнительной документации здесь . |
| Использование API | Запрос на рекомендации по масштабированию вкладов для многих небольших значений. | Мы рекомендуем экспериментировать с различными подходами масштабирования бюджета, чтобы найти тот, который лучше всего подходит для ваших вариантов использования. Для сценария многих небольших значений мы рекомендуем экспериментировать с различными значениями Epsilon, чтобы идентифицировать точки перегиба, при которых шум от Epsilon может быть приемлемым для вашего варианта использования. Более подробная информация доступна в нашем исследовательском документе об оптимизации сводного отчета в ARA. |
| Гибкий уровень событий | Когда будет реализован гибкий уровень событий (несколько триггерных характеристик)? | В настоящее время гибкий уровень на уровне событий поддерживает настройку следующих аспектов конфигурации регистрации: количество отчетов, которые могут быть сгенерированы для каждого источника, количество и длину отчетных окон и кардинальность данных триггера. В настоящее время мы собираем дополнительные отзывы экосистемы относительно дополнительных гибких улучшений на уровне событий, но не планируем реализовать какие-либо в настоящее время. Мы приветствуем дополнительные отзывы о вариантах использования, которые могут извлечь выгоду из некоторых гибких улучшений на уровне событий, перечисленных здесь . |
| Обработка ведра | Запрос на рассмотрение завершения агрегированных взносов для ведер, а также будущей расширяемости и обратной совместимости. | Мы обсуждаем этот запрос и приветствуем здесь дополнительные отзывы. |
| Эпсилон | Что происходит с диапазоном Epsilon, как только ARA изменит общую доступность? | ARA достигла общей доступности на Chrome в 3 -м квартале 2023 года. В настоящее время не существует плана для изменения окна значения Epsilon. Наше предложение о пересмотренной структуре управления предоставит дополнительные гарантии, если предусмотрены любые модификации. |
| Отчетность | Отчеты о Trigger-unknown-error не содержат атрибутов источника в органе отчета. | Как изложено в спецификации , в теле в отчете не требуется, чтобы другие поля были присутствовать в теле для триггера-снятия . Мы признаем, что таблица, описывающая поля в органе отчета, потенциально вводит в заблуждение, так как поля, связанные с источником, могут присутствовать или не присутствовать в зависимости от основной причины ошибки. Например, внутренняя ошибка может возникнуть до того, как произойдет логика сопоставления источников, что означало бы, что исходные данные не доступны для заполнения отчета отладки. Документация теперь была обновлена, чтобы уточнить это. |
| Использование API | При работе с двумя целями измерения, подсчетом и стоимостью, является ли признак разделения как бюджета взносов, так и Epsilon? | Работая с двумя целями измерения, мы рекомендуем разделить бюджет взносов между ними. |
| Отчетность | Поддерживает ли ARA Attribution или Assist Attribution или отчеты о помощи (отчеты о взносах)? | ARA в настоящее время не поддерживает отчеты о призыве Multi-Touch или Assist. В настоящее время у нас нет планов для реализации этого. Мы приветствуем дополнительные отзывы о вариантах использования и их приоритете здесь . |
| API ошибка | Для ARA документация гласит, что XOR используется для комбинирования клавиш агрегации источника и агрегации запуска, но на практике или используется. Это расхождение приводит к путанице и потенциальным ошибкам в реализации. | Документация была обновлена, чтобы отразить, что это ошибка. |
Служба агрегации
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Работа по агрегации | Запрос разрешить несколько префиксов в заданиях агрегации. | Мы расследуем этот отзыв и опубликовали здесь предложение. Мы приветствуем отзывы о предложении здесь . |
| Запрос функции | Запрос на изменение сценария Terraform, чтобы, если service_account_token_creator_list не установлен (или пуста), то изменение учетной записи IAM политика пропускается. | Мы расследуем эту проблему здесь и приветствуем дополнительные отзывы экосистемы. |
| Использование API | Необходимы разъяснения в отношении плана терраформ, всегда показывают изменения. | Эта проблема была исправлена в выпуске AGS 2.8 . |
| Использование API | Поиск рекомендаций по настройке настроек для каждого развертка для частоты агрегации с гибкой фильтрацией вкладов. | Отказ от рекламодателя в настоящее время возможен с ARA. Гибкая фильтрация взносов может быть использована для более продвинутых случаев, когда AD Tech хочет дополнительно сегментировать взносы отчета по разным частотам. AD Techs могут узнать больше о партии здесь и использование идентификаторов фильтрации с ARA здесь . Мы также работаем над дополнительной документацией для фильтрации идентификаторов. |
| Запрос функции | Запросить поддержку для `log_sum_exp` в службе агрегации (AGS). | Мы обратились к этой заинтересованной стороне для получения более подробной информации об использовании. Мы предоставим обновление, когда у нас будет более подробная информация. |
| Запрос функции | Запрос, чтобы иметь возможность увидеть больше журналов/идей/других метрик всякий раз, когда возникают проблемы с AGS и потенциальные проблемы на развернутых AG. | Мы опубликовали обновления в нашу документацию, чтобы включить здесь больше ошибок, смягчения и описаний. Мы приветствуем дополнительные отзывы о любых ошибках/метрик/журналах и т. Д., Которые не документированы или доступны, и какие детали будут полезны здесь . |
| API -тестирование | Каким будет конечное значение Epsilon после тестового периода? | В настоящее время нет плана изменить окно значения Epsilon. Мы призываем тестеров экспериментировать с различными параметрами и обеспечивать обратную связь. |
| Отчетность | Отчет генерируется, но также все еще получает privacy_budget_authorization_error в коде по возвращении. | Мы предоставили руководство по указанию правильного происхождения отчетности и обширных отчетов, чтобы избежать этой ошибки. Мы приветствуем дополнительные отзывы по этому вопросу, в частности, если есть повторяющиеся ошибки. |
| Ключевое открытие | Каковы планы на ключевое предложение об обнаружении? | У нас еще нет временной шкалы для развертывания предложения Key Discovery, но мы приглашаем обратную связь от экосистемы по предложению здесь . |
| Кастомизация | Поиск параметров настройки, доступных для службы агрегации. | Настройки службы агрегации невозможны в тройнике, но возможны для некоторых компонентов за пределами футболки. Это связано со стандартами конфиденциальности и безопасности, которые мы должны поддерживать в тройнике. Мы работаем над обновлением нашей документации, чтобы помочь рекламным технологиям понять архитектуру и какие компоненты настраиваются. Мы не сможем поддерживать определенные настройки, поэтому мы рекомендуем AD Techs использовать наши стандартные конфигурации, где это возможно. |
| Стоп против случаев по требованию | Была протестирована система с использованием экземпляров точечных экземпляров по сравнению с экземплярами по требованию? Есть ли какие -либо конкретные недостатки для использования точечных экземпляров, помимо их потенциальной временной недоступности? | Мы не расставляли приоритеты в тестировании на точечные экземпляры, потому что мы рекомендуем рекламным технологиям использовать экземпляры по требованию. Недостатком спотовых экземпляров будет работа, которая будет прервана во время потребления бюджета. Если бюджет был использован, и работа прерывается до того, как рекламная технология получит сводный отчет, AD Techs не просто смогут повторить работу, но им необходимо потребовать восстановления бюджета . Восстановление бюджета рекомендуется только для катастрофических неудач для сохранения конфиденциальности. Мы рекомендуем AD Techs настройку AutoScaling, чтобы помочь минимизировать затраты. Выбор 0 для автоматического масштаба означает, что не будет выполнения экземпляров, пока не будет запрошено задание (обратите внимание, что это может увеличить задержку, так как экземпляры будут раскрыты во время запроса). |
| Известные ошибки и решения | Необходимо разъяснения в отношении задания службы агрегации, показывающая «Ошибка обслуживания» | Эта проблема была решена здесь . Мы также обновили некоторые из наших сообщений об ошибках, чтобы сделать их более описательными. Например, мы начали бросать более конкретные ошибки разрешения/автозаправления на AWS, в отличие от ранее, когда эти ошибки были обнаружены как внутренние ошибки. Мы обновили документацию по кодам ошибок и шагам смягчения здесь и приветствуем дополнительные отзывы об ошибках, которые не задокументированы или доступны, и какие детали будут полезны здесь . |
Частная агрегация API
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Ключевой дизайн | Запрос на частное руководство по проектированию ключей агрегации | Несмотря на то, что у нас нет специального руководства по частному агрегации, как в качестве ресурсов можно использовать как структуру тестирования нагрузки на загрузку службы агрегации , так и руководство управления передовым управлением ключами . |
| Бюджет взносов | On what level is the contribution budget calculated and limited? | The contribution budget is 2^16 in a rolling 10 minute window and 2^20 in a rolling 24 hour window. |
Limit Covert Tracking
User Agent Reduction/User Agent Client Hints
No feedback received this quarter.
IP Protection (formerly Gnatcatcher)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Андроид | What is the plan to roll out IP Protection to Android? | While we are exploring bringing anti-covert tracking features to Android, including IP Protection, we don't have formal plans to share at this time. |
| API Usage | Question on if there is or will be an anti-fraud exception for IP Protection? | We strive to strike a balance between protecting users from being tracked across the web based on their IP addresses while minimizing disruption to the normal operations of servers, including the use of IP addresses for anti-abuse. While we cannot provide more details at the moment, we expect to provide them in the near future and look forward to continuing the discussion. |
| Bad Actor Identification | Concerns regarding the effectiveness of traditional security measures against malicious IP addresses. | IP Protection will not proxy 1P requests, so we expect most Intrusion Detection Systems will not be impacted. We plan to provide additional details in the future that address anti-fraud and site breakage concerns for incognito users. |
| IP Address Masking | If the news publisher site (1P) uses the same domain with the advertising site (3P), will the IP address be masked for both? If not, how does one distinguish the two? | IP Protection currently proposes a list-based approach to identify which third-party traffic goes through the proxies. However, even if an origin is on that list, it won't be proxied if accessed in a 1P context. We are finalizing the details regarding which specific 3P domains will be prioritized initially and how we'll precisely define 1P and 3P contexts for IP Protection. |
| IP Address Masking | Concern about IP protection and its impact on anti-fraud systems. | 1Ps are not impacted by our IP Protection plans, so sites such as forums should have access to IP addresses for dispute resolution. We plan to provide additional details in the future that address advertising fraud concerns. |
| IP Address Masking | Is the IP masked in the header for impacted domains? | Users will be assigned to a geographic area based on their pre-proxy IP address representing their current location. You can find more details here . |
Bounce Tracking Mitigation
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| API Spec | Clarification needed on the behavior of Chrome's handling of extended navigation when a tab is closed. | We have resolved this issue here and updated the specification accordingly. |
| Nav Tracking | Discussion of a tracking mitigation approach involving a finite set of links to reduce entropy in cross-site requests. | We are continuing to discuss this topic with other browser vendors here , and welcome additional feedback and any specific proposals on this issue from the ecosystem. |
Privacy Budget
As noted in the GitHub explainer and developer site , Privacy Budget is no longer being actively
considered as part of the Privacy Sandbox proposals.
Strengthen cross-site privacy boundaries
Related Website Sets (formerly First-Party Sets)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| (Also reported in previous quarters) Related Website Set (RWS) Domain Limit | Request to increase the limit of Associated domains within RWS | Our response is similar to previous quarters: At present, we do not expect to increase the numeric limit. The limit was established based on user privacy considerations, feedback from ecosystem stakeholders in the W3C, and consideration of comparable implementations in other browsers. For additional information, please see our blog posts ( 1 , 2 ). We recommend examining use cases that require cross-site cookie access beyond the numeric limit, and consider leveraging our guidance for identity use-cases , authenticated embeds , and advertising use cases . If the user sessions are tied to login actions, we would recommend using the Federated Credential Management (FedCM) API to maintain functionality. We welcome feedback on other use cases which may be required here . |
| Cross-site cookie handling | Cross-site cookies set by a subdomain are not being passed in subsequent requests from the primary domain. The problem persists even with proper CORS and credential configurations. | We provided guidance here regarding correct usage of the requestStorageAccessFor API needing to specify the full origin (ie include subdomains) in order for cross-site cookies to be sent on subsequent fetch requests. |
| User Choice | Request for further information regarding requestStorageAccessFor used by RWS after the rollout of user choice, in particular how the implicit or explicit user gesture, which currently allows access to 3PCs, will function in the new system. | We expect that the behavior of RWS in either user choice mode, (ie, regardless of whether users have chosen to retain or limit their 3PCs) will be consistent with existing/shipping behavior in Chrome with 3PCs allowed vs. 3PCs blocked with RWS enabled ("Allow related sites to see your activity in the group" setting). We recommend invoking hasStorageAccess first to check whether the embed already has access to unpartitioned cross-site cookies before invoking requestStorageAccess. The hasStorageAccess method will return true if the user chose to allow 3PCs. requestStorageAccessFor currently does not require a user gesture if 3PCs are allowed. We have opened a new GitHub issue to discuss and specify what the right behavior should be in this case, and welcome additional feedback from the ecosystem. |
| API Usage | Concerns about the lack of clarity regarding the use of RWS for "commercial" purposes, hindering their adoption. The stakeholder indicated interest in grouping publications for targeted advertising. | The intended use of RWS is to support core site functionality and core user journeys. We encourage using our purpose-built advertising APIs for use cases related to targeted advertising. |
| API Usage | Report of an issue with requestStorageAccess where they could set localStorage data but not cookies. | The issue was caused by a typo in the SameSite attribute. Ensure correct spelling and explicitly set it to None for 3PCs. |
| API Spec | Discrepancies in the JSON schemas across the repository, such as the misplacement of the "contact" field and suggestions for improvements, including the use of the "oneOf" keyword to ensure consistency. | We are investigating this feedback and will look into making these improvements to the schema in the near future. We welcome additional feedback here . |
| Third-party (3P) access to RWS | With given user consent, allow an outlet to indicate the 3P domains that will also have such access to the RWS API data. | Allowing 3Ps to combine their own unpartitioned data with RWS site data would undermine Privacy Sandbox's cross-site tracking protections. However, we are considering the potential for enabling 3Ps to maintain data partitioned to an RWS and are seeking feedback on the design for such a solution here . |
Fenced Frames API
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| API Question | Concerns on how Fenced Frames with no network access could break brand safety and fraud protection for advertisers. | We are tracking this concern in the context of our plan to enforce Fenced Frames. We will start looking soon into solutions that are compatible with Fenced Frames enforcement and as soon as proposals exist that are material enough we will share them. |
| API Question | Is Fenced Frames API still scheduled for 2026? | As stated in our public announcement , Fenced Frames will be required no sooner than 2026. |
| API Bug | When reportEvent() successfully sends click data from a cross-origin subframe, setReportEventDataForAutomaticBeacons() does not overwrite the top frame's data. | We are discussing this issue and welcome additional feedback here . |
Shared Storage API
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| App Advertising | There is no equivalent of the Shared Storage API in Privacy Sandbox on Android. | We are evaluating solutions on Android based on use case needs and platform constraints. We do not have any plans to share at the moment, but we welcome additional feedback from the ecosystem on this issue. |
| API Usage | Confusion regarding the need for an additional javascript worklet for implementation for Shared Storage API. | We are investigating this feedback and looking into potentially updating our documentation to explain the need for additional worklet scripts for Share Storage API. |
| Unreliability | Shared Storage API could change significantly or be dropped based on the privacy criticisms, making it an unreliable base to build on. | We do not have plans to significantly change or drop the Shared Storage infrastructure. The main changes that have been announced are to the Select URL output gate where fenced frames will be required and event level reporting will be deprecated. However these changes will not go into effect until at least 2026. |
ЧИПСЫ
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Partitioned Cookies | Chrome does not differentiate partition keys based on frame ancestors, unlike Firefox, leading to inconsistencies. | Chrome adopted the "ancestor chain bit" to resolve the security concern and discrepancy with Firefox's behavior. We have set this out in further detail here . |
| Partitioned Cookies | Embedded iframes with different storage access levels share and overwrite the same partitioned cookie, causing inconsistencies in authentication states. | For this particular configuration, our recommendation is to use unpartitioned cookies with an invocation of Storage Access API. We have discussed this in further detail here . |
| Partitioned Cookies | Will partitioned cookie jars be cleared when 3PCs are disabled? Is there a way to test this behavior? | We do not have any plans to share at this time. However, developers can test this functionality by manually deleting partitioned cookies via the Chrome DevTools Application>Cookies panel. |
FedCM
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Identity Provider (IdP) Registration Scope & Organization Chooser | Question on extending IdP registration from the current same-origin policy to a same-site policy. This change would allow broader and more flexible identity management, such as enabling a university's welcome page to register multiple subdomain-based identity providers without needing separate origin-specific registrations. Feedback on improving debuggability, handling approved clients for silent mediation, clarifying cookie behavior, allowing customization of the popup wording, and addressing timeout issues. | We acknowledge this feedback and are considering how an organization chooser could be incorporated into FedCM. We welcome additional feedback from the ecosystem here as we continue to refine this approach. |
| IdP Cookies | Discussion on the impact of implementing short-lived session cookies as part of the Device Bound Session Credentials (DBSC) proposal. Concerns are raised about user experience in FedCM, where expired IdP cookies require a user-visible modal for renewal. | The proposed DBSC should allow for cookie renewal without user interaction, ensuring continuous user experience. We have discussed this issue in further detail here . |
| API Spec | Question on appropriateness of using "NetworkError" in the FedCM API specification when the size of the "providers" array is not equal to 1. | We agree that "TypeError" would be more appropriate for this situation since it reflects a coding error rather than a network issue. We will consider this change and explore the possibility of removing this restriction in future updates as we progress towards multi-IdP support. We welcome additional feedback here . |
Fight spam and fraud
Private State Token API (and other APIs)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Deprecation Trial & Mode B | Concerns about the deprecation trial, Mode B testing, the potential discontinuation of Private State Tokens (PSTs), and the possibility of a new API better suited for their anti-fraud use case. | The deprecation trial and Mode B testing remain unchanged. We will communicate any updates through the dev blog . We have no plans to discontinue PSTs and we are discussing ongoing feature development and updates on GitHub . We have not announced any new APIs, but we welcome feedback on how PSTs can better address anti-fraud use cases. |
| API Feedback | Request for the capability of revoking tokens to address an anti-fraud use case. | While the issuer could revoke all tokens by changing the keys they use, individual token revocation is infeasible with the API as it would require allowing the issuer to associate token issuance and redemption which breaks the PST privacy model of preventing tracking between the two events. |