Современный веб стремительно развивается, и одной из ключевых задач становится обеспечение безопасного и удобного входа пользователей на сайты и веб-приложения. В этом контексте API статуса входа (Login Status API) играет важнейшую роль, предоставляя возможность веб-сайтам получать информацию о состоянии аутентификации пользователя и адаптировать пользовательский интерфейс. Недавние обсуждения между крупнейшими игроками отрасли, такими как команды WebKit, Chrome и PrivacyCG, раскрывают перспективы развития этого механизма, его влияние на конфиденциальность и интеграцию с новыми протоколами федеративной идентификации, такими как FedCM (Federated Credential Management). Сегодня мы подробно рассмотрим, какие изменения ожидают API статуса входа, в чем ключевые вызовы и чем это грозит как для пользователей, так и для разработчиков. Одной из основных тем, затронутых на конференции TPAC, стал разлад мнений по поводу текущей реализации API статуса входа в браузере Chrome.
Команда WebKit выразила обеспокоенность тем, что API был внедрен в такой форме, которая не учитывает всех нюансов безопасности и конфиденциальности. Этот момент заставил участников сообщества внимательно пересмотреть концепцию и заложенные в нее принципы уровня доверия к данным, получаемым от API. Суть состоит в том, что информация о том, вошел пользователь в систему или нет, может иметь разный уровень достоверности – от «низкого доверия», когда данные могут быть упрощенными и не гарантируют точности, до «высокого доверия», предоставляющего надежное подтверждение входа. В Chrome API используется как сигнал с низким уровнем доверия, который прежде всего необходим для управления отображением интерфейса FedCM, позволяющего пользователям безопасно и удобно вводить учетные данные посредством федеративной идентификации. Эта реализация носит более декларативный характер и учитывает существенное влияние на приватность пользователя, минимизируя риски раскрытия данных о входе третьим сторонам.
Однако, в противоположность этому, некоторые разработчики и представители Privacy Community Group, к которым относится @johnwilander, настаивают на создании более «высокого доверия» API статуса входа. Их идеей является получение точной и достоверной информации о том, что пользователь аутентифицирован на сайте, с последующей возможностью использовать эту информацию для смягчения ограничений по отслеживанию пользователей и улучшения взаимодействия с сервисом. Создание такой высокоточной функции значительно расширило бы возможности разработки защищенных и одновременно приватных сервисов. Общим консенсусом отрасли стало понимание, что нерационально поддерживать два полностью раздельных API, поскольку базовая функциональность почти идентична — определить, вошел ли пользователь в систему или нет. Вместо этого предложено объединить эти подходы, создавая многоуровневую систему с контролируемым уровнем доверия, где простой API может работать для базовых сценариев, а более продвинутый — включать строгие проверки и интегрироваться с комплексными системами безопасности и конфиденциальности.
Перспективы развития API статуса входа находятся в центре внимания FedID Working Group. С одной стороны, ведется активная работа над улучшением текущей модели, оптимизацией архитектуры и созданием обратной совместимости с существующими реализациями, ориентированными на низкий уровень доверия. С другой стороны в Privacy Community Group продолжается активное обсуждение концепции «высокого доверия», где внимание уделяется тому, какие именно технические механизмы позволят гарантировать правильность и безопасность аутентификации, сохраняя при этом максимальную защиту пользовательских данных. Открытые обсуждения показывают, что обе группы стремятся к достижению интероперабельности — возможности использовать API в разных браузерах и платформах без потери качества и безопасности. Важный момент — это совместная работа по выработке единого стандарта, который поможет избежать фрагментации и ускорит адаптацию новых решений разработчиками.
Среди новых идей, обсуждаемых в сообществе, особое внимание уделяется потенциальному использованию более надежного API статуса входа для смягчения проблем с механизмами блокировки отслеживания (bounce tracking mitigation). Такая интеграция могла бы помочь веб-сайтам эффективнее работать с ограничениями, сохраняя при этом баланс между пользовательским удобством и конфиденциальностью. При этом дискуссии также затрагивают важный аспект пользовательского восприятия. Названия API и их классификация по уровню доверия должны быть интуитивными и понятными для разработчиков, чтобы не возникало ложных предположений о степени защищенности информации. Например, идея переименования существующего репозитория privacycg/is-logged-in на нечто вроде privacycg/high-trust-login-signals вызвала споры.
Некоторые считают, что подразумевать низкое доверие как дефолтную опцию неправильно, и что доверие должно быть по умолчанию высоким, чтобы избежать неверных ожиданий. С точки зрения разработчиков и бизнес-заказчиков, будущее API статуса входа сулит значительное улучшение гибкости и безопасности. Возможность получать достоверные данные о состоянии входа без ущерба для конфиденциальности создаст предпосылки для более персонализированных, но в то же время этичных и безопасных веб-сред. Более того, стандартизация и расширение возможностей интеграции с федеративными системами идентификации, такими как FedCM, поспособствует созданию единого цифрового идентификатора, который станет фундаментом для будущих сервисов. Нельзя упускать из виду и важность коллаборации между крупными браузерами и сообществами разработчиков.
