Персонализация на устройстве — персонализация с улучшенной защитой конфиденциальности.

В этом техническом пояснении, предназначенном для реализации в проекте Android с открытым исходным кодом (AOSP) , обсуждаются мотивы персонализации на устройстве (ODP), принципы проектирования, которые определяют ее разработку, ее конфиденциальность через модель конфиденциальности и то, как это помогает обеспечить проверенно частный опыт.

Мы планируем добиться этого за счет упрощения модели доступа к данным и обеспечения того, чтобы все пользовательские данные, выходящие за пределы безопасности, были дифференциально конфиденциальными на уровне каждого (пользователя, приемника, экземпляра модели) (в этом документе иногда сокращается до уровня пользователя).

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

Зрение

Персонализация на устройстве предназначена для защиты информации конечных пользователей от компаний, с которыми они не взаимодействовали. Предприятия могут продолжать настраивать свои продукты и услуги для конечных пользователей (например, используя надлежащим образом анонимизированные и дифференцированно частные модели машинного обучения), но они не смогут увидеть точные настройки, сделанные для конечного пользователя (это зависит не только от правило настройки, созданное владельцем бизнеса, но также и индивидуальное предпочтение конечного пользователя), за исключением случаев прямого взаимодействия между бизнесом и конечным пользователем. Если компания создает какие-либо модели машинного обучения или статистический анализ, ODP будет стремиться обеспечить их надлежащую анонимность, используя соответствующие механизмы дифференциальной конфиденциальности.

Наш текущий план состоит в том, чтобы изучить ODP в несколько этапов, охватывая следующие функции и возможности. Мы также приглашаем заинтересованные стороны конструктивно предлагать любые дополнительные функции или рабочие процессы для дальнейшего исследования:

1. Изолированная среда, в которой содержится и выполняется вся бизнес-логика, что позволяет множеству сигналов конечного пользователя поступать в песочницу, ограничивая при этом выходные данные.

2. Хранилища данных со сквозным шифрованием для:

   1. Пользовательские элементы управления и другие данные, связанные с пользователем. Это может быть предоставлено конечным пользователем или собрано и выведено компаниями, а также контроль времени жизни (TTL), политики уничтожения, политики конфиденциальности и многое другое.
   2. Конфигурации бизнеса. ODP предоставляет алгоритмы для сжатия или запутывания этих данных.
   3. Результаты обработки бизнеса. Эти результаты могут быть:
      1. Используемые в качестве входных данных в последующих раундах обработки,
      2. Зашумляется в соответствии с соответствующими механизмами дифференциальной конфиденциальности и загружается на соответствующие конечные точки.
      3. Загружается с использованием доверенного потока загрузки в доверенные среды выполнения (TEE), в которых выполняются рабочие нагрузки с открытым исходным кодом, с соответствующими центральными механизмами дифференциальной конфиденциальности.
      4. Показан конечным пользователям.

3. API, предназначенные для:

   1. Обновление 2(a), пакетное или постепенное.
   2. Обновляйте версию 2(b) периодически, пакетно или постепенно.
   3. Загрузите 2(c) с соответствующими механизмами шумообразования в доверенных средах агрегации. Такие результаты могут стать 2(b) для следующих раундов обработки.

Хронология

Это текущий план тестирования ODP в бета-версии. Сроки могут быть изменены.

Особенность	1 полугодие 2025 г.	3 квартал 2025 г.
Обучение на устройстве + вывод	Свяжитесь с командой Privacy Sandbox, чтобы обсудить возможные варианты пилотного проекта в этот период.	Начните развертывание на соответствующих устройствах Android T+.

Принципы проектирования

Есть три столпа, которые ODP стремится сбалансировать: конфиденциальность, справедливость и полезность.

Модель данных Towered для улучшенной защиты конфиденциальности

ODP следует принципам Privacy by Design и по умолчанию разработан с учетом защиты конфиденциальности конечных пользователей.

ODP исследует перенос обработки персонализации на устройство конечного пользователя. Этот подход сочетает конфиденциальность и полезность, сохраняя как можно больше данных на устройстве и обрабатывая их вне устройства только при необходимости. ODP фокусируется на:

• Устройство контроля данных конечного пользователя, даже когда они покидают устройство. Направления должны быть сертифицированы. Доверенные среды выполнения, предлагаемые поставщиками общедоступных облаков, использующих авторский код ODP.
• Возможность проверки на устройстве того, что происходит с данными конечного пользователя, если они покидают устройство. ODP предоставляет рабочие нагрузки с открытым исходным кодом и федеративными вычислениями для координации машинного обучения и статистического анализа между устройствами для своих пользователей. Устройство конечного пользователя подтвердит, что такие рабочие нагрузки выполняются в доверенных средах выполнения без изменений.
• Гарантированная техническая конфиденциальность (например, агрегирование, шум, дифференциальная конфиденциальность) выходных данных, выходящих за пределы контролируемой устройством/проверяемой границы.

Следовательно, персонализация будет зависеть от устройства.

Более того, предприятия также требуют мер конфиденциальности, которые платформа должна учитывать. Это влечет за собой хранение необработанных бизнес-данных на соответствующих серверах. Для этого ODP использует следующую модель данных:

1. Каждый источник необработанных данных будет храниться либо на устройстве, либо на стороне сервера, что обеспечивает возможность локального обучения и вывода.
2. Мы предоставим алгоритмы для облегчения принятия решений по нескольким источникам данных, например, фильтрацию между двумя разрозненными местоположениями данных или обучение или вывод по различным источникам.

В этом контексте могут быть бизнес-башня и башня конечного пользователя:

Бизнес-башня содержит данные, сгенерированные предприятием до того, как произойдет персонализация. ODP просит предприятия сохранять право собственности на эту информацию, обеспечивая доступ к ней только авторизованным деловым партнерам.
Башня конечного пользователя состоит из данных, предоставленных конечным пользователем (например, информации об учетной записи и элементов управления), собранных данных, связанных с взаимодействием конечного пользователя со своим устройством, а также производных данных (например, интересов и предпочтений), выведенных бизнес. Выведенные данные не перезаписывают прямые объявления пользователя.

Для сравнения: в облачной инфраструктуре все необработанные данные из башни конечного пользователя передаются на серверы предприятий. И наоборот, в инфраструктуре, ориентированной на устройства, все необработанные данные из башни конечного пользователя остаются в источнике, а коммерческие данные остаются храниться на серверах.

Персонализация на устройстве сочетает в себе лучшее из обоих миров, позволяя обрабатывать только проверенный код с открытым исходным кодом для обработки данных, которые могут иметь какое-либо отношение к конечным пользователям в TEE, используя более частные каналы вывода.

Инклюзивное участие общественности в поиске справедливых решений

ODP стремится обеспечить сбалансированную среду для всех участников разнообразной экосистемы. Мы осознаем сложность этой экосистемы, состоящей из различных игроков, предлагающих различные услуги и продукты.

Чтобы стимулировать инновации, ODP предлагает API, которые могут быть реализованы разработчиками и компаниями, которые они представляют. Персонализация на устройстве облегчает интеграцию этих реализаций при управлении выпусками, мониторинге, инструментах разработчика и инструментах обратной связи. Персонализация на устройстве не создает какой-либо конкретной бизнес-логики ; скорее, он служит катализатором творчества.

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

Утилита разработчика для улучшения пользовательского опыта

При использовании ODP не происходит потери данных о событиях или задержек наблюдения, поскольку все события записываются локально на уровне устройства. Ошибок присоединения нет, все события связаны с конкретным устройством. В результате все наблюдаемые события естественным образом образуют хронологическую последовательность, отражающую взаимодействия пользователя.

Этот упрощенный процесс устраняет необходимость объединения или реорганизации данных, обеспечивая доступность пользовательских данных практически в реальном времени и без потерь. В свою очередь, это может повысить полезность, которую воспринимают конечные пользователи при использовании продуктов и услуг, основанных на данных, что потенциально приведет к более высокому уровню удовлетворенности и более значимому опыту. С помощью ODP компании могут эффективно адаптироваться к потребностям своих пользователей.

Модель конфиденциальности: конфиденциальность через конфиденциальность

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

Модель потребитель-производитель как основа анализа конфиденциальности

Мы будем использовать модель потребитель-производитель для изучения гарантий конфиденциальности через конфиденциальность. Вычисления в этой модели представлены как узлы в направленном ациклическом графе (DAG), который состоит из узлов и подграфов. Каждый вычислительный узел состоит из трех компонентов: потребляемые входные данные, производимые выходные данные и вычисления, сопоставляющие входные данные с выходными.

График, иллюстрирующий модель потребитель-производитель. Этот граф имеет 2 вычислительных узла. Последовательность выполнения: Узел 1 -> Узел 2. Узел 1 выполняется первым. Он потребляет 2 начальных входа: вход 1 и вход 2. Узел 1 производит выход 1. Узел 2 потребляет выход узла 1 и начальный вход: вход 3. Он производит выход 2. Выход 2 также является конечным выходом этого графа.

В этой модели защита конфиденциальности применяется ко всем трем компонентам:

• Конфиденциальность входа . Узлы могут иметь два типа входов. Если входные данные сгенерированы узлом-предшественником, они уже имеют гарантии конфиденциальности вывода этого предшественника. В противном случае входные данные должны очистить политики входа данных с помощью механизма политики .
• Конфиденциальность вывода . Возможно, продукцию придется приватизировать, например, как это предусмотрено Дифференциальной конфиденциальностью (DP).
• Конфиденциальность вычислительной среды . Вычисления должны происходить в надежно изолированной среде, гарантирующей, что никто не имеет доступа к промежуточным состояниям внутри узла. Технологии, которые позволяют это сделать, включают федеративные вычисления (FC), аппаратные доверенные среды выполнения (TEE), безопасные многосторонние вычисления (sMPC), гомоморфное шифрование (HPE) и другие. Стоит отметить, что конфиденциальность посредством конфиденциальности защищает промежуточные состояния, и все выходные данные, выходящие за границу конфиденциальности, по-прежнему должны быть защищены механизмами дифференциальной конфиденциальности. Два обязательных утверждения:
  • Конфиденциальность окружающей среды, гарантирующая, что только заявленные результаты покидают окружающую среду и
  • Обоснованность, позволяющая точно выводить заявления о конфиденциальности выходных данных из заявлений о конфиденциальности входных данных. Рациональность позволяет распространять свойства конфиденциальности по DAG.

Частная система обеспечивает конфиденциальность ввода, конфиденциальность вычислительной среды и конфиденциальность вывода. Однако количество применений механизмов дифференциальной конфиденциальности можно уменьшить, герметизируя больше обработки внутри конфиденциальной вычислительной среды.

Эта модель имеет два основных преимущества. Во-первых, большинство систем, больших и малых, можно представить в виде DAG. Во-вторых, постобработка DP [раздел 2.1] и лемма композиции 2.4 в разделе «Сложность свойств дифференциальной конфиденциальности» предоставляют мощные инструменты для анализа (наихудшего случая) компромисса между конфиденциальностью и точностью для всего графа:

• Постобработка гарантирует, что после того, как какое-то количество будет приватизировано, его нельзя будет «отменить приватизацией», если исходные данные не будут использованы снова. Пока все входные данные узла являются частными, его выходные данные являются частными, независимо от его вычислений.
• Расширенная композиция гарантирует, что если каждая часть графа является DP, то и весь граф также эффективно ограничивает ε и δ конечного результата графа примерно ε√κ соответственно, предполагая, что граф имеет κ единиц, а выход каждой единицы равен (ε , δ)-ДП .

Эти два свойства воплощаются в два принципа проектирования для каждого узла:

• Свойство 1 (из постобработки), если все входные данные узла являются DP, его выходными данными являются DP, вмещающие любую произвольную бизнес-логику, выполняемую в узле, и поддерживающие «секретные соусы» бизнеса.
• Свойство 2 (из расширенной композиции): если входы узла не все являются DP, его выходные данные должны быть совместимы с DP. Если вычислительный узел работает в доверенных средах выполнения и выполняет рабочие нагрузки и конфигурации с открытым исходным кодом, предоставляемые персонализацией на устройстве, то возможны более жесткие границы DP. В противном случае при персонализации на устройстве может потребоваться использовать границы DP наихудшего случая. Из-за ограниченности ресурсов на начальном этапе приоритет будет отдаваться надежным средам выполнения, предлагаемым поставщиком общедоступных облаков.

Конфиденциальность вычислительной среды и точность вывода

Отныне персонализация на устройстве будет сосредоточена на повышении безопасности конфиденциальных вычислительных сред и обеспечении недоступности промежуточных состояний. Этот процесс безопасности, известный как запечатывание, будет применяться на уровне подграфа, позволяя одновременно сделать несколько узлов совместимыми с DP. Это означает, что свойства 1 и свойства 2 , упомянутые ранее, применяются на уровне подграфа.

Разбиение графа с 7 узлами на 2 подграфа и 1 узел. В этом примере каждый подграф имеет 3 узла. Если выполнение каждого подграфа скрыто от злоумышленников, только Выход 3 и Выход 6, результаты подграфов, должны быть обработаны DP.
Конечно, окончательный вывод графика, Выход 7, обрабатывается DP для каждой композиции. Это означает, что всего для этого графика будет 2 DP; по сравнению с 3-мя общими (локальными) DP, если герметизация не использовалась.

По сути, за счет обеспечения безопасности вычислительной среды и исключения для злоумышленников возможности доступа к входам и промежуточным состояниям графа или подграфа это позволяет реализовать центральный DP (то есть выходные данные изолированной среды соответствуют DP), что может повысить точность по сравнению с с локальным DP (т. е. отдельные входы совместимы с DP). Этот принцип лежит в основе рассмотрения FC, TEE, sMPC и HPE как технологий обеспечения конфиденциальности. См. главу 10 «Сложность дифференциальной конфиденциальности» .

Хорошим практическим примером является обучение модели и вывод. В приведенном ниже обсуждении предполагается, что (1) обучающая совокупность и совокупность вывода перекрываются, и (2) как функции, так и метки представляют собой частные данные пользователя. Мы можем применить DP ко всем входам:

Локальный DP: частные объекты объекта 1 + частные торговые марки -> частная модель. ( свойство 1 ) Частная модель + частные функции -> частный вывод.
Персонализация на устройстве может применять локальный DP к пользовательским меткам и функциям перед отправкой их на серверы. Этот подход не накладывает никаких требований к среде выполнения сервера или его бизнес-логике.

Центральный DP: ( свойство 2 ) в качестве альтернативы вы можете применять DP во время обучения модели, сохраняя при этом точность функций и меток. В этом сценарии владелец модели может передать модель для вывода в другое место. Однако для обеспечения конфиденциальности во время вывода функции, вводимые в частную модель, также должны быть совместимыми с DP для каждого свойства 1 .

Вы можете еще больше повысить точность вывода, запечатлевая обучение и вывод. Это позволяет вводить точные характеристики в частную модель.

Сделав еще один шаг вперед, вы также можете закрепить окончательный вывод. В этом случае владелец модели также не имеет доступа к выводу.
Это текущий дизайн персонализации на устройстве.

Подтверждаемо конфиденциально

Персонализация на устройстве стремится обеспечить проверяемую конфиденциальность. Основное внимание уделяется проверке того, что происходит на пользовательских устройствах. ODP разработает код, который обрабатывает данные, покидающие устройства конечных пользователей, и будет использовать архитектуру процедур удаленной аттестации (RATS) NIST RFC 9334 для подтверждения того, что такой код работает без изменений на совместимом с Консорциумом конфиденциальных вычислений сервере, лишенном привилегий администратора экземпляра. Эти коды будут иметь открытый исходный код и будут доступны для прозрачной проверки в целях укрепления доверия. Такие меры могут дать людям уверенность в том, что их данные защищены, а предприятия могут создать себе репутацию, основанную на прочном фундаменте обеспечения конфиденциальности.

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

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

Мы просим конструктивного сотрудничества с экспертами по конфиденциальности, органами власти, отраслями и частными лицами, чтобы помочь нам постоянно улучшать дизайн и реализацию.

На графике ниже показан путь кода для агрегирования между устройствами и шума в соответствии с дифференциальной конфиденциальностью.

Структура службы федеративных вычислений, которая обрабатывает как федеративное обучение, так и федеративную аналитику. Незашифрованные, незашумленные данные обрабатываются только на устройстве (красная линия). Результаты обработки загружаются в зашифрованном виде как при передаче, так и при хранении ( линии бирюзового цвета ). Только созданная персонализация на устройстве, рабочая нагрузка с открытым исходным кодом для агрегирования между устройствами и шумовой обработки имеет доступ к незашифрованным необработанным результатам устройства после успешной аттестации многосторонними координаторами. После правильного применения шума в соответствии с механизмами дифференциальной конфиденциальности внутри доверенной среды выполнения все нисходящие потоки данных могут быть незашифрованы ( оранжевые линии ).

Дизайн высокого уровня

Как можно реализовать конфиденциальность через конфиденциальность? На высоком уровне механизм политики, созданный ODP и работающий в закрытой среде, служит основным компонентом, контролирующим каждый узел/подграф, одновременно отслеживая статус DP их входов и выходов:

• С точки зрения механизма политики устройства и серверы обрабатываются одинаково. Устройства и серверы, на которых работает один и тот же механизм политики, считаются логически идентичными, если их механизмы политики прошли взаимную аттестацию.
• На устройствах изоляция достигается с помощью изолированных процессов AOSP (или pKVM в долгосрочной перспективе, когда доступность станет высокой). На серверах изоляция опирается на «доверенную сторону», которая представляет собой либо TEE плюс другие предпочтительные технические решения по герметизации, либо договорное соглашение, либо и то, и другое.

Другими словами, все закрытые среды, в которых устанавливается и работает механизм политики платформы, считаются частью нашей базы доверенных вычислений (TCB). Данные могут распространяться без дополнительного шума с помощью TCB. DP необходимо применять, когда данные покидают TCB.

Высокоуровневый дизайн персонализации на устройстве эффективно объединяет два важных элемента:

• Архитектура парных процессов для выполнения бизнес-логики
• Политики и механизм политик для управления входящими, исходящими и разрешенными операциями данных.

Этот целостный дизайн предлагает предприятиям равные условия, где они могут запускать свой собственный код в надежной среде выполнения и получать доступ к пользовательским данным, прошедшим соответствующие проверки политики.

В следующих разделах будут подробно рассмотрены эти два ключевых аспекта.

Архитектура парных процессов для выполнения бизнес-логики

Персонализация на устройстве представляет архитектуру парных процессов в AOSP для повышения конфиденциальности пользователей и безопасности данных во время выполнения бизнес-логики. Эта архитектура состоит из:

• Управляющий процесс. Этот процесс создает изолированные процессы и управляет ими, гарантируя, что они остаются изолированными на уровне процесса с доступом, ограниченным API-интерфейсами из разрешенного списка, без разрешений на сеть или диск. ManagingProcess обрабатывает сбор всех бизнес-данных, всех данных конечного пользователя, а политика очищает их для бизнес-кода, отправляя их в изолированные процессы для выполнения. Кроме того, он опосредует взаимодействие между Изолированныепроцессами и другими процессами, такими как system_server.

• ИзолированныйПроцесс. Обозначенный как изолированный ( в манифесте isolatedprocess=true ), этот процесс получает бизнес-данные, данные конечных пользователей, очищенные политикой, и бизнес-код от ManagingProcess. Они позволяют бизнес-коду работать со своими данными и данными конечных пользователей, очищенными политикой. Изолированный процесс взаимодействует исключительно с ManagingProcess как для входа, так и для выхода, без каких-либо дополнительных разрешений.

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

На следующем рисунке показана эта парная архитектура процессов.

Субъект, создающий «приложение для адоптера», может быть, а может и не быть тем же самым субъектом, что и тот, кто является автором «apk для адоптера» на графике. Объект, создающий «APK-адаптер», тот же, что и тот, кто владеет «Локальным магазином-адаптером» на графике.

Политики и механизмы политик для операций с данными

Персонализация на устройстве обеспечивает уровень соблюдения политики между платформой и бизнес-логикой. Цель состоит в том, чтобы предоставить набор инструментов, которые преобразуют контроль конечных пользователей и бизнеса в централизованные и действенные политические решения. Эти политики затем комплексно и надежно применяются ко всем потокам и предприятиям.

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

Эта архитектура применения политик включает три типа рабочих процессов, которые можно использовать:

• Локально инициируемые автономные рабочие процессы с использованием связи Trusted Execution Environment (TEE):
  • Потоки загрузки данных: доверенные загрузки
  • Потоки загрузки данных: доверенные транзакции
• Онлайн-рабочие процессы, инициированные на местном уровне:
  • Потоки обслуживания в реальном времени
  • Потоки вывода
• Локально инициируемые автономные рабочие процессы:
  • Потоки оптимизации: обучение модели на устройстве, реализованное посредством федеративного обучения (FL).
  • Потоки отчетности: агрегирование между устройствами, реализованное через Federated Analytics (FA).

На следующем рисунке показана архитектура с точки зрения политик и механизмов политики.

Механизм политик находится в центре проекта. Примеры (не исчерпывающие):

• Скачать: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• Порция: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• Оптимизация: 2 (предоставляет план тренировок) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• Отчетность: 3 (предоставляет план агрегирования) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

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

Многоуровневые поверхности API

Персонализация на устройстве предоставляет многоуровневую архитектуру API для заинтересованных компаний. Верхний уровень состоит из приложений, созданных для конкретных случаев использования. Потенциальные компании могут подключить свои данные к этим приложениям, известным как API верхнего уровня. API верхнего уровня построены на API среднего уровня.

Со временем мы планируем добавить больше API верхнего уровня. Когда API верхнего уровня недоступен для конкретного варианта использования или когда существующие API верхнего уровня недостаточно гибки, компании могут напрямую внедрить API среднего уровня, которые обеспечивают мощность и гибкость с помощью примитивов программирования.

Заключение

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

Мы хотели бы взаимодействовать с заинтересованными сторонами, такими как эксперты по конфиденциальности, аналитики данных и потенциальные конечные пользователи, чтобы гарантировать, что ODP отвечает их потребностям и решает их проблемы.