Блог · 13 марта 2026 г.

Оптимизация iOS SDK для ITP и предотвращения отслеживания в Safari (RU)

Интеллектуальное предотвращение отслеживания (ITP) Safari и другие функции конфиденциальности постоянно развиваются, создавая проблемы для iOS SDK, использующих традиционные методы отслеживания.

Автор: Didit13 марта 2026 г.Обновлено 21 мая 2026 г.

Используйте контекст первого лицаITP Safari жестко ограничивает сторонние файлы cookie. Разработайте ваш iOS SDK так, чтобы он работал в контексте первого лица, используя серверные решения или прямую интеграцию, когда это возможно.

Приоритизируйте идентификаторы, сохраняющие конфиденциальностьОткажитесь от постоянных, межсайтовых идентификаторов. Сосредоточьтесь на эфемерных или одобренных пользователем идентификаторах, соблюдая настройки конфиденциальности пользователя и фреймворк App Tracking Transparency от Apple.

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

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

Интеллектуальное предотвращение отслеживания (ITP) Safari фундаментально изменило ландшафт веб-отслеживания, особенно для разработчиков, полагающихся на сторонние файлы cookie и постоянные идентификаторы. Для iOS SDK это представляет уникальный набор проблем, особенно при интеграции с веб-представлениями или обработке междоменной связи. Постоянная приверженность Apple конфиденциальности пользователей, подкрепленная такими функциями, как App Tracking Transparency (ATT) и более строгая политика в отношении сбора данных, означает, что разработчики SDK должны активно адаптировать свои стратегии, чтобы обеспечить функциональность, поддерживать целостность данных и уважать согласие пользователя.

Этот пост в блоге углубляется в тонкости ITP и аналогичных механизмов конфиденциальности в Safari на iOS, предлагая практические советы и примеры для оптимизации вашего SDK. Наша цель — помочь вам создавать отказоустойчивые, конфиденциальные SDK, которые не только надежно функционируют, но и укрепляют доверие пользователей в мире, все более ориентированном на конфиденциальность.

Понимание ITP Safari и его влияния на iOS SDK

Intelligent Tracking Prevention (ITP) — это набор технологий повышения конфиденциальности, встроенных в Safari (и WebKit). Его основная функция — ограничение межсайтового отслеживания путем ограничения использования файлов cookie и других форм данных веб-сайтов третьими сторонами. На протяжении многих лет ITP развивался через несколько итераций, каждая из которых вводила более строгие меры контроля:

Блокировка сторонних файлов cookie: Самый значительный аспект. ITP агрессивно разделяет или блокирует сторонние файлы cookie, что затрудняет отслеживание пользователей рекламодателями и поставщиками аналитики на разных веб-сайтах.
Storage Access API: Представлен как способ с сохранением конфиденциальности для встроенного контента запрашивать доступ к своему хранилищу первого лица, когда пользователь взаимодействует с ним.
Защита от украшения ссылок: ITP также может удалять параметры отслеживания из URL-адресов, чтобы предотвратить отслеживание через украшение ссылок.
Политика реферера: Safari часто отправляет более строгую политику реферера (например, strict-origin-when-cross-origin), ограничивая объем информации, передаваемой сторонним сайтам.
Предотвращение отслеживания эфемерных переходов: Выявляет и смягчает методы, при которых трекеры перенаправляют пользователей через свой сайт для установки файлов cookie первого лица.

Для iOS SDK, особенно тех, которые взаимодействуют с веб-контентом (например, встроенные в приложение браузеры, потоки аутентификации, платежные шлюзы или встроенная аналитика), влияние ITP может быть глубоким. Если ваш SDK полагается на установку или чтение файлов cookie из стороннего домена в WKWebView, или если он ожидает передачи определенной информации о реферере, ITP может сломать эти механизмы, что приведет к:

Неудачные процессы аутентификации или оплаты.
Неточные данные атрибуции или аналитики.
Нарушение пользовательского опыта из-за отсутствия состояния или информации о сессии.

Стратегии разработки iOS SDK, устойчивого к ITP

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

1. Приоритизация контекста первого лица и серверных решений

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

Практический пример: Серверное отслеживание для аналитики

Вместо того чтобы полагаться на сторонний аналитический скрипт, встроенный в ваш WKWebView, который пытается установить свои собственные файлы cookie, рассмотрите серверный подход:

SDK собирает данные: Ваше iOS-приложение (или веб-контент в вашем WKWebView) собирает соответствующие данные о взаимодействии пользователя (например, просмотренный продукт, нажатая кнопка).
Отправка данных в ваш бэкэнд: Эти данные отправляются непосредственно на ваш собственный сервер бэкэнда.
Бэкэнд пересылает данные поставщику аналитики: Затем ваш бэкэнд пересылает эти данные в API вашего поставщика аналитики. Поскольку эта связь происходит между серверами, она обходит ограничения ITP на клиентские файлы cookie.

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

2. Использование Storage Access API для межсайтовых нужд

Когда вам абсолютно необходим доступ к межсайтовым файлам cookie во встроенном WKWebView (например, для единого входа с поставщиком идентификации), Storage Access API является одобренным, сохраняющим конфиденциальность методом. Этот API позволяет стороннему контенту запрашивать явное разрешение у пользователя на доступ к его хранилищу первого лица.

Практический пример: Бесшовный SSO в `WKWebView`

Представьте, что ваш SDK встраивает WKWebView для потока аутентификации, которому необходимо получить доступ к файлам cookie вашего поставщика идентификации (IDP) для достижения SSO. Без Storage Access API Safari заблокирует эти файлы cookie.

На стороне клиента (в вашем встроенном веб-контенте):

document.requestStorageAccess().then(function() {
    // Доступ к хранилищу предоставлен, теперь вы можете выполнять запросы, использующие файлы cookie
    // например, загрузить iframe SSO или сделать XHR-запрос к IDP
}).catch(function() {
    // Доступ к хранилищу отклонен или требуется взаимодействие с пользователем
    // Обработайте изящно, возможно, вернитесь к полному перенаправлению для входа
});

iOS SDK (WKUIDelegate и WKNavigationDelegate):

Вам нужно будет обработать запрос пользователя, который Safari представляет. Метод WKUIDelegate webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (или аналогичные запросы разрешений) может быть вызван, но для доступа к хранилищу запрос обычно обрабатывается самим Safari. Убедитесь, что ваша WKWebViewConfiguration настроена правильно, особенно websiteDataStore.

3. Принятие идентификаторов, сохраняющих конфиденциальность, и согласия пользователя

С помощью App Tracking Transparency (ATT) Apple требует явного согласия пользователя для отслеживания в приложениях и на веб-сайтах, принадлежащих другим компаниям. Ваш SDK должен это уважать. Откажитесь от использования постоянных идентификаторов устройства для целей отслеживания без согласия.

Практический пример: Обработка ATT и IDFA

Если ваш SDK ранее полагался на Identifier for Advertisers (IDFA) для атрибуции или таргетинга:

Запрос авторизации ATT: Используйте AppTrackingTransparency.framework для запроса авторизации пользователя перед доступом к IDFA.
Условное использование IDFA: Извлекайте и используйте IDFA только в том случае, если пользователь дает разрешение.
Альтернативные идентификаторы: Если отказано, полагайтесь на контекстно-специфичные, эфемерные идентификаторы (например, идентификатор сессии) или сгенерированные сервером, непостоянные идентификаторы, которые не используются для межсайтового отслеживания.

Пример Swift:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // Использовать IDFA для отслеживания с согласия
            case .denied, .notDetermined, .restricted:
                print("Авторизация ATT отклонена или не определена.")
                // Полагаться на другие методы, сохраняющие конфиденциальность
            @unknown default:
                break
            }
        }
    } else {
        // Запасной вариант для версий iOS до 14
        // Проверить, включено ли отслеживание через ASIdentifierManager.shared().isAdvertisingTrackingEnabled
    }
}

Как помогает Didit

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

Интеграция первого лица: SDK и API Didit разработаны для прямой интеграции первого лица в ваше приложение, гарантируя, что процессы проверки личности происходят в контексте вашего приложения, в значительной степени обходя проблемы ITP, связанные с межсайтовым отслеживанием.
Серверная обработка: Многие надежные возможности Didit, такие как проверка AML и анализ сигналов мошенничества, работают по схеме сервер-сервер. Это означает, что обработка конфиденциальных данных и проверки личности происходят безопасно на нашем бэкэнде, устраняя уязвимости отслеживания на стороне клиента.
Эфемерная биометрия: Didit обрабатывает биометрические данные в памяти и удаляет их, возвращая вашему приложению только логические результаты. Этот подход «конфиденциальность по умолчанию» означает, что мы не храним постоянные биометрические идентификаторы для отслеживания, что идеально соответствует целям ITP.
Безопасные потоки аутентификации: Наши методы аутентификации, включая биометрическую повторную аутентификацию, созданы для обеспечения безопасности и конфиденциальности, используя механизмы «вызов-ответ», которые не зависят от межсайтовых файлов cookie для управления состоянием.
Соответствие требованиям и доверие: Будучи совместимой с SOC 2 Type II, ISO 27001 и GDPR, Didit построена на основе конфиденциальности и безопасности данных, что естественным образом делает нашу платформу устойчивой к изменениям в технологиях предотвращения отслеживания.

Готовы начать?

Адаптация вашего iOS SDK для Safari ITP и более широкого ландшафта конфиденциальности — это не просто соблюдение требований; это создание доверия у ваших пользователей и обеспечение долговечности вашего продукта. Применяя контексты первого лица, используя соответствующие API, такие как Storage Access, отдавая приоритет согласию пользователя и оставаясь в курсе меняющейся политики Apple, вы можете создать надежный и уважающий конфиденциальность SDK.

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