Сравнение браузеров с оружием
Установка нового браузера не заканчивается его запуском. При первом старте браузеры проходят фазу донастройки — что-то докачивают, конфигурируют и, конечно, рапортуют. Если посмотреть на соответствующие сетевые запросы, можно многое узнать о браузере – в частности, какой информацией о пользователе и устройстве он поделится с неустановленной группой лиц.
В этой статье мы оценивали поведение пяти браузеров: Brave, Chrome, Firefox, Edge и Opera. Все исследования проводились на десктопе под управлением Windows 10 (версия 20H2, билд 19042.804) с подтвержденной учёткой Microsoft.
TLDR: меньше всего запросов делает Brave
В 2020 году профессор Дуглас Лейт из Тринити-колледжа (Дублинский университет) провел исследование браузеров и разделил их по тому, насколько успешно они хранят конфиденциальность пользователя. В первую группу вошел Brave как самый приватный браузер, во вторую — Chrome, Firefox и Safari, в третью — Edge и Yandex, которые защищали данные пользователя хуже всего. В нашем исследовании не участвовали Safari и Yandex, а в исследовании профессора Лейта – Opera, но в целом мы получили похожие результаты.
У Brave сетевых запросов меньше всего, также меньше всего хостов, к которым он обращался. Все соединения были с бэкендами Brave. Множество запросов отправил Firefox, хотя большинство из них были связаны с безопасностью. Запросы отправлялись на узлы Mozilla. Edge был наиболее активен в отношении рекламы, он начинал собирать соответствующие данные раньше всего. Кроме того, браузер от Microsoft блестяще продемонстрировал, как много информации о пользователе можно получить через учетную запись Windows.
Методология
Перед каждым анализом мы зачищали папки %appdata% и %localappdata% в Windows, т. е. информацию, относящуюся к профилю пользователя. Все браузеры были обновлены до последней версии. Чтобы отслеживать запросы, мы использовали программу Telerik Fiddler версии 5.0.20204.45441. Она мониторила запросы в течение 10 минут с момента первого запуска каждого браузера.
В течение первых пяти минут пользователь ничего не делал в браузере, а затем открывал новую вкладку. Любые запросы — на сбор каких-либо данных, синхронизацию или персонализацию — отклонялись. После открытия новой вкладки пользователь ничего не делал в течение еще четырех минут. На девятой минуте в адресной строке печаталось слово «brave» (как пример потенциального поискового запроса), а затем удалялось посимвольно. Потом пользователь вставлял в адресную строку слово «password» целиком и таким же образом это слово удалял. Это делалось для того, чтобы отследить, передает ли браузер данные пользователя, включая случайно вставленную информацию, каким-либо удаленным службам.
После десятиминутной первичной сессии пользователь закрывал браузер, а потом спустя некоторое время открывал его снова на две минуты. Повторный запуск был нам нужен для того, чтобы сравнить, как ведет себя браузер в первый и последующие разы, и выявить возможную разницу.
Подробные результаты по каждому браузеру
Brave версии 1.21.73
Запросы Brave распределились по следующим категориям.
Скачивание «вариаций» браузера. Это анонимные A/B-тесты, которые Brave проводит для улучшения своей работы.
Скачивание Sponsored Images для региона пользователя — это рекламные NTP. Пользовательские данные при этом никуда не передаются.
Анонимная телеметрия и отчетность — браузер отправляет дату установки, платформу, и несколько P3A-метрик.
После первоначальной настройки Brave также обновил некоторые компоненты.
При повторном запуске было сделано 24 запроса, они касались обновлений компонентов браузера, заголовков, A/B-тестов и списков Safebrowsing.
Chrome версии 89.0.4389.72
Одним из первых запросов Chrome была попытка ассоциировать пользователя и существующий аккаунт Google. Затем браузер запросил возможные вариации — Chrome также тестирует новые функции таким образом.
Далее браузер обновил компоненты и скачал набор расширений — например, ярлыки Google Docs, Google Drive и YouTube. Запросил списки Safebrowsing и загрузил список проверенных плагинов.
Всего Chrome сделал 91 сетевой запрос к 5 доменам верхнего уровня. Все домены принадлежали Google. Хотя попытка ассоциировать пользователя и Google-аккаунт была, никакой персональной информации в итоге Chrome не передал. Как и Brave, Chrome собирал общую информацию об устройстве, с которого пользователь зашел в браузер.
Firefox версии 86
Затем Firefox установил WebSocket-соединение с сервером автопушей. Это соединение веб-приложения используют, чтобы иметь возможность отправлять пользователям уведомления, даже если они в данный момент не работают в браузере. Во время соединения сервер отправил браузеру идентификатор регистрации нового пользователя пушей Push User Agent Registration ID (UAID).
При запуске в Firefox было открыто две вкладки: одна — обычная новая вкладка, вторая — «Уведомление о конфиденциальности для веб-браузера Firefox». Поскольку для второй нужно было подключение к интернету, отправлялись дополнительные запросы. Их было 22.
Всего Firefox отправил 2799 запросов к восьми доменам верхнего уровня. Большинство доменов принадлежали или поддерживались Mozilla. В конце первой сессии браузер сделал запрос к терминалу классификации клиентов, позже такой запрос был замечен повторно.
Что касается телеметрии, диагностические данные обычно содержали информацию о событии, браузере, а также идентификаторы клиента и сессии в браузере. Кроме того, несколько запросов были отправлены через отдельный процесс pingsender.exe. Этот процесс отправлял запросы и после того, как пользователь закрыл браузер, причем информации пересылалось довольно много: идентификатор клиента, данные об устройстве, о браузере, включая список дополнений, плагинов и даже данные о внешнем оформлении браузера, о тестах, в которых был задействован браузер, о количестве мониторов, об установленном антивирусном ПО и так далее. Интересно, что мы нашли ключ, который, судя по названию, должен был отвечать за передачу телеметрических данных: environment.settings.telemetryEnabled. В нем было выставлено false, но по факту данные пересылались, и в огромном объеме.
Последний запрос перед закрытием включал в себя множество разнообразных метрик. Хотя большинство из них к персональным данным отношения не имело, все же мы почувствовали себя неуютно, настолько подробной была телеметрия.
После ввода или вставки символов (не менее двух) Firefox отправлял запросы с этими символами в Google. Отметим здесь, что профессор Лейт не обнаружил подобных запросов, но он вставлял в адресную строку URL – возможно, Firefox отправляет данные в поиск, только если они не представляют собой URL.
Edge версии 88.0.705.81
Первым делом Edge попытался идентифицировать пользователя. Надо сказать, что возможностей для этого у браузера от Microsoft куда больше, чем у прочих, и пользуется он ими весьма агрессивно, получая данные из аккаунта Windows. Конечно, как и другие браузеры, Edge запрашивал списки безопасных плагинов и потенциально вредоносных URL, но это была лишь часть запросов. Еще часть была связана с рекламой и трекерами — таких запросов было намного больше, чем у других браузеров, также больше было и запросов к посторонним бэкендам.
Всего Edge отправил 367 запросов к 13 доменам верхнего уровня. Большинство доменов принадлежало Microsoft. В этих запросах присутствовала и потенциально конфиденциальная информация, причем защищена она была слабо.
Интересно, что Edge был единственным из браузеров, который отправлял специальные запросы, связанные с редиректами и онлайн-рекламой по технологии real-time bidding. Также Edge транслировал информацию ScorecardResearch, сервису, который специализируется на сборе данных о поведении пользователей в интернете. Этот сервис есть во многих блок-листах.
Забавно, что одним из первых запросов был запрос на демонстрацию рекламы со словами «Сделан с учетом защиты вашей конфиденциальности». В самом запросе при этом было достаточно много информации о пользователе.
При повторном запуске Edge сделал еще 70 запросов, аналогичных тем, что были отправлены до этого.
Opera версии 88.0.4324.182
Символы при вводе или вставки Opera сразу транслировал в Google для поиска в реальном времени. В этих запросах содержался идентификатор, сообщавший Google, что поиск идет с Opera.
При повторном запуске Opera сделал всего 16 запросов – для обновления расширений, загрузки набора идентификаторов функций, а также получения свежей информации о курсе валюты и криптовалюты.
Подозреваем, что одно только упоминание о браузерных войнах 2000-го года вызовет у олдов горечь и раздражение (да, скорее всего, войны были в 1995-м, нам просто нравится округлять числа). В те дни веб-сайты представляли собой страницы, украшенные недружелюбными к пользователю логотипами «Compatible with Netscape» («Совместимый с Netscape») и анимированными гифками вроде «Under Construction» («В разработке»), загружать которые модем на 56 кбит/с мог вечность.
Сайты работали на аляповатых плагинах, а Microsoft нарушала бытующие в то время стандарты направо и налево, чтобы заполучить долю на рынке. Чудесные деньки, если под словом «чудесный» понимать «отвратительный».
Бороздить просторы Интернета в 2005-м было не очень весело
Всё изменилось благодаря той же корпорации Microsoft, точнее Биллу Гейтсу, который уже тогда осознал значимость браузеров для будущего и всё равно умудрился уступить лидирующую позицию на рынке какому-то отважному неудачнику. Этого неудачника звали Google
Зачем нам вообще нужно раздумывать над выбором веб-браузера? Что сделало его таким производительным? Как он устроен, и есть ли между веб-обозревателями хоть какая-то значительная разница? Для ответа на эти и другие вопросы нужно разобраться в принципе работы веб-браузера, протестировать несколько из них и спросить эксперта о том, стоит ли продолжать использовать обозреватель, навязанный нам корпорациями. Подсказка: нет.
Лидерство на ПК всегда принадлежало одному браузеру
Тут нужно отметить, что Всемирная паутина представляет собой набор ненадёжных, нагромождённых друг на друга стандартов, распространяемых посредством сети на международном уровне. Любое вмешательство корпорации или государства может привести к нарушению её работы. Взять хотя бы DDoS-aтаки или тот факт, что отдельные страны перенаправляют трафик, нарушая тем самым протокол граничного шлюза. Это означает, что если владельцы известного браузера решат подорвать открытые стандарты, то они вполне могут сделать это – и, можно сказать наверняка, делали это.
Внутри браузера
Базовые составляющие браузера мало изменились со времени его появления в середине 1990-х годов. Сейчас веб-обозреватели способны поддерживать обработку языка JavaScript и сохранять локальные данные. На диаграмме ниже показано, как построен браузер.
Пользовательский интерфейс. Наверное, вы считаете это само собой разумеющимся, но всевозможные интерактивные моргалки и дуделки в браузере, а также его дополнительные функции вроде закладок, истории, хранения паролей и др. – всё это часть интерфейса.
Браузерный движок. Наименее понятная по сравнению с остальными составляющая браузера. Включает в себя элементы пользовательского интерфейса, рендеринга и движков Java с привязкой к хранилищу данных.
Хранилище данных. Хотя браузеры начинались с куки, для локальных приложений современные обозреватели чаще используют локальные хранилища. Веб-хранилище предоставляет базовые локальные переменные, в то время как Web SQL предлагает настоящую локальную базу данных. Индексная база данных API является компромиссным решением между двумя вариантами.
Движок JavaScript. Язык веб-программирования JavaScript включает интерактивное и динамическое содержимое веб-страниц. Поскольку он нуждается в интерпретации, современные браузеры используют динамический компилятор, который исполняет код по требованию в максимально сжатые сроки. Все популярные веб-обозреватели работают на собственном движке и имеют разную производительность.
Механизм визуализации. Ключевой компонент любого современного браузера. Большая часть статьи будет посвящена изучению механизма его работы, для чего нам понадобится ещё одна блок-диаграмма (см. изображение ниже). Фактически здесь всего два парсера: один отвечает за обработку кода HTML и объектных моделей документов (DOM), другой—за анализ данных в каскадной таблице стилей. На основе этого создаётся дерево рендера.
Всё то же самое, но другое
Здесь мы не будем много распространяться про сеть, пользовательский интерфейс, движок браузера и хранилище данных. И не потому, что они не важны (это абсолютно не так), но потому что по большей части эти составляющие открыто дублируют друг друга на разных уровнях.
Мы остановимся на механизме визуализации, потому что он большой и имеет сложную структуру. Но сначала ответим на вопрос: почему столько шума из-за простого кода HTML? Как было упомянуто ранее, интернет и онлайн-приложения строятся на стандартах; в случае HTML это Консорциум Всемирной паутины, известный также под именем W3C, руководящие принципы которого определяют, что должен делать каждый тег HTML.
Проблема заключается в том, что из-за большого количества обстоятельств эти руководящие принципы и правила можно интерпретировать по-разному, и то, что будет допустимо для одного браузера, для другого таковым являться не будет. К тому же глупые людишки придумали ещё один набор тегов.
Поскольку механизм визуализации отвечает за интерпретирование и отображение контента, а движки у браузеров отличаются, то может оказаться, что содержимое интернет-страниц может отображаться по-разному. Обычно различия минимальны, но иногда это может привести к позиционным изменениям или же в крайнем случае к невозможности отобразить всю страницу.
Как ни странно, ошибки в процессе рендеринга появляются от того, что движки не справляются с ситуациями сбоя, потому как подобное поведение не стандартизировано. Случается, что редакторы HTML и разработчики могут выдать всякого рода дикий неподдерживаемый код, который бедный браузер должен интерпретировать максимально точно.
Составляющие браузеров
Подноготная механизма визуализации
Сетевой движок выполняет свою работу, извлекает содержимое веб-страницы и адресует его механизму визуализации. На этом этапе есть два варианта обработки содержимого. Мы посмотрим, как движки WebKit и Blink справляются с этим процессом, но знайте, что у Gecko, на котором построен Firefox (и его производные) иной порядок обработки.
Все вышеупомянутые движки, однако, делят всё содержимое веб-сайта на HTML и CSS данные. И те и другие данные обрабатываются отдельно своим собственным парсером. А что потом? В общих чертах парсер принимает этот входящий двоичный поток и переводит данные в дерево узлов; структуру такого дерева определяет синтаксис (правила) языка (HTML или CSS).
Если вам знакомы теги HTML, то имеет смысл сказать, что парсинг включает в себя две составляющие:
лексический анализатор. Делит входящие данные на известные токены (теги) в соответствии с существующими правилами;
синтаксический анализатор. Создаёт структуру документа, построенную по определённым грамматическим правилам. Токен запрашивается у лексического анализатора. Если тэг подпадает под известное правило, то добавляется к дереву, в противном случае он сохраняется и запрашивается другой токен. Если для сохранённого токена не находится совпадений, то синтаксический анализатор выдаёт ошибку.
HTML интересен в языковом плане. Его грамматика нечётко определена, потому что должна быть обратно совместимой и ошибкоустойчивой. В то же время она должна уметь обрабатывать динамический код (посредством скриптов), который может обратно добавлять токены, пока он обрабатывается синтаксическим анализатором. Это означает, что его синтаксический анализатор не может регулярно использовать нисходящий или восходящий подход для анализа. В языковом мире это называют контекстно-зависимой грамматикой.
Edge мёртв. Да здравствует Edge (построен на движке Blink).
Чтобы вы имели представление, с чем имеет дело парсер, давайте взглянем мельком на тяжёлые будни лексического анализатора кода HTML. Сначала он по умолчанию включает режим «data state» (данные). Когда он обнаруживает символ <, то включает режим «tag open state» («открытый тег»). Идущие далее символы a–z создают токен «start tag» (открывающий тег») и состояние «tag name state» («название тега»). Это продолжается до тех пор, пока не появится закрывающий тег и не включится режим «data state». Если же после символа < обнаруживается символ /,то создаётся «end tag token» («закрывающий тег»), и так до тех пор, пока не будет найден символ > .
Эти токены передаются в синтаксический анализатор кода HTML и впоследствии встраиваются в структуру документа, всякий раз когда находится подходящий тег HTML, от <HTML> к <BODY> , от <BODY> к </BODY> , и от </BODY> к </HTML>.
Что кажется ещё более интересным, так это то, какие танцы с бубном приходится выплясывать браузерам, когда они натыкаются на не просто плохо отформатированные документы HTML, но на откровенную ересь. Синтаксический анализатор браузера должен быть ошибкоустойчивым, иначе веб-страницы просто «споткнутся» и не смогут загрузиться. Как минимум браузер должен знать, что делать, если какой-либо тег закрыт некорректно, что случается повсеместно. Кроме того, нередки случаи, когда анализатор натыкается на неизвестный, старый или неподдерживаемый тэг.
И хотя официальной инструкции по исправлению кривого кода HTML не существует, в коде движка WebKit от Apple имеются занимательные комментарии относительно подхода к различным классическим ошибкам, в том числе к незакрытым или неверно закрытым тэгам, неправильно размещённым таблицам, тэгам с большими вложениями или ошибочно закрытым тегам <body>.
В итоге обработанный парсером код HTML становится объектной моделью документа, так называемой моделью DOM. Отдельно от HTML также анализируются элементы CSS (каскадные таблицы стилей) и на основе этого создаётся объектная модель CSS. В отличие от HTML грамматика CSS не имеет контекстуальных ограничений, отчего глупым людишкам становится трудно сломать её. Синтаксический анализатор должен обработать каскадные таблицы стилей, чтобы определить стиль каждого элемента.
Ранее мы упоминали про динамическое содержимое и скрипты. И хотя сценарии не сильно меняются, браузеры должны обрабатывать их синхронно –парсинг не возобновится до тех пор, пока каждый скрипт не будет выполнен. Если требуются сетевые ресурсы, то их надо загрузить, а все остальные процессы должны быть остановлены до тех пор, пока это не будет сделано. Авторы сценариев также могут добавить атрибут <defer>, чтобы отложить выполнение сценария до тех пор, пока документ не будет проанализирован.
Однако WebKit и Gecko используют спекулятивный парсинг, чтобы заранее считывать и загружать любые сетевые ресурсы, например, скрипты, изображения и CSS, облегчая тем самым загрузку страницы. Это хорошее решение, поскольку сценарии, которые запрашивают нагружающие сеть таблицы стилей, вызывают проблемы, если к ним (к таблицам стилей) нельзя получить доступ
Дерево рендера
И тут начинается самое интересное. Из модели DOM мы знаем, где должны располагаться объекты на странице, созданной из кода HTML. Из объектной модели CSS мы знаем также, как элементы должны быть оформлены стилями. Каждый визуализируемый объект – это, по сути, прямоугольная область, имеющая определённый размер, позицию и стиль. Большинство объектов построено из множества отрисованных прямоугольников; важно помнить, что дерево рендера построено из узла DOM.
Также нужно заметить, что процесс совмещения стиля с объектом отображения не так прост, как кажется. Он зависит от унаследованных правил. А на саму обработку браузером унаследованных правил стиля и поиск соответствий с объектами может уйти не один обход дерева.
Теперь можно начать вёрстку страницы. Она подразумевает вычислительный процесс, в ходе которого те самые прямоугольники совмещаются с назначенным стилем. HTML уже сконструирован, и потому вёрстку можно сделать в один заход. Переверстать страницу можно полностью (например, при кардинальной смене стиля или размера окна) или же её отдельные «дочерние» объекты. В заключение отметим, что дерево рендера можно нарисовать и обработать элементами пользовательского интерфейса браузера, поскольку последний зависим от ОС.
Отстаивать свободу и приватность в Интернете - нелёгкий труд
Наращивание возможностей
Раннее мы упоминали о том, что во всех современных браузерах имеется движок JavaScript с JIT-компилятором. Динамический компилятор нужен для максимального увеличения скорости работы программ. Все браузеры используют свой движок JavaScript, и именно благодаря ему вы можете «программировать паутину» и создавать комплексные интерактивные онлайн-приложения. И так как JavaScript морально устарел (он появился ещё 1990-х, и в то время ещё никто не знал его прямого предназначения), встречайте – Web Assembly (Wasm).
Этот бинарный формат стартовал в 2015-м, а к 2017-му поддерживался почти во всех браузерах и стал стандартизированным концу 2019-го. Он поддерживает низкоуровневый кроссплатформенный язык и нативно запускается на самом устройстве через браузер. Wasm может компилировать C/C++ и Rust и запускается в той же "песочнице", что и JavaScript, и потому может быть использован его библиотеками для безграничного ускорения.
В итоге мы имеем совместимую с HTML5 веб-страницу со всеми моргалками и дуделками от Web 2.0 на любой вкус и цвет. IT-корпорации (Google, Apple, Microsoft), видимо, остановили свой выбор на браузерах с движками WebKit/Blink, которые имеют хорошую совместимость и кучу производных. Искренне надеемся, что Mozilla отстоит независимость Firefox, но сейчас она действует в невыгодных для себя условиях. Похоже, браузерные войны возвращаются.
Архив новостей по дате:
| « Ноябрь 2021 » | ||||||
|---|---|---|---|---|---|---|
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
Рекомендуем:
Статистика:
RTX 3090 В ДЕЛЕ Обзор, сравнение с RTX 3080 и 2080 Super
Спецназ ФСБ удивился арсеналу бандитов, когда вскрыли тайники с оружием
Снайперы с оружием и в полной боевой экипировке заняли позиции. Протесты в США
Владелец ресторана «Пушкин» в Сан-Диего рассказал, как с оружием оборонялся от протестующих
Самый мощный игровой ПК с 3х ядерным процессором AMD. Сравнение процессоров 2 ядра, 3 ядра и 4 ядра.
i9 ЗА 80.000 СЛИВАЕТ AMD ЗА 30! СМОТРЕТЬ БЕСПЛАТНО БЕЗ СМС И РЕГИСТРАЦИИ!
ЗИЛ-157 против ГАЗ-66 на бездорожье. Сравнение легенд!
Тест и сравнение GTX 1650 с GTX 1660, 1060 и 1050ti! Что может самый дешёвый Turing?
GTX 1660 (не Ti) - ТЕСТИРОВАНИЕ В РАЗНЫХ СБОРКАХ И СРАВНЕНИЕ С GTX 1060!
Сравнение производительности intel i5 8400 c i7 4790k - оценены процессоры в 179$
Читайте также: