TL;DR
С самых первых релизов Brave блокировал все сторонние хранилища (куки, localStorage, indexedDB). Такая блокировка защищает наших пользователей от самых распространённых форм трекинга, но может ломать сайты. Сегодня мы поговорим об «эфемерных хранилищах», нашей стратегии работы со сторонними хранилищами в Brave, которая улучшает веб-совместимость, сохраняя при этом этот же уровень защиты конфиденциальности пользовательских данных.
Что было раньше?
В основном трекинг в сети основывается на использовании сторонних (3rd-party) кук и других данных, то есть на сохранении и передаче уникальных идентификаторов на сайты, которые вы не собирались посещать. Такой трекинг и ваша идентификация, как правило, происходят без вашего ведома и согласия, и конфиденциальные браузеры постоянно борются с таким трекингом.
Ранее Brave агрессивно блокировал все сторонние хранилища по умолчанию (в частности, не сохранял 3rd-party куки). Это даёт серьёзную защиту, но может сломать сайты, которые рассчитывают на доступность внешних хранилищ. И, к сожалению, большинство сайтов созданы под Chrome и рассчитывают на практически ни в чём не ограниченные внешние хранилища. При этом Chrome является самым популярным, и самым небезопасным с этой точки зрения браузером.
Из-за этого раньше в Brave сайты часто ломались, а пользователям приходилось выбирать между функционирующим браузером и нетронутыми личными данными. Мы боролись с этим по-разному, и скриптами, и точечными исключениями. В основном, конечно, работало, но решение не было идеальным. В результате мы разработали принципиально новую систему «эфемерных» хранилищ, которая защищает от трекинга, но при этом практически не влияет на функционирование сайтов.
Как работают «эфемерные хранилища»?
Эфемерные хранилища по сути представляют собой объединение нескольких решений.
Во-первых, мы никогда не отправляем куки на запросы подресурсов от третьей стороны. Мы будем отправлять куки для запросов подресурсов с основного документа, или в других локальных (с того же сайта) вложенных документах, но мы не будем отправлять куки на запросы подресурсов из различных источников, даже если они вызываются с основного сайта.
Во-вторых, сторонние фреймы получат секционированное хранилище для некоторых API хранилищ DOM. JavaScript, выполняющийся в стороннем фрейме, может использовать document.cookie, localStorage и sessionStorage API, но значения, которые он увидит, секционированы в рамках основного документа. Это означает, что код, исполняющийся в social.org <iframe> на example.org, будет видеть хранилище, отличающееся от того, что social.org <iframe> увидит на other.org.
В-третьих, хранилища доступны для всех для оригинальных страниц одного и того же сайта. Если пользователь открыл два таба одного и того же сайта (одинаковый eTLD+1), третьи стороны на этих сайтах будут видеть одно и то же хранилище, и смогут использовать его, чтобы общаться между собой. К примеру, вы открыли два таба одного сайта, first.example.org и second.example.org, и оба включают в себя iframe ютуба. В этом случае оба фрейма ютуба будут видеть одно и то же хранилище. Однако же, фрейм ютуба на different.org увидит другое хранилище, а таб, загружающий youtube.com напрямую, увидит вообще третье.
В-четвёртых, внешние хранилища очищаются, когда закрывается последний оригинальный документ. Внешние документы получают различные хранилища для каждого сайта верхнего уровня. Если хотя бы один документ верхнего уровня сайта открыт, хранилище будет существовать, а сторонние фреймы будут видеть одно и то же хранилище для любых новых документов верхнего уровня для этого же сайта верхнего уровня. Но когда больше не будет существовать ни одного документа верхнего уровня для сайта, все внешние хранилища для этого сайта будут очищены. Если вы вновь посетите этот сайт позднее, все включённые внешние фреймы на этом сайте будут видеть новые пустые хранилища.
Наконец, хранилища очищаются при перезапуске браузера. Когда вы выходите из Brave, все хранилища очищаются вне зависимости от того, перезапускаете ли вы браузер полностью или вы включили опцию запуска браузера с «ранее открытыми вкладками». Логика здесь схожа с той, по которой мы меняем затравку для рандомизации цифрового отпечатка вашего браузера. Это делается для предотвращения появления неожиданно долгоживущих сессионных значений, о которых говорил Эрик Лоуренс из команды Edge.
А что с другими браузерами?
Во многом наши эфемерные хранилища схожи с тем, как Safari работает с внешними хранилищами. Мы хотели бы отметить роль Safari в популяризации идеи секционирования внешних хранилищ для защиты от трекинга. Safari, как и Tor Browser Bundle, который давно уже секционирует сторонние хранилища в рамках системы First-Party Isolation, предоставляют разделённые хранилища для внешних данных в зависимости от того, на каком сайте они находятся.
Тем не менее, наш подход достаточно сильно отличается от Safari. Safari очищает внешние хранилища при закрытии браузера, мы же очищаем эти хранилища при закрытии сайта. У каждого подхода свои плюсы и минусы, но наш подход защищает от некоторых случаев провязывания аккаунтов пользователя третьими сторонами. Тем не менее, снимаем шляпу перед Safari и TBB за то, что они во многом выступили пионерами подхода секционирования. Firefox тоже работает с секционированием схожим образом, но его секционирование сохраняется навсегда (в Brave — пока вы взаимодействуете с сайтом, в Safari — до закрытия браузера). Несмотря на то, что наш подход во многом агрессивнее других браузеров, мы хотели бы подчеркнуть их, и в особенности Firefox, работу над секционированием других элементов сайтов (кэш HTTP и т.д.). Команда Chromium также работает в этом направлении, и, хотя эта работа и не всегда видна глазу конечных пользователей, она критически важна для безопасности браузеров, основанных на Chromium, таких как Chrome, Brave, и Edge.