Ежеквартальный отчет за первый квартал 2025 года, в котором суммируются отзывы экосистемы, полученные по предложениям Privacy Sandbox, и ответ Chrome.
Компания Google подготовила этот ежеквартальный отчет в рамках своих обязательств перед Управлением по конкуренции и рынкам («CMA») согласно параграфам 12, 17(c)(ii) и 32(a). В этом отчете рассказывается о прогрессе Google в реализации предложений Privacy Sandbox; обновленные ожидания по срокам; подробные объяснения того, как Google учел замечания третьих лиц; а также краткий обзор взаимодействия между Google и CMA, включая отзывы CMA и подход Google к их рассмотрению.
Google информирует CMA о ходе реализации предложений по Privacy Sandbox на своих регулярных совещаниях, запланированных в соответствии с пунктом 17(b) Обязательств. Кроме того, команда ведет документацию для разработчиков , в которой представлены обзоры основных функций частной рекламы и изменений файлов cookie , а также информация о реализации API и статусе . Ключевые обновления публикуются в блоге разработчиков , а целевые обновления — в отдельных списках рассылки разработчиков.
Глоссарий сокращений
- АРА
- API отчетов по атрибуции
- ЧИПСЫ
- Файлы cookie, имеющие независимое разделенное состояние
- ЦСП
- Платформа спроса
- ФедКМ
- Федеративное управление учетными данными
- IAB
- Бюро интерактивной рекламы
- ВПЛ
- Поставщик удостоверений
- IETF
- Целевая группа по интернет-инжинирингу
- ИП
- Адрес интернет-протокола
- openRTB
- Ставки в реальном времени
- ОТ
- Исходная пробная версия
- ПА API
- API защищенной аудитории (ранее FLEDGE)
- ПатКГ
- Группа сообщества частных рекламных технологий
- РП
- Доверяющая сторона
- РВС
- Сопутствующие наборы веб-сайтов (ранее — собственные наборы)
- ССП
- Платформа предложения
- UA
- Строка пользовательского агента
- UA-CH
- Подсказки для клиента User-Agent
- W3C
- Консорциум Всемирной паутины
- ВИПБ
- Умышленная IP-слепота
Общий отзыв, без конкретного API/технологии
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Выбор пользователя | Неясно, как будет выглядеть обновленный подход Google к расширению выбора пользователей, как он будет представлен пользователям и ожидаемый уровень согласия/отключения. Требуется дополнительная информация, чтобы отличить это от прекращения поддержки сторонних файлов cookie. | В апреле 2025 года Google опубликовал сообщение в блоге «Следующие шаги для Privacy Sandbox и защиты от отслеживания в Chrome» , в котором объявил, что Google принял решение сохранить текущий подход к предложению пользователям сторонних файлов cookie в Chrome и не будет внедрять новую отдельную подсказку для сторонних файлов cookie. Мы будем предоставлять дальнейшие обновления по мере их поступления. |
| Отпечатки пальцев | Google не предоставил издателям или маркетологам никакой информации о том, как они могут полагаться на какие-либо альтернативы рекламным системам Google, не используя более рискованные идентификационные данные потребителей в качестве общего ключа сопоставления (т. е. снятие отпечатков пальцев). | Мы выделили несколько рекламных систем, не принадлежащих Google, которые предлагают издателям и маркетологам решения, частично построенные на API-интерфейсах Privacy Sandbox. Сюда входят рекламные системы, не принадлежащие Google, на разных рынках и каналах. Более подробную информацию и тематические исследования можно найти в разделе «Бизнес-ресурсы» на сайте Privacysandbox.com здесь . |
| Песочница конфиденциальности | API Privacy Sandbox заменят компоненты интернет-данных собственными готовыми продуктами Google. Поскольку альтернативой Google является API, он предлагает доступ к продукту, которым он владеет и который контролирует, а также к продукту, на который распространяются положения и условия, которые Google имеет право по своему усмотрению. Это не замена компонентам, которые другие используют для производства собственной готовой продукции. | API-интерфейсы Privacy Sandbox были разработаны и внедрены после широкого взаимодействия с регулирующими органами и широким кругом заинтересованных сторон экосистемы. Как и в случае с другими платформенными технологиями, API-интерфейсы Privacy Sandbox должны учитывать, что они будут использоваться в качестве компонентов в готовых продуктах других компаний, и мы приветствуем усилия экосистемы по разработке дополнительных технологий для работы вместе с API-интерфейсами Privacy Sandbox. |
| Выбор пользователя | Запросите информацию о том, будет ли обновленный подход Google к 3ПК на Chrome соответствовать определенным нормативным требованиям, которые могут повлиять на работу платформы управления согласием заинтересованных сторон. | В апреле 2025 года Google опубликовал сообщение в блоге «Следующие шаги для Privacy Sandbox и защиты от отслеживания в Chrome» , в котором объявил, что Google принял решение сохранить текущий подход к предложению пользователям сторонних файлов cookie в Chrome и не будет внедрять новую отдельную подсказку для сторонних файлов cookie. Мы будем предоставлять дальнейшие обновления по мере их поступления. |
| График конфиденциальности и внедрение песочницы | Рекламные технологии приостановили тестирование Privacy Sandbox API и ищут веские причины для реинвестирования в эти технологии для продуктовой и маркетинговой деятельности. На их решения о реинвестировании сильно влияет необходимость большей ясности в отношении сроков выбора пользователя, а также опасения по поводу задержки API защищенной аудитории (PA API) и дорожной карты B&A. Кроме того, существуют опасения по поводу предстоящего обзора обязательств CMA, особенно в отношении роли Google как основного драйвера технологий Privacy Sandbox без использования идентификаторов 3P, а также общего будущего направления инициативы по информированию инвестиционных стратегий. | В апреле 2025 года Google опубликовал сообщение в блоге «Следующие шаги для Privacy Sandbox и защиты от отслеживания в Chrome» , в котором объявил, что Google принял решение сохранить текущий подход к предложению пользователям сторонних файлов cookie в Chrome и не будет внедрять новую отдельную подсказку для сторонних файлов cookie. Мы будем предоставлять дальнейшие обновления по мере их поступления. Аукционы Chrome PA API стали на 35 % быстрее по сравнению с прошлым годом. Кроме того, мы наблюдаем значительный рост использования параллельных аукционов, что обеспечивает еще больший выигрыш для этих аукционов. Наш текущий план развития B&A доступен здесь . |
| Хронология конфиденциальности в песочнице | Что было обновлено на странице «Хронология конфиденциальности песочницы»? | Обзор API тем был недавно добавлен на страницу временной шкалы Privacy Sandbox. |
| Песочница конфиденциальности | Существуют ли какие-либо исследовательские работы по вопросам конфиденциальности и полезности, которые помогут понять влияние Privacy Sandbox на доход? | Соответствующие тематические исследования рынка, в которых рассматриваются эти вопросы, доступны здесь , а результаты тестирования API-интерфейсов Privacy Sandbox доступны здесь . |
| Принятие «песочницы» конфиденциальности | Один из первых пользователей сообщил о первоначальных проблемах с API-интерфейсами Privacy Sandbox из-за медленного внедрения более крупными компаниями, что повлияло на запуск тестов. Однако, несмотря на это, совместный подход команды Privacy Sandbox и оперативность реагирования на отзывы были оценены по достоинству. | Мы ценим отзывы первых пользователей. Мы стремимся сотрудничать с ранними пользователями и продолжим взаимодействовать с экосистемой и собирать отзывы, оценивая роль технологий Privacy Sandbox в поддержке экосистемы. |
| Тестирование Chrome | Обеспокоенность по поводу возможности эффективного продолжения тестирования Privacy Sandbox после удаления меток тестирования, подчеркивающих значительную разницу в качестве трафика между Chrome с отключенными 3 компьютерами (режим B) и пользователями, которые лично отключили 3 ПК в настройках Chrome. | Наш ответ аналогичен предыдущим кварталам: Команда Privacy Sandbox понимает, что компании хотели бы продолжать использовать метки прекращения поддержки файлов cookie . Процесс продления доступности этикеток аналогичен продлению пробного периода происхождения. Поддержка лейблов расширялась несколько раз. Мы планируем предложить дальнейшее расширение поддержки меток прекращения поддержки файлов cookie и будем делиться обновлениями на Blink-dev по мере их доступности. |
Регистрация и аттестация
В этом квартале отзывов не получено.
Показывайте релевантный контент и рекламу
Темы
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Согласие на вход/выход | Будет ли подтверждение Google того, что Google Search не будет использовать решение сайта об отказе от API Topics в качестве сигнала ранжирования, ограничит ли Google использование решения сайта о согласии на API Topics в качестве сигнала ранжирования? | Наш ответ аналогичен предыдущим кварталам: Команда Privacy Sandbox не координировала и не просила поисковую организацию использовать рейтинг страниц в качестве стимула для веб-сайтов к внедрению API тем. Поиск Google не будет использовать решение сайта о поддержке (или не поддержке) API тем в качестве сигнала ранжирования. |
| Наблюдение за использованием | Запрос механизма наблюдения для SSP или общей рекламной технологии, чтобы иметь возможность видеть, используется ли их реализация API тем в Интернете. | Мы оцениваем поддержку этой функции и приветствуем дополнительные отзывы от экосистемы, если эта функция имеет высокий приоритет. |
| Конфиденциальность | Вопросы о согласии и возможности повторной идентификации. | В настоящее время мы обсуждаем этот вопрос здесь и будем рады дополнительным отзывам. |
API защищенной аудитории
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| PA API и GAM/AdX | Google не будет отправлять запросы GAM/AdX издателю, который желает использовать рекламный сервер конкурирующего издателя. Google должен предоставить конкурирующим издателям возможность выбирать альтернативных продавцов на аукционе PA API верхнего уровня для управления финальным аукционом. Информация из PA API будет доступна GAM, но ограничена для конкурирующих SSP. В результате издатели не могут сравнивать эффективность запросов, полученных от PA API в GAM, например от AdX или от SSP, интегрированных в PA API. | Ответ Chrome: Стандарт PA API задуман как гибкий и позволяет различным сторонам проводить аукцион верхнего уровня. Этот выбор зависит от конкретных реализаций и возможностей, предлагаемых рекламным сервером издателя (будь то GAM или другой) и другими компаниями-участниками экосистемы. Ориентированный на конфиденциальность дизайн PA API последовательно ограничивает детализированную отчетность для всех участников. Конкретные данные, полученные на самом аукционе PA API, подпадают под действие одних и тех же правил и ограничений, определенных API, обеспечивающих конфиденциальность, для всех участников, включая любых SSP. Издатели используют сводные отчеты PA API, сохраняющие конфиденциальность, для оценки производительности. Это позволяет оценить общий вклад спроса, поступающего через API PA, и позволяет сравнивать его с другими каналами спроса в соответствии с принципами конфиденциальности API. Ответ Google Ad Manager: Издателям не требуется использовать функции рекламного сервера GAM для доступа к спросу AdX. Кроме того, PA API не зависит от того, кто инициирует аукцион как в случае с одним продавцом, так и в случае с несколькими продавцами. |
| Продавец высшего уровня | Продавец верхнего уровня (TLS) имеет доступ к информации, к которой нет доступа ни у одного из других продавцов компонентов, что вызывает обеспокоенность по поводу неравного доступа к информации. Хотя TLS может быть любой сущностью, для доступа к спросу AdX издатели должны использовать GAM в качестве сервера объявлений издателя. Это создает стимул для использования GAM в качестве сервера объявлений издателя, создавая конкурентное преимущество для Google. | Ответ Chrome: Конструкция PA API не определяет, какой объект может выступать в роли TLS. Роль TLS требует координации аукциона и доступа к соответствующей информации об аукционе в соответствии со структурой API. Ответ Google Ad Manager: В течение многих лет мы уделяем пристальное внимание честности аукционов, включая наше обещание, что никакая цена из любого из негарантированных рекламных источников издателя, включая цены негарантированных позиций, не будет передана другому покупателю до того, как он сделает ставку на аукционе, что мы затем подтвердили в наших обязательствах перед Управлением по конкуренции Франции . Что касается аукционов PA API, мы намерены сдержать свое обещание и не делиться ставкой любого участника аукциона с любым другим участником аукциона до завершения аукциона с участием нескольких продавцов. Чтобы внести ясность: мы не будем делиться ценой контекстного аукциона с каким-либо компонентным аукционом, включая наш собственный, как объясняется в этом обновлении . Более того, мы не используем информацию о конфигурациях аукционов компонентов, включая сигналы, предоставляемые покупателями SSP, в рамках нашего собственного аукциона. Более того, как указано выше, GAM не требует, чтобы издатели использовали функции своего рекламного сервера для доступа к спросу AdX. Наконец, как отмечалось ранее в отчете Google за второй и третий квартал 2024 года , покупательские платформы Google — Google Ads (ранее AdWords) и DV360 — покупают показы на биржах, не принадлежащих Google, в том числе через PA API. |
| PA API и GAM/AdX | Издателям сложно понять, как активировать PA API на 100 % ресурсов, поскольку в маркировке этой опции не ясна цель. Для SSP, чьим основным способом доступа к инвентарю часто является многоуровневый аукцион, в котором GAM выступает в роли TLS, фактически не существует возможности проводить тесты или монетизировать через PA API, не подпадая под действие GAM. | Ответ Chrome: Стандарт PA API определяет технические роли (например, TLS и продавец компонентов) и процесс аукциона, обеспечивая гибкость в выборе платформ, выполняющих эти роли. Операционная деятельность, такая как настройка, координация и заключение соглашений, управляется сторонами-исполнителями (издателями, SSP, поставщиками TLS) для облегчения участия с использованием инфраструктуры PA API. Ответ Google Ad Manager: Как описано в нашем Справочном центре , Менеджер рекламы предлагает издателям возможность проводить тестирование с участием продавцов компонентов, не принадлежащих Google, например других SSP, на 100 % ресурсов издателя, где API доступен для использования (отменяя любую выборку или регулирование, которые может применять GAM). Если издатель включает этот элемент управления, то всякий раз, когда продавец компонентов, не являющийся Google, предоставляет конфигурацию аукциона, GAM попытается провести аукцион верхнего уровня, включив в него аукцион предоставленных компонентов, при условии, что издатель получил на это необходимое согласие пользователя. GAM ясно дает понять издателям, что этот контроль может повлиять на производительность, чтобы издатель мог принять обоснованное решение. |
| На стороне сервера и на устройстве | Серверные решения, такие как Bidding and Auction (B&A), потенциально могут помочь в формировании трафика, сохраняя при этом конфиденциальность. Серверные решения — единственный возможный путь вперед, и Google следует отказаться от решений, встроенных в устройства. | Privacy Sandbox нацелен на поддержку решений аукционов как на стороне сервера (сервисы B&A), так и на устройствах, предоставляя возможности для удовлетворения различных потребностей в рекламных технологиях и вариантов использования. |
| Безопасность аукциона | Атаки на ставки PA API по сути лишают права участвовать в торгах и аукционах на устройстве. Заинтересованные стороны не считают эту проблему решенной, и они продолжают запрашивать технические гарантии, гарантирующие, что ставки PA API не будут подделаны, а также режим исчерпывающей отладки для обеспечения обнаружения инцидентов в реальном времени и эффективной отладки. | Обеспечение целостности аукциона PA API, включая предотвращение потенциальных атак, является ключевым моментом Privacy Sandbox. Дизайн API включает в себя меры обеспечения целостности, и мы приветствуем дальнейшее техническое обсуждение конкретных проблем. Мы представили и обсудили подробный список потенциальных атак на PA API и наши меры по их устранению во время встречи группы сообщества W3C по борьбе с мошенничеством в мае 2024 года . Мы приветствуем дальнейшее обсуждение и отзывы о том, какие потенциальные «атаки на ставки PA API» вызывают беспокойство. |
| Трафик без файлов cookie | Будет ли возможность включить PA API только для трафика без файлов cookie для тестирования или других целей? | Рекламные специалисты могут определить, присутствуют ли 3PC или нет. Более подробно это объясняется здесь . |
| Идентификатор места | Что касается предложения по идентификатору места , знание идентификатора места необходимо для большинства запросов ставок, что вызывает опасения по поводу привязки идентификатора места к регистрации креатива. Кроме того, будет ли это применяться только к «основному объявлению» или также к составным объявлениям? | Предложение BuyerAndSellerReportingId решает проблему отсутствия идентификатора места покупателя во время регистрации креатива для основного объявления. Этот идентификатор предназначен для передачи идентификатора места покупателя продавцу. Мы оцениваем поддержку компонентной рекламы. |
| Мониторинг и отчетность | Запрос на функцию мониторинга в реальном времени (RTM) для (1) отправки отчетов RTM об отмененных аукционах, а также (2) новых сегментов, заполняемых браузером, чтобы прояснить, какой тип отмены произошел. | RTM не является подходящим решением для исследования уровня участия. RTM разработан как API-интерфейс мониторинга с малой задержкой для обнаружения критических, внезапных и временных сбоев. Напротив, уровень участия не требует отчетов с низкой задержкой и не является критическим внезапным временным отключением. На опасения по поводу уровня участия наиболее эффективно отвечают продавцы, с которыми сотрудничают покупатели, а не покупатели, проводящие расследование через браузер. Более того, поскольку отмененные аукционы чрезвычайно распространены, если бы браузер создавал отчеты RTM по каждому отмененному аукциону, он мог бы заглушить отчеты RTM о фактических сбоях. |
| Документация Разъяснение | Отчет о несоответствии документации в пояснении API PA, в котором говорится, что nonce должен быть строкой UUID, но на самом деле он возвращает обещание. | Здесь предлагается разъяснение. |
| Замороженный Контекст | Какие варианты доступны при работе с замороженным контекстом для решения проблем и проблем, связанных с (1) объединением, (2) внешними библиотеками и (3) неподдерживаемыми типами данных? | Мы предоставили ответ на этот вопрос здесь . |
| Характеристики | В API частной агрегации добавлена универсальная операция submitToHistogramOnEvent . Как следствие, определение в PA API стало перегруженной операцией, а операции Web IDL «не должны перегружаться через интерфейс, частичный интерфейс [...]» , так что определение теперь недействительно. | Эта проблема указывает на временное несоответствие между спецификациями PA API и Private Aggregation, хотя мы объединяем аналогичные изменения в обоих. Чтобы решить эту проблему, мы объединили запрос на включение . |
| Группы интересов | Запрос рекомендаций относительно рекомендуемого и ресурсоэффективного метода прекращения участия группы интересов (IG) в торгах при остановке кампании. | Вот несколько предложений, которые мы можем предоставить: Мы считаем, что механизм с наименьшей задержкой, наименее постоянным, но и с наименьшим высвобождением ресурсов использует сигналы ставок в реальном времени, чтобы сообщить generateBid() о прекращении торгов.Второй вариант, который использует меньше ресурсов, — это установка отрицательного приоритета для этого IG в ответе на сигналы назначения ставок в реальном времени, поскольку это предотвратит даже вызов generateBid() .Третий вариант, требующий еще меньше ресурсов, — удаление рекламы из ИГ. У IG без рекламы не вызывается generateBid() .Четвертый вариант, который использует еще меньше ресурсов, — это удаление biddingLogicURL из IG. На этом этапе IG все еще можно обновить/воссоединиться, чтобы повторно активировать его.Дальнейшие варианты связаны с выходом из IG либо через leaveAdInterestGroup() , либо через clearOriginJoinedAdInterestGroups() , либо через истечение срока действия IG.Как отмечалось выше, разные варианты имеют разные последствия для задержки и потребления ресурсов. Рекламные специалисты могут выбрать вариант, который лучше всего подходит для их конкретных случаев использования. |
| Аудитории | Запрос на механизм выполнения логических операций над созданной аудиторией (например, возможность нацеливаться на пересечение IG A и B) | Благодаря PA API сегодня стало возможным выполнение логических операций с аудиторией одного и того же сайта. Логические операции с аудиториями на разных сайтах сегодня не поддерживаются из соображений конфиденциальности, как описано в нашей модели конфиденциальности . Мы продолжаем проводить исследования в этой области и будем делиться любыми обновлениями по ходу дела. |
| Запрос функции | Предложение снять ограничение на дополнительные заявки, требующие предварительного знания TLS. | В настоящее время мы обсуждаем это предложение здесь и будем рады дополнительным отзывам. |
| Обновленный подход к 3ПК в Chrome | Будут ли API-интерфейсы Privacy Sandbox, такие как PA API, оставаться общедоступными для всех пользователей Chrome Stable или API-интерфейсы (или подмножество API-интерфейсов) будут доступны только пользователям, которые отказались от 3PC? | Мы не намерены, чтобы решение пользователя отказаться от 3PC повлияло на доступность API-интерфейсов Privacy Sandbox в стабильной версии Chrome. |
| Расширенная сигнализация | Планируется ли добавить функциональность, указывающую, собирается ли TLS проводить аукцион API PA? | Мы оцениваем поддержку этой функции. Мы поделимся более подробной информацией о сроках, когда она станет доступна, и будем рады дополнительным отзывам по этому запросу. |
| Идентификатор сделки | Опасение, что требование к серверу KV в предложении по идентификатору сделки может оказаться дорогостоящим и трудоемким процессом на стороне сервера. | Предложение по идентификатору сделки позволяет SSP запрашивать метаданные выбранных идентификаторов сделок с сервера «ключ-значение» во время аукционов PA, поэтому им не нужно предварительно загружать все метаданные, связанные со сделкой, на устройство. Это предложение разрабатывается в ответ на запросы SSP, и мы приветствуем дополнительные отзывы экосистемы здесь . Мы понимаем, что для настройки сервера «ключ-значение» требуется работа, но в целом по-прежнему считаем, что это чистая выгода для компаний, занимающихся рекламными технологиями. Мы по-прежнему будем рады отзывам и предложениям по упрощению этого процесса. |
| Ограничение частоты перекрестного IG | Запрос на ограничение частоты показов между IG через API PA. | Ограничение частоты показов Cross-IG имеет сложные характеристики конфиденциальности, для которых мы не смогли найти решения. Мы приветствуем дополнительные отзывы от экосистемы, если эта функция имеет высокий приоритет. |
| Отчеты по идентификаторам сделок и идентификаторам мест | Запрос возможности включать идентификаторы сделок или мест в сводные отчеты. | Функциональные возможности идентификаторов отчетов, над которыми мы здесь работаем, сделают возможным создание отчетов по идентификаторам сделок и мест. selectedBuyerAndSellerReportingId передается в reportResult(), поэтому самый простой способ сообщить об этом — через отчеты на уровне событий (т. е. кодирование идентификатора сделки в URL-адрес, передаваемый в sendReportTo()). Если будет использоваться агрегированная отчетность, это также можно сделать. Функция идентификатора отчетности в настоящее время доступна для 10 % трафика канала Chrome Stable. Мы оцениваем расширение запуска до 100%. |
| Группы интересов | Используйте один и тот же порядок приоритета как при выборе, так и при оценке IG, а также используйте этот порядок приоритета во всех режимах оценки. | В настоящее время мы обсуждаем это здесь и будем рады дополнительным отзывам. |
| Группы интересов | Предложение использовать активацию и делегирование аудитории как способ увеличения внедрения API Privacy Sandbox. | Мы знаем об этом запросе от нескольких заинтересованных сторон и ищем решение. Мы приветствуем дополнительные отзывы от экосистемы. |
| Группы интересов | Проблемы, связанные с созданием групп PA API IG, особенно с делегированием и владением при совершении нескольких покупок или от имени издателей. | Мы получили запрос на поддержку более продвинутых делегаций IG от нескольких заинтересованных сторон и видим дополнительную ценность SSP, способствующих этому процессу. Мы проводим исследования, чтобы найти лучшее решение, которое позволит различным сторонам участвовать в процессе расширения аудитории. Мы приветствуем дополнительные отзывы от экосистемы. |
| Производительность на стороне клиента | Запросите рекомендации по упрощению кэширования доверенных сигналов на стороне клиента для оптимизации инфраструктурных затрат и задержек. | В настоящее время мы обсуждаем это здесь и будем рады дополнительным отзывам. |
Защищенный аукцион (услуги B&A)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| К/В услуги | Как группируются запросы от браузера к КВ-серверу продавца? Как для продавца будет выглядеть запрос из браузера — запрос GET или POST? Кроме того, необходимы некоторые разъяснения относительно требований к анонимности. | В версии 1 Chrome отправляет запрос GET в службу KV продавца для получения trustedScoringSignalsURL с сигналами в параметрах запроса запроса. Параметры будут включать hostname , renderUrls , adComponentRenderUrls и experimentGroupId . В настоящее время мы экспериментируем с некоторыми расширениями для отправки дополнительной информации для творческого сканирования, но они еще не запущены.Если для maxTrustedScoringSignalsURLLength установлено значение 0, Chrome потенциально может объединить все сигналы в один запрос (возможно, превысив любой предел длины URL-адреса на своем сервере), но это не гарантировано. В настоящее время Chrome предпочитает включать запросы в один пакет, если они готовы к отправке с разницей в 10 мс, хотя в настоящее время мы изучаем, как это оптимизировать.При работе с TrustScoringSignals полезно помнить, что Chrome учитывает кэширование заголовков. Заголовки, подобные заголовку Stale-While-Revalidate «Cache-Control», могут уменьшить среднюю задержку, позволяя Chrome использовать кэшированную копию (и обновлять кеш для следующего аукциона), эффективно удаляя выборку сигналов с критического пути.Наконец, что касается k-анонимности, конкретный раздел пояснения кажется устаревшим. Первоначально мы собирались потребовать, чтобы URL-адреса доверенных сигналов были k-анонимными, но это требование было отменено. Мы удалим это предложение из объяснителя. |
| Услуги Б&А | Обновление до последней версии B&A занимает много времени. Было бы полезно ускорить сборку или использовать готовые образы. | Рекламные специалисты могут создавать двоичные файлы самостоятельно и проверять их, используя предоставленные хеши. Мы рассмотрим возможность предоставления готовых артефактов или сокращения времени сборки в будущем. |
| Запрос функции API | Запрос на совместимость с macOS для скриптов сборки Bidding & Auction Services (B&A), образов контейнеров и инструментов вызова для облегчения локальной разработки и тестирования. | В настоящее время мы поддерживаем amd64 , которого достаточно для развертывания на поддерживаемых облачных платформах (GCP и AWS). В будущем мы можем изучить возможность поддержки других архитектур. |
| АВС | Создает ли наличие ролей IAM требование для производственных сборок? | Да, роли IAM необходимы для получения надлежащих разрешений и связи с координаторами. Ключи используются для расшифровки зашифрованного текста ProtectedAudienceInput, который генерируется на устройстве, как указано здесь . Кроме того, эти роли необходимы для прохождения аттестации сервера/TEE производственных сборок с теми же координаторами. Подробнее об этом говорится в нашем руководстве по самообслуживанию . |
| Флаги B&A | Запрос определений доступных флагов B&A для включения в документацию, учитывая, что сегодня эти определения находятся в коде Terraform, файлах cc и файлах прототипов, но специалисты по рекламе выиграют от документации по этим флагам, используя ее как источник истины для понимания того, как настраивать развертывание. | Мы изучаем возможность документирования описаний флагов Terraform и приветствуем дополнительные отзывы здесь . |
| АВС Служба торгов | Ищу рекомендации относительно сервиса назначения ставок на AWS, а также поведения и конфигурации ведения журналов по умолчанию. | Для отладки служб назначения ставок в TEE (например, службы назначения ставок) мы рекомендуем использовать отладку с согласия Ad Tech . Это позволяет вам включить подробное ведение журнала и собирать данные запросов/ответов для ваших конкретных тестовых запросов непосредственно от вашего клиента, чтобы помочь в отладке. |
| ТРОЙНИК К/В Документация | Запрашиваю разъяснения относительно начала применения TKV, как указано на сайте разработчиков . | Мы предоставим заблаговременное уведомление о необходимости использования TEE. До тех пор вы можете продолжать использовать свой собственный сервер для сигналов «ключ-значение» в режиме реального времени. |
| Тестирование и анализ B&A | Анализ и тестирование B&A остаются дорогостоящими и, похоже, не готовы к производству. | Для дальнейшего изучения нам потребуется дополнительная информация об анализе затрат и факторах, влияющих на оценку готовности производства. |
| Оптимизация доверенного сервера | Предложение объединить параметры, специфичные для продавцов компонентов, в один параметр inputsPerSeller , используя в качестве значения строку JSON. | Мы обсуждаем это предложение и приветствуем дополнительные отзывы здесь . |
| Безопасность | Как риски безопасности, связанные с TKV, снижаются с помощью B&A? | Запретить внешние вызовы на TKV возможно. Сегодня это полностью поддерживается и настраивается в GCP. Для AWS необходимо разработать дополнительную поддержку из-за прекращения поддержки AWS App Mesh, которая ранее позволяла это делать. Мы приветствуем дополнительные отзывы здесь . |
| Услуги Б&А | Прошу внести ясность в повествование/сообщения о значении потоковой передачи HTTP для оптимизации B&A. | Privacy Sandbox поддерживает возможности потоковой передачи данных B&A, чтобы уменьшить задержку для рекламных специалистов, которые решат ее использовать. Это необязательная оптимизация производительности в случае смешанного режима. |
| Предварительная ставка | Запрос обновлений о вкладе в библиотеку Prebid с открытым исходным кодом для включения функций PA API B&A для экосистемы. | В марте 2025 года Chrome запустил в стабильной версии оптимизацию Prebid, как это описано в общедоступной дорожной карте B&A ( см. март 2025 г.). |
| Формирование трафика | Запрос на механизмы регистрации контекстных сигналов, полученных B&A, чтобы лучше понимать, когда активируются IG, и улучшать их логику «намерения сделать ставку» в контекстном ответе. Это позволяет лучше использовать сетевые ресурсы и избегать «бесполезного трафика» (так называемого формирования трафика). | В настоящее время мы обсуждаем предложение здесь и будем рады дополнительным отзывам. |
| Документация Разъяснение | Необходимо разъяснение относительно ошибки «Прокси-сервер Service/Vsock недоступен», обнаруженной при настройке интеграции теста B&A. | Это связано с минимальными требованиями к памяти . Объяснение конфигурации AWS было обновлено с учетом этого требования. |
Измерение цифровой рекламы
Отчеты по атрибуции (и другие API)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Данные в реальном времени | Отсутствие данных в реальном времени влияет на всех в отрасли. Задержка данных в режиме реального времени является серьезной проблемой для рекламодателей. Покупатели переходят на платформы с Google Analytics, поскольку это единственное место, где они могут получить подтверждение охвата аудитории. | Задержки данных в реальном времени, являющиеся частью API отчетов об атрибуции (ARA), реализованы как механизмы защиты конфиденциальности, позволяющие специалистам по рекламе использовать отчеты на уровне событий для отслеживания пользователей на разных сайтах. Тем не менее, ARA обеспечивает гибкость в предоставлении отчетов по атрибуции, позволяя отчетам на уровне событий иметь минимальный период отчета в 1 час и предоставляя возможность мгновенной отправки сводных отчетов специалистам по рекламе без задержек. |
| Использование API | Запрос подтверждения правильности конфигурации потока атрибуции между веб-приложениями, особенно при параллельной атрибуции между веб-сайтами и веб-приложениями. | При параллельном проведении кампаний «Интернет-сайт» и «Интернет-приложение» специалист по рекламе должен выбрать только одну платформу для регистрации каждого источника или триггера, чтобы избежать двойного учета. Мы настоятельно рекомендуем использовать операционную систему (ОС), где это возможно, поскольку ОС способна выполнять атрибуцию как между веб-сайтами, так и между веб-приложениями, при условии, что веб-источники и триггеры были правильно делегированы. Это будет означать ответ заголовком Attribution-Reporting-Register-OS-Source для источников и заголовком Attribution-Reporting-Register-OS-Trigger для триггеров. Заголовок Attribution-Reporting-Support можно использовать для определения наличия поддержки на уровне Chrome и/или Android. Заголовок Attribution-Reporting-Info полезен, когда в запросе отсутствует заголовок Attribution-Reporting-Support, и в этом случае браузер примет решение о регистрации платформы на основе наличия поддержки платформы на устройстве пользователя. |
| Спецификация API | Требуется разъяснение о заголовке HTTP-запроса Attribution-Reporting-Support, установленном API отчетов об атрибуции, и о том, предназначен ли он для того, чтобы заголовок содержал как веб-ключи, так и ключи операционной системы, независимо от платформы. | Заголовок Attribution-Reporting-Support зависит от добавления браузером параметров «GREASE», чтобы гарантировать, что серверы используют анализатор структурированного заголовка, соответствующий спецификации. Для этого заголовка следует интерпретировать только ключи структурированного словаря. Значения и параметры в настоящее время не используются. См. здесь пример. |
| Отчетность на базе 3-х ПК | Запрашиваю рекомендации по устранению расхождений в измерениях между ARA и 3PC в рекламных кампаниях. | ARA поддерживает два типа отчетов отладки, которые можно использовать для устранения неполадок и отладочных расхождений. Отчеты отладки Attribution-Success могут быть использованы для легкого сравнения результатов ARA с результатами других технологий измерения, а отчеты отладки могут использоваться для получения дополнительной информации и устранения потенциальных проблем в регистрациях атрибуции. |
| Использование API | При тестировании ARA были обнаружены определенные проблемы: недостаточная гранулированная отчетность, приводящая к шумным данным и негибкой оптимизации кампании, высокие пороговые значения, исключающие меньших рекламодателей и трудности сравнения кампаний из -за противоречивых ключевых показателей эффективности. | ARA обеспечивает гибкость, предоставляя несколько параметров, которые AD Techs могут настроить для достижения конкретных вариантов использования измерений. Отчеты на уровне событий поддерживают гибкую отчетность на уровне событий, которая позволяет AD-технологиям настраивать свои отчетные окна, количество отчетов, которые они могут получить, и данные о триггерах, которые они хотят измерить, что может изменить влияние шума на их данные и позволить им достигать различных вариантов использования. Аналогичным образом, совокупные отчеты имеют различные способы, которыми AD -технологии могут настроить свои конфигурации, такие как количество измерений, которые они отслеживают, их частота партии и использование бюджета взносов для изменения воздействия шума и также достичь различных вариантов использования. |
| API Spec | Вопрос о зависимости ARA на 3PCS, в частности, относительно того, остается ли она на этапе тестирования, требующей этих 3pcs. | ARA включена независимо от 3PCS, но 3PC необходимо разрешить, чтобы позволить отчетности ARA переходной отладки для сравнения результатов ARA с результатами атрибуции на основе cookie. |
| Использование API | Запрос о регистрации источников для атрибуции приложения к пакете на старых версиях Android (11, 12 и 13) с использованием ARA. | ARA в настоящее время поддерживается на Android S и выше (12+). |
| Использование API | Запрос на ставки и детали распределения ARA. | Наш ответ неизменен от предыдущих кварталов: «Мы не планируем обмениваться этой информацией с экосистемой. Разработчики могут позвонить в API, где у них есть код, развернутый сегодня для оценки доступности APIS Sandbox Conficate» » |
| Доступность API | Когда ARA включена, включено ли 3PC или отключено? | Когда ARA включена в браузер пользователей, он не оказывает никакого влияния на настройки файлов cookie пользователей. Возможно, чтобы ARA была включена, и для пользователя будет включен или отключен файлы cookie. |
| Отчетность | Существует ли предопределенный список значений, которые мы можем получить в заголовке «Поддержка отчета»? | Как изложено в нашем руководстве , это значение представляет собой структурированный словарь заголовка, единственной в настоящее время определяемой в настоящее время семантика является наличие или отсутствие ОС и веб -ключей. Все остальные части заголовка следует игнорировать. Другими словами, для анализа требуется использование структурированного анализатора заголовка, а не простого сопоставления строк. |
Служба агрегации
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Запрос функции | Запросы на функции на службу агрегации: Интеграции сервера к серверу , измерение меру, облегчение отчетности и отчетности о атрибуции и вкладах , облегчение атрибуции и взносов, а также поддержки передовых петлей оптимизации ML (например, обучение частной модели). | Мы оцениваем эти запросы и поделимся более подробной информацией, когда они доступны. Мы приветствуем дополнительные отзывы от экосистемы о том, являются ли эти запросы приоритетом. |
| Запрос функции | Запрос на установление параметра EBS DELETE_ON_MERMINATE в TRUE в среде Terraform, чтобы смягчить опасения по поводу сброса при обновлении сервиса агрегации. | Мы оцениваем этот запрос и поделимся более подробной информацией, когда они доступны. Мы приветствуем дополнительные отзывы от экосистемы о том, является ли этот запрос приоритетом здесь . |
| Документация Разъяснение | Запрашивая руководство о том, что можно изменить (например, пороги мониторинга) и что должно оставаться нетронутым. | Мы оцениваем публикацию дополнительной документации и руководства по доступным настройкам службы агрегации. |
| Развертывание | Запрос о разъяснении относительно нового развертывания, проваленного в Bazel Command. | Развертывание может произойти из -за версии Bazel, используемой в окружающей среде. Документация будет скорректирована для охвата отладки на сбоях терраформ, а также для указания требуемой версии Bazel. |
Частная агрегация API
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Использование API | Запрос на руководство по некоторым проблемам реализации, таких как потенциальная потеря данных из -за сообщенных общих ограничений хранения, трудностей с высокой кардинальностью, требующими сложных служб агрегации, разрешенных списками (подстановочный знак), и замедленное тестирование, вызванное правилом службы агрегации «без дубликатов». | Что касается общих ограничений хранения, то ограничение 20 взносов (подробно здесь ) за выполнение, а не в месяц. Кроме того, вызывающие API могут переопределить этот предел. Лимит существует для того, чтобы помочь управлять стоимостью отчетов о обработке в службе агрегации, а не ограничить утилиту отчетности. Что касается запросов подстановочных знаков, мы оцениваем этот запрос и будем делиться более подробной информацией, когда они доступны. Что касается правила «без дубликатов», чтобы включить тестирование, мы временно поддерживаем режим отладки с целью обхода этого правила. Это изложено здесь более подробно. |
| Фильтрация идентификатора и ведра | Можно ли запросить службу агрегации в одном и том же ведре с двумя различными идентификаторами фильтрации в двух отдельных прогонах агрегации, т. Е. Может ли идентификатор фильтрации действовать как дополнительное разделение доменов? | Да, эта функция поддерживается. При выполнении агрегации будут обработаны только вклады с идентификатором фильтрации, соответствующим списку в параметрах задания, а остальные останутся доступными для обработки в отдельном прогоне (-ах). |
| Атрибуция мульти-тауч | Запросы на разъяснения относительно реализации атрибуции Multi-Touch (MTA): 1) Есть ли предел количества взносов, если значение агрегации не превышает 2^16? 2) Существует ли предел количества уникальных клавиш агрегации (ведра), которые можно хранить для данного контекста? 3) Как отчеты о процессах службы агрегации отчеты, когда каждый пользовательский агент (браузер) имеет уникальный ключ агрегации, как это, вероятно, в MTA? | 1) Мы установили ограничения по умолчанию, но есть варианты для абонента API, чтобы переопределить их, как объяснено здесь . Цель ограничений состоит в том, чтобы помочь абонентам API управлять стоимостью отчетов о обработке в службе агрегации. 2) Такого ограничения нет, хотя AD-технологии должны учитывать гранулярность ключей агрегации для улучшения отношения сигнал / шум, как объяснено здесь . 3) Пожалуйста, смотрите это руководство , особенно руководство по сигналу / шум, рассмотренное выше по пункту 2). |
Ограничьте скрытое отслеживание
Пользовательский клиент-подсказки об сокращении/агенте пользователя
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Запрос функции | Запрос на добавление SEC-CH-UA-ROBOT в клиентские подсказки (UA-CH), поскольку это позволит серверам идентифицировать автоматический трафик для адаптации, безопасности и аналитики. | Это важный вариант использования, который обсуждается в других группах стандартов (см. Здесь для получения дополнительной информации см. Здесь), и мы рекомендуем заинтересованным сторонам участвовать, предоставляя их обратную связь. Тем не менее, мы считаем, что UA-CH может быть не подходящим решением, учитывая, что заголовки HTTP-запроса могут легко манипулировать автоматическим трафиком. |
Защита от IP (ранее Gnatcatcher)
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| IP -адрес конфиденциальность | Оставляя IP -адреса, доступными для Google, чтобы использовать противоречивые цели. Несмотря на то, что Google говорит, что он анонимизирует данные с помощью защиты от IP, пользователи должны войти в Chrome, чтобы использовать защиту от IP, поэтому Google все еще изучает свои личности. | Причины входа в систему связаны с целями против мошенничества и злоупотреблений, в первую очередь, ограничивающие скорость доступа к прокси. Кроме того, чтобы защитить конфиденциальность пользователей в контексте требования к аутентификации, наш дизайн токена ослепительна, что означает, что токен, выданный во время входа в систему, отличается от токена, который используется во время оформления, выпущенные токены не могут быть связаны с идентификацией Google пользователя в дальнейшем. Это означает, что Google не знает, кем является пользователь, когда трафик этого пользователя прокси-прокси в режиме инкогнито, несмотря на требование аутентификации по борьбе с мошенничеством. |
| IP -адрес конфиденциальность | Использование IPS - это шаг в неправильном направлении. Их нельзя удалить из браузера, например, файлы cookie, и пользователи не имеют такого же контроля прозрачности, как и с помощью файлов cookie. Если файлы cookie уйдут, отрасль перейдет к использованию IPS в качестве альтернативного решения, определяя приоритет самосохранения над конфиденциальностью. | Как платформа, Chrome стремится предоставить пользователям функции, которые улучшают их опыт просмотра в Интернете. Для пользователей Chrome, которые предпочитают просматривать Incognito, это означает обеспечение повышенной защиты от отслеживания перекрестного сайта, ограничивая доступность информации IP-адреса в сторонних контекстах. |
| Список доменов в масках | Каковы критерии отбора в списке доменов в масках (MDL)? | Chrome разработал критерии, чтобы определить , какие домены должны находиться на MDL, и, следовательно, получать маскированные IP-адреса в контексте сторонних. Google в партнерстве с Dinconnect.me , известным лидером конфиденциальности в Интернете, который также сотрудничает с другими веб -браузерами. Chrome будет использовать Deanconct.me для определения доменов, которые соответствуют установленным критериям Chrome. Кроме того, Chrome разработал методологию для идентификации широко используемых функций JavaScript, которые обеспечивают постоянные выходы из стабильных и высокопроизводительных веб-API и, следовательно, могут использоваться для построения высоких вероятностных идентификаторов энтропии. Эти функции затем обнаруживаются, когда они загружаются на веб-сайты в стороннем контексте, что приводит к списку доменов, которые служат сценариям с этими характеристиками, которые становятся частью MDL и, следовательно, являются прокси. Трубопровод обнаружения, который ищет эти модели злоупотребления API, рассматривает все домены, включая собственные домены Google. |
| Предотвращение мошенничества | Обратная связь о вероятностных токенах (PRT), которые предложенные 24-часовые, выявляют задержку и выявляют показатели, препятствуют обнаружению мошенничества в реальном времени. Запрос на более короткие задержки (1-часовая задержка) и более высокие показатели (по крайней мере, двузначные). Дальнейшие предложения включают в себя включение дифференциальных показателей на основе сигналов риска (VPN, автоматизированных браузеров) и разрешение на целевые выявления специфических токенов. | Большинство разработчиков, которых мы разговаривали, чтобы предоставить почасовую отчетность своим клиентам, и несколько обновлений IP -списков в течение дня. Более короткий период задержки обеспечивает более частые обновления, и менее часа будет повторно определять измерение IVT в почасовой статистике, но также потенциально увеличивает вероятность повторной определения пользователей. Мы открыты для изучения сокращения периодов задержки и изменения показателя раскрытия на основе исследований экосистем, а также отзывы от заинтересованных сторон и приветствуем здесь дополнительную обратную связь. |
| Список доменов в масках | Вопрос относительно включения домена в MDL, несмотря на то, что у него нет варианта использования рекламы. Обеспокоенный тем, что это может позволить «IP-Bridging» для создания профилей на основе IP-адресов. | Мы признаем важность внедрения апелляционного процесса для нашего подхода, основанного на списке. Апелляционные компании разрешают компаниям заявить, что их домен на MDL не соответствует критериям включения и должен быть удален, что позволяет этому домену продолжать получать исходные IP-адреса пользователей в контексте сторонних в режиме Incognito. В настоящее время мы запустили апелляционный процесс, чтобы предоставить владельцам доменов достаточно времени, чтобы обратиться за апелляцией и получить решение до запуска защиты от IP в режиме инкогнито в хромированной стабильной. Более подробная информация о процессе апелляции доступна здесь . |
| Список доменов в масках | Обратная связь о том, что издатели исследуют последствия того, что их партнеры включают в MDL. Они были уверены в положениях о геоипках в рамках Объяснителя по защите ИС. | Chrome признает важность поддержки вариантов использования на основе гео. Прокси назначит IP -адреса, которые представляют грубое местоположение пользователя, включая страну. Дополнительная информация доступна в объяснении IP Geolocation . |
| Список доменов в масках | Вопрос относительно MDL, является ли таргетирование на уровне страны все еще доступно. | Chrome признает важность поддержки вариантов использования на основе гео. Прокси назначит IP -адреса, которые представляют грубое местоположение пользователя, включая страну. Дополнительная информация доступна в объяснении IP Geolocation . |
| Обнаружение мошенничества | Беспокойство по поводу воздействия защиты от ИС на системы обнаружения мошенничества. Будут ли пользователи прокси -IPS или заголовок? Будут ли SSP и DSP увидеть тот же прокси -IP -адрес для данного использования? Несоответствия могут повлиять на обнаружение мошенничества и OpenRTB. | Пользователи, просматривая режим Incognito с включенной IP -защитой, которые делают запросы в домены в MDL, получат прокси -адрес на основе определенного геофинации. Организации могут просить ПРТ в качестве дополнительного заголовка на прокси -трафике, где небольшая выборка оригинальных IPS может быть обнаружена после периода задержки. Мы подозреваем, что многие SSP будут передавать свой проксированный IP-адрес в запросах на сторону сервера своим партнерам по требованию, но выигрышные DSP не гарантируют тот же самый IP-адрес прокси во время впечатления. |
| Обнаружение мошенничества | Вопросы о частоте обновления файла IP Geolocation, времени обновления для получения подробной информации о сообщении о мошенническом поведении и PRT, а также о том, как AD Tech должна обнаружить мошеннические действия. | Объяснитель PRTS является живым , как и список прокси -адресов IP -адресов и их картовых регионов GEO. Мы рекомендуем периодически проверять этот файл на наличие обновлений и изменений, так как IP -адреса будут вращаться с течением времени. Общественный адрес электронной почты для сообщения о злоупотреблениях будет объявлен ближе к запуску. |
| Геолокация | Запрос об публичном списке IP -адресов, используемых для прокси. | IP -адреса отображения файлов в грубые местоположения для защиты от IP доступны здесь . Обратите внимание, что этот файл периодически обновляется. |
| Использование API | Утверждение, что защита IP, по -видимому, включена по умолчанию, и пользователям не предоставляется возможность отказаться. | IP -защита будет доступна для пользователей в режиме Chrome Incognito, на Android и настольных платформах. Пользователи будут иметь возможность отключить защиту от IP. Для управляемых предприятием версий Chrome можно включить защиту от IP, но она будет выключена по умолчанию. |
| Использование API | Запрос относительно доступности экспериментального флага для включения и проверки защиты от IP в Chrome Canary и бета -выпусках. | В настоящее время у нас нет экспериментального флага, доступного для проверки полной функции защиты от IP. Функциональные эксперименты, которые мы проводим только прокси -трафик, идущие в домены Google. |
| IP -адрес конфиденциальность | Как работают настройки приглашения 3PC, когда браузер перемещается в режим инкогнито? | 3pcs блокируются по умолчанию в режиме инкогнито. |
| Режим инкогнито | Поиск разъяснения о том, функции ли IP защиты в режиме инкогнито, когда пользователь не подписан в Chrome. | Защита от IP не активна, если пользователь не вошел в Chrome в преддверии запуска режима Incognito. Причины этого связаны с целями против мошенничества и злоупотреблений, а именно, ограничивающего скорость доступа к прокси. IP Protection будет использовать аутентификацию клиента, чтобы ограничить способность плохих субъектов использовать прокси для усиления атак на услуги на MDL. Таким образом, защита от IP будет доступна только для пользователей, которые были аутентифицированы с использованием учетной записи Google, с которой они подписаны в браузере Chrome перед открытием нового окна Incognito. |
| Режим инкогнито | Запросы на оценку влияния защиты от ИС в преддверии запуска, включая: (1) предложение использовать флаг состояния браузера или отчетность API -отчетности для количественной оценки использования режима инкогнито; (2) отправка заголовка защиты от IP на период, прежде чем включить эту функцию; и (3) Доставка функции в небольшой, известный процент трафика для экстраполяции. | Мы понимаем интерес экосистемы к возможности понимать и измерить масштаб и влияние защиты от ИС. Тем не менее, Chrome работает над тем, чтобы сделать выбор пользователя для просмотра в режиме Incognito Private. Chrome не обнаруживает метод обнаружения пользователей, просмотрев инкогнито, и предпринимал шаги , чтобы ограничить другие сигналы, которые могут показать режим просмотра пользователя. Мы рассматриваем способы облегчения этого тестирования, не влияя на конфиденциальность пользователей, просматривающих в режиме инкогнито и приветствуем дополнительную обратную связь от экосистемы. |
Отслеживание отслеживания смягчений
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Согласие | Нежелание Google авторизовать метод использования метода смягчения отслеживания отслеживания (BTM), которая соответствует законодательству о защите данных, не имеет правовой основы и делает процесс апелляции на песочницу конфиденциальности бессмысленным. | Как мы объяснили в нашем предыдущем отчете об обратной связи, статус соответствия не имеет отношения к применению BTM, а Google не принимает никаких решений, касающихся соответствия в реализации BTM. Вместо этого BTM, как и другие защиты конфиденциальности Chrome, вместо этого сосредоточена на продвижении контроля пользователей над тем, используются ли их данные. Сторонний процесс управляемых апелляций, упомянутый в отчете CMA 2 Q2/Q3, специфичен для областей, где Google принимает решения об включении или исключении отдельных компаний в списках. |
| Согласие | Обсуждение о том, как браузеры обеспечивают соблюдение юридически согласованных действий в контексте сценариев выделения GDPR, в которых браузеры могут подавлять действия (например, перенаправления или настройки cookie), на которые пользователи явно дали согласие, создавая конфликт между юридическим согласия и условиями конфиденциальности браузеров. | Браузер не имеет видимости в характере отношений между пользователем и веб -сайтом. Кроме того, с текущим поведением BTM уже существуют обходные пути для пользователя, чтобы дать явное согласие на отслеживание отслеживания с данного сайта. Дополнительная информация относительно соответствия доступна в наших часто задаваемых вопросах, связанных с конфиденциальностью . |
| Сайты с двойным использованием | Обратите внимание на разъяснения о том, будут ли в BTM в BTM рассматриваться переходы от WebView или App-to-Web (Chrome)? | Браузер не имеет видимости в том, началась ли цепочка отскок через переход от WebView или App. Следовательно, BTM не дает этим потокам никакого особого лечения. Вместо этого он интерпретирует поток как перекрестный отскок, начиная с «О: Blank» и продолжается со стандартным поведением. |
Укреплять границы конфиденциальности поперечного сайта
Связанные наборы веб-сайтов (ранее первые наборы)
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Использование API | Беспокойство по поводу потенциала злоупотребления RWS в сочетании с защитой IP. Раскрытие IP -адресов организациям в рамках набора RWS может стимулировать организации присоединиться к нескольким наборам RWS для получения доступа к данным портативного IP -адреса для отслеживания пользователей Incognito. | Установленные требования к ассоциированным сайтам, сайтам обслуживания и наборам в целом, применяемые автоматическими проверками, смягчают любой потенциальный стимул для попытки присоединения к нескольким наборам. Присоединение к активности пользователей по наборам через IP -адреса потребует включения домена MDL в набор, который требует координации между владельцем SET и владельцем домена. Этот же риск применяется к отдельным сайтам (то есть без RWS), координируя с доменами MDL. Мы ответили на этот вопрос более подробно здесь . |
О огороженные рамки API
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Местная реклама | Обратная связь с тем, что огороженные рамы, как в настоящее время спроектированы, несовместима с их родной рекламной бизнес -моделью, которая требует, чтобы реклама гибко адаптировалась к окружающему контенту. | Мы продолжаем оценить потребности экосистемы и текущие огороженные рамки. В любом случае, как указывалось ранее, огороженные рамы потребуются не раньше, чем в 2026 году . |
Общий API хранилища
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| API ошибка | Сообщите, что Chrome регистрирует ошибку, когда механизм бюджетирования общего хранилища предотвращает выполнение операции Selecturl, даже если это ожидаемое поведение. Запросить, чтобы Chrome понизил уровень регистрации с ошибки до предупреждения или информации, так как ошибка не является действительной для вызывающего абонента. | Изменения были внедрены и включены в Chrome M134, доступный с 4 марта 2025 года. |
Чипсы
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| API-документация | Необходимо разъяснения в отношении защиты безопасности, предлагаемых разделенными файлами cookie по сравнению с SameSite = LAX/Strict Cookie. Предположение о том, что документация должна явно указать, что разделенные файлы cookie не обеспечивают такого же уровня защиты от атак XSS и CSRF, что и SameSite = Lax/Strict Cookie. | Мы обновим объяснение и спецификацию, чтобы прояснить семантику и защиту, предлагаемые разделенными файлами cookie. |
Fedcm
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Пользовательский интерфейс и безопасность | Обратная связь о том, что пользовательский интерфейс FEDCM слишком похож на предыдущий вход в однобудок Google, трудно количественно оценить производительность FEDCM из-за отсутствия отслеживания пассивной презентации и рекомендации для более сильного языка документации в отношении PKCE. | Мы активно взаимодействуем с заинтересованными сторонами для решения их отзывов. Области продолжающегося обсуждения включают способы обеспечения лучших показателей для ВПЛ, чтобы они могли отслеживать производительность FedCM и возможные улучшения для решения новых вариантов использования для FEDCM вокруг вариантов использования подписки. |
| Использование API | Когда пользователь обновляет страницу и вызывает навигацию. Может ли полагаться на кэш -кэширование партий (RPS) токен, возвращаемый Navigator.credentials.get для улучшения пользовательского опыта? | RPS может использовать свои собственные файлы cookie для хранения токена. Затем RPS может проверить свои собственные файлы cookie, чтобы определить, входит ли пользователь, прежде чем вызывать Navigator.credentials.get. Мы рассмотрели это более подробно здесь . |
| Много-IDP-выбор | Как браузер отобразит параметры входа в систему для нескольких поставщиков идентификаций (IDP) в FedCM? | В документации разработчика есть информация о том, как будут отображаться несколько ВПРП. Заинтересованные стороны могут экспериментировать с этой функциональностью, позволяя флагу FedCM-Multi-IDP в Chrome: // Flags. |
| Браузеры и ВПЛ | Возможно ли для браузера, таким как Chrome, действовать как сам IDP? Браузеры могут использовать свои хранимые данные и профиль данных в качестве надежного источника аутентификации. | В связи с тем, что браузеры могут быть изменены (например, через расширения), любые претензии по проверке электронной почты, сделанные непосредственно браузером, не могут доверять без дополнительной проверки на основе сервера. Таким образом, решение на основе чисто клиента не рекомендуется. Мы обсуждали этот вопрос более подробно здесь . |
| API Spec | Обсуждение о том, должен ли параметр для алгоритма идентификации идентификации. Disconnect () алгоритм или необязательным. | Это сейчас исправлено. Более подробную информацию можно найти здесь . |
| API Security | Опасения, связанные с утечкой токенов в процессе входа в FedCM, если у RP есть уязвимость XSS. Злоумышленник мог бы выполнить Navigator.credentials.get в вредоносном коде, чтобы получить токен. | FedCM не создает новые риски XSS; Эти риски присущи в веб -приложениях и существующих протоколах автоза. Чтобы смягчить эти риски, RP должны проверить заявление AUD в токенах ID и принять только утверждения, выпущенные в их собственном происхождении. Как обсуждалось здесь , существуют широко установленные лучшие практики для обеспечения обмена токенами, которые существуют сегодня и доступны для использования с FedCM. Кроме того, API доступа к хранилищам может использоваться с FEDCM, а вызовы API доступа к хранилищам автоматически предоставляются при предварительном вызове FEDCM. Это должно позволить встраиваемому перенаправленному потоку, обсуждаемому по вопросу GitHub . |
| API Spec | Client_metadata_endpoint - это необходимое поле в ответе конечной точки конфигурации для FedCM. Пустой объект является допустимым ответом, и хром молча игнорирует ответ 404, что позволяет предположить, что конечная точка рассматривается как необязательная на практике. | Мы согласны с тем, что спецификация может быть изменена, чтобы отразить это и сделать Client_metadata_endpoint необязательным поле. |
| Использование API | Опасения относительно сложности тестирования реализаций FedCM из-за контролируемых браузером пользовательских интерфейсов, которые недоступны через DOM. | Мы поддерживаем API -интерфейсы автоматизации браузеров для регрессионного тестирования, которые могут решить эти проблемы. Эти API задокументированы здесь . |
| API Spec | Параметр login_url, который является необходимой частью ответа конечной точки конфигурации, не был задокументирован в разделе 3.2 спецификации. | Мы представили обновление в документацию, чтобы включить параметр login_url в раздел 3.2. |
| API Spec | Забота о потенциальном векторе отслеживания в FedCM. IDP может вставлять идентификаторы в качестве параметров пути в конечные точки, указанные в ответе конечной точки конфигурации (Accounts_endpoint, Client_metadata_endpoint), и использовать эти идентификаторы для корреляции запросов учетной записи и метаданных клиентов. | Несмотря на то, что у нас нет доказательств того, что ВПЛ вставляют идентификаторы в эти конечные точки, мы активно рассматриваем смягчения для решения этой проблемы здесь . |
Борьба со спамом и мошенничеством
API токена частного государства (и другие API)
В этом квартале не было получено отзывы.