Ежеквартальный отчет за второй квартал 2023 года, в котором суммируются отзывы экосистемы, полученные по предложениям 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 может еще не ответить.
Глоссарий сокращений
- ЧИПСЫ
- Файлы cookie, имеющие независимое разделенное состояние
- ЦСП
- Платформа спроса
- ФедКМ
- Федеративное управление учетными данными
- ФПС
- Наборы для первой вечеринки
- IAB
- Бюро интерактивной рекламы
- ВПЛ
- Поставщик удостоверений
- IETF
- Целевая группа по интернет-инжинирингу
- ИП
- Адрес интернет-протокола
- openRTB
- Ставки в реальном времени
- ОТ
- Исходная пробная версия
- ПатКГ
- Группа сообщества частных рекламных технологий
- РП
- Доверяющая сторона
- ССП
- Платформа предложения
- ТРОЙНИК
- Доверенная среда выполнения
- UA
- Строка пользовательского агента
- UA-CH
- Подсказки для клиента User-Agent
- W3C
- Консорциум Всемирной паутины
- ВИПБ
- Умышленная IP-слепота
Общий отзыв, без конкретного API/технологии
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Управление данными и соблюдение нормативных требований | Экосистемное руководство по использованию Privacy Sandbox в соответствии с нормативными требованиями. | Как и в случае с любой новой технологией, каждая компания несет ответственность за то, чтобы использование Privacy Sandbox соответствовало закону; Google не может предоставлять другим юридические консультации. Однако мы понимаем, что это ключевая область интересов экосистемы. Для каждого API мы опубликовали обширную техническую документацию, которая должна обеспечить основу для проведения необходимых юридических оценок, и мы работаем над предоставлением дополнительных материалов в поддержку усилий компаний по соблюдению нормативных требований. |
| Предложение по количественному тестированию CMA | Дополнительная информация о предложении по количественному тестированию CMA | Мы работаем вместе с CMA над разработкой экспериментов, которые дадут представление о влиянии прекращения поддержки сторонних файлов cookie и внедрения предложений Privacy Sandbox на экосистему. В апреле CMA опубликовало руководство высокого уровня о том, чего ожидать в период тестирования и испытаний, а в июне последовало подробное руководство . Мы рекомендуем направлять вопросы или отзывы о предложении CMA по количественному тестированию непосредственно в CMA. |
| Режимы тестирования с поддержкой Chrome | Дополнительная информация и разъяснения по графикам тестирования | 18 мая мы опубликовали сообщение в блоге , в котором поделились дополнительной информацией о двух режимах тестирования с помощью Chrome. Эти подробности не являются окончательными, и мы опубликуем дополнительные рекомендации по реализации по мере продвижения в третьем квартале 2023 года. |
| Разделенное хранилище | Будет ли использоваться разделенное хранилище во время тестирования с помощью Chrome? | Разделение хранилища будет доступно всем пользователям до начала эксперимента по прекращению поддержки сторонних файлов cookie. Поэтому он будет включен для всех групп эксперимента. На сайтах будет возможность включить пробную версию устаревания, чтобы вернуть неразделенное хранилище в течение этого периода времени. |
| Поддержка производства | Каков процесс поддержки технических проблем Privacy Sandbox и эскалации в Chrome, влияющих на экосистему? | Google предоставляет ряд каналов, позволяющих специалистам по рекламе сообщать о проблемах и обеспечивать необходимую эскалацию. Пожалуйста, ознакомьтесь с нашим сообщением для разработчиков для получения дополнительной информации на общедоступных и частных форумах для обратной связи и эскалации. |
| График регистрации | Текущие сроки регистрации слишком короткие. | Мы все еще оцениваем крайний срок исполнения и хотели бы услышать от экосистемы, какой график будет более подходящим. |
| Номер DUNS | Дополнительная информация о требованиях к номеру DUNS для регистрации и аттестации. | Участники могут найти требования для получения номера DUNS на веб-сайте Dun and Bradstreet . Требования различаются в зависимости от рынка, поэтому участникам следует обязательно проверить веб-сайт на предмет конкретного рынка, который их интересует. Однако в целом участникам необходимо предоставить основную информацию о своем бизнесе, например название бизнеса, адрес и контактную информацию владельца или менеджера бизнеса. Участников также могут попросить предоставить финансовую информацию, например, годовой доход бизнеса. Как только заявка будет заполнена, D&B рассмотрит ее и выдаст номер DUNS, если заявка будет одобрена. |
| Переход с пробной версии Origin на общедоступную версию | Повлияет ли переход с пробной версии Origin на общедоступную версию для текущих тестировщиков пробной версии Origin? | С июля тестировщики смогут получить доступ к общедоступным API-интерфейсам релевантности и измерения. Это обеспечит совпадение между доступностью исходной пробной версии и общей доступностью. |
| Исследование AdExchanger | Дополнительная информация о методологии опроса | В ходе опроса респондентам было предложено оценить скорость синхронизации и доходы их бизнеса. Методика ответа на индивидуальные вопросы респондентов была на их усмотрение. |
| Значения параметров | Как определяются значения параметров, таких как уровень шума, пороги анонимности и бюджет конфиденциальности? | В этом пояснении GitHub излагаются более общие принципы, лежащие в основе API Privacy Sandbox. Многие значения все еще находятся на стадии доработки, и мы приветствуем отзывы по этому вопросу. |
Показывайте релевантный контент и рекламу
Темы
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Сохранение конфиденциальности | Исследование по оценке API Topics с точки зрения сохранения конфиденциальности | Мы активно сотрудничаем с исследовательским сообществом, представляя наши исследования свойств конфиденциальности API Topics в статьях, отчетах и презентациях на семинарах. Мы рады видеть больше внешних членов исследовательского сообщества, занимающихся этой областью. API Topics защищает пользователей от общего отслеживания в Интернете, затрудняя отслеживание пользователей в больших масштабах. Эти документы показывают, что мы успешно делаем это с помощью Topics API. Они более конфиденциальны, чем сторонние файлы cookie, и защищают пользователей, одновременно поддерживая сайты, которые они любят посещать. |
| Таксономия тем недостаточно детализирована | Таксономия широких тем не включает более подробные темы, в том числе специфичные для региона. | В ответ на предыдущие отзывы экосистемы 15 июня мы опубликовали сообщение в блоге с подробным описанием новой обновленной таксономии, которая включает в себя многочисленные улучшения после отзывов экосистемы. В рамках нашей работы над пересмотренной таксономией мы сотрудничаем с несколькими компаниями экосистемы, такими как Raptive (ранее CafeMedia) и Criteo. В обновленной таксономии исключены категории, которые, как мы слышали, менее полезны, в пользу категорий, которые лучше соответствуют интересам рекламодателей, сохраняя при этом наше обязательство исключать потенциально деликатные темы. Мы призываем экосистему пересматривать последнюю таксономию и предоставлять отзывы об изменениях. |
| Процесс обновления таксономии и классификатора | Дополнительная информация о таксономии тем и периодичности выпуска классификаторов, а также о том, как компании могут подготовиться к таким обновлениям. | Как сообщалось в недавнем сообщении в блоге , мы ожидаем, что таксономия будет развиваться с течением времени и что управление таксономией в конечном итоге перейдет к внешней стороне, представляющей заинтересованные стороны со всей отрасли. Мы также поделились планом наращивания мощности в группе анонсов тем . |
| Влияние на собственные сигналы | Увеличение количества тем в недавнем обновлении Таксономии может быть очень ценным и в результате обесценивает другие сигналы, основанные на интересах. | В отчете за первый квартал 2023 года CMA отметило: «Мы понимаем, что Google обсуждает предложенную новую таксономию с несколькими участниками рынка в цепочке поставок рекламных технологий. Хотя несколько крупных издателей заявили, что большая полезность тем увеличит конкурентное давление на их собственные решения на основе данных, наше предварительное мнение заключается в том, что более высокая полезность лучше для конкуренции в целом, в частности, для возможности мелких издателей продолжать монетизировать свои ресурсы после прекращения поддержки сторонних файлов cookie». Наше мнение совпадает с этим комментарием CMA. |
| Полезность для разных типов заинтересованных сторон | Рекламные технологии, выступающие в роли SSP и DSP, могут иметь значительные преимущества перед другими игроками экосистемы. | Наш ответ не изменился по сравнению с предыдущими кварталами: «Google обязалась перед CMA разработать и реализовать предложения Privacy Sandbox таким образом, чтобы не искажать конкуренцию за счет личного предпочтения собственного бизнеса Google, а также учитывать влияние на конкуренцию в цифровой рекламе, а также на издателей и рекламодателей, независимо от Их размер. Мы продолжаем тесно сотрудничать с CMA, чтобы обеспечить соответствие нашей работы этим обязательствам. По мере продвижения тестирования Privacy Sandbox одним из ключевых вопросов, которые мы будем оценивать, является то, как новые технологии работают для различных типов заинтересованных сторон. Обратная связь В этом отношении решающее значение имеет, особенно конкретная и действенная обратная связь, которая может помочь нам в дальнейшем усовершенствовать технические конструкции. Мы работали с CMA над разработкой нашего подхода к количественному тестированию и поддерживаем публикацию CMA заметки о планировании экспериментов, чтобы предоставить больше информацию участникам рынка и возможность прокомментировать предлагаемые подходы». |
| Потомки темы | Если критерием выбора темы является частота посещений браузера, приведет ли фрагментация сегмента к тому, что темы-потомки никогда не поднимутся на вершину? | Chrome в настоящее время оценивает другие методологии ранжирования и изучает другие сигналы, которые могут улучшить рейтинг. В свое время мы сообщим экосистеме о наших пересмотренных планах. |
| Чувствительность | Целью Topics API должно быть обеспечение того, чтобы пользовательская информация, полученная или полученная с помощью Topics API, была менее конфиденциальной, чем та, которую можно получить с помощью современных методов отслеживания. | Мы считаем, что API Topics значительно более конфиденциальен, чем существующие технологии, значительно ограничивает повторную идентификацию пользователей и предназначен для исключения деликатных тем. Мы признаем, что темы можно сопоставлять или комбинировать с собственными данными для создания конфиденциальных категорий, но мы считаем, что API тем — это шаг вперед к обеспечению конфиденциальности пользователей, и мы намерены продолжать совершенствовать API. |
| Структура таксономии | Добавьте идентификатор, управление версиями и другую структуру метаданных в таксономию тем. | В настоящее время в ответ API мы включаем идентификатор таксономии. По мере того, как мы движемся к долгосрочному управлению, имеет смысл просмотреть объект Topics и при необходимости включить дополнительные метаданные по управлению версиями. |
| Издательский контроль | Издатели должны иметь право голоса в отношении того, к каким темам следует отнести их сайты. | Неправильная классификация сайтов может сделать сигнал «Темы» несколько менее полезным в качестве сигнала в целом, но конкретные неправильно классифицированные сайты страдают от этого не больше и не меньше, чем любые другие сайты. Это связано с тем, что контекстная информация сайта всегда будет доступна для аукционов на этом сайте, что обеспечит информацию, сопоставимую с правильной темой, даже в случае неправильной классификации. Мы приветствуем отзывы по этой теме здесь . Разрешение издателям контролировать свою классификацию сопряжено с риском. Сайты могут намеренно неправильно классифицировать свои сайты, снижая их полезность для всех, или кодировать деликатные значения в менее распространенных темах, нанося ущерб конфиденциальности пользователей. |
| Расширения Chrome | Разрешить расширениям Chrome управлять темами и фильтровать их, аналогично текущим расширениям управления файлами cookie. | Это уже должно быть возможно, как обсуждалось на GitHub , но мы приветствуем дополнительные отзывы от экосистемы. |
| Переход в общедоступную версию | Повлияет ли переход с пробной версии Origin на общедоступную версию API тем? | Данные пользователей, переходящих с пробной версии Origin на общедоступную, не будут потеряны. |
| Конфиденциальность | Имена хостов могут содержать личную информацию, которая может быть раскрыта API тем. | У нас есть ряд мер по обеспечению конфиденциальности, описанных здесь . |
| Мошенничество и злоупотребления | Как предотвратить манипулирование Темами путем мошеннических посещений | Смягчающие меры описаны здесь . |
| Классификатор тем | Могут ли веб-сайты запрашивать изменение классификации тем? | Мы заинтересованы в получении информации от экосистемы по этой теме и приветствуем отзывы здесь . |
| Сайты поставщиков тем | Назначьте определенные веб-сайты, на которых размещается контент для многих тем, как «сайты поставщиков специальных тем» и обучите классификаторы на основе тегов, представленных на веб-страницах. | Мы обсуждаем предложение здесь и будем рады дополнительным отзывам. |
API защищенной аудитории (ранее FLEDGE)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Формирование трафика | Влияние фильтрации на основе SSP на производительность для оптимизации нагрузки по количеству запросов в секунду (QPS) | Мы потратили значительное количество времени на размышления о формировании трафика, и рекомендуем SSP воспользоваться преимуществами кэширования. |
| Объем тестирования | Тестировать защищенную аудиторию сложно, поскольку SSP и DSP изо всех сил пытаются получить большие объемы трафика. | Мы постоянно привлекаем партнеров SSP и DSP к внедрению и тестированию защищенных аудиторий. Общая доступность уже началась, и мы уверены, что процент трафика с включенным PA сделает тестирование более привлекательным для партнеров. |
| Сложность | Внедрение решений защищенной аудитории требует значительных усилий и затрат. | Мы признаем, что новые технологии сложно внедрить, включая Privacy Sandbox. Команда Privacy Sandbox тесно сотрудничает с широким кругом заинтересованных сторон, обучая и поддерживая их усилия, а также постоянно оценивает другие ускорители для поддержки внедрения экосистемы. |
| Доверенные среды выполнения | Поддержка доверенных сред выполнения (TEE) в закрытых облачных средах. | Хотя мы изучаем потенциальные варианты поддержки, выходящие за рамки облачных решений, в настоящее время невозможно поддерживать локальные TEE из-за локальных ограничений безопасности, которые потребовали бы трудоемкой оценки Privacy Sandbox. Учитывая требования безопасности Privacy Sandbox и серьезные проблемы, связанные с локальным развертыванием, мы считаем, что продолжение расширения и улучшения облачных развертываний (например, поддержка GCP в дополнение к AWS) является наиболее полезным для экосистемы. Однако мы приветствуем дополнительные отзывы о том, почему такое требование необходимо. |
| Структура затрат | Предложение по услугам ставок и аукционов увеличит затраты и сложность для рекламных технологий по сравнению с моделями на стороне клиента. | В настоящее время мы разрабатываем руководство по оценке затрат на поддержку рабочих процессов торгов и аукционов на сервере ставок и аукционов, которое будет коррелировать с использованием рекламных технологий, что соответствует одной из целей нашего проекта. |
| К-Анон | Когда будут введены запланированные ограничения анонимности k для `renderUrl`? | Мы работаем над объяснением сроков исполнения, которое скоро опубликуем. |
| ограничения runAdAuction | Может ли Chrome ограничить вызов runAdAuction только с верхней страницы? | Хотя наш дизайн полностью поддерживает возможность вызова runAdAuction с верхней страницы, мы считаем, что для издателей было бы более вредно ограничивать возможность вызова только из верхнего домена.Мы, в частности, услышали от представителей экосистемы, что Privacy Sandbox должна минимизировать нагрузку на издателей и рекламодателей. Эта обратная связь соответствует общему принципу веб-разработки, согласно которому владельцы сайтов могут использовать сторонние инструменты для управления своими сайтами. Целью Privacy Sandbox было создание здоровой экосистемы без необходимости предписывать, как должны работать издатели и рекламные специалисты. Позволяя издателю выбирать, как и кто вызывает runAdAuction на своем сайте, мы считаем, что мы предлагаем издателям гибкость в поиске наилучшего пути для их требований. |
| Поддержка внедрения | Может ли Chrome создать или внести свой вклад в реализацию аукциона с несколькими продавцами с открытым исходным кодом? | Privacy Sandbox направлена на разработку технологий сохранения конфиденциальности, которые не полагаются на сторонние файлы cookie или другие межсайтовые идентификаторы. Мы хотим способствовать здоровой экосистеме без необходимости предписывать, как должны работать рекламные технологии. Мы опубликовали руководство по работе API в нашем репозитории GitHub и открыты для изучения отраслевых решений. Мы не планируем создавать какую-либо конкретную реализацию, поскольку наша основная задача — создавать платформенные технологии, а не диктовать стратегии использования этих технологий. Наши технологии помогут компаниям, занимающимся рекламными технологиями, наилучшим образом обслуживать своих клиентов, обеспечивая правильные меры конфиденциальности для потребителей. |
| Аукционы с несколькими продавцами | Заставит ли Chrome разделить «контекстного» победителя на аукционах компонентов? | API защищенной аудитории предназначен для того, чтобы предоставить сторонам, инициирующим аукцион с несколькими продавцами, возможность передавать информацию на компонентный аукцион (примечание: только до начала аукциона). Тем не менее, мы не видим возможности для браузера определить, является ли та или иная информация контекстуально выигрышной или нет, поэтому мы не можем принудительно заблокировать или потребовать определенную информацию. |
| Предпочтения пользователя для отслеживания согласия | Adtech спрашивает PA, как правильно реализовать отслеживание согласия пользователей | Наш ответ включает в себя то, что мы сказали в первом вопросе: «Для конкретных объявлений соответствующая рекламная технология лучше всего может предложить контроль над тем, какие креативы показываются или как они выбираются». Мы обсудили ряд сценариев, связанных с этим вопросом, во время майского собрания защищенной аудитории WICG и приветствуем дополнительные отзывы и обсуждения по этому вопросу . |
| Пользовательские аудитории | Будут ли API защищенной аудитории поддерживать варианты использования SSP, связанные с созданием индивидуально настроенных аудиторий? | API Protected Audience позволяет SSP и другим поставщикам рекламных технологий владеть индивидуально настроенными аудиториями и управлять ими. Дальнейшие рекомендации о том, как SSP может интегрироваться с PA API, разрабатываются и будут доступны SSP и другим поставщикам рекламных технологий для поддержки их усилий по интеграции. |
| Форматы | Поддерживается ли видео API Protected Audience? | Видеообъявления доставляются одним из двух способов: в виде VAST XML или HTML (исходящая реклама, которая в конечном итоге также может загружать VAST XML в видеоплеер). Покупатели могут вернуть любой формат через renderURL. Спецификация VAST была недавно обновлена для поддержки API отчетов по атрибуции. Сайтам, показывающим видеорекламу, необходимо подготовиться к доставке рекламы через API Protected Audience. Это означает, что теги мест размещения могут передавать URL-адрес из iframe защищенной аудитории в видеопроигрыватель. Что касается Fenced Frames, мы будем работать над удовлетворением потребностей в видео до введения требования об использовании Fenced Frames, которое появится не раньше 2026 года . |
| темп | Как вариант использования Pacing работает с API Protected Audience? | Мы ценим обратную связь. Нам было бы интересно увидеть больше случаев этого запроса с более подробной информацией от большего количества партнеров SSP, поскольку на сегодняшний день это в основном проблема DSP. |
| Частота обновления | Частоты вызовов dailyUpdate (до 1 на группу по интересам в день) может быть недостаточно для определенных случаев использования, например обновления информации о продукте. | Мы ценим обратную связь. Существуют и другие решения, позволяющие рекламным специалистам использовать сигналы, которые обновляются с разной частотой, например, поиск K/V. |
| Контроль качества рекламы | Как издатели осуществляют контроль качества рекламы? | Сегодня API Protected Audience предлагает издателям возможность информировать своих SSP об определенных элементах управления, которые они могут установить в рамках конфигурации аукциона перед ставкой (т. е. списки запретов на основе меток, связанных с рекламой). Мы приветствуем отзывы о любых дополнительных функциях, которые могут потребоваться экосистеме. |
| Отладка | Когда будет удалена функция forDebuggingOnly ? | Мы планируем прекратить forDebuggingOnly в случае событий потери из-за прекращения поддержки сторонних файлов cookie. Мы планируем отказаться от forDebuggingOnly для победных турниров не раньше 2026 года. |
| Группы по интересам кросс-устройств | Предложение включить группы по интересам между устройствами для аутентифицированных пользовательских агентов | Мы рассматриваем это предложение, но высокая специфичность таргетинга на несколько устройств создает серьезные проблемы с конфиденциальностью, как обсуждается в этом выпуске GitHub. |
| (Также сообщалось в первом квартале) Динамический ремаркетинг | Будет ли по-прежнему возможен динамический ремаркетинг с API Protected Audience после прекращения поддержки сторонних файлов cookie? | Мы считаем, что этот вариант использования возможен с использованием Защищенной аудитории, как описано здесь . |
| Нажмите на связанные данные | Добавьте данные, связанные с кликами, в browserSignals. | В настоящее время мы просим разъяснений относительно того, когда произошел щелчок, дающий предварительную позицию. |
| (Также сообщалось в четвертом квартале 2022 г.) Пользовательские функции в Защищенной аудитории | Как будут поддерживаться пользовательские функции (UDF) в API Protected Audience? Это функции, которые конечные пользователи могут запрограммировать для расширения функциональности API. | Рекламный техник, поднявший эту проблему, также упомянул, что они все еще оценивают, что они могут сделать с UDF, поэтому пока нет действенных отзывов, на которые можно было бы отреагировать, по крайней мере, до общедоступности. |
| Валюта | Суммы валюты не должны быть представлены с использованием плавающей точки. | Подробно этот вопрос мы рассмотрели здесь . |
| Возможности выбора объявлений без DSP | Какую роль рекламные серверы играют в аукционах Protect Audience API? | Нам известно о просьбах к рекламным серверам продолжать предлагать услуги выбора объявлений/динамической оптимизации объявлений после ставки. В настоящее время мы проводим подробный анализ пробелов, существующих между текущим API защищенной аудитории и этими запросами. |
| Создать ставку | Поддержка предложения Google Ads о возврате более одного объявления-кандидата на каждую группу интересов из generateBid и о присвоении этим кандидатам оценок в ScoreAd. | В настоящее время это оценивается. Мы приветствуем дополнительные отзывы здесь . |
| Порядок аукциона | Должны ли аукционы Protected Audience API проводиться последними, чтобы можно было учитывать результаты всех других аукционов? | Технических требований к тому, чтобы API Protected Audience запускался последним, не существует. |
| Навигация, не инициированная пользователем | Разоблачить навигацию, не инициированную пользователем | Мы рассматриваем этот запрос и обсуждаем его здесь и будем рады получить дополнительные отзывы. |
| Кэширование | SSP не должен создавать perBuyerSignals данного DSP из кэша, если состояние пользователя меняется. | Мы понимаем, что кэширование работает не для всех случаев использования сигналов perBuyer, и рассматриваем дополнительные варианты. Мы приветствуем любые дополнительные отзывы от экосистемы о том, будет ли кэширование работать в их сценариях использования. |
| Отчеты по атрибуции и защищенная аудитория | Как API отчетов по атрибуции и API защищенной аудитории могут работать вместе? | В настоящее время интеграция API Protected Audience доступна для обоих режимов API отчетов об атрибуции (отчеты на уровне событий и сводные отчеты). 1 июня мы поделились дополнительной информацией об улучшенной интеграции API Protected Audience и отчетов по атрибуции. Вы можете прочитать о них здесь . |
| Конечная точка сервера | Будет ли конечная точка сервера доверенным сервером агрегации в окончательном проекте? | Конечная точка сервера — это конечная точка, поддерживаемая рекламными технологиями и независимая от доверенных серверов агрегации, используемых для обработки собранных и преобразованных отчетов. На данный момент у нас не запланировано никаких изменений для конечной точки отчетности. Текущая конструкция направлена на то, чтобы сами агрегированные отчеты (с зашифрованными полезными данными) не допускали утечки межсайтовых данных, поэтому доверенная конечная точка не требуется. Дополнительная сложность заключается в том, что разные рекламные технологии, вероятно, будут иметь разные желаемые стратегии пакетирования. Мы приветствуем дополнительные отзывы здесь . |
| ВебИДЛ | Текущая спецификация API защищенной аудитории несовместима со спецификацией WebIDL. | Мы оцениваем этот отзыв и обсуждаем проблему здесь . |
| Управление согласием | Как передача сигнала согласия будет обрабатываться в API Protected Audience? | Контекстная информация не входит в сферу действия API Protected Audience. Мы обсуждаем этот вопрос и будем рады дополнительным отзывам. |
| Маркетинг на основе аккаунта | Возможны ли варианты использования маркетинга на основе учетных записей? | API Protected Audience поддерживает различные варианты использования маркетинга на основе аудитории. Мы продолжаем понимать, как API Protected Audience может наилучшим образом поддержать этот конкретный вариант использования, и приветствуем дополнительные отзывы по этому вопросу от экосистемы. |
| Аукцион компонентов | Какие баллы получают участники аукциона по компонентам? | Аукционы компонентов не оценивают группы по интересам напрямую, а скорее оценивают рекламу и ставки, которые DSP отправляет из generateBid . generateBid() запускается для каждой группы интересов, и DSP возвращает следующее при выполнении методаgenerateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Внешние взносы | Запрос на поддержку внешнего вклада в базу кода GitHub сервера ключей/значений. | Мы планируем обновить наши соответствующие процессы для поддержки внешнего вклада в код GitHub. |
| Размер группы по интересам | Какое максимальное количество ключей может поддерживать IG? | Текущий лимит составляет 50 КБ на размер одного IG, и ключи считаются его частью. Мы приветствуем дальнейшее обсуждение ограничения размера . |
| Пакетирование | Как можно уменьшить количество обращений к серверу K/V? | Вы можете использовать заголовки управления кэшем HTTP , чтобы уменьшить количество вызовов K/V. Например, его можно кэшировать между аукционами компонентов, а также между рекламными местами на одной странице. |
| Контроль версий | Поддержка нескольких версий кода рекламных технологий. | Службы назначения ставок и аукционов будут поддерживать несколько версий кода рекламных технологий. В API ставок и аукционов запрос SelectAd может указывать версию кода, используемого для запроса аукциона (т. е. для ставок/аукциона, а также отчетов). |
| Общее хранилище | Поддержка записи в общее хранилище в Службе торгов и аукционов. | В настоящее время Службы ставок и аукционов не поддерживают общее хранилище, но мы приветствуем дополнительные отзывы о том, почему такие варианты использования важны для экосистемы. |
| Интернет-приложение | Поддержка обмена информацией между группами по интересам через веб-приложение. | Переход от Интернета к приложению в настоящее время не входит в сферу развертывания API Protected Audience API в Chrome и Android, но мы заинтересованы в том, чтобы услышать мнение экосистемы о важности этого варианта использования. |
| К-Анонимность | Как справиться с откатами K-Anonymity | Мы обсуждаем проблему и будем рады дополнительным отзывам. |
Измерение цифровой рекламы
Отчеты по атрибуции (и другие API)
| Тема обратной связи | Краткое содержание | Ответ Chrome |
|---|---|---|
| Альтернативные конфигурации отчетов об уровне событий VTC | Отзыв об альтернативных конфигурациях отчетов на уровне событий VTC | Мы получили отзывы о том, что текущие конфигурации уровня событий не являются оптимальными, и просим вас высказать мнение об оптимальных глобальных конфигурациях. Мы открыты для дополнительных отзывов по этому поводу и считаем, что наше гибкое объяснение на уровне событий также поможет решить эту проблему. |
| Гибкие конфигурации на уровне событий | Каков статус функции гибкой конфигурации на уровне событий? | У нас есть общая документация по гибкой настройке уровня событий . Эта функция все еще находится на стадии предложения, и мы ждем дополнительных отзывов о том, будет ли эта функция полезна для экосистемы. |
| Гибкие конфигурации на уровне событий | Как можно согласовать противоречивые сообщения разных сторон? | Большинство сценариев отчетности решаются с помощью агрегированных отчетов, тогда как предложение гибкой конфигурации на уровне событий предназначено специально для дополнительной гибкости отчетов на уровне событий, которые чаще всего используются для вариантов использования оптимизации. Мы приветствуем любые дополнительные комментарии/отзывы экосистемы относительно этого сценария. |
| Регистрация источника | Что, если регистрация источника произойдет после регистрации триггера? | В настоящее время, если регистрация источника происходит после регистрации триггера, то источник и триггер нельзя будет приписать друг другу. Похоже, это крайний сценарий. Мы приветствуем любые дополнительные отзывы по этой проблеме и постараемся решить ее, если с такой ситуацией столкнутся многие рекламные специалисты. |
| Работа с несколькими рекламными агентствами | Как DSP могут использовать API отчетов об атрибуции, если рекламодатель работает с несколькими рекламными агентствами? | API поддерживает перенаправления и поэтому может использоваться, даже если рекламодатель работает с несколькими рекламными агентствами. Кроме того, существуют некоторые ограничения в отношении перенаправлений, чтобы гарантировать, что API улучшает конфиденциальность. Мы также нашли потенциальное обходное решение с использованием API общего хранилища для конкретного сценария, предложенного рекламной технологией. Мы приветствуем любые дополнительные отзывы относительно этого сценария и продолжим работу на основе этих отзывов. |
| Ограничения назначения | На вариант использования автоматического обновления рекламы могут повлиять ограничения по местам назначения. | Мы обсуждали этот вопрос на встрече WICG 1 мая и ждем отзывов о том, каким будет разумный предел. Мы добавили в отчеты об атрибуции поясняющие отчеты на уровне событий, в которых говорится, что браузер может ограничивать количество «целевых» eTLD+1, представленных исходными сайтами. (См. запрос на вытягивание ). |
| Отчеты по атрибуции и защищенная аудитория | Как API отчетов по атрибуции и API защищенной аудитории могут работать вместе? | В настоящее время интеграция API Protected Audience доступна для обоих режимов API отчетов об атрибуции (отчеты на уровне событий и сводные отчеты). 1 июня мы поделились дополнительной информацией об улучшенной интеграции API Protected Audience и отчетов по атрибуции. Вы можете прочитать о них здесь . |
| Гибкие конфигурации на уровне событий | Поделитесь лучшими практиками моделирования шума теперь, когда параметры можно настраивать. | Мы поделились кодом на GitHub , который каждый может использовать для оценки получения информации и воздействия шума для любых гибких конфигураций уровня событий, которые он хочет протестировать. Нам было бы интересно услышать мнение всех, кто решит протестировать код, и поделиться отзывами. |
| Измерение межприложенной и веб-атрибуции | Когда будет доступно измерение кросс-приложенной и веб-атрибуции? | 9 мая мы объявили об эксперименте по измерению межприложений и веб-атрибуции с помощью API отчетов об атрибуции . Хотя общая доступность запланирована для API-интерфейсов релевантности и измерения в Chrome 115, в настоящее время не планируется, что измерение межприложенной и веб-атрибуции станет общедоступным в Chrome 115. |
| Дедупликация конверсий | Как можно совместить независимые измерительные решения с ARA? | Как и в случае с текущей стандартной практикой, рекламодатели будут работать со сторонним независимым поставщиком измерений для деопликации отчетности по конверсии. Мы предложили ресурсы о том, как дедупликации конверсий для отчетности на уровне событий. |
| Потеря данных во время обновлений базы базы данных о атрибуции | Будет ли какая -либо потеря данных, когда Chrome обновляет базу данных отчетности по атрибуции, как объявлено? | Начиная с хромированной стабильной 115, мы начнем по умолчанию актуальных и измерений API для части пользователей Chrome. Эта общая доступность будет расти, поскольку мы контролируем потенциальные проблемы. Цель будет заключаться в том, чтобы достичь 100% доступности в течение периода недель, к Q3 2023. Это будет совпадать с окончанием исследования релевантности и измерения. Начиная с июля, тестеры смогут зарегистрироваться для доступа к этим API в общей доступности. Это обеспечит совпадение между доступностью испытания происхождения и общей доступностью посредством зачисления. Ваш токен пробного испытания будет действительным до 19 сентября, но мы рекомендуем вам зарегистрироваться на API до истечения срока действия, чтобы беспрепятственно переходить из испытания происхождения без прерывания каких -либо текущих тестов. Как упоминалось в этом объявлении , данные, зарегистрированные из более старых версий (M113 и ранее), не будут перенесены после обновления, поэтому может быть потеря данных. Эта потеря данных не будет отображаться в отчетности отладки, и мы постараемся избежать потери данных с 114 до 115. |
| Биллинг | Использование отчетности по атрибуции для выставления счетов за расходы на конверсию | Как указано в этой статье , API отчета о атрибуции не может быть подходит для потребностей в платежных платежах за расходы на конверсию из-за шума, добавленного к отчетам на уровне событий и сводных отчетов. Мы призываем игроков экосистемы делиться отзывы о влиянии на различные модели выставления счетов с помощью API отчета о атрибуции на GitHub. |
Служба агрегации
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Агрегируемое изменение задержки отчета | Положительные реакции на предложение изменить агрегируемую задержку отчета-от [10-60 мин] до [0-10 минут] после обратной связи от экосистемы | Мы рады видеть положительную реакцию на предлагаемые изменения и поощряем экосистему продолжать предоставлять отзывы о наших предложениях. |
| Локальное решение | Можно ли развернуть службу агрегации в локальных центрах обработки данных? | Несмотря на то, что мы исследуем потенциально поддерживающие варианты за пределами облачных решений, в настоящее время невозможно поддержать локальные футболки, предоставленные локальными ограничениями безопасности, которые потребуют много времени оценки на песочницу конфиденциальности. Учитывая требования к безопасности на песочнице конфиденциальности и значительные проблемы, представленные локальными развертываниями, мы считаем, что продолжение расширения и улучшения облачных развертываний (например, поддержка GCP в дополнение к AWS) является наиболее полезным для экосистемы. Тем не менее, мы приветствуем дополнительные отзывы о том, почему такое требование необходимо. |
| Revocess Reports для разных периодов времени | Способность перерабатывать отчеты в течение разных периодов времени | Мы слышали, как аналогичные запросы могут разделить партии для разных диапазонов дат. Одним из предложений является предоставление возможности расширить общий идентификатор с помощью метки, определяемого AD, чтобы отчеты могли быть разделены на разные партии. Мы находимся в раннем процессе оценки этого процесса и будем держать экосистему обновляться по мере развития этого предложения. |
| Последствия конфиденциальности среды доверенной исполнения | Позитивные чувства к последствиям конфиденциальности средств доверенной исполнения | Мы рады услышать о положительных реакциях экосистемы относительно наших предложений, и мы приветствуем дополнительные отзывы, поскольку мы продолжаем итерацию и развиваться. |
| Условия использования | Какой крайний срок для принятия условий обслуживания агрегации? | Несмотря на то, что мы еще не указали крайний срок для принятия условий, мы бы посоветовали экосистемным компаниям принимать условия как можно скорее, чтобы предотвратить задержки в зачислении. Мы призываем компании обратиться, если у них есть какие -либо вопросы. |
| Ключевое открытие | Ключевая функция обнаружения позволит тестерам запросить отчеты об агрегате без необходимости явного списка возможных ключевых комбинаций, чтобы обработать сводные отчеты для атрибуции межсети для повышения производительности и точности. | В настоящее время мы исследуем возможные решения и обходные пути и приветствуем дополнительные отзывы от экосистемы. |
Частная агрегация API
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Сообщение о происхождении | Как определяется происхождение отчетности? | Происхождение отчетности всегда является происхождением сценария частного абонента агрегации. |
| 128 -битное пространство ключа | Ясность на 128-разрядном ключевом ограничении пространства | Мы сделаем это ограничение на ключи более ясным и разрешаем несоответствия на всех страницах. Мы рекомендуем использовать стратегии хеширования, чтобы остаться в этом ключевом пространстве. |
| Максимальный вклад за отчет | Текущий лимит 20 вкладов за отчет слишком низок. | Вместо того, чтобы увеличить максимальное количество взносов, мы открыты для рассмотрения деления отчетов, а не укорочить на пределе. Мы будем привлекать экосистему по мере развития этого предложения. |
| Достичь отчетности | Запрос о перекрестном платформенном/перекрестном отчете. Reach - это основополагающий показатель рекламы бренда. Рекламодатели полагаются на кроссплатформенные/перекрестные аппроксимации для охвата и отчетов о частоте для анализа их кампаний и распределения расходов. Модели Reach используют сторонние файлы cookie в качестве сигнала для измерения объявлений, показанных в сторонних средах, и поэтому AD-технологии запросили альтернативное решение после того, как сторонние куки оправдываются. | Команда Sandbox Privacybox изучает функции, чтобы поддержать методологии перекрестного домара после стороннего управления печенья. Мы приветствуем дополнительные отзывы от экосистемы. |
Ограничьте скрытое отслеживание
Намеки клиента пользовательского агента/пользовательского агента
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| (Также сообщается в первом квартале 2023 г.) Намекает на дополнительные форм -факторы | Запрос на подсказки клиента пользователя (UA-CH) для предоставления дополнительных форм-факторов, таких как TV, VR | Мы все еще работаем над некоторыми ключевыми проектными решениями (будь то единственное значение, такое как «ТВ», или список возможностей для форм-фактора), но по-прежнему заинтересованы в прототипировании этой идеи. |
| Бюджет конфиденциальности | Бюджетные ограничения на конфиденциальность могут привести к тому, что запросы UA-CH станут неэнергинными при отправке слишком большого количества запросов. | В настоящее время у нас нет новых обновлений о предложении бюджета конфиденциальности, но мы обязались не ограничивать запросы на подсказки клиентов UA до того, как сторонние файлы cookie не устарели. |
| Совместимость сайта | Веб-сайты используют бренд UA-CH для ограничения определенных браузеров от доступа к сайтам. | Существуют действительные варианты использования для получения списка брендов, и одним из них является точно совместимость. UA может свободно иметь несколько брендов для решения этих проблем. |
Защита от IP (ранее Gnatcatcher)
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Мошенничество и злоупотребление | Как компании могут организовать меры по защите от мошенничества с защитой от ИС? | Мы понимаем важность вариантов использования против мошенничества и возможного воздействия на эти варианты использования. Мы планируем опубликовать более подробную информацию о поддержке антипроводной мошенничества в конце лета. Мы ищем отзывы экосистемы о том, как мы можем лучше поддерживать варианты использования против мошенничества. |
| Геоип | Более подробная информация о графике тестирования и развертывания для GeoIP | Chrome недавно опубликовал новую информацию , подробно описывающую наши планы Geoip. Мы планируем опубликовать больше информации о сроках развертывания в 3 -м квартале. Мы рассчитываем запустить IP Protection в качестве функции пользователя в первоначальном проценте трафика. Причина этого заключается в том, что мы признаем, что это предложение может включать некоторые существенные изменения для компаний, и мы хотим дать экосистему время для корректировки и предоставления обратной связи, прежде чем эта функция будет развернута более широко. |
| Аутентификация учетной записи | Как точно будет работать аутентификация учетной записи с прокси -сервером? | Мы планируем опубликовать более подробную информацию об аутентификации учетной записи позже этим летом, хотя мы уже поделились некоторыми первоначальными соображениями . |
Снижение отслеживания отслеживания
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Руководство по тестированию | Информация о том, как проверить смягчение отслеживания отслеживания отслеживания. | В мае мы опубликовали поставку с дополнительной информацией о том, как проверить смягчение отслеживания отслеживания отслеживания. |
| Документация | Ясность в предложении отслеживания отскок | Нынешнее предложение -это в значительной степени незавершенная работа, и Chrome продолжает обновлять предложение, чтобы предоставить ясность и информацию для экосистемы. Мы работаем над предоставлением более подробной информации и приветствуем любые дополнительные отзывы. |
| Удаление печенья | Будет ли отслеживание отслеживания отслеживания удаления всех файлов cookie в домене? | Снижение отслеживания отслеживания (BTM) очистит все хранилище и все кеш, как объяснено здесь . |
| Обход отслеживания отслеживания отслеживания | Классификация трекеров Bounce может быть обойдена путем выполнения перенаправлений с всплывающими окнами или новыми вкладками. | Спецификация смягчения отслеживания отслеживания отслеживания все еще находится в стадии разработки. До сих пор мы были в основном сосредоточены на перенаправлениях с одноразовым табсом, но мы планируем работать над всплывающими потоками в будущем. Мы приветствуем здесь дополнительные отзывы . |
Бюджет конфиденциальности
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Близое нацеливание | Бюджет конфиденциальности может повлиять на то, что нацеливание на близость. | Мы получили отзывы по этому вопросу и заинтересованы в том, чтобы больше услышать о потенциальных последствиях от экосистемы. |
Укреплять границы конфиденциальности поперечного сайта
Первопартийные наборы
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| (Также сообщается в предыдущих кварталах) предел домена | Запрос на расширение количества связанных доменов | Chrome оценивает соответствующий числовой предел для связанного подмножества, которое будет сбалансировать конфиденциальность и полезность для выявленных вариантов использования. С самого начала Chrome поделился, что точное число для связанного подмножества еще предстоит завершить. |
| Встроенный вариант использования | Поддержка встроенных вариантов использования, которые требуют первых наборов, чипов и общего хранения | Chrome получил отзывы об этом варианте использования, и команда расследует и приветствует дополнительную обратную связь . |
| Управление хранилищем | Информация о политиках по удалению наборов первых лиц из репозитория GitHub, если есть расхождения или пренебрежение | Chrome получил отзывы об этом варианте использования. Команда расследует и приветствует дополнительные отзывы . |
| Пользовательский образование | Chrome должен повысить осведомленность пользователей и понимание первых наборов для управления принятием. | Chrome стремится информировать пользователей о первых наборах и опубликовал статью о справочнике (связанная с UI Chrome). Chrome также инвестируется в продолжение изучения того, как наилучшим образом обучать пользователей в соответствующих контекстах. |
| Пост 3PCD | Сторонние файлы cookie будут продолжать существовать в рамках первого набора после стороннего смягчения печенья. | В то время как requestStorageAccess и requestStorageAccessFor for действительно предоставляют сторонние файлы cookie снова доступными для конкретных, четко определенных вариантов использования, теперь они требуют активного вызова сайта, вместо того, чтобы быть доступными по умолчанию, как и в текущем состоянии сторонних куки (в Хром).Хотя этот вызов в пределах одного набора не потребует одобрения пользователя, пользователи могут предотвратить это, отказавшись от этого поведения в настройках. Дополнительная информация доступна пользователям в статье Help Center (связанную с пользовательским интерфейсом Chrome). Мы планируем расширить существующее руководство разработчика , поскольку FPS увеличивает до 100%. |
| Первопартийная установка | Переименуйте необходимый .well-known/first-party-set чтобы включить расширение .json. | Мы внесли это изменение, чтобы обеспечить поддержку определенных планов веб -хостинга. |
| Регистрация Яны | first_party_sets.JSON должен быть зарегистрирован в Iana | Мы рассматриваем это предложение и приветствуем дополнительные отзывы здесь . |
О огороженные рамки API
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Блокировка рекламы | Огороженные рамки могут облегчить блокировщикам рекламы блокировать рекламу. | Расширения могут взаимодействовать с огороженными рамами, аналогичными тому, как они будут взаимодействовать с iframes. Фактический URL -адрес, который должен пройти огороженную раму, также будет виден для расширений, и, следовательно, они могут применять любые правила соответствия URL для блокировки, как и в Iframes. Проще говоря, блокирование всех огороженных кадров безоговорочно может разорвать варианты использования не ADS огороженных рам. |
Общий API хранилища
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Более широкое принятие | Общее хранилище должно быть стандартом в отрасли, доступным в браузерах. | Мы приветствуем и признаем этот отзыв. Chrome продолжает активно участвовать в W3C FORA, чтобы отстаивать это предложение, искать обратную связь и стимулировать принятие. |
| Выходные ворота | Общие выходные ворота слишком ограничены. | Мы рассматриваем эту обратную связь и приветствуем дополнительную обратную связь экосистемы о том, почему выходные ворота слишком ограничены. |
| Соответствие нормативным требованиям | Как общее соблюдение нормативных требований будет сдерживать, например, политики хранения данных? | Общее хранилище обеспечивает гибкость для реализации и настройки логики для управления сроком службы и истечения срока действия любых хранимых данных. AD Techs могут обновлять или очистить данные общего хранения на основе временных метков записи. |
| А/Б-тестирование | Как можно провести A/B -тестирование для общего хранения и защищенного API аудитории? | Мы работаем над тем, чтобы опубликовать дополнительное руководство по этому вопросу и надеемся поделиться более подробной информацией в будущем. |
| Общий лимит хранения | Что произойдет после достижения общего лимита хранения? | Если предел достигнут, дальнейшие входы не будут сохранены. |
| Несколько доступ на одну и ту же загрузку страницы | Что происходит, когда доступ к общему хранилищу несколько раз на той же загрузке страницы? | Лучший способ справиться с этим - через window.sharedStorage.append(key, value) . Вместо того, чтобы обновлять значение для каждого объявления, которое может вызвать столкновения, если есть несколько объявлений. Функция добавления просто добавит новое значение к концу ранее существовавшего. |
| функциональность iframe | Поддержит ли общее хранилище определенные функции iframe, когда они больше не работают после выпуска третьих сторонников? | Опубликуйте сторонние печенья, местное хранение в iframes будет разделено на сайт верхнего уровня, но сами iframes не будут заблокированы. Данные в локальном хранилище iframe не могут быть воспроизведены на нескольких сайтах верхнего уровня, но локальное хранилище все еще можно использовать в IFRAME. |
Чипсы
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Предел разделения | 10 киб на распределенный сайт все еще существенен и хотел бы, чтобы он был снижен. | Firefox уже указал на положительную позицию на чипсах. Для поддержки Webkit мы призываем разработчиков предоставлять отзывы Apple непосредственно по этой проблеме GitHub, касающихся их вариантов использования, когда разделенные файлы cookie предпочтительны в разделе «Разделенное хранение». |
| Аутентифицированные вставки | Чипы могут влиять на ток SSO-входной поток из-за различных разделов, влияющих на аутентифицированные вставки. | Мы намереваемся использовать API доступа к хранилищам (с пользовательскими подсказками) для поддержки выбора аутентифицированных Enceds, а недавно отправили намерение к прототипу . |
| Пожизненная политика | Будет ли потенциальная политика в течение всего жизни применяться к первоклассным файлам cookie? | В настоящее время у нас нет планов навязывать пределы пожизненной службы на первом партийном печенье. |
Fedcm
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| OAuth Authorization Поддержка | Соответствовать разрешению некоммерческих прицелов OAuth | Мы активно ищем вклад в сообщество веб-идентификации через W3C FedID CG о лучших способах поддержки авторизации за пределами базовой аутентификации после стороннего управления cookie. |
| Поддержка SAML | Соответствовать требованиям поддержки SAML | Команда активно ищет вклад в исследовательские и образовательные сообщества по потребностям поддержки SAML (в дополнение к поддержке OpenID-подключения) после выпуска сторонних печенья. |
Борьба со спамом и мошенничеством
API токена частного государства (и другие API)
| Тема обратной связи | Краткое содержание | Хромированный ответ |
|---|---|---|
| Изучение новых сигналов | Несколько партнеров выразили положительные чувства к изучению основанных на браузере сигналов целостности устройства или доверия пользователей. Как правило, они также осторожны с тем, что новые специально построенные сигналы были достаточными для сохранения текущих уровней обнаружения мошенничества. | Мы рады изучить новые предложения вместе в рамках сообщества по борьбе с мошенничеством и веб -безопасностью, а также признаем и поделиться своими проблемами - именно поэтому «борьба со спамом и мошенничеством» была основным рабочим пособием песочной коробки конфиденциальности и почему мы продолжаем расставлять приоритеты Инвестиции в сохранение безопасности в Интернете по мере улучшения конфиденциальности пользователей. |
| Положительные отзывы о PST | Несколько партнеров выразили заинтересованность в тестировании или использовании PST для различных вариантов использования безопасности или веб-безопасности. | Мы рады услышать поддержку и интерес к дальнейшему изучению новых решений, которые используют PST. У нас есть ресурсы и пример кода, доступные через сайт Chrome Developer , и приветствуем дальнейшие отзывы. |
| Мошенничество и злоупотребление | Руководство по предотвращению / обнаружению мошенничества с рекламой при измерении после стороннего снижения печенья, когда идентификаторы больше не доступны. | Мы представили такие инструменты, как жетоны частного штата, которые помогают восстановить некоторые сигналы, потерянные сторонними куки, для целей против мошенничества, но с новыми контролями конфиденциальности. Мы активно инвестируем в новые предложения по борьбе с мошенничеством и анти-злоупотреблением для сохранения возможностей с другими изменениями песочницей конфиденциальности. |
| Эмитент до происхождения ставки информации | Информационная ставка на эмитент-теоригин достаточно высока, чтобы идентифицировать уникальных пользователей. | Мы обновили спецификацию, чтобы быть более ясными в отношении того, какие пользовательские данные могут передаваться с использованием токенов частного состояния. По дизайну можно использовать до шести общественных ключей за раз, что может представлять «состояние» для конкретного пользователя. Эти наборы ключей могут быть обновлены только каждые 60 дней (за исключением редких случаев, когда необходимо вращение аварийного ключа), что замедляет потенциал для объединения дополнительных пользовательских данных с течением времени. С любым новым веб -API существует баланс утилиты и чистую новую информацию пользователя, которую он предоставляет. Мы оцениваем, что PST обретают соответствующий баланс при защите конфиденциальности пользователей, обеспечивая при этом ключевые варианты использования против мошенничества, на которые повлияет сторонние смягчения печенья. |
| Получить интеграцию | Интеграция fetch сложна и ненужна. | Существуют плюсы и минусы, чтобы использовать fetch , и мы хотели бы продолжить дальнейшую стандартизацию в веб -экосистеме, но мы думаем, что будет слишком рано вносить эти изменения, пока у нас будет более четкое представление о том, как будет выглядеть стандарт. Если и когда появляется стандарт, мы также стремимся к ответственному переходу веб -разработчиков на этот стандарт. |
| Место хранения | Конфигурации ключей токенов частного состояния должны храниться в том же месте, что и протокол Privacypass. | Во время тестирования во время испытания происхождения разработчики указали, что они предпочитают гибкость хранить свои ключи в общих URL-адресах, а не в известном каталоге. Ключевой формат обязательств в Privacypass не особенно подходит для версии, в которой Keysets предназначены для того, чтобы обеспечить неявное значение «публичных метаданных». Если вариант Privacypass в конечном итоге станет стандартизированным с публичными метаданными (либо как POPRF, частичное ослепительное RSA или Keysets), мы можем перейти к будущей версии PST, чтобы поддержать это. |
| Внедрение заголовка API | Вопросы, касающиеся реализации заголовка API | По мере того, как API стандартизируется, и использование экосистемы этого API созревает, мы надеемся, что они могут либо поддержать как стандартную непогодивную версию этого API, так и потенциально в конечном итоге выпустить версию заголовка, если использование достаточно, либо достаточно инструментов/поддержки разработчика для стандарта. Способы корреляции запросов на выпуск/выкупа с другими данными. Мы обсуждаем проблему здесь . |
| Постановка на учет | Практичнее ли заставлять эмитентов зарегистрироваться у поставщиков браузеров? | Мы обновили спецификацию, чтобы описать процесс регистрации эмитента для токенов частного штата . Несмотря на то, что он использует свой собственный процесс, он аналогичен планам регистрации для остальной части работы с песочницей конфиденциальности, где мы просим эмитентов сделать публичное заявление о том, как они намерены использовать PST и подтвердить технические ограничения, которые защищают конфиденциальность пользователей. |