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

Разное время жизни пермиссий

Начиная с версии 1.25 браузера Brave (как для настольных ПК, так и для Андроида) появилось больше возможностей контролировать то, как долго сайтам будут доступны мощные, но антиконфиденциальные функции, такие как геолокация, веб-камеры и микрофоны.

Ранее мы использовали обычный способ Chrome для работы с правами доступа, который ограничивал пользователей в их выборе вариантами «навсегда» или «никогда». К примеру, нельзя было сказать «этот сайт может использовать мою камеру, пока я нахожусь на этой странице, но необходимо спросить меня снова в следующий раз». Опции, ограниченные выбором «всё или ничего», поощряют чрезмерную передачу данных, выгодную бигтеху, которому интересно сохранить максимум информации. Так, Apple обнаружила, что когда у пользователей есть возможность ограничить срок доступа к данным геолокации, пользователи стали предоставлять на 68% меньше таких данных, что является существенным улучшением с точки зрения защиты их конфиденциальности.

Пользователи Brave теперь могут выдавать сайтам временные права доступа для более строгого контроля за конфиденциальностью. Стандартные примеры таких возможностей браузера —  это веб-камеры, микрофоны, геолокация и датчики движения. Это похоже на средства защиты в других браузерах, но в браузере Brave это, естественно, работает существенно лучше. Так, Safari и Firefox позволяют выдать сайтам постоянный доступ, доступ для определённой страницы или же полностью отказать в доступе, а Brave теперь позволяет пользователям предоставлять сайтам доступ к подобным возможностям на определённый срок времени. В Chrome тестируется что-то подобное, но только для данных геолокации.

Дополнительная защита от переадресующего трекинга

Всё больше браузеров защищают пользователей от самых популярных и очевидных форм трекина в сети, таких как сторонние куки, сторонний localStorage и фингерпринтинг. В ответ трекеры переходят на более изощрённые методы слежки, такие как «трекинг первого уровня», или же методы провязывания вашей идентичности и действий на одном сайте с вашими действиями и идентичностью на других сайтах.

Наиболее популярная форма такого трекинга — это так называемый переадресовывающий трекинг (bounce tracking), при котором сайт добавляет уникальное айди к гиперссылкам перед тем, как вы покидаете этот сайт. Например, трекинговые скрипты Facebook добавляют идентификаторы fbclid к урлам перед тем, как вы покидаете сайт, чтобы скрипты Facebook на сайте назначения могли считать этот идентификатор из адреса URL, что позволит Facebook выстроить цепочку посещений и скормить её хтоническим алгоритмам машинного обучения.

Общепринятое название для такой формы слежки —  это bounce tracking, переадресовывающий трекинг, или, говоря более обобщённо, трекинг, основывающийся на веб-навигации. Его идея позволяет обходить оборонительные механизмы браузеров, такие как изоляция или разделение стораджей сайтов, посредством передачи идентификаторов через адреса или редиректы.

На сегодня браузеры плохо защищают от такой формы трекинга. Что-то умеет система Safari Intelligent Tracking Protection 2.0, а Brave защищает пользователей от известных переадресующих трекеров, удаляя параметры трекинга из адресов URL. Эти системы полезны, но неполны и не защищают пользователей от некоторых форм переадресующего трекинга. Мы улучшаем свою защиту от подобных тёмных дел путём уведомления (при включении агрессивного режима) пользователей о том, что они собираются перейти по адресу, который похож на переадресующий трекер. Когда 1) включена агрессивная защита от трекинга и 2) происходит переход по адресу, который списки фильтрации обозначают как подозрительный, наш браузер покажет большой алярм и заблокирует переход (при желании его можно будет продолжить). Мы предполагаем, что в таком виде защита окажется востребованной не для всех, поэтому она работает только в режиме агрессивной блокировки трекеров. Однако, поскольку наша цель — бескомпромиссная защита приватности для всей аудитории, мы работаем над соединением дебаунсера и эфемерных хранилищ, чтобы включить такой механизм по умолчанию.

Brave определяет, является ли адрес переадресующим трекером, точно так же, как великолепный проект uBlock Origin, и применяет подход, который в uBlock называется «строгим блокированием». В общих чертах, предупреждающая страница будет показана, если выполняются все три условия:

• Пользователь выставил щиты как «реклама и трекеры блокируются (агрессивно)»;

• Навигационный запрос верхнего уровня был бы заблокирован правилом фильтрационного списка (например, EasyList, EasyPrivacy и uBlock Origin);

• Не существует специального исключения для этого адреса.

Продление жизни эфемерных хранилищ

Ранее мы анонсировали новую форму разделения localStorage под названием «сторонние эфемерные хранилища», которая предотвращает межсайтовый и межсессионный трекинг, не нарушая работу сайтов. Мы улучшили эту функциональность без потери качества, позволяя лучше работать сайтам, которые рассчитывают на длительную жизнь сторонних хранилищ. Основной сценарий — это починка систем однократного входа (single sign-on), которые часто ломались об первоначальную версию наших эфемерных стораджей. 

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

Огорчительно, но эфемерные сторонние хранилища нередко ломали SSO по причинам, описанным здесь. Теперь Brave предотвращает поломки подобного рода, так как в течение короткого времени браузер будет держать данные разделённых сторонних хранилищ (в настоящий момент эта задержка составляет 30 секунд).

Так, например, если ранее example.org включал в себя фрейм third-party.org, хранилище для third-party.org закрывалось в тот момент, когда не оставалось ни одной открытой вкладки example.org. Теперь браузер выжидает полминуты после того, как последняя вкладка example.org была закрыта, до того как очистить хранилище для third-party.org. Если же внезапно была открыта другая вкладка example.org в течение этого тридцатисекундного окна, таймер сбрасывается.

Мы экспериментируем с этим 30-секундным окном, чтобы найти оптимальное время, но к настоящему моменту тридцать секунд выглядит оптимальным значением, которое позволяет важным сценариям работать, а следящим скриптам не позволяет ничего. 

Дополнительные меры по защите от фингерпринтинга

Кроме того, мы выпустили дополнительные меры защиты от фингерпринтинга, чтобы всегда оставаться на шаг впереди трекеров. Вот некоторые из них:

• Защита от фингерпринтинга в тёмном режиме — в агрессивном режиме щитов;

• Улучшения для защиты от фингерпринтинга WebGL — в агрессивном режиме щитов.