Сторонним вход воспрещён
С давних времён и до наших дней отслеживание сайтами действий пользователя, по большому счёту, основано на эксплуатации одного из самых старых пороков интернета сторонних (по-иностранному, third-party) данных: кук, записей в localStorage и т. д. Разумеется, в древние времена мало кто мог предположить, что браузерными куками будет вскормлен бессердечный спрут индустрии слежки и рекламных сетей, а конфиденциальность абонентов сети будет пожертвована во славу Больших Данных, принадлежащих Большим Корпорациям.
Как уже было сказано, простая блокировка сторонних кук спорное решение, поскольку мешает нормальной работе множества обычных сайтов. Причём нередко ломаются важные сценарии: вход на сайт или процесс оплаты. Дело в том, что до недавних пор основные браузеры позволяли этим хранилищам работать без каких-то ограничений соответственно и сайты не ждут подвоха или недоступности сторонних данных. Такое отсутствие ограничений позволяет всем разновидностям аналитических скриптов, следящих пикселей и рекламных сетей выдавать вашему браузеру уникальную куку и вести журнал её жизнедеятельности (в хромоподобных браузерах куки можно увидеть на странице chrome://settings/siteData)
Пример
Cайты shop.com, school.edu и bank.ru добавляют на свои страницы следящий пиксель <img src=https://trackingcorp.com/track.gif>. При первом запросе за этим пикселем, сайт trackingcorp.com сохранит в браузере куку с уникальным номером. При последующих запросах с сайтов магазина, школы и банка, сервер trackingcorp будет записывать историю визитов для этого номера и продавать её всем желающим за пригоршню долларов.
До недавнего времени мы балансировали между сохранением приватности и обеспечением корректности работы сайтов путём всевозможного колдунства, монтажа костылей и инжекта скриптов. Некоторые сайты приходилось просто добавлять в список исключений, иначе они отказывались работать. Это более или менее помогало оборонять наших пользователей, но стратегически это глубоко ущербный подход, который не решает проблему в целом.
Усилиями наших лучших умов (и с помощью наблюдений за другими браузерами на рынке) было придумано эфемерное хранилище сторонних данных новая конструкция, которая не кормит трекеры, рекламные сети и Корпорации Добра данными пользователей, и при этом сильно реже ломает посещаемые сайты. На момент публикации мы включили эфемерное хранилище в бете и раскатываем на пользователей релизного канала.
В чем сила
Эфемерное веб-хранилище по сути представляет собой комбинацию решений по хранению данных, каждое из которых мы опишем подробнее, с оговоркой, что по результатам работы некоторые пункты могут быть пересмотрены.
-
Никаких кук по запросам за ресурсами (картинки, скрипты и т. д.) на сторонних доменах. Brave шлет куки по запросам на поддомены текущего сайта (например, sub.habr.com), но если это cross-origin запрос (например, за evilcorp.com/tracking_pixel.gif), ни одна кука не будет выдана.
-
Секционированное (то есть, раздельное) хранилище для сторонних фреймов. Скрипты, которые исполняются в таких фреймах, могут обращаться к кукам документа, localStorage или sessionStorage API (остальные API пока что, как и раньше, полностью отключены для сторонних запросов), однако фактически им будут предоставлены разные хранилища. Например, если фрейм trackingcorp.com встроен в сайты example.org и other.org, то будут созданы два хранилища: одно для trackingcorp.com + example.org, другое для trackingcorp.com + other.org. Таким образом, исключается возможность сохранения в браузере уникальной куки (или записи в localStorage) имени trackingcorp.com.
-
На одном и том же сайте все сущности используют одно хранилище. Например, у вас открыты две вкладки сайта first.example.org и second.example.org, на каждой вкладке есть фрейм с видео с YouTube. Оба фрейма будут обращаться к одному хранилищу. А вот если тот же YouTube-фрейм встроен в other.org или на одной из вкладок открыто то же самое видео на сайте YouTube хранилище example.org ни тот, ни другой фрейм не увидят, ибо не положено.
-
Все сторонние хранилища для first-party сайта очищаются, как только закрывается последняя вкладка с этим сайтом. Соответственно, сторонние фреймы, о которых мы говорили в примерах выше, теряют данные в этих хранилищах. Пока открыта хоть одна страница для данного сайта, сторонние хранилища для фреймов существуют. Если закрыть последнюю и открыть заново появятся новые, пустые хранилища.
-
После закрытия браузера очищаются все сегменты всех сторонних хранилищ. Даже при включенном восстановлении вкладок, после рестарта, хранилища будут новыми. Этот подход совпадает с алгоритмом рандомизации браузерных отпечатков в Brave, о которым мы расскажем в следующих сериях.
Пока что мы умеем только секционировать куки и localStorage, на подходе indexedDB и другие API например, предстоит интегрироваться с Storage Access API (которое в Chromium внедряла команда Edge).
Что у других браузеров?
Пионеры секционирования сторонних хранилищ это Safari и Tor Browser, примером которых мы и вдохновились. В отличие от Safari, Brave очищает сторонние хранилища при закрытии сайта, а не всего браузера, что существенно усиливает защиту многие пользователи крайне редко перезапускают браузер.
Секционированное хранилище (в отличие от нас не эфемерное, а персистентное) для обороны от суперкук сделали в Firefox. Chromium же в этой области догоняющий на сегодня в нём секционируется только кэш, и ведётся работа по другим компонентам. C 2019 года Firefox блокирует сторонние куки, принадлежащие доменам известных трекеров. А совсем недавно авторы Chromium объявили о курсе на полный запрет сторонних кук этот процесс растянется надолго, но одной исторической ошибкой в интернете станет меньше.
