Pull to refresh
40.58
Brave
Browse privately. Search privately. Ditch Big Tech

Ставим Google Sign-In под контроль в браузере Brave

Level of difficultyMedium
Reading time6 min
Views1.7K
Original author: Peter Snyder

В версии 1.51 Brave усилит защиту пользователей, распространив систему браузерных пермиссий на устаревший метод авторизации Google Sign-In, который использует сторонние куки или другие неконфиденциальные технологии, позволяющие пользователям логиниться на сайты через учётку Гугла. Эта технология заменит ныне существующую в Brave систему глобального разрешения или запрета для устаревшей авторизации Google Sign-In. Эта технология будет доступна для десктопов и Андроида и является ещё одним примером того, как мы встраиваем лучшую в своей нише защиту конфиденциальности в веб-API, которые были разработаны без внимания к приватности пользователей.

Google Sign-In: за и против

Google, как и многие другие популярные сайты с аккаунтами, позволяет пользователям использовать свои учётные записи для того, чтобы логиниться на других сайтах. Эта технология единого входа (single-sign on, SSO) имеет как положительные, так и отрицательные стороны с точки зрения конфиденциальности.

У SSO достаточно много полезных сторон. Во-первых, такие системы очень удобны для пользователей, так как позволяют им полностью обойти подчас утомительный процесс создания аккаунтов на различных сайтах. Что важнее, SSO в целом (и «вход с помощью Google»‎ в особенности) может повысить безопасность пользователей, так как им не приходится доверять сотням сайтов, у которых может быть самое разное отношение к безопасности, свои логины и пароли, и вместо этого воспользоваться топовыми технологиями безопасности от Google даже на сайтах, которые ему не принадлежат. Google — это двухфакторная аутентификация, продвинутые механизмы защиты аккаунта и в целом одна из лучших на рынке команд безопасности.

Однако же, системы SSO могут и вредить пользователям. К примеру,  централизованная природа SSO подразумевает, что любая проблема может иметь последствия по всей сети: недавнее исследование показало, что многие подобные системы не в состоянии корректно обработать аннулирование аккаунта, могут приводить к неверным конфигурациям интеграции сайтов, и вообще подвержены различным серьёзным проблемам с безопасностью и конфиденциальностью.

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

«Войти с помощью Google»‎ в Brave: вчера и сегодня

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

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

Что мы делали с «войти с помощью Google»‎ раньше

Раньше мы обеспечивали совместимость с SSO от гугла с помощью единой глобальной настройки по адресу brave://settings/socialBlocking. Если эта опция была выключена, Brave блокировал сторонние куки для SSO гугла так же, как Brave блокирует сторонние куки для всех других запросов в сети. Если же она была включена, Brave делал единичное исключение из правил по отношению к сторонним кукам и открывал гугловской SSO доступ к кукам от гугла. Это исключение влияло только на адреса, используемые для гугловской авторизации (вида https://accounts.google.com/o/oauth2/auth/* или https://[*.]firebaseapp.com/__/auth/*), и не позволяло другим системам Google (таким, как Google Analytics, Google Tag Manager, или Doubleclick) получать доступ к сторонним кукам. Тем не менее, включение этой опции означало, что Brave для десктопов и Андроида отправлял сторонние куки гуглу в этом конкретном случае.

Что мы делаем с «войти с помощью Google»‎ теперь

Начиная с версии 1.51, Brave убирает это исключение и глобальный переключатель и начинает использовать систему на основе разрешений. Это позволит пользователям контролировать, когда сторонние куки отсылаются в Google (и отсылаются ли они вообще), сохраняя при этом возможность пользоваться удобствами SSO от гугла. Если сайт уже использует новую технологию Google Identity Services, которой не требуются сторонние куки для авторизации, никаких изменений не происходит.

Новое разрешение для входа с помощью SSO от Google в Brave продолжает нашу работу с разрешениями в Chromium, включающую в себя возможность контролировать, как долго разрешение будет валидно, и секционировать разрешения во внешних фреймах.

А что у других браузеров?

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

Chrome

Chrome не нуждается в обеспечении совместимости с основанными на сторонних куках системах SSO, так как Chrome в принципе никак не ограничивает сторонние куки. В Chrome провайдеры SSO используют ровно те же технологии, которые используют сторонние трекеры и рекламодатели для того, чтобы отслеживать ваши действия в сети. Естественно, такой подход фундаментально несовместим с принципом Brave «конфиденциальность превыше всего»‎.  

Edge, Firefox и Safari

Другие браузеры накладывают определённые ограничения на сторонние куки. Edge ограничивает сторонние куки, если они фигурируют в списке известных трекеров Disconnect, а Firefox и Safari секционируют сторонние куки на всех сайтах. Эти браузеры поддерживают совместимость с входом через Google, используя систему под названием API доступа к хранилищам с добавлением различных эвристик. Storage access API был изначально разработан для Safari, и открывал сторонним фреймам доступ к неограниченным сторонним куки только после получения соответствующего разрешения от пользователя.

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

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

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

Смотрим в будущее с оптимизмом 

К счастью, многие браузеры согласны с тем, что узкоспецифичные API необходимы для защиты пользовательской конфиденциальности там, где сайтам необходимо вступать в коммуникацию между собой. Мы в Brave с оптимизмом смотрим на такие разработки, как Federated Credential Management (FedCM) API, который позволит сайтам запрашивать конкретную информацию у других сайтов для таких целей, как вход по Google SSO, не прибегая к широкомасштабному и неограниченному доступу к сторонним данным, который позволяет API доступа к хранилищам. Мы всё ещё находимся в процессе детального изучения предложений FedCM, но в целом мы поддерживаем их. Можно сказать, что новый подход Brave к поддержке авторизации с помощью Google на основе разрешения — это наш сегодняшний вклад в достижение гарантий конфиденциальности FedCM в будущем. Эта наша новая функция прекрасно иллюстрирует наш подход к конфиденциальности в сети: предоставлять самую сильную возможную на сегодняшний день защиту конфиденциальности пользовательских данных, параллельно работая с органами стандартизации для того, чтобы развитие Сети в будущем шло по пути всё большего соблюдения прав и безопасности пользователей.

Tags:
Hubs:
+4
Comments2

Articles

Information

Website
brave.com
Registered
Founded
Employees
101–200 employees
Location
США