Ежеквартальный отчет за первый квартал 2024 года, в котором суммируются отзывы экосистемы о предложениях 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-интерфейсов «Темы», «Защищенная аудитория» и «Атрибуция».
На отзыв, полученный после окончания текущего отчетного периода, Chrome может еще не ответить.
Глоссарий сокращений
- АРА
- API отчетов по атрибуции
- ЧИПСЫ
- Файлы cookie, имеющие независимое разделенное состояние
- ЦСП
- Платформа спроса
- ФедКМ
- Федеративное управление учетными данными
- ФПС
- Наборы для первой вечеринки
- IAB
- Бюро интерактивной рекламы
- ВПЛ
- Поставщик удостоверений
- IETF
- Целевая группа по интернет-инжинирингу
- ИП
- Адрес интернет-протокола
- openRTB
- Ставки в реальном времени
- ОТ
- Исходная пробная версия
- ПАТ API
- API защищенной аудитории (ранее FLEDGE)
- ПатКГ
- Группа сообщества частных рекламных технологий
- РП
- Доверяющая сторона
- РВС
- Сопутствующие наборы веб-сайтов (ранее — собственные наборы)
- ССП
- Платформа предложения
- ТРОЙНИК
- Доверенная среда выполнения
- UA
- Строка пользовательского агента
- UA-CH
- Подсказки для клиента User-Agent
- W3C
- Консорциум Всемирной паутины
- ВИПБ
- Умышленная IP-слепота
Общая обратная связь, без конкретного API или технологии.
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Управление | Интерес к периоду общественного обсуждения любых обновлений управления Privacy Sandbox. | Мы открыты для разумных отзывов заинтересованных сторон о любых существенных событиях, касающихся Privacy Sandbox, включая будущее управление Privacy Sandbox. |
| Тестирование | Дополнительные этапы тестирования для 3PCD в дополнение к текущему 1%-ному тестированию с поддержкой Chrome. | Мы не намерены предлагать тестирование с помощью Chrome, превышающее текущий 1% трафика Chrome, включенный с начала января. |
| Интернет в приложение | 3PCD на мобильных устройствах не должно происходить до тех пор, пока не будет достигнута полная совместимость между Интернетом и приложением. | Мы согласны с тем, что желательно поддерживать совместимость приложений и веб-сайтов, запустили измерение атрибуции между приложениями и веб-сайтами и изучаем решения для таргетинга между приложениями и веб-приложениями. Однако мы не планируем откладывать выпуск 3PCD в мобильном Интернете. У нас нет цели обеспечить 100%-ный охват в конце 3PCD. Скорее, мы ожидаем, что совместимость на Android для перекрестных приложений и веб-измерений будет достаточно высокой на уровне 3PCD и будет увеличиваться со временем по мере того, как пользователи обновляют свои телефоны. |
| Роль браузера | Chrome, похоже, берет на себя роль рекламного сервера или SSP. | Chrome не берет на себя роль рекламного сервера или SSP. С помощью PA API Chrome предоставляет контейнер для рекламных серверов, SSP, DSP и других рекламных технологий, позволяющих реализовать собственную логику назначения ставок и оценки. |
| Руководство по использованию | Более четкое руководство о том, какие варианты использования будут поддерживаться API-интерфейсами Privacy Sandbox. | В начале проекта Privacy Sandbox документация для разработчиков была в первую очередь ориентирована на вовлечение разработчиков в процессы обсуждения и обратной связи по всем предложениям. Это означало, что контент, как правило, был структурирован вокруг понимания мотивации и концепций проекта, а затем подробностей ранней разработки и деталей тестирования каждого предложения. Это было эффективно для создания реальной экосистемы сотрудничества при разработке предложений, но по мере того, как API стали общедоступными, появилась новая аудитория разработчиков, которые здесь в первую очередь для того, чтобы опираться на API, а не вносить вклад в их базовую разработку. Недавно мы обновили навигацию по адресу Developer.google.com/privacy-sandbox , чтобы она была ориентирована на варианты использования, используя те же категории, что и IAB Tech Lab в ее недавнем отчете рабочей группы Privacy Sandbox. Мы продолжим развивать этот подход к документированию, основанный на прецедентах. |
| Местная среда разработки | Как нам продолжить разработку и тестирование нашего интерфейса локально на http://localhost, если файл cookie имеет значение SameSite=Secure, а серверная часть находится под управлением CDN? | Мы обсуждаем этот вопрос здесь и приветствуем дополнительные отзывы от экосистемы. |
| Смягчение последствий 3PCD | Есть ли программный способ узнать, что 3 компьютера заблокированы или когда эвристика активна? | В Chrome как обнаружение функции, так и document.hasStorageAccess , вызываемый в iframe, позволяют разработчику узнать, имеет ли источник в iframe доступ к 3 компьютерам. |
| Видео тестирование | В настоящее время невозможно протестировать видеорекламу в Privacy Sandbox. | Сегодня Chrome опубликовал обсуждение и демонстрацию нескольких возможных способов создания видео с помощью PA API (см. 242 и 254 в нашем репозитории демонстраций на GitHub). Обратите внимание, что они предназначены не для примера кода, который рекламные специалисты будут использовать массово, а скорее для проверки концепции и демонстрации методов, которые могут поддерживать рендеринг видео VAST с помощью PA API. В ходе этого обсуждения также стало ясно, что, хотя рендеринг видео уже возможен сегодня, Chrome мог бы внести некоторые изменения, которые упростили бы реализацию с помощью PA API. Например, обновления замены макросов (обсуждаемые здесь ), которые мы уже планировали реализовать на основе отзывов о сценариях использования безопасности бренда стороннего средства проверки рекламы, также будут учитывать отзывы в варианте использования видео, где покупатель ищет, какие макросы продавца использовать при рендеринге. Большинство обсуждений до сих пор было сосредоточено на рендеринге видеорекламы VAST. При рендеринге нативной рекламы можно использовать те же подходы, и во многих отношениях это проще. Кажется, что нативному контенту в настоящее время уделяется меньше внимания, чем видео, но это всего лишь вопрос расстановки приоритетов в индустрии рекламных технологий, а не каких-либо технических препятствий для внедрения. |
| Измерения без рекламы | 3PCD может повлиять на решения по измерению аудитории, не связанные с рекламой. | API-интерфейсы измерения не требуют, чтобы вариант использования был связан с рекламой. В то время как ARA более специфичен для типичного рекламного путешествия, частное агрегирование является универсальным. Эти два строительных блока можно использовать для решения широкого спектра измерительной деятельности. |
| Создатели контента | Privacy Sandbox создана таким образом, чтобы поощрять создателей контента создавать больше контента для YouTube и меньше — на своих сайтах. | Инициатива Privacy Sandbox направлена на сохранение конфиденциальности действий людей в открытом и бесплатном Интернете. Мы знаем, что издатели полагаются на рекламу для создания контента и обеспечения его максимально широкой доступности. Рекламодатели помогают людям открыть для себя новые продукты или предложения, которые им могут понадобиться. Функции Privacy Sandbox позволяют веб-сайтам всех типов, в том числе тем, которые работают с создателями контента, показывать людям полезную рекламу на основе их активности с различными сторонами, не раскрывая этим сторонам личность пользователя. |
| Более четкие сроки | Более четкие и подробные графики выпуска технологий Privacy Sandbox. | Документация по API Privacy Sandbox включает страницы состояния и доступности API. На этих страницах перечислены предстоящие функции и их сроки (например, PA API , ARA ). Здесь представлен центральный взгляд на эти статусы. |
| Машинное обучение | Рекламные технологии не смогут должным образом обучать модели машинного обучения до тех пор, пока 3PCD не превысит 1%. | Расширение 3PCD для большего количества браузеров для тестирования не гарантирует, что API-интерфейсы будут использоваться чаще, что, по-видимому, и есть то, что ищут рекламные специалисты для дальнейшего обучения моделей машинного обучения. Если более широкое использование экосистемы — это не то, к чему стремятся рекламные специалисты для дальнейшего обучения моделей машинного обучения, то нет причин расширять 3PCD, поскольку рекламные технологии, желающие обучать модели на большем трафике, могут сделать это сегодня без увеличения 3PCD. Это можно сделать так, чтобы Chrome не продвинулся вперед на 3PCD до окончания периода ожидания. |
| Неподдерживаемый вариант использования | Варианты использования DSP для самообслуживания в настоящее время не рассматриваются. | Существует несколько DSP самообслуживания, которые регулярно предоставляют публичные отзывы об API. Некоторые из тех DSP, которые регулярно предоставляют публичную обратную связь, также указали себя в качестве тестировщиков . Кроме того, Chrome активно занимается типичными темами DSP самообслуживания, такими как видео и сторонние рекламные серверы. Эти темы были затронуты в недавних еженедельных вызовах API PA . |
| Исходная пробная версия | Запрос на OT для сайтов, желающих более агрессивно наращивать мощность и тестировать 3PCD. | Chrome в настоящее время разрабатывает собственный OT, который позволит источникам согласиться на поэтапный отказ от 3PC. У источников верхнего уровня, которые регистрируются для участия в этой пробной версии и развертывают токены, 3 компьютера будут заблокированы, как если бы на пользовательском устройстве была включена защита от отслеживания. Этот ОТ предоставит предприятиям ценную возможность провести более широкое тестирование долгосрочных альтернатив 3PC перед окончательным прекращением использования 3PC, которое запланировано после консультаций с CMA. Мы все еще работаем над окончательным определением сроков внедрения OT. |
| Отчет технической лаборатории IAB | Отзыв о Privacy Sandbox получен из отчета технической лаборатории IAB. | Подробно на отчет IAB Tech Lab мы ответили здесь . Мы также признали там, что «отчет поднимает вопросы, касающиеся фрагментированной документации, коммерческих требований, стороннего аудита, отраслевой аккредитации, масштабируемости, прозрачности и будущего управления, над которыми мы будем сотрудничать с экосистемой и соответствующим образом обновлять наши общедоступные часто задаваемые вопросы». Ранее мы рассматривали фрагментированную документацию . Мы рассматриваем коммерческие требования в разделе «Гарантии данных» здесь, и некоторые рекламные продукты Google поделились своими подходами. Мы проводим сторонние аудиты в рамках «Гарантии целостности алгоритма» здесь . Что касается аккредитации, мы ожидаем, что эти органы продолжат аккредитовывать продукты, включая использование ими технологий, а не сами технологии. Что касается масштабируемости, мы по-прежнему открыты для данных от разработчиков, которые демонстрируют проблемы. Что касается прозрачности и управления, мы продолжаем открыто развиваться на GitHub и на таких форумах, как W3C, одновременно взаимодействуя с CMA в рамках Обязательств. |
| Вход в Google | Вход в систему Google приведет к тому, что Google сможет использовать данные для входа в систему с перекрестной идентификацией в нарушение Обязательств. | Вход в Google не позволяет Google использовать данные в нарушение Обязательств. |
| Совместимость | Каковы планы по поддержке API-интерфейсов Privacy Sandbox и прямой/обратной совместимости? | Как только Chrome выпустит какую-либо функцию в общий доступ, мы постараемся сохранить ее поддержку. Конечно, не всегда возможно сохранить обратную совместимость, и в таких случаях у нас есть четкий процесс устаревания и удаления существующих функций, описанный здесь . Мы ожидаем, что со временем мы продолжим добавлять больше функций в API Privacy Sandbox в ответ на отзывы экосистемы о вариантах использования, которые выиграют от улучшенной поддержки. В таких случаях мы склонны включать какой-либо метод обнаружения функций, чтобы специалист по рекламе, заинтересованный в экспериментировании с новой функцией, мог напрямую спросить браузер, поддерживается ли эта функция. Это лучше, чем просить разработчиков проверить определенный номер версии Chrome, поскольку некоторые функции могут не быть доступны всем пользователям Chrome одновременно. Например, нашу работу по обнаружению функций для PA API можно найти здесь . |
| Реализация сервера | Вместо того, чтобы связываться со своей собственной реализацией, Chrome должен указать поведение, которому должна соответствовать удовлетворительная реализация сервера доверенных сигналов, сервера агрегации и любых других необходимых небраузерных компонентов. Это позволит внедрять инновации в рамках приемлемых границ конфиденциальности. | Мы ценим и приветствуем стремление к инновациям со стороны внешних сторон. Для всех API и сервисов мы стремимся предоставить рекламным специалистам гибкость в реализации их функциональности. Например, мы разрешаем специалистам по рекламе использовать конфиденциальную деловую информацию при разработке логики ставок для аукционов. Более того, мы постоянно учитываем отзывы рекламных специалистов и, где это оправдано, включаем их в наши проекты. Чтобы позволить другим запускать свой собственный код в доверенных средах выполнения, Privacy Sandbox необходимо будет проверить код (и все изменения), чтобы убедиться, что он соответствует гарантиям конфиденциальности. Это потребует значительных усилий со стороны команды Privacy Sandbox. Поэтому мы хотели бы понять, каких выгод хочет достичь заинтересованная сторона, чего мы сегодня не достигаем. |
| Эвристика | Каковы долгосрочные планы в отношении эвристики? | В соответствии с тем, что указали другие браузеры, мы намерены в конечном итоге отказаться от этой эвристики, поскольку альтернативные решения станут широко использоваться, при условии дальнейшего анализа осуществимости. Мы поделились этим здесь . |
| Объем тестирования | Разный объем трафика при сравнении разных параметров. | Эксперимент с 1 % имеет критерии исключения, которые приводят к различиям в приемлемости для участия в эксперименте между разными группами клиентов Chrome. Например, из эксперимента исключены пользователи Chrome Enterprise , поэтому ожидается, что доля трафика с метками эксперимента будет выше в выходные дни. Ожидается, что мы увидим разный процент трафика в разных фрагментах данных (например, по географическому положению, дате и платформе), и это соответствует тому, что мы видим в данных Chrome. |
| Вручную повторно включите 3 компьютера. | Смогут ли сайты узнать, сколько пользователей (%) вручную повторно включили файлы cookie после введения 3PCD? | Пользователи будут иметь возможность повторно включить доступ 3PC на уровне сайта через User Bypass, если они столкнутся с поломкой. 3PC также можно повторно включить с помощью других мер, таких как API доступа к хранилищу. Существуют технические меры, такие как hasStorageAccess(), которые позволяют сайтам определять, включены или отключены 3 компьютера. Однако Chrome не позволит веб-сайтам узнать причины повторного включения. |
| Защита от отслеживания | Как долго будет доступна функция пользовательского интерфейса Chrome «Защита от отслеживания»? | Ожидается, что пользовательский интерфейс защиты от отслеживания в адресной строке останется неизменным после прекращения поддержки 3PC. |
| (Также сообщалось в предыдущих кварталах) Кроссбраузерная поддержка | Другие поставщики браузеров используют API-интерфейсы Privacy Sandbox. | Другие поставщики браузеров, такие как Apple, Mozilla и Microsoft, активно участвуют в публичных форумах, на которых обсуждаются принципы конфиденциальности и подходы, основанные на браузерах. Нас воодушевляют совместные дискуссии на таких форумах, как недавнее ежегодное собрание W3C TPAC и текущие форумы W3C PATCG, где мы видим признаки конвергенции. Например, Microsoft Edge недавно объявил о своем плане, который «направлен на максимальную синтаксическую совместимость» с PA API и ARA , а также предлагает дополнительные функции для разработчиков. |
| Резервный вариант для несовместимых встраиваний после 3PCD | Предоставьте перехватчики API, чтобы определить, совместим ли сторонний iframe/внедрение с 3PCD или нет. | Мы обсуждаем запрос здесь и приветствуем дополнительные отзывы от экосистемы. |
| Тестирование | Запрос дополнительных флагов в управляемых экземплярах Chrome, которые временно отключают настраиваемое поведение. | Мы рассматриваем этот запрос на управляемые экземпляры Chrome и приветствуем дополнительную информацию от экосистемы, если такой флаг будет полезен. |
Регистрация и аттестация
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Проверка аттестации | Как Google будет обеспечивать подлинность подтверждений? | Все зарегистрированные лица обязаны сохранять файл аттестации при использовании API. Google проверяет наличие файла и правильность синтаксиса, но не проверяет поведение рекламной технологии в отношении языка подтверждения. |
| Процесс регистрации API частного агрегирования | Есть ли способ проверить статус регистрации API частного агрегирования? | Все одобренные участники получают уведомление по электронной почте от службы поддержки регистрации после подтверждения регистрации. Если у регистранта возникнут какие-либо вопросы в ходе процесса, он может обратиться в службу поддержки (с которой он связан после отправки формы регистрации). Служба поддержки ответит на вопросы и предоставит любые необходимые дополнительные рекомендации. |
Показывайте релевантный контент и рекламу
Темы
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| (Также сообщалось в предыдущих кварталах) График работы классификатора и документация | Должен быть какой-то механизм для пересмотра классификации или, по крайней мере, дополнительная прозрачность того, как режим классификации определяет категории. | Наш ответ не изменился по сравнению с предыдущими кварталами: «Неправильная классификация сайтов может сделать сигнал «Темы» несколько менее полезным в качестве сигнала в целом, но конкретные неправильно классифицированные сайты страдают от этого не больше и не меньше, чем любые другие сайты. Это связано с тем, что контекстная информация сайта всегда будет доступна для аукционы на их сайте, которые будут предоставлять информацию, сопоставимую с правильной темой, даже в случае неправильной классификации. Мы приветствуем отзывы по этому вопросу здесь ». |
| Google Менеджер рекламы | Google Ad Manager уже встроен на большинство сайтов и будет содержать гораздо более широкую информацию о темах пользователей, чем конкуренты, которые присутствуют на меньшем количестве сайтов. | Требование наблюдения существует для того, чтобы API Topics не приводил к тому, что пользовательские данные передавались большему количеству объектов, чем технологии, которые API заменяет (включая 3 ПК). Другие отраслевые решения, такие как Prebid, работают с 10 000 сайтов и позволяют участникам рынка вызывать Topics API с помощью своей технологии. Кроме того, стоит отметить, что ограничение до 5 наиболее популярных тем в неделю может иметь уравнивающий эффект, поскольку участники рынка, присутствующие на многих сайтах и способные изучить более 5 эквивалентных тем с использованием 3 компьютеров, будут ограничены до 5. |
| (Также сообщалось в предыдущих кварталах) Полезность для разных типов заинтересованных сторон | Обеспокоенность по поводу создаваемой ценности и распределения этой ценности для сайтов в зависимости от уровня их трафика или специализированности их контента. | Мы понимаем, что специализированные сайты с большей вероятностью будут предлагать более подробные темы, чем области общих интересов. Однако не все специализированные сайты представляют коммерчески ценные темы. Кроме того, эта динамика отражает статус-кво и совершенно не зависит от прекращения поддержки 3ПК в Chrome. Кроме того, в нынешних условиях некоторые сайты представляют большую ценность, чем другие, в системах релевантности рекламы на базе 3ПК. Кроме того, темы на специализированных сайтах могут быть взаимовыгодными, поскольку разные рекламодатели могут проводить кампании по разным наборам тем, а логика назначения ставок может оценивать ценность по широкому кругу тем. |
| Имена хостов и полные URL-адреса | Достаточно ли эффективна классификация на основе имен хостов веб-сайтов и снижает ли это риск конфиденциальности по сравнению с полными URL-адресами? | Мы рассмотрели возможность использования информационных URL-адресов или заголовков страниц в дополнение к именам хостов и пришли к выводу, что потенциальные преимущества будут перевешиваться рисками для конфиденциальности и безопасности пользователей. Примером рисков конфиденциальности пользователей является классификация конфиденциальной информации, включенной в URL-адрес или заголовок страницы, в темы пользователя. |
| Темы как сигнал | Запрос рекомендаций о том, как сочетать темы с другими сигналами и какие еще сигналы могут быть полезны. | Решения в области рекламных технологий могут добиться наилучших результатов, сочетая все доступные инструменты, такие как машинное обучение и безопасные сигналы конфиденциальности от API-интерфейсов, сохраняющих конфиденциальность, а также контекстные данные, творческие данные и собственные данные. Дополнительные рекомендации по этому вопросу доступны здесь . |
API защищенной аудитории (ранее FLEDGE)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Тестовый объем трафика | Тестировщики сообщают о низком количестве ответов на запросы ставок на аукционе PA API. | 1. Плотность ставок коррелирует с участием экосистемы в PA API, которое, как мы ожидаем, будет продолжать расти в течение 2024 года и в последующий период. В конечном итоге рекламодатели, их агентства и поставщики технологий сами решают, как распределять бюджеты кампаний. Мы ожидаем, что некоторые участники экосистемы могут отложить свои инвестиции в различные решения без файлов cookie, включая PA API, до завершения 3PCD. В то время мы ожидаем, что они могут увеличить ассигнования бюджета своей кампании на такие решения. 2. На объем запросов ставок на аукционах PA API может повлиять (1) то, что издатели и их поставщики рекламных технологий могут принять решение не инициировать аукционы PA API, если они считают, что спрос низкий. Издатели сами определяют приоритетность обновления своих страниц и участия. Мы ожидаем, что по этим причинам издателям может потребоваться время для тестирования и постепенного увеличения трафика. Этот отчет также включает ответ Google Ad Manager о средствах контроля издателей за участие PA API. |
| (Также сообщалось в предыдущих кварталах) Мошенничество/злоупотребление | Как экосистема может снизить риски и помешать злоумышленникам или покупателям позиционировать себя в качестве желательной аудитории? | Механизмы отчетности объявлений PA API сохраняют информацию, используемую сегодня для того, чтобы отличать людей от трафика ботов. Кроме того, в PA API можно использовать текущие доменные методы включения или исключения доменов. Более подробно это описано в нашем ответе на отчет IAB Tech Lab о Privacy Sandbox. |
| То же ограничение Origin для владельца IG и URL-адреса логики назначения ставок. | При соблюдении требования об одном и том же источнике конечные точки владельца IG будут вынуждены проходить через один и тот же балансировщик нагрузки, что может привести к отклонению перенаправлений. | Требование того же происхождения для загрузки скриптов является важной защитой безопасности. Здесь есть некоторые подробности предлагаемого решения, которое уравновешивает обратную связь от экосистемы и другие соображения. |
| Многослотовый частный аукцион | Существует много возможностей для разрешения частных аукционов с несколькими слотами в рамках конфиденциальности за счет использования шума и более тесной интеграции с текущей практикой рекламы. | Мы рассматриваем этот отзыв и оцениваем запрос на аукционы с несколькими тегами на предмет повышенной сложности и рисков конфиденциальности, связанных с этой функцией. Подробнее мы обсуждали этот вопрос во время звонка группы сообщества веб-инкубатора PA API (WICG) здесь . |
| Продавцы высшего уровня | Текущая структура PA API предоставляет любому продавцу верхнего уровня значительно больше данных и понимания относительной ценности показов, чем издателям или продавцам компонентов. | На аукционе с участием нескольких продавцов каждый продавец предложит лучшую ставку. Кроме того, из экосистемы мы узнали, что издатели могут захотеть учитывать спрос на прямые продажи наряду с лучшими предложениями каждого продавца, с которым они работают. Чтобы определить, какую рекламу показывать, необходимо рассмотреть все эти потенциальные возможности монетизации. Эта ситуация, когда какому-то субъекту необходимо видеть полный набор параметров, чтобы выбрать рекламу для показа, возникла до появления PA API. PA API стремится поддерживать аукционы с участием нескольких продавцов и желание издателей учитывать лучшее предложение каждого продавца наряду с рекламными кампаниями с прямой продажей, где последнее применимо. Это означает, что должен быть механизм выбора среди тех возможностей монетизации, которые есть сегодня. Мы не считали, что роль браузера должна заключаться в выборе того, какое объявление показывать. Таким образом, концепция продавца высшего уровня необходима для того, чтобы выбрать выигрышное объявление из множества возможностей. Логика продавца верхнего уровня должна учитывать лучшие предложения от каждого продавца, с которым издатель решит работать. И логика продавца может решить предоставить информацию о кампаниях прямой продажи издателя, где эта информация доступна. Вся эта информация может быть учтена в логике выбора объявлений верхнего уровня. Это означает, что логика верхнего уровня учитывает лучшие ставки на аукционе PA API и, если применимо, любые варианты объявлений с прямой продажей от издателя, чтобы определить победителя. Google Ad Manager подробно описывает реализацию PA API в качестве продавца верхнего уровня в этом отчете в теме « Доступ к информации ». |
| Разделение конкурентной рекламы | Запрос на разделение конкурентной рекламы, например запрет показа рядом друг с другом рекламы конкурирующих брендов. | Мы не знаем, как обеспечить конкурентное разделение в сегодняшней программной экосистеме цифровой рекламы с несколькими продавцами. Однако PA API позволяет продавцам получать дополнительные сигналы в режиме реального времени на основе комбинации renderURL и имени хоста (представляющего домен издателя), которые можно использовать во время ScoreAd() при оценке объявлений. Это может использоваться продавцами, чтобы предотвратить появление рядом друг с другом рекламы конкурирующих брендов, при условии, что издатель желает обеспечить соблюдение этого правила. |
| Ограниченная информация | PA API сокращает объем информации, доступной издателям, такой как ценность объявления, имя покупателя компонента, имя рекламодателя, URL-адрес целевой страницы, размер объявления, время ответа и ставка ставки, а также потери ставок. | Мы предложили здесь некоторые потенциальные решения и приветствуем дополнительные отзывы от экосистемы. |
| Отчетность на уровне событий | Издатели не могут получить достаточно информации о показываемом объявлении после прекращения поддержки API PA для отчетов на уровне событий. | Нам известны различные варианты использования отчетов, которые мы должны продолжать поддерживать после прекращения создания отчетов на уровне событий. Вот почему мы установили, что дата прекращения отчетности на уровне событий будет не ранее 2026 года. В период между настоящим и потом мы приглашаем к активному участию, поскольку мы взаимодействуем с экосистемой по долгосрочным путям продвижения вперед, которые могут включать новые идеи для получение информации с соблюдением конфиденциальности. |
| Несколько поставщиков общих служб | Дополнительная выгода от наличия нескольких SSP будет слишком низкой для издателей. | Мы не считаем это правильным и будем рады дополнительным отзывам от экосистемы, чтобы понять обоснование этого утверждения. |
| Кураторская деятельность | Кураторская деятельность невозможна с помощью PA API. | Мы слышали отзывы о возможности продавцов использовать PA API для предоставления информации о своей аудитории покупателям через Интернет (расширение аудитории AKA). Мы считаем, что это возможно сегодня, используя функции делегирования PA наряду с деловыми соглашениями. Одновременно мы активно думаем , можем ли мы лучше приспособиться к этим типам вариантов использования и если да, то каким образом. |
| Отказ покупателя | Отказ покупателя по умолчанию может привести к снижению результатов на аукционах компонентов. | Независимо от того, определяете ли аукцион PA с одним продавцом или с несколькими продавцами, продавец должен явно перечислить покупателей в поле InterestGroupBuyers в AuctionConfig. Это основано на обратной связи экосистемы о том, что у продавцов есть договорные соглашения с одними покупателями, а не с другими, поэтому потребуется явный контроль над тем, каких покупателей включать в аукцион. Мы приветствуем дальнейшее обсуждение на GitHub. |
| Размер объявления | Невозможно выполнить предварительный фильтр по размеру объявления и adSlotSize. | Мы работаем над добавлением этой возможности, более подробную информацию можно найти здесь . |
| Поддержка негативного таргетинга IG | API для поддержки негативного таргетинга IG: показ рекламы только в том случае, если пользователь не принадлежит к IG. | В этом выпуске GitHub предлагается альтернативный способ реализации негативного таргетинга, при котором браузер напрямую сообщает рекламному серверу, какие правила негативного таргетинга должны действовать для конкретного запроса объявления. Хотя этот подход кажется привлекательным, все версии этой идеи, которые мы исследовали, позволяют серверу однозначно идентифицировать пользователя. |
| Закон о цифровых услугах | Как издатель может использовать Fenced Frames, но при этом не допускать предоставления ответов, содержащих информацию, подпадающую под действие Закона о цифровых услугах? | Как и в случае с любой новой технологией, каждая компания несет ответственность за то, чтобы использование Privacy Sandbox соответствовало закону; Google не может предоставлять другим юридические консультации. По каждому API мы опубликовали обширную техническую документацию, которая должна стать основой для проведения необходимых юридических оценок. Fenced Frames не требуется для использования в API PA ранее 2026 года, что дает заинтересованным сторонам дополнительное время для обеспечения того, чтобы использование этой технологии соответствовало всему соответствующему законодательству. |
| Документация | Является ли updateAdInterestGroups() временным? | Мы не объявляли о планах по прекращению поддержки updateAdInterestGroup. В будущем мы можем применять аналогичные меры защиты конфиденциальности, о которых мы публично говорили, для других механизмов обновления IG, например, используя IP-адрес и прокси-сервер и добавляя некоторую задержку перед выполнением обновления. |
| Поддержка метаданных и логики покупателя на стороне, не являющейся DSP. | Запрос на способ выступать в качестве прокси для DSP. | Мы знаем об этой обратной связи от сегментов, не использующих DSP, и рассматриваем этот запрос. Мы приветствуем дополнительные отзывы от экосистемы. |
| Составление отчетов | Запрос на добавление функции пользовательского обработчика для сегмента/значения сигналов в отчетах Private Aggregation. | Мы знаем об этом, и этот запрос на функцию находится в нашей очереди для дальнейшего изучения. Мы приветствуем дополнительные отзывы от экосистемы здесь . |
| Документация | Есть ли ссылка, по которой можно просмотреть все заголовки ответов, которые должны быть установлены рекламодателем и (делегированным) владельцем домена? | Мы планируем обновления документации, чтобы прояснить это, и приветствуем дополнительные отзывы от экосистемы. |
| Многобашенные торги | Запрос на объяснение рабочего процесса (обучение и вывод) через архитектуру/блок-схему того, как рассматривается подход с несколькими башнями в контексте PA API. | Спасибо за ваш отзыв! У нас есть несколько презентаций по этой теме, на основе которых мы планируем построить дополнительную документацию. |
| Негативный таргетинг | Способность Privacy Sandbox защищать деликатную аудиторию и несовершеннолетних от нежелательной рекламы, например азартных игр. | API PA не учитывает содержание показываемой рекламы. Это контролируют разработчики рекламных технологий, использующие PA. Как правило, издатель и его поставщики рекламных технологий могут блокировать рекламные объявления на аукционах защищенной аудитории, используя контекстную информацию со страницы, а также наборы правил издателя. Это отражает наше понимание подхода экосистемы к этим проблемам сегодня. Для покупателей функция негативного таргетинга IG также может быть полезна для некоторых случаев использования соответствия. |
| API-дизайн | Google сопротивляется и хочет, чтобы рекламные специалисты использовали функцию универсального назначения ставок, тем самым увеличивая задержку, а не разные URL-адреса BiddingLogicURL в разных IG, что разрешено. | В ходе обсуждения задержки аукциона мы подчеркнули, что повторное использование одного и того же сценария во всех IG покупателя приведет к ускорению торгов этого покупателя. Более подробно это изложено здесь вместе с другими нашими рекомендациями по уменьшению задержки на аукционе PA API. |
| Маркетинг на основе аккаунта | PA API не является чистым API для вариантов использования маркетинга на основе учетных записей. | Мы приветствуем отзывы от экосистемы в любых конкретных случаях использования, которые, по их мнению, невозможно, и поощряем участников экосистемы продолжить это обсуждение с помощью нашего публичного репозитория GitHub или еженедельных звонков. |
| А/Б-тест | Когда PA API настроен в GAM для издателя, в настоящее время он должен быть включен либо для всех инвентаризации, либо нет. Это ограничивает способность издателей запускать жизнеспособный A/B -тест. | Ответ предоставлен Google Ad Manager: Управление API PA в Google Ad Manager (GAM) влияет на способность GAM использовать API, при условии, что API доступен для использования. Таким образом, издатели могут запускать A/B -тесты с использованием функциональности политики разрешений Chrome, чтобы отключить использование API на подмножестве трафика для использования в качестве управляющего рычага для анализа A/B. |
| Машинное обучение | Издатели нуждаются в большем контроле над предложенным GAM использование машинного обучения. | Ответ предоставлен Google Ad Manager: В январе 2024 года мы запустили контроль, который предлагает издателям возможность отключить нашу машинного обучения Throttler и обеспечить аукционы PA API с продавцами, не являющимися Google, во всем их трафике. Более подробную информацию об этом управлении можно найти в нашем справочном центре . |
| (Также сообщается в предыдущих кварталах) Аукционы верхнего уровня | Способность использовать рекламный сервер Google Publisher, не предоставляя GAM управление на аукционе API верхнего уровня. | Ответ предоставлен Google Ad Manager: По причинам, объясненным в отчете Google Q3 2023 , планы GAM для его интеграции PA API не включают в себя поддержку издателей, использующих GAM в качестве своего рекламного сервера издателя без контроля аукциона высшего уровня. |
| Доступ к информации | GAM имеет доступ к ценной информации от конкурентов, включая цены на контекстуальные аукционы, сигналы, предоставленные покупателями для SSP для аукциона PA API, и параметры конфигурации от SSP. | Ответ предоставлен Google Ad Manager: В течение многих лет мы уделяли особое внимание справедливости на аукционах, в том числе наше обещание, что никакая цена от не гарантированных источников рекламы издателя, включая негарантированные цены на позиции, не будет передана другим покупателю до того, как они ставят предложение на аукционе, что мы затем подтвердили в наших обязательствах перед Французским Управлением конкуренции. Для аукционов PA API мы намерены сдержать свое обещание и не делиться заявкой любого участника аукциона с любым другим участником аукциона до завершения аукциона на аукционах с несколькими продавцами. Чтобы быть ясным, мы не будем делиться ценой контекстуального аукциона с каким -либо компонентным аукционом, включая наш собственный, как объяснено в этом обновлении . Кроме того, мы не используем информацию о конфигурациях компонентов, включая сигналы, предоставленные покупателями для SSP, в рамках нашего собственного аукциона. Фактически, мы будем приветствовать изменения в API PA, которые позволяют продавцам компонентов указать свои конфигурации компонентов аукциона таким образом, чтобы запутать от продавца высшего уровня. |
| Компонентные аукционы | В качестве аукциона на высшем уровне GAM будет контролировать, какие SSP запускают компонентные аукционы для каждой возможности рекламы. | Ответ предоставлен Google Ad Manager: Как рекламный сервер издателя, GAM предлагает легкий API для SSP, с которыми может работать издатель, чтобы указать свои конфигурации компонентов аукциона через API Google Publisher Tag (GPT). Более подробную информацию можно найти здесь . Если SSP предоставляет конфигурацию компонента аукциона через этот API, то они будут включены в список компонентов аукционов для этой возможности AD. GAM не налагает никаких ограничений на компонентные аукционы, включенные. Любой SSP, который желает провести аукцион компонентов, сможет сделать это, при условии, что издатель позволил им выполнить необходимый код на странице издателя. |
| Компонентные аукционы | GAM может применить конкретный и нераскрытый этаж к каждой победной стадии компонента. | Ответ предоставлен Google Ad Manager: GAM в течение многих лет удерживал акцент на справедливости на аукционах. В рамках поддержания справедливого и прозрачного аукциона мы не поддерживаем цены на этаж, которые применяются только к конкретным сегментам спроса. Это последовательный принцип в нашем продукте и будет продолжать быть таким для аукционов PA API. |
| Сторонние рекламные серверы | Сторонние рекламные серверы не имели бы доступа к участию Google на аукционе более высокого уровня, что ограничивает его способность пользоваться спросом Google SSP в контексте PA API. | Ответ предоставлен Google Ad Manager: В настоящее время GAM поддерживает тестирование PA API с несколькими продавцами на GAM через API, описанный здесь . Участие GAM в качестве компонентного аукциона на других аукционах высшего уровня в настоящее время не поддерживается. |
| (Также сообщается в предыдущих кварталах) Производительность аукционов PA API | Отчет от тестеров о том, что аукционы PA API имеют высокую задержку. | Мы слышали опасения по поводу задержки, и это одна из причин, по которой мы разработали ряд функций в рамках API PA, которые позволят SSP возможны как на задержку DSP, так и улучшают улучшения, которые могут уменьшить задержку . Недавно мы обновили наше руководство по лучшим практикам задержки , которое включает в себя больше информации о том, как воспользоваться этими функциями. Мы также продолжаем развивать новые улучшения задержки, некоторые из которых можно увидеть здесь . |
| (Также сообщается в предыдущих кварталах) Рендеринг видео | Поддержка рендеринга видео с использованием PA API и огороженных рам. | В январе мы опубликовали демонстрацию того, как Videam Video может работать на аукционе PA , с дополнительными подробностями о альтернативных подходах. Мы также видим, как игроки экосистемы начинают предлагать, как рендеринг видео работает для партнеров, которые интегрируются с ними, такие как предложения GAM по созданию совместимого с видео, или полный процесс E2E . Кроме того, мы слушаем отзывы экосистемы об изменениях, которые мы можем внести, чтобы увеличить принятие, и одно из таких изменений подробно описано в GitHub . Мы по -прежнему активно взаимодействуем с экосистемой, чтобы определить любые другие препятствия для усыновления, с которыми мы можем столкнуться и своевременно решать их. |
| (Также сообщается в предыдущих кварталах) Политика обработки данных | Какова политика обработки данных для IGS / PA API? | В дизайне PA API все данные, хранящиеся в IGS, или о том, что люди находятся в каких IG, либо (i) остаются на грани или (ii) обрабатываются в услугах торгов и аукциона (B & A), работающих в доверенной среде выполнения. (Футболка). В обоих случаях данные не могут быть прочитаны любыми другими сторонами или использованы каким -либо образом, кроме как для создания предложений на аукционе. Некоторые улучшения конфиденциальности, которые изучает Chrome, включают взаимодействие с Google-управляемым сервером K-анонимности. Это взаимодействие тщательно разработано, чтобы избежать обмена информацией о пользователях и запуска в тройнике, чтобы обеспечить паритет информации в экосистеме ADS. Google посвятил себя CMA для разработки и реализации предложений с песочницей конфиденциальности таким образом, чтобы не искажать конкуренцию за счет самостоятельного привязки собственного бизнеса Google и учитывать влияние на конкуренцию в цифровой рекламе, а также на издателей и рекламодателей. Мы продолжаем тесно сотрудничать с CMA, чтобы гарантировать, что наша работа соответствует этим обязательствам. |
| (Также сообщается в предыдущих кварталах) Ig Lifetime | Запрос продлить жизнь IGS от 30 до 90 дней. | Такое изменение требует тщательной оценки, что привело к преимуществам отрасли от влияния на пользователей Chrome и других заинтересованных сторон. Мы рассматриваем этот запрос и приветствуем здесь дополнительные отзывы. |
| (Также сообщается в предыдущих кварталах) Моделизгровяния | Запросите новое поле в дополнение к моделям, которые могут только кодировать отображение и щелкнуть информацию. | Мы ответили на этот отзыв с помощью встречного предложения здесь . Мы активно взаимодействуем с отраслью, чтобы понять их мнение о нашем предложении, и в настоящее время откладываем преимущества для отрасли от влияния на пользователей Chrome и других заинтересованных сторон. |
| Дополнительные биты в отчете () | Предоставьте дополнительные биты в отчете () из текущего предела 12 до 3pcd. | В настоящее время мы исследуем подходы для поддержки этого варианта использования. Это занимает некоторое время, так как мы также ищем подходы, которые могут помочь у нас есть долгосрочный план конфиденциальности. |
| Аукционный дизайн | Запросы на единый аукцион, который возвращает URL -адреса с соответствующим результатом. | Совместное использование нескольких рендеров и их соответствующих результатов из одного аукциона PA - это то, что мы рассмотрели, но не реализовали из -за проблем с конфиденциальностью. Мы действительно понимаем желание не показывать одно и то же объявление несколько раз пользователю на одной странице и приветствуем дальнейшее обсуждение GitHub. |
| reportwin | Логические произвольные поля в функции Reportwin (). | Это уже происходит сегодня в течение периода тестирования. Как только Chrome закончит поддержку 3PCS, версия API Fordebuggingonly будет мигрировать, чтобы обеспечить отладку по снижению дискретизации, которая указана здесь . |
| Продавцы компонентов | Имейте независимый механизм, чтобы подсчитать свои собственные впечатления и другие события, и не должен быть в состоянии зависеть исключительно от отчетов AD Techs. | Этот запрос функции находится в нашей очереди для дальнейшего открытия. Мы не предвидим, обращаясь к этому в течение хромированного периода тестирования. |
| Стоимость за клик | Реализуйте счет за затрат на клик в PA API. | Мы рассматриваем этот запрос здесь , и в настоящее время мы рассматриваем это как запрос о предложениях о том, как реализовать его с текущей поверхностью API. |
| браузерз | Добавить входной билет в спецификации BrowserSignals для продавца. | Мы рассматриваем этот запрос и приветствуем здесь дополнительные отзывы. |
| Покупать метаданные и поддержку владения логикой для не DSPS | Текущий дизайн API может привести к значительному сдвигу в кампаниях ретаргетинга на уровне продукта, где кампаниям может потребоваться мигрировать на платформы, которые служат как DSPS, так и поставщики DCO. | Мы обсуждаем эту проблему и приветствуем здесь дополнительные отзывы. |
| Покупать метаданные и поддержку владения логикой для не DSPS | Поделитесь примерами, где DSP не является владельцем IG. | Мы понимаем, что не-биддеры хотели бы использовать некоторую функциональность IG, но не других. Мы активно оцениваем варианты решения этих вариантов использования и приветствуем здесь дополнительную обратную связь. |
| Управление тайм -аутом | Издатели должны иметь возможность диктовать количество IG, способных участвовать, и тайм-аут на высшем уровне / глобальный тайм-аут. | Мы понимаем, что существует стремление к улучшению контроля тайм-аута и видимости между продавцом высшего уровня и компонентов, и мы рассматриваем этот запрос. |
| Многочисленная реклама | PA API Поддержка для вариантов использования размера многочисленных объявлений. | Мы рассматриваем этот запрос и приветствуем дополнительные отзывы от экосистемы. |
| Документация | Есть ли список атрибутов IG, которые подвергаются K-Anon? | Мы ответили на этот вопрос здесь . |
| Отладка | Улучшенные возможности отладки для PA API. | Мы признаем важность надежных инструментов отладки для разработчиков, работающих с PA API. Мы стремимся к улучшению опыта разработчика, изучив способы лучше интегрировать. Наша цель состоит в том, чтобы обеспечить большую видимость и возможности устранения неполадок в среде разработки. Мы обсуждаем этот вопрос дальше здесь и приветствуем дополнительные отзывы. |
| Этикетки | У всех пользователей в меток обработки в режиме B включены APIS Sandbox Crivacybox? | Назначения группы экспериментов Chrome являются случайным образом определяются и не зависят от настроек Chrome, сфигурируемых пользователем. Хотя эти API могут быть доступны пользователям в определенных группах лечения (например, лечение_1.*), Их функциональность может быть изменена или отключена с помощью настроек Chrome. В режиме B CONTROL_2 Группа: включение в эту группу по своей природе отключает актуальность песочницей конфиденциальности и API измерения, и этот параметр не может быть переопределен пользователем в настройках Chrome. |
| Использование API | Происходит ли призыв к отчету () и рекламный рендеринг параллельно или один за другим? | Reportwin () называется непосредственно после завершения Runadauction (). В то же время процесс рендеринга AD может начаться, когда результат аукциона находится в IFRAME или огороженной кадре. После того, как обоих отчетов () завершает выполнение, и объявление начинается, URL -адреса, предоставленные SendReportto (). |
| (Также сообщается в предыдущих кварталах) A/B -тестирование | Запросить поддержку для тестирования PA API A/B. | Мы обсуждаем этот запрос здесь и приветствуем дополнительные отзывы. |
| Формирование трафика | Предложение от Google о управлении необходимым принятием решений через KV -сервер не помогает, поскольку продавцы не могут взаимодействовать со своим бэкэндом, что делает сложные формы трафика. | Как обсуждалось в вопросе GitHub , выявление того, есть ли отдельные DSP, присутствующие IG, могут иметь проблемы с давлением отпечатков пальцев. Мы предложили другие альтернативы в этой проблеме и открыты для дальнейших предложений. |
| Формирование трафика | Механизмы кэширования добавляют значительный слой сложности и не позволяют DSP знать истинную форму трафика, на котором они будут предлагать. | Механизм кэширования был просто предложен в качестве предложения. Adtechs могут выбрать использовать предложения, которые служат их варианту использования, и мы приветствуем здесь дополнительное обсуждение. |
| Этикетки | Chrome должен разделить этикетку в качестве параметра в запросах на доверенные серверы покупателя и продавца. | По -видимому, это разумный запрос, поскольку он, по -видимому, в целом соответствует цели ответственного использования данных IG. Тем не менее, мы рассматриваем запрос, при условии внутреннего обзора, и будем предоставлять публичные обновления по этому вопросу в соответствии с обсуждением. |
| Использование API | Уточнить явное определение группы «control_1» в документе «Дополнительное руководство CMA третьим лицам при тестировании». В частности, существует опасение, что изменение формулировки может быть неверно истолковано как требующее исключения всех APIS Sandbox с конфиденциальностью из Control_1. | Мы выразили наши взгляды на это в этой ветке GitHub . Тем не менее, мы не можем говорить за CMA, и мы предлагаем поднять любые вопросы, касающиеся интерпретации их руководства по тестированию непосредственно с CMA. |
| Использование API | Разрешит ли Chrome вызов joinAdInterestGroup () на пустой странице при перенаправлении на другой ресурс? | Если пользователь посещает какой -то сайт, то владелец сайта может делегировать возможность позвонить в JoinAdinterestGroup третьей стороне. Эта делегация позволяет третьим сторонам построить IG без необходимости добавления какого -либо перенаправления через пустую страницу. Мы приветствуем обратную связь по конкретным причинам построения IG в середине перенаправления вместо использования предполагаемого механизма делегирования. |
| Использование API | Обмены должны быть в состоянии написать IG на страницы, принадлежащие издателям, с которыми они работают, и что они могут затем делегировать разрешение на ставку на этот IG любому покупателю или DSP. | Мы получили отзыв и оцениваем, может ли такой запрос быть поддержан. Мы приветствуем дополнительные отзывы от экосистемы. |
| Использование API | Не существует уведомления о потери отладки, если никто не выиграет аукцион PA API. | Функции Chrome Reportwin и Reportresult предназначены для отчетности о победе на уровне событий в системе аукциона по конфиденциальности (PA). В обстоятельствах, когда все заявки отклоняются во время аукциона PA, ожидается, что эти функции не будут вызовом, поскольку не определяется ни один победитель. Недавнее обновление Chrome может объяснить несоответствия, когда URL -адреса перешли в Fordebuggingonly.ReportAductionLoss (), не появляются на сетевой панели DevTools. Мы рекомендуем проверить эту функциональность, используя либо канальный, либо разработчик, сборка Chrome. |
| Использование API | Может ли Adcost, возвращаемый из Generatebid, быть отрицательным (он уже стохастически округлен до 2 байтов)? | Adcost - это клик или стоимость конверсии рекламодателя, передаваемая из GenerateBid () в reportwin (). Это значение может быть нулевым или двойным. Отрицательные значения будут проигнорированы, а не переданы. Значение будет стохастически округлым при прохождении. |
| Улучшение API | Можно ли использовать доверенные и зашифрованные серверы выполнения для обработки таргетирования / когортов / атрибуции и аукционов, а не браузера Chrome? | Мы рекомендуем изучить компоненты и опции на основе TEE в PA API (например, серверы KV и сервисы B & A ), а также в компонентах отчетности по атрибуции и частной агрегации ( служба агрегации EG), которые решают этот вопрос. |
| Улучшение API | Может ли ответ на аукцион на аукционе для конфиденциальности быть ответом на ставку (например, ставки за заголовок), а не ответ AD (например, AD Tags)? | Этот тип изменений в корне изменяет свойства конфиденциальности PA API, поэтому мы не рассматриваем. |
| Издательские элементы управления | Могут ли издатели заблокировать PA API Creatives на своих страницах? | Chrome имеет предложение о творческом сканировании в реальном времени , которое еще не доступно для тестирования. Хотя это еще не доступно, мы наблюдали, как большинство SSP создали решения для этого. |
| Использование API | Каков ограничение размера на перспективы? | В своей классической форме Perbuyersignals не несет ограничений по размеру в Chrome. Основные ограничения заключаются в том, что данные остаются сериализуемыми JSON и не вызывают чрезмерного потребления памяти. Тем не менее, следует отметить, что очень большие и сложные Perbuyersignals могут негативно повлиять на производительность. Существует альтернативный метод для прохождения Perbuyersignals через DirectFromSellerSignalSheaderAdSlot. Этот подход передает Perbuyersignals в заголовке, в зависимости от ограничения максимального размера 10 КБ для всего отклика заголовка. Кроме того, отдельные серверы могут наложить свои собственные ограничения на максимальный размер заголовка. |
| Документация | Документация на Call RegisterAdbeacon изнутри GenerateBid должна быть изменена. | Мы обновили эту документацию 17 февраля. |
| Использование API | Как ReportEvent выбирает правильный URL маяка из нескольких зарегистрированных вариантов? | Каждый аукцион приводит к отдельной конфигурации, которая, в свою очередь, приводит к отдельной карте отчетности. Отдельные аукционы (и их полученные рамки) полностью отделены друг от друга и не обмениваются данными. Объяснитель « Огромные рамки отчетности » предоставляет более подробную информацию по этой теме. |
| Chrome UI | Добавьте фильтр в вкладке Chrome Devtools «Приложение ->« Группы интересов », позволяя фильтровать от IG -владельца (или, возможно, также по имени IG). | Мы оцениваем этот запрос и приветствуем дополнительные отзывы от экосистемы. |
| Безголовный хром | PA API поддержка в безголовом Chrome. | Есть некоторые компоненты PA API, которые связаны с Chrome, например, K-Anon вызовы на серверах Google, которые могут не работать в «старом» хроме без головы. Мы считаем, что это может быть рассмотрено «новой» версией без головы Chrome, выпущенной в Chrome 112. |
| Использование API | В случае отчетности по утрате с отчетом wareaductionloss мы видим «toplevelwinningbid = 0» во многих случаях. Что это за интерпретация? | Значение Toplevelwinningbid происходит от функции Scoread () в пределах компонента продавца верхнего уровня. Это значение играет роль в определении результатов аукциона верхнего уровня. Согласно Объяснению, топвельвиннинг значения нуля или любого отрицательного числа означает, что соответствующая AD не имеет права выиграть аукцион. Этот механизм может быть использован, например, для фильтрации целевых рекламных объявлений группы, которые не превосходят контекстно-нацеленного кандидата. В то время как топвельвиннингбид с нулевым значением может указывать на то, что контекстуальный аукцион преобладал, спецификация API PA признает, что другие факторы могут способствовать этому результату. |
| Режим A/B Тестирование | Разъяснение в режиме B и режиме выбора трафика и подсказки отказа. | Критерии включения для режима A и режима B одинаковы. Цель состоит в том, чтобы иметь группы, которые являются репрезентативными для нормального хромированного трафика, если они поддерживают API -интерфейсы песочниц конфиденциальности и метод маркировки, поскольку некоторые конфигурации клиента не совместимы. Для целей эксперимента важно сравнивать только маркированный трафик с другим помеченным трафиком. Пользователи в режиме B имеют включенную функцию защиты отслеживания, и, как таковые, они получают уведомление об этой функции. |
| Улучшение API | Можно ли включить «LifeTimems» в качестве прямого свойства в Call -Call или управлять им или управлять им как отдельный аргумент? | Мы тщательно рассмотрим отзывы сообщества веб -разработчиков о функциональности «okinadinterestgroup» в предложении PA API. Ключевой точку обсуждения фокусируется на оптимальном методе управления жизнью IG. Мы оцениваем преимущества отдельного аргумента для параметра «LifeTimems», поскольку он способствует гибкости и адаптивности для потенциальных будущих улучшений для спецификации. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Потенциал для увеличения ложных негативных ставок в рамках PA API из-за столкновений с низко экспрояльными идентификаторами браузера. | Команда Chrome активно занимается продолжающейся уточнением рамки PA API. Мы ценим обсуждение потенциальных ложных негативных ставок, возникающих в результате столкновений идентификаторов браузера. Мы тщательно оцениваем эту обратную связь и будем работать над тем, чтобы обновленный анализ всесторонне отражает все соответствующие факторы. Наша приверженность заключается в решении, которое достигает желаемых результатов конфиденциальности при сохранении точности и надежности. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Необходим ли идентификатор браузера с низким уровнем энтропии, чтобы не дать клиентам неоднократно отправлять запросы «соединения» для одного и того же объекта в системе K-анонимности? | Мы признаем и ценим продолжающуюся дискуссию об использовании идентификаторов браузеров при реализации систем K-анонимности. Мы понимаем проблемы, связанные с потенциальными последствиями для конфиденциальности таких идентификаторов. В то время как наша первоначальная реализация использовала идентификатор с низким уровнем энтропии в качестве механизма против злоупотребления, мы активно изучаем альтернативные методы, такие как токены анонимного подсчета, которые приоритет конфиденциальности пользователей при сохранении целостности системы. Мы стремимся найти решения, которые балансируют ответственные данные с помощью надежной защиты конфиденциальности, и мы приветствуем постоянный диалог с исследовательским сообществом. Мы обсуждаем это здесь и приветствуем дополнительные отзывы. |
| Использование API | Поддерживает ли AMP (ускоренные мобильные страницы) PA API. | AMP в настоящее время не поднимает PA API. Мы приветствуем дополнительные отзывы от экосистемы, если поддержка AMP является высоким приоритетом. |
| Улучшение API | Рассмотрим удаление типа из проверки K-анонимности. | Мы тщательно рассмотрим отзывы о потенциально оптимизации структур запросов K-анонимности. Мы понимаем предложение о консолидации параметров и потенциально объединить типы для оптимизации процесса. Наша цель - обеспечить эффективность и обслуживание, и мы оцениваем все варианты, поскольку мы продолжаем разрабатывать наши решения для конфиденциальности. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Chrome UI | Запрос на механизм для менее технологических пользователей легко просмотреть и управлять IG, к которым они принадлежат, включая потенциальные элементы управления на уровне веб-сайта для отказа. | Мы признаем важность предоставления удобных инструментов для понимания и управления IG. Мы тщательно рассмотрели различные методы и обнаруживаем, что выявление IGS на веб -сайте, где они присоединились, предлагает лучший баланс ясности и защиты конфиденциальности. В настоящее время глобальное управление IGS находится в условиях Chrome. Мы постоянно изучаем способы дальнейшего улучшения пользовательского опыта в этой области. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Безопасность API | Является ли PA API уязвимым к утечкам конфиденциальности с помощью творческих взаимодействий AD, даже в контексте огороженных рам? | Мы признаем потенциал утечки информации через сложные рекламные взаимодействия. Мы активно исследуем взаимодействие между огороженными рамами, PA API и потенциальными векторами атаки. Смягчение рисков конфиденциальности является главным приоритетом, и мы стремимся к разработке надежных решений, которые уравновешивают инновации с защитой пользователей. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Задержка | Является ли дефолт на 50 мс тайм -аута для логики торгов покупателя реалистичным значением? | Мы подтверждаем проблемы, связанные с потенциальными несоответствиями между спецификацией и сроками сетевых запросов на логику торгов. Мы активно рассматриваем спецификации, чтобы обеспечить их точность и исследование оптимальных настроек тайм -аута по умолчанию, чтобы сбалансировать производительность и выполнимость. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Документация | Потенциальная утечка сроков в спецификации, где веб-сайт может сделать вывод о том, не удалось ли объявление по порогу k-анонимности, и потенциальные последствия для отслеживания перекрестного сайта. | Мы признаем эту проблему, поднятую в отношении потенциальной утечки времени. Мы подтвердили несоответствие в спецификации и предпринимаем шаги, чтобы гарантировать, что статус K-анонимности AD определяется до аукциона для предотвращения таких утечек. Мы серьезно относимся к этим опасениям и будем обновлять спецификацию, чтобы отразить эти изменения. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Способы реализации блока SSP в PA API. | Мы признаем необходимость в механизмах для управления ограничениями AD SSPS. Мы поощряем изучение решений, которые определяют приоритеты в оценке и использовании существующих метаданных AD для защиты конфиденциальности пользователей, одновременно обеспечивая гибкость. Мы стремимся работать с разработчиками для выявления оптимальных подходов в PA API. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Может ли кто -нибудь сказать своему браузеру, чтобы притвориться, что он занимается PA API таким образом, чтобы сайты не могли обнаружить? | Мы признаем, что в своей нынешней форме отказа от PA API можно было обнаружить веб -сайтами. Мы активно работаем над такими функциями, как дополнительные предложения и негативное таргетинг, наряду с огороженными кадрами, чтобы повысить конфиденциальность и работу в направлении предоставления неопределяемых вариантов отказа. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Режим A/B Тестирование | Трафик центра обработки обработки данных, который должен быть лечением 1.1. | Команда Chrome подтвердила команду GAM, что этот трафик теперь отфильтрован из эксперимента. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Эффективность и справедливость реализации интересов GroupBuyers в PA API. | Мы признаем продолжающуюся дискуссию об эффективности и справедливости поля «интересов» на аукционах PA API. Мы признаем компромиссы между эффективностью, конфиденциальностью и справедливостью на рынке. В то время как продавцы должны управлять деловыми отношениями с покупателями, мы изучаем способы оптимизации процесса сопоставления. Они могут включать динамические корректировки на основе данных в реальном времени и гибридных моделей. Мы по -прежнему привержены поиску решений, которые определяют приоритет конфиденциальности пользователей и поддерживают конкурентную рекламную экосистему. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Chrome UI | Потенциальные проблемы памяти и ясность пользовательского интерфейса, связанные с IG в Chrome. | Мы понимаем проблемы, связанные с отображением IG в DevTools. Хотя текущее представление отражает все события IG для исторического отслеживания, мы признаем ценность в обеспечении более четкой видимости в текущем состоянии хранимых IG. Мы рассмотрим оптимизацию и потенциальные улучшения пользовательского интерфейса, чтобы улучшить понимание разработчиков. Что касается управления памятью, реализация IG предназначена для предотвращения утечек памяти, но мы постоянно контролируем и оптимизируем использование ресурсов. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Документация | Оригинальный постер встречается с ошибкой при попытке использования размеров AD непосредственно в поле «SizeGroup» функции «JoinAdinterestGroup». Они хотят знать, является ли это поведение. | Мы распознаем значение оптимизирующей конфигурации AD в функции «JoinAdinterestGroup». Мы активно работаем над учетом этого ограничения и планируем включить эту функциональность в будущих обновлениях. Это улучшение согласуется с нашим обязательством предоставить разработчикам гибкие и эффективные инструменты для управления рекламой. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Хромированная тестовая этикетка | Запрос иметь прямые данные о режиме A VS B и точных метках в SendReportto, чтобы мы могли последовательно отслеживать эксперимент. | Мы обсуждаем этот запрос здесь и приветствуем дополнительные отзывы |
| Документация | Является ли доменное имя продавца, включенное в запросы, полученные на доверенный сервер продавца в целях проверки? | Мы подтверждаем первоначальное упущение параметра имени хоста из документации API API защищенной аудитории KV. Мы хотим заверить разработчиков, что доменное имя продавца автоматически включено в запросы на доверенный сервер продавца. Эта функциональность необходима для надежных процессов проверки рекламы. Мы обновили документацию, чтобы рассмотреть этот надзор и продолжим расставлять приоритеты в ясности и прозрачности сообщества разработчиков. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Потенциальные методы включения имени IG в отслеживание впечатлений от AD для целей отчетности. | Мы стремимся сбалансировать необходимость надежных механизмов отчетности с фундаментальным принципом конфиденциальности пользователей. Включение имен IG в отслеживание впечатлений от AD подлежит защите K-анонимности, предназначенных для предотвращения идентификации отдельных лиц. Мы будем продолжать изучать инновационные отчетные решения в рамках этих ограничений конфиденциальности. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Функция API | Запрос на доверенный сервер Покупателя для получения клиентских подсказок HTTP. | Мы отслеживаем этот запрос на функцию здесь . |
| Использование API | Должен ли файл делегирования требовать загрузки заголовка «Контроль доступа к авертиругу», учитывая, что он диктует поведение членства IG для браузера? | Мы обязуемся согласовать лучшие практики веб -безопасности. Требование заголовка «Контроль доступа к аллевому происхождению» для делегирования файлов обеспечивает согласованность с принципами CORS и предотвращает непреднамеренное воздействие конфиденциальной информации. Мы исследуем способы оптимизации этого процесса при сохранении сильной осанки безопасности. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Использование API | Позвольте рекламным серверам персонализировать креативщиков в рамках PA API. | Мы признаем роль, которую рекламные серверы могут играть в творческой персонализации. Мы активно изучаем решения для расширения возможностей AD -серверов в PA API, таких как модель «совместное IG», где можно объединить ткад и логику творческого выбора AD. Наша цель состоит в том, чтобы найти баланс между обеспечением надежных творческих возможностей AD и защитой конфиденциальности пользователей. Мы приветствуем дальнейшее сотрудничество и отзывы о развитии API, чтобы удовлетворить потребности всех заинтересованных сторон здесь . |
| Проблемы конфиденциальности | Доступность альтернативных идентификаторов (например, Rampid, ID5) в запросах на контекстуальные предложения может подорвать цели конфиденциальности PA API, облегчая сбор данных поперечного сайта. | Мы признаем потенциальное напряжение между идентификаторами поперечного сайта и целями конфиденциальности PA API. В то время как издатели могут поделиться такими идентификаторами, дизайн PA API в основном направлен на отдел выбора AD от необходимости отслеживания перекрестного сайта. Мы стремимся к развитию рекламной экосистемы, ориентированной на конфиденциальность, и поощрять разработчиков расставить приоритеты в подходе API PA. Мы обсуждаем эту проблему здесь и приветствуем дополнительные отзывы. |
| Кэширование | Есть ли способ предотвратить повторное использование сценариев торгов на нескольких аукционах? | Мы признаем наблюдаемое кэширующее поведение сценариев торгов в рамках PA API. В то время как стандартные механизмы кэширования HTTP поддерживаются, потенциал повторного использования сценариев в разных аукционах существует из -за приостановки поведения устройства и проектирования исполнителей торгов. The team is investigating solutions to provide buyers with greater control over script caching to manage their bidding strategies effectively. We are discussing this issue here and welcome additional feedback. |
| Использование API | Centralize reporting of bidding activity across all IGs for a DSP, while respecting user privacy. | We prioritize user privacy when designing PA API. While direct reporting of individual bidding events is not feasible due to cross-site tracking risks, we offer mechanisms like Shared Storage and Private Aggregation. These enable DSPs to gain aggregated insights on bidding activity, in a manner that upholds user privacy. |
| Использование API | The fetch from sendReportTo() in reportResult() only happens 94% of the time relative to getting a fetch registered with forDebuggingOnly.reportAdAuctionWin(). | While they may not have the same timing, it is possible for both URLs to be fetched at the same time. In some instances, the component seller's worklet was disposed of and needs to be reloaded to then run the reportResult() function. However, neither the time it takes to fetch the scoring logic nor the time for the worklet to reload affects the 50ms timeout of for reportResult(). Please note that Chrome will use caching headers to define its fetching behavior in cases where the worklet needs to be reloaded. You can learn more about the phases of a PA auction here . |
| K-anonymity | Request for confirmation that the name of the interestGroup does not affect the k-anonymity of ad serving. | For a creative to be considered k-anonymous, the tuple of IG owner URL, bidding script URL, creative URL, and ad size must meet the specified threshold (k) over a past time period (w). The k-anonymity status is updated periodically (p). |
| Chrome UI | Proposal to provide the type of "internal visibility" that lots of MVC, ORM, etc frameworks offer. Eg start with simple logging of selected internal events to a new panel in the Dev Tools --> Application --> Application section | We are discussing the proposal here and welcome additional feedback. |
| Chrome UI | Dev Tools IG joining doesn't show priority related elements. | We have addressed this issue here . |
| API Improvement | It would be preferable to allow the creative ad server to track its own events. Could a list of allowed tracking domains be configurable? | We have shared a proposal here and welcome additional feedback from the ecosystem. |
| API Feature Request | Can PA API be extended to support non-RTB media transactions and maintain critical use cases such as ad serving and DCO? | We are discussing the issue here and welcome additional feedback. |
| Publisher Auction Timeout | Publishers need control over auction duration to prevent lost impressions, especially in header-bidding setups where ads are selected sequentially. | We acknowledge the importance of giving publishers granular control over ad auction timeouts. We are actively exploring how to implement a global auction timeout mechanism, potentially within the "auctionConfig" object, while carefully considering the edge cases. This feature aims to optimize impression fill-rates for publishers, and we will continue collaborating with the community to find the best solution. We are discussing the issue here and welcome additional feedback. |
| API Improvement | The current design of IGs in PA API leads to large metadata sizes due to lengthy renderURLs. Testers would like a way to compress these URLs for greater efficiency. | We recognize the importance of optimizing IG metadata size, particularly for efficiency-sensitive ad auctions. We think a template-based solution for compressing renderURLs offers significant potential. We will carefully evaluate the proposed template designs and ensure that any implemented solution includes robust abuse-prevention mechanisms to maintain browser stability. Collaborating with the web standards community to develop the optimal approach, with these considerations in mind, remains a priority. We are discussing the issue here and welcome additional feedback. |
| Использование API | Testers handling native ad formats want to optimize the Privacy Sandbox auction process by retrieving multiple ad results in a single call to reduce network load and improve ad rendering speed. | We recognize the performance concerns raised for native ad rendering in the Privacy Sandbox. We are committed to finding a balance between efficiency and strong user privacy protections. While returning multiple ads with full scores compromises privacy, we are actively exploring ways to optimize the auction process. We are dedicated to enhancing PA API support for native ad formats and investigating alternative mechanisms to improve efficiency within the strong privacy constraints of the Privacy Sandbox. We are discussing the issue here and welcome additional feedback. |
| Использование API | Flexibility in how ad bids are scored and sorted within the Privacy Sandbox, especially to represent priority levels or private marketplace rules. | We understand the need for fine-grained control over ad scoring and sorting within the Privacy Sandbox, particularly in complex bidding scenarios. We acknowledge the proposed solutions using tuples and mathematical functions to achieve multi-dimensional scoring without sacrificing user privacy. While these approaches may add complexity for developers, they offer the necessary expressiveness. We are committed to exploring ways to streamline these processes, potentially through helper functions or guidelines, to ensure optimal use of Privacy Sandbox features for advanced auction logic. We are discussing this issue here and welcome additional feedback. |
| reportEvent() | Add a new reserved event (automatic beacon perhaps) fired by the browser once a frame with an ad creative is initialized. | We are discussing this request here and welcome additional feedback. |
| adCost | Allowing breakdown of adCost. | Each cost value is an opportunity to send a limited amount of information out of the auction. Allowing a whole list of N of those costs would be enough to send a whole user identifier, which would enable cross-site tracking. We are discussing this here and welcome additional feedback. |
| resolveToConfig | Should resolveToConfig be inherited from the top level and exposed in browserSignals? | We are discussing this request here and welcome additional feedback. |
| Better Tools | Is there something akin to chrome://topics-internals but for PA API? | There is nothing exactly the same. However, there is extensive developer tooling for PA API . |
| Этикетки | Can Chrome use labels to identify the 20% k-anon population? | We are considering this request and welcome additional feedback from the ecosystem. |
| Документация | Will Privacy Sandbox auction worklets become standard worklet types? | Due to unique privacy and security requirements, these worklets differ significantly from standard browser worklet types, so we do not anticipate that they will become standard worklet types within the HTML specification soon. We are committed to enhancing our developer resources with clear explanations about the implementation and execution environment of auction worklets, making this information more accessible for Privacy Sandbox participants. We have discussed this further here . |
| Bring-Your-Own-Server (BYOS) Key-Value (KV) server | Parties may be able to learn multiple IGs (from the same owner) joined by a user through KV services queries in a BYOS KV Service setup. | This will no longer be possible when KV servers run in TEEs and we can ensure they can abide by the published trust model. |
| userBiddingSignals | update part of the "userBiddingSignals" while maintaining others. | This is already possible without any changes required to the API. |
| Использование API | Implement frequency capping across multiple IGs within the Privacy Sandbox, potentially using the KV server or modified "prevWinsMs" data. | We acknowledge the desire for advanced frequency capping capabilities within the Privacy Sandbox. We recognize that current restrictions on data sharing across IGs can present challenges when implementing these strategies. While the KV server provides a potential mechanism with appropriate privacy safeguards, we encourage developers to explore solutions within a single IG model. We are discussing this issue here and welcome additional feedback. |
| Использование API | Component sellers (those participating in nested auctions within the Privacy Sandbox) need visibility into top-level auction timeouts to optimize their own configurations and avoid unnecessary delays. | We recognize the need for improved timeout coordination between top-level sellers and component sellers within the Privacy Sandbox. We are actively investigating the addition of new timeout mechanisms, including a potential whole-auction timeout and exploring ways to apply top-level timeouts to component auctions. Our goal is to enhance efficiency and predictability for all participants in the Privacy Sandbox auction process. We are discussing this issue here and welcome additional feedback. |
Службы защищенной аудитории
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Trusted Execution Environments (TEEs) | More expensive to run TEEs in public clouds as opposed to on-premise ad tech data centers? | Our response is similar to previous quarters: Our current TEE security model benefits from the practices of public cloud implementations. In particular, current hardware-based TEEs do not defend against all physical attacks. Our existing supported public cloud providers, AWS and GCP, designed and implemented mitigations for physical access risks, including from employees. See further details below regarding on-premise support. Ad techs have mentioned to us that running cloud services is more expensive than on-premise ad tech data centers. While we are not in a position to evaluate those statements, we welcome additional feedback on costs and continue to evaluate options for expanding our TEE support. |
| TEEs | Support for TEEs in non-public cloud environments | Our response is similar to previous quarters: While we are continuing to explore support for options beyond public cloud-based solutions, we have no current plans to support on-premise TEEs. At this stage, given Privacy Sandbox security requirements and the significant challenges presented by on-premise deployments, we believe that continuing to expand and improve cloud-based deployments (for example, supporting Google Cloud in addition to AWS) is the most beneficial for the экосистема. However, we welcome additional feedback on why such a requirement is necessary and feasible given the privacy and security constraints. |
| Other Cloud Providers | Support for other cloud providers | We are always open to suggestions for other cloud providers, but currently we are planning at least to support GCP and AWS when 3PCD is enforced. Refer to this explainer for more information. |
| B&A Services API | What is Google's direction for the B&A Services API? Will it be prioritized above or below the Chrome browser Protected Audience on device auctions? | Our response is similar to previous quarters: We remain committed to the current Protected Audience on-device bidding design. The B&A services have been proposed to explore possible solutions to support a subset of use cases where the computational power or network speed of the device may be limited. |
| Стандартизация | B&A services have not gone through a standardization process. | The B&A Services proposal is in the middle of one phase of the standardization process, and we welcome additional engagement in support of that goal. It began with a proposal (based on previous proposals), it is being publicly incubated through extensive open discussion at W3C and interested developers are able to begin experimenting with it and providing feedback. This is the usual pattern for web feature development, as described for example in our blog post here . |
| KV Server | Expose full URL to buyer's KV server for content / contextual / site targeting. | We are discussing this request here and welcome additional feedback from the ecosystem. |
| Документация | The documentation for "Trusted/Enforced components vs. optional" on GitHub causes confusion with some ad techs who have their own set of deployment images and infrastructure. | We are looking to improve the documentation for "Trusted/Enforced components vs optional", and am interested in hearing from the ecosystem if such work needs to be prioritized. |
| API Improvement | The HTTP Status Code of a KV server call should also be available to the scoreAd() function as a parameter. | We are evaluating this request and welcome additional feedback from the ecosystem. |
| Документация | Provide more information on how JS and WASM workloads would be handled exactly with the UDF execution. | We are looking into providing this information and welcome additional feedback here . |
| Документация | Request to update repo name. | We have renamed the repository to "protected-auction-key-value-service". This is in line with the term for the collection of services this belongs to, which also has other repositories such as the Protected Audience Services discussion , and the Protected Auction Services documentation repos. |
| Документация | Remove reference to Cloud debugger API in bidding_auction_services_gcp_guide.md. | We have updated the documentation and removed the reference. |
| Использование API | Latency introduced by the KV lookup is taking more than 50ms. It's taking nearly 100ms. Do you have any guidance on what's been working well for other sellers? Do you have any suggestions on how to measure the timeouts and timing? | The KV server call happens inside the context of the Script Runners, ie the special protected environment inside of the Chrome browser. It is intended to keep information in these script runners protected from any non-API access. We have provided a detailed explanation here . |
| Использование API | Is there a timeout for the KV server to respond in a particular time? | Sellers can specify the "perBuyerCumulativeTimeouts" field in the auction config. This timeout includes the time needed to fetch trusted bidding signals. |
| Задержка | How is the Privacy Sandbox team working to address latency? | For strategies we are exploring to keep the latency within acceptable limits, see here . |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Manual Campaign Optimization | ARA does not support manual campaign optimization. | We have discussed this scenario with the ad tech and shown ways in which ARA can be used to support manual campaign optimization. ARA has been built in a way that allows for ad tech customization and flexibility to solve a range of ad tech use cases. A few suggestions that were provided included using different flexible event-level configurations and, using event-level reports with summary reports to reduce the impact of noise and to achieve their manual and automatic optimization needs. We are open to additional ecosystem feedback regarding the customizability and flexibility of ARA configurations. |
| Тип конверсии | Google is only allowing eight conversion types which is limiting. | We have implemented the majority of Flexible event-level reporting , which gives ad techs additional flexibility in terms of the number of reporting windows, number of attribution reports, and bits of trigger data that they can use. Ad techs can choose a configuration that allows measuring up to 32 different conversion types. |
| Aggregatable Report Event Limit | The numerical minimum of 20 conversion events per aggregable report is not workable for smaller advertisers with limited budget. | There is no minimum number of conversion events needed per aggregatable report. Additionally there are a number of design decisions that can be made to optimize aggregatable reports for smaller advertisers such as changing the key structure / dimensions tracked, testing different levels of epsilon, testing longer batching frequencies, and testing different contribution budget allocations between measurement goals. Smaller ad techs can also experiment with combining event-level reports and summary reports as a way to reduce the impact of noise. |
| Данные в реальном времени | Depriving DSPs of real-time data (eg on clicks, sessions, and conversions) which DSPs use to adapt their bidding strategy and achieve better campaign effectiveness, goes against the commitment to maintain existing functionalities. | Even with ARA, clicks and sessions remain real time, and conversions are always after the fact even with 3PCs. |
| Missing Fields | Missing requirements in the Full Flexible event rollout: i) Currency field, and ii) orderID / TransactionID field. | We do not plan to support a Currency field or Order ID / Transaction ID field currently as part of full flexible event-level because there are already ways to do this with current event-level reporting. We are open to additional feedback regarding these fields, and will reconsider if there are additional use cases that require these. The ways to use ARA's current design to measure currency and order ID type information: 1. Based on the feedback, the currency is determined by a user's geo, which can be added as part of the source_event_id as a way to determine what currency was used. 2. Based on the feedback, the order ID field is needed to ensure conversions and values are not double counted by mistake, which can be done by using deduplication keys. |
| Privacy Budget | ARA Privacy Budget limits the ability to measure across multiple dimensions | ARA has been designed in such a way as to allow ad techs to customize their own ARA configurations to cover a variety of attribution scenarios. With the current ARA design ad techs will need to think about the trade off between what dimensions are most crucial for them to measure and the impact of noise on their data. Adding noise to the data depending on the granularity of dimensions that are being measured is essential for privacy. We are open to additional ecosystem feedback regarding the ability to measure across different dimensions, but would need to understand the specific use cases that require this. |
| Update Specification | Although Google has said it has moved from fixed to flexible event reporting windows, this has not been reflected in Google's Technical Specifications which still currently has a minimum window of one hour. | Flexible event-level reporting currently allows ad techs to change the number of attribution reports per source event, the bits of trigger data, and the number/length of reporting windows. ARA still has a minimum reporting window of 1 hour for event-level reports which is essential to maintain privacy and mitigate against certain types of history reconstruction attacks. Since summary reports provide information in aggregate, ad techs can opt in to receive aggregatable reports immediately with no delay, if needed for their use cases. |
| API Design | Concern that reducing information in conversion reports and adding noise could impact the ecosystem more than Google. | 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 of all sizes. |
| Attribution Correction | ARA doesn't allow the tech provider to control and verify the correct attribution. | There are many available solutions within ARA that provide verification capabilities: 1. Ad techs can verify that ARA behavior matches their expectations: – ARA client-side code is open-sourced. – ARA server-side code is also open sourced, and Coordinators ensure that only allowed versions of Aggregation Service can decrypt and process aggregatable reports. 2. Chrome has provided ad techs with a Simulation Library to verify attribution behavior, where the ad tech can test how ARA performs attribution in a mock environment. 3. ARA supports a number of debug signals that help to verify whether or not and why expected processing may not have occurred. |
| (Also reported in previous quarters) Шум | Feedback that the level of noise is too high and it is impacting the usefulness of the reporting. | We have spoken to ad techs with this same feedback and were able to identify ways in which ARA can be customized to better suit their use cases, even with noise. We have developer documentation that contains the majority of design decisions and customizations that we discussed with the ad techs. ARA has been designed in a way to allow ad techs to customize their own ARA configurations to cover a variety of attribution scenarios. But ad techs will need to think about the trade off between what dimensions are most crucial for them to measure and the impact of noise on their data. We are open to additional ecosystem feedback regarding the impact of noise and can provide additional guidance on ARA levers that can be used to change the impact of noise. |
| Cross-domain Attribution | How to track the attributions that are cross domain? | Ad techs can redirect to different reporting URLs to solve for this use case. We are open to additional ecosystem feedback regarding this design aspect of ARA. |
| API Improvement | Regularly change the scaling factor used when registering attribution for ARA Summary Reports. | Based on the discussion on GitHub, it seems that handling multiple scaling factors in Aggregation Service will most likely result in a higher amount of noise added to summary reports versus the current functionality. We are open to additional feedback regarding the need for scaling factors as part of aggregatable reports, but want to call out the potential trade off with increased noise. We are also evaluating whether other future ARA features may help to solve this use case as well. |
| Использование API | Opportunity to unify how attribution events get shared with all participants which is beneficial for SSP, DSP, etc. | We plan to sync with ad tech to better understand their feedback and any limitations they are running into. |
| Test Traffic Volume | Is the test traffic for Mode B for all Chrome stable? | Inclusion in an experiment group is unaffected by (independent of) Chrome settings. |
| Документация | Support ARA for pixels. | We have published information about how to support this use case and welcome additional feedback from the ecosystem. |
| Использование API | ARA may not be attributed to the correct source for third-party sellers on ecommerce platforms if the conversion is not done by the last touch. | Companies can use filters to prevent incorrect attribution from happening (as in no conversion report will be generated). We are also working on a proposal for pre-attribution filtering to help with this use case. |
| Поддержка браузера | Will ARA be supported in different browsers? | We welcome other browsers to adopt the Privacy Sandbox APIs and continue to dedicate time to discussing our approach in the open at W3C. We have explicitly stated interoperability as a goal for shipping ARA and ARA's design is intended to be browser-agnostic with flexible vendor-specified values for vendors with different privacy stances. Other browsers are making their own choices on whether to provide viable alternatives to cross-site identifiers that can support the digital ecosystem of content and services. We're encouraged that Microsoft Edge has indicated it will support A RA . |
| Использование API | What is the expected source kind for ARA source registrations for registerAdBeacon/reportEvent (and navigation_start/commit automatic beacons)? | It depends if these beacons are automatic or manual: - reserved.* (ie automatic) events to be of navigation-source type. - Manually triggered events to be of event-source type. |
| Использование API | Does the maximum limit of 20 aggregatable reports per source mean for each source event? Is the limit global or daily? Is there a plan to increase the limit? | The 20 aggregatable reports per source limit is a global limit where 20 aggregatable reports can be created for each source. The limit is set by the browser and non-configurable. The purpose of this limit is to avoid abusing the protection of real attribution reports with null reports. We have discussed this further here . |
| Использование API | Support for email marketing using ARA. | Right now there is no direct support for this use case within ARA (if you don't control the email hosting site). We are discussing this here and welcome additional feedback. |
| Эпсилон | When will the value of epsilon for the Aggregate API be determined? | The current epsilon value can be configured by ad techs up to a predetermined threshold defined by Privacy Sandbox (which is currently 64). We recommend testing different epsilon values and identifying inflection points for your own use cases and providing feedback. We will make sure to communicate to ad techs in advance prior to any changes to the range of epsilon values. |
| API Improvement | Support a use case where the advertiser can insert an identifier into the trigger_data field for matching with external CRM data to allow advertisers to verify the quality of conversions. | We are discussing the request and welcome additional feedback here . |
| Использование API | How to handle redirect URLs as destination urls. | Ad techs can do either of the following: 1. Put the final destination URL in the destination field; 2. Destination field allows up to 3 urls which allows you to put multiple URLs into the field. Both options will require knowing the final destination URL. We have discussed this further here. |
Aggregation Service
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Key Discovery Mechanism | Request for a key discovery mechanism | We have a proposal for key discovery and welcome feedback from the ecosystem on the proposal. |
| Использование API | Roadmap for observability on Aggregation Service | We are reviewing options to support more observability and welcome feedback from the ecosystem here . |
| API Improvement | Requesting to be able to requery reports. | Aggregation Service is working on a requerying proposal where ad techs can split their epsilon for each report. This can introduce more noise per query but will allow ad techs to requery and maintain privacy. |
| API Improvement | Would like to be able to associate multiple origins to the same AWS ID. | Aggregation Service will now allow multiple sites to be onboarded on the same cloud account (GCP or AWS). This will allow ad techs to use the same Aggregation Service enclave for processing reports from multiple sites and multiple origins from the same sites. |
| Использование API | When aggregatable batches fail, not sure if the budget is consumed or not and if they can reprocess their batch. When an aggregation service encounters a budget error for duplicate reports, the rest of the remaining reports are lost. How to minimize this loss? | In a typical scenario, if the entire job fails, the budget will not be consumed. In cases of a rare failure where budget is consumed, ad techs can request budget recovery. If the ad tech encounters frequent job failures with the budget exhausted error, they should confirm their batching strategy. Instructions on how to batch correctly and avoid duplicate reports and errors can be found here . We welcome feedback on budget recovery here . |
| Использование API | Using Private Aggregation API with the trigger described here would produce an aggregatable report for every auction. What are the scaling capabilities of Aggregation Service? | Aggregation Service itself does not put an upper limit on the number of keys or reports in a batch but a scale of 10^14 reports and 10^12 keys is currently unsupported due to the memory that would be required. Our sizing guidance indicates the ranges we have tested and recommend for optimal performance given expected load and the supported cloud vm instance types. |
| Обработка данных | If an encrypted data has personal information, what is the legal arrangement of providing encrypted data to the Aggregation Service? Can you advise whether it is guaranteed that the coordinator will not access encrypted data? | The Aggregation service does not share encrypted / user data with the Coordinator. The Aggregation service uses the coordinator for key management and accounting. Some details on the coordinator can be found here . For accounting, Aggregation service only shares the shared ID and the reporting origin with the PBS for budget consumption. Once we launch a multi-site we will replace origin with site. Note that Aggregation service runs in a TEE which is the only place where reports from clients can be decrypted. The code running in the TEE is open sourced and audited by external parties as outlined here . |
Private Aggregation API
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Использование API | Ability of component sellers to send reports to multiple aggregation servers within a TEE. | The current Private Aggregation API status does not support this feature. We have discussed this issue further here . |
| Документация | What is the epsilon value used in Google's trials? | For the Private Aggregation API, the ε value specified in an aggregation service query corresponds to the L1 contribution budget of 2^16 that is enforced on a rolling 10 minute basis. There's also a 'backstop' L1 contribution budget of 2^20 that is enforced on a rolling 24 hour basis. So essentially, the privacy parameter is ε on a rolling 10 minute basis, and is 16ε on a rolling 24 hour basis (rather than 144ε). Aggregation service currently supports a range of ε for testing (up to 64) to allow for experimentation with different aggregation strategies and provide feedback on the utility of the system with different privacy parameters for Private Aggregation and other APIs. We plan to revisit the maximum allowable epsilon value over time as we get feedback from testers and add features that allow for more efficient privacy budget usage. |
Limit Covert Tracking
User Agent Reduction/User Agent Client Hints
No feedback received this quarter.
IP Protection (formerly Gnatcatcher)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Resolution ID | Privacy Sandbox needs to be more vocal to press that resolution IDs often built on IP are not sustainable for advertisers. | Privacy Sandbox has made it clear that we aim to reduce cross-site tracking. Our public initiatives, which extend beyond cookies, are publicized both on privacysandbox.com and GitHub. We strive to reduce cross-site tracking, including that based on IP addresses. However, it is ultimately up to individual websites to decide whether to proactively enable cross-site tracking. In an era of increased scrutiny on regulatory compliance, it is prudent for individual companies to have an understanding of the practices employed by their service providers. |
| Хромкаст | Will IP Protection impact Chromecast or other Chrome devices? | There are currently no plans for IP Protection to be applied to Chromecast devices. |
| IP Protection List | Will the list of third parties identified as potentially using IP addresses for web-wide cross-site tracking be published? | The list will be published once finalized, as discussed here . |
Bounce Tracking Mitigation
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Single Sign On (SSO) Exemption | How will Bounce Tracking Mitigation (BTM) verify SSO use cases for exemption? | BTM will be disabled by Chrome heuristics. Подробности смотрите здесь . |
| Deprecation Trial | Is BTM enabled for sites in the 3PC deprecation trial? | No, BTM honors the cookie exceptions created by the deprecation trial, as discussed here . |
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 |
|---|---|---|
| Запрос функции | CHIPs and / or Storage Partitioning are automatically allowed to be accessed across the RWS, without the need for the Storage Access API, nor user interaction. | We are considering the benefits and feasibility of a feature that may perform this function. One consideration is a potential gap in cross-browser interoperability, which RWS addresses by leveraging the Storage Access API. There is no current equivalent to this requested functionality supported on other browsers. We encourage developers to submit their use cases on this issue to facilitate discussion here . |
| Removal of Non-compliant Sets | What is the process to remove sets that become non-compliant from the repository? | We are working on defining a process for this, and we'll share updates as soon as they're available. |
| Enforcement Process | There is a lack of clarity around Google's subjective role in the RWS enforcement process. | As RWS is an ongoing project and we are continuing to receive new submissions, aspects of the process and our criteria are still being solidified. We do agree that it is important for our submission guidelines to fully outline our requirements for submission, and we will add greater detail to our submission guidelines going forward to avoid further ambiguity and confusion. Our intent is for the submission process to be as technical as possible so that we can phase out human involvement and entirely rely on automated checks. PRs such as this one necessitate more human interaction because they include behaviors we did not anticipate, but they allow us to identify more areas for automation and ways we can fix our guidelines to avoid these problems going forward. |
| Sharing Data | Request for a feature that allows domain owners to indicate they would like a third party to also share RWS data, with user consent. | The requested functionality is already available through APIs such as FedCM, and Storage Access APIs that enable access to authenticated identity after the user accepts a permission prompt. We welcome feedback from the ecosystem on any specific use cases that they believe are not possible. |
| Other Storage Methods | Will information saved on local storage or session storage will also be interpreted as 3PCs? | Local storage, session storage, and other forms of non-cookie storage when used within third-party contexts have been partitioned in Chrome since version 115. See this blog post for additional details. |
| Associated Sets Limit | What happens to organizations who submit more than 5 domains even though this is "capped at 5 associated sites"? | These sets will be accepted via the GitHub process, but the browser (Chrome) will only apply our Storage Access API auto-granting rules to the first 5 domains; and ignore the remaining domains, as discussed here . |
| find_robots_txt | find_robots_txt check does not work with redirects. | A fix has been submitted to resolve this issue here . |
| User Gesture | Remove user gesture requirement for accessStorage(). | This requirement was made based on a similar design that is in place across all major browsers for the requestStorageAccess API. We invite additional feedback and use cases in this GitHub issue to help us prioritize this request, and enable cross-browser discussions. |
| User Gesture | Is a user-gesture required to grant permission for third-party storage access after a Chrome or OS restart? | Yes, but we welcome additional feedback from the ecosystem on whether to change this behavior here . |
API изолированных фреймов
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| adComponent | Lack of documentation and flexibility using AdComponents with Fenced Frames. | We are looking to share more documentation regarding this use case. Also to add, ad components are supported in Fenced Frames using getNestedConfigs() which is documented in the spec here . |
| (Also reported in previous quarters) Render adComponent | Request for sample codes on how to render adComponents in Fenced Frame. | We are working on sharing some sample codes here . |
| Third-party Ad Verification | The role of third-party ad verification in the context of Fenced Frames needs more detail, especially regarding contextual/brand safety. | Today, Fenced Frames Ad Reporting does allow for DSPs to send impression and auction event-level data to 3P ad verifiers for post-render brand safety checks and billing. |
| Expandable Ads | Request to support expandable ads. | If the ad needs to switch between two sizes with the same aspect ratio, and there is no functional difference between the two (just size), the embedder could resize the Fenced Frame with the second ad size and the browser accordingly scales the Fenced Frame element . |
| (Also reported in previous quarters) Support for Video & Native Inventory | Does Fenced Frames support video & native inventory? | Our response is similar to previous quarters: PA API supports video rendering using a mechanism that relies on iframes. However, we haven't yet designed a solution for video and native ads rendering that is compatible with Fenced Frames, and this is one of the reasons we had decided to push back Fenced Frames enforcement to 2026. That means if a partner does decide to enforce Fenced Frames now, the support for video and native would be lacking for that partner. |
| Консультативный совет | Requests the creation of an advisory board of native ad vendors to ensure Fenced Frames implementations follow industry standards. | Fenced Frames are not required for use in PA API any sooner than 2026. The additional time allows us to continue working with the industry to design and implement support for a broader range of critical use cases. We've previously stated we will evolve Fenced Frames ahead of their requirement to maintain support for video and native ads with PA API. Per our commitments, we will engage with and inform the CMA of any such changes, and we will continue engaging with feedback from the ecosystem ahead of requiring Fenced Frames. Our ecosystem engagement model at W3C and ad standards organizations like IAB Tech Lab allows for industry experts of all kinds to guide the designs before they are required. |
| (Also reported in previous quarters) Size Difference Across Platforms | Reports that the size of content displayed in the Fenced Frame looks different between desktop and smartphones. | This is a known Chromium issue which we are investigating. We welcome additional feedback here . |
| API Improvement | Did the Fenced Frames requirement get pushed back to 2025 so that native ads are now supported under Privacy Sandbox? | As we noted in our public announcement for Fenced Frames enforcement no sooner than 2026, we had learned of a broad "significant effort to accommodate" Fenced Frames. Certainly, one of which was Native, but it was not the only factor. The intent was to provide more time to ensure ecosystem readiness to support key use cases, including, but not limited to, native. |
Shared Storage API
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Производительность | Shared Storage return times outside of the worklet appear to be dependent on activity in the worklet. | We are discussing this test result here . |
| Wider Adoption | Shared Storage should be an industry-wide standard available across browsers. | We welcome and acknowledge this feedback. Chrome is continuing to actively participate in W3C fora, including the WICG , to champion the proposal, seek feedback, and drive adoption. |
| Bidding Worklets | Is it possible to read from Shared Storage within the generateBid (which is already running in a worklet) to apply ad-decision / business logic (such as Frequency Capping) based on cross-site information and select a subset of ads? | No, it is impossible to read from shared storage within bidding worklets. |
ЧИПСЫ
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Partition Capacity | Clarify behavior when over partition capacity. | When capacity is reached, the oldest cookies are ejected from the least recently accessed cookie(s) to free memory until the limit is no longer surpassed. Developers see the updated Cookie header in subsequent requests. |
| Third-party iFrame Access | Embedded third-party iFrame content opening a new tab/window to the same third-party site should have access to the same partitioned cookies as the opener. | We are discussing this use case and welcome additional feedback from the ecosystem here . |
| Duplicate Cookies | If there's a partitioned cookie and an unpartitioned cookie with the same name, which key value does the browser decide to send? | When having two cookies with the same name (one partitioned, and one not), you'll get both cookies – unfortunately, there is no way to differentiate which is which. The RFC spec on this is available here , which explains that the order in which cookies are sent should not be relied upon. |
| Запрос функции | Opt into origin-partitioned cookies. | We are considering this request and welcome additional feedback from the ecosystem here . |
FedCM
No feedback received this quarter.
Борьба со спамом и мошенничеством
Private State Token API (and other APIs)
| Feedback Theme | Краткое содержание | Chrome Response |
|---|---|---|
| Webview | Are Private State Tokens (PSTs) persisted across multiple Webviews on the same mobile device (profile)? | Each app that uses webview will have a different local storage, which means PST issuers cannot issue tokens in one app's webview and then later in a separate app, allow token redemptions. This is true for other forms of data stored locally on webviews as well, such as cookies. PSTs are not yet fully available in WebView. We expect to provide an update on this by the end of Q2. |
| New Token Type | Proposal for a new token type. | We are thankful for this proposal and continued exploration into applications and adaptations of PSTs, and look forward to learning more about this proposal in upcoming Anti-Fraud Community Group meetings in Q2 2024. |
| Идентификация пользователя | How to prevent users being identified based on the particular PSTs a user has? | This is currently mitigated by limiting redemption attempts on a site to two issuers, regardless of whether there are tokens available from that issuer. You need to count an issuer against the limit even if there aren't tokens available as otherwise the site could iterate through all issuers until it hits a positive match. |
| Постановка на учет | How long will registration be required for PSTs? | Registration will continue to be required for the foreseeable future, as explained in further detail here . |
| Support for other Chromium Browsers | Will PST issuer registration for other Chromium-based browsers be supported through the Chrome Issuer Registration repository ? | Chrome fetches the key commitments and distributes them to Chrome clients through a mechanism called Component Updater. As other browsers add more complete support for the API, they'll need to establish a process for getting the key commitments to the client, either through a component updater-style method or some other method. This is addressed in further detail here . |