Mozilla

Обрабатываем данные на стороне клиента с помощью WebAssembly

28.09.2020 14:11:21 |

Автор: admin

WebAssembly (сокр. WASM) технология запуска предварительно скомпилированного бинарного кода в браузере на стороне клиента. Впервые была представлена в 2015 году и на текущий момент поддерживается большинством современных браузеров.

Один из распространенный сценариев использования предварительная обработка данных на стороне клиента перед отправкой файлов на сервер. В этой статье разберемся как это делается.

Перед началом

Про архитектуру WebAssembly и общие шаги допольно подробно написано здесь и тут. Мы же пройдемся только по основным фактам.

Работа с WebAssembly начинается с предварительной сборки артефактов, необходимых для запуска скомпилированного кода на стороне клиента. Их два: собственно сам бинарный WASM файл и JavaScript прослойка, через которую можно вызывать экспортированные в него методы.

Пример простейшего кода на C++ для компиляции

#include <algorithm>extern "C" {int calculate_gcd(int a, int b) {  while (a != 0 && b != 0) {    a %= b;    std::swap(a, b);  }  return a + b;}}

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

em++ main.cpp --std=c++17 -o gcd.html \    -s EXPORTED_FUNCTIONS='["_calculate_gcd"]' \    -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap"]'

Указанием в качестве объекта *.html файла подсказывает компилятору, что нужно создать также простую html-разметку с js консолью. Теперь если запустить сервер на полученных файлах, увидим эту консоль с возможностью запуска _calculate_gcd:

Обработка данных

Разберем ее на простом примере lz4-компрессии с помощью библиотеки, написанной на C++. Замечу, что на этом множество поддерживаемых языков не заканчивается.

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

Весь код целиком можно найти тут.

С++ часть

Используем уже готовую реализацию lz4. Тогда main файл будет выглядеть весьма лаконично:

#include "lz4.h"extern "C" {uint32_t compress_data(uint32_t* data, uint32_t data_size, uint32_t* result) {  uint32_t result_size = LZ4_compress(        (const char *)(data), (char*)(result), data_size);  return result_size;}uint32_t decompress_data(uint32_t* data, uint32_t data_size, uint32_t* result, uint32_t max_output_size) {  uint32_t result_size = LZ4_uncompress_unknownOutputSize(        (const char *)(data), (char*)(result), data_size, max_output_size);  return result_size;}}

Как можно видеть, в нем просто объявлены внешние (используя ключевое слово extern) функции, внутри вызывающие соответствующие методы из библиотеки с lz4.

Вообще говоря, в нашем случае этот файл бесполезен: можно сразу использовать нативный интерфейс из lz4.h. Однако в более сложных проектах (например, объединяющих функционал разных библиотек), удобно иметь такую общую точку входа с перечислением всех используемых функций.

Далее компилируем код используя уже упомянутый компилятор Emscripten:

em++ main.cpp lz4.c -o wasm_compressor.js \    -s EXPORTED_FUNCTIONS='["_compress_data","_decompress_data"]' \    -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap"]' \    -s WASM=1 -s ALLOW_MEMORY_GROWTH=1

Размер полученных артефактов настораживает:

$ du -hs wasm_compressor.*112K    wasm_compressor.js108K    wasm_compressor.wasm

Если открыть JS файл-прослойку, можно увидеть примерно следующее:

В ней много лишнего: от комментариев до сервисных функций, большая часть которых не используется. Ситуацию можно исправить добавлением флага -O2, в Emscripten компиляторе он включает также оптимизацию js кода.

После этого js код выглядит более приятно:

Клиентский код

Нужно как-то вызвать обработчик на стороне клиента. Первым делом загрузим файл, предоставленный пользователем, через FileReader, хранить сырые данные будем в примитиве Uint8Array:

var rawData = new Uint8Array(fileReader.result);

Далее нужно передать загруженные данные в виртуальную машину. Для этого сначала аллоцируем нужное количество байт методом _malloc, затем скопируем туда JS массив методом set. Для удобства выделим эту логику в функцию arrayToWasmPtr(array):

function arrayToWasmPtr(array) {  var ptr = Module._malloc(array.length);  Module.HEAP8.set(array, ptr);  return ptr;}

После загрузки данных в память виртуальной машины, нужно каким-то образом вызвать функцию из обработки. Но как эту функцию найти? Нам поможет метод cwrap первым аргументом в нем указывается название искомой функции, вторым возвращаемый тип, третьим список с входными аргументами.

compressDataFunction = Module.cwrap('compress_data', 'number', ['number', 'number', 'number']);

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

function wasmPtrToArray(ptr, length) {  var array = new Int8Array(length);  array.set(Module.HEAP8.subarray(ptr, ptr + length));  return array;}

Полный скрипт обработки входящих файлов лежит тут. HTML-разметка, содержащая форму загрузки файла и подгрузку wasm артефактов здесь.

Итог

Поиграться с прототипом можно здесь.

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

Подробнее..

Категории: Блог компании ruvds.com , Javascript , Браузеры , Web-разработка , Webassembly , Mozilla , Asmjs , Wasi

Mozilla пользователя можно идентифицировать по посещению предпочитаемых сайтов с точностью в 99

02.09.2020 20:13:34 |

Автор: admin

Сотрудники компании Mozilla изучили возможность идентификации пользователей на основании журнала посещений различных сайтов. Журнал могут видеть посторонние лица или же разные сервисы и сайты. В ходе исследования представители Mozilla изучили профили примерно 52 000 пользователей браузера Firefox, которые согласились принять участие в проекте, установив расширение OpenWPM для Firefox.

Данные собирались с 16 июля по 13 августа 2019 года. Разработчикам удалось получить информацию о более чем 35 миллионах посещенных страниц и 660 тысяч доменов. В среднем каждый участник исследования просматривал за день 8 доменов.

Исследование состояло из двух этапов. В ходе первого сотрудники Mozilla собирали статистику посещения доменов, а в ходе второго пытались идентифицировать пользователей по полученным ранее данным. Временной интервал между двумя этапами 7 дней. На втором этапе при выборке в 50 и более посещенных сайтов удалось идентифицировать 50% пользователей. Когда выборку увеличили до 150 и более доменов, удалось идентифицировать 80% пользователей.

Как оказалось, уникальность полученных профилей истории посещений сайтов составляет 99%.

Авторы проекта дополнительно изучили 10 000 сайтов на предмет наличия инструментов для идентификации пользователей. На 9 823 сайтах были обнаружены средства идентификации пользователей от Google, на 7 348 от Facebook, на 5 500 от Verizon. Эти инструменты дают возможность владельцам популярных ресурсов идентифицировать пользователей с высокой вероятностью.

Исследователи отметили, что сейчас появились новые способы идентификации пользователей. Например, оценка кэширования настроек HSTS и анализ состояния CSS-свойства visited. Также в ряде случаев при помощи перебора в коде на JavaScript популярных доменов по оценке времени доступа к ресурсам можно было узнать, посещал ли пользователь искомый сайт. Тем не менее, самым популярным средством идентификации посетителей до сих пор остаются куки.

В Mozilla отмечают, что большинство пользователей не знают об инструментах защиты от идентификации со стороны владельцев сайтов или иных лиц. Например, у Edge и Firefox есть встроенная защита на основе черных списков средств идентификации разных разработчиков. Браузер Tor периодически меняет цифровые отпечатки пользователей. Правда, эти способы в некоторых случаях приводят к проблемам с отображением сайтов. Mozilla предлагает активнее информировать пользователей о способах защиты персональных данных и широко использовать программные инструменты для обеспечения конфиденциальности.

Подробнее..

Категории: Информационная безопасность , Браузеры , Блог компании selectel , Статистика в it , Исследования и прогнозы в it , Цифровой след , Mozilla , Слепок , Паттерны поведения , Журнал посещений

Firefox представил новую архитектуру безопасности браузера с изоляцией сайтов

19.05.2021 16:06:46 |

Автор: admin

Firefox, как и любой другой браузер, может загружать код с ненадёжных и потенциально опасных сайтов, а потом запускать его на компьютере. Чтобы защитить пользователей и вывести безопасность работы в интернете на новый уровень, команда Mozilla решила переработать свой браузер.

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

Для защиты данных Firefox применяет различные механизмы безопасности, например,Правило ограничения домена(Same Origin Policy Принцип одинакового источника),которое ограничивает взаимодействие информации, поступившей из разных источников. То есть предотвращает доступ злоумышленников к информации с других ресурсов, загружаемых в одном и том же приложении. Но этого недостаточно. Чтобы оградить пользователей от потенциальных угроз, следует полностью разделять пространство памяти, выделенное под разные сайты новая архитектура Firefox обеспечивает эти гарантии безопасности.

Почему так важно разделение пространства памяти

В начале 2018 года специалисты, исследующие вопросы безопасности, обнаружили две основные уязвимости, известные какMeltdown(аппаратнаяуязвимость, которая использует ошибку реализацииспекулятивного выполнения командв некоторых процессорах Intel и ARM, из-за которой процессор игнорирует права доступа к страницам.) иSpectre(группа аппаратныхуязвимостей большинства процессоров, позволяющая считывать данные черезсторонний канал). Специалисты продемонстрировали, как ненадёжный сайт может дать злоумышленникам доступ к памяти процесса даже на таком высокоуровневом языке, как JavaScript (на котором работает почти каждый сайт).

Для защиты от уязвимостей были развёрнуты временные меры противодействия со стороны ОС, ЦП и основных веб-браузеров. Они быстро нейтрализовали атаки, однако привели к снижению производительности. Но это были именно временные заплатки.

Firefox решила коренным образом переделать архитектуру браузера, чтобы оградить пользователей от текущих и будущих версий подобных уязвимостей. На картинке ниже подробно рассматривается пример того, как злоумышленник может получить доступ к личным данным при атаке, подобной Spectre.

С новой архитектурой Firefox загружает каждый сайт в своём собственном процессе, тем самым изолируя их память друг от друга. Например, у пользователя открыто два сайта: www.my-bank.com и www.attacker.com.Как показано на картинке выше, со старой архитектурой браузера контент с обоих сайтов может быть загружен в один и тот же процесс операционной системы.Если с сайта www.attacker.com произойдёт атака наподобие Spectre, злоумышленники смогут запрашивать и получать доступ к данным с сайта my-bank.com.

Несмотря на существующие меры безопасности, единственный способ обеспечить полноценную защиту памяти это изоляция контента с разных сайтов и использование разделения процессов операционной системы.

Как работала прежняя архитектура браузера

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

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

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

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

Хотя разделение контента на восемь процессов уже обеспечивало неплохую защиту, оно не соответствовало стандартам безопасности Mozilla, поскольку позволяло двум совершенно разным сайтам работать в одном и том же процессе операционной системы и, следовательно, совместно использовать память процесса.Чтобы избежать этого, Firefox переходит на архитектуру изоляции сайтов, которая загружает каждый сайт в свой собственный процесс.

Что происходит на иллюстрации выше? Пользователь открывает в разных вкладках сайты: www.my-bank.com, www.getpocket.com, www.mozilla.org и www.attacker.com.Может так получиться, что my-bank.com и attacker.com будут обрабатываться одним и тем же процессом операционной системы, то есть они будут совместно использовать память этого процесса.Соответственно, злоумышленник может выполнить атаку типа Spectre для доступа к данным с my-bank.com.

Ещё один важный момент: без изоляции сайтов браузер будет загружать все всплывающие страницы в том же процессе, что и сайт верхнего уровня. Субфреймы (реклама, встроенное видео), тоже обрабатываются в общем процессе. В результате вредоносный сайт может получить доступ к субфреймам и конфиденциальной информации, которую вы там вводите. Новая архитектура безопасности изоляции сайтов в Firefox не позволит совершать такие атаки.

Как работает новая архитектура Firefox с изоляцией сайтов

При добавлении Изоляции сайтов в Firefox для настольных ПК каждый уникальный сайт будет создавать свой отдельный процесс.Например, если вы загрузите https://mozilla.org и http://getpocket.com, браузер с изоляцией сайтов разделит их по двум разным процессам операционной системы, поскольку они не являются одним и тем же сайтом.

Точно так же https://getpocket.com (обратите внимание, здесь именно протокол https, а не http, как в предыдущем абзаце) также будет загружен в отдельный процесс. То есть все три сайта будут загружаться в разных процессах.

Более того, существуют некоторые домены, такие как .github.io или .blogspot.com, которые являются слишком общими, чтобы можно было идентифицировать их, как сайт.Поэтому для работы с ними Firefox будет использовать поддерживаемыйсообществомсписок доменов верхнего уровня (eTLD), чтобы помочь различать сайты.

Поскольку github.io указан как eTLD, a.github.io и b.github.io будут загружаться в разных процессах.Если вернуться к примерам, о которых говорилось ранее, сайты www.my-bank.com и www.attacker.com не считаются одним сайтом, поэтому они будут изолированы друг от друга в отдельных процессах. Память также будет изолирована, что гарантирует безопасность данных.

Также и с субфреймами. Субфреймы, которые не являются тем же сайтом, что и страница верхнего уровня, будут загружаться в другом процессе.

На картинке выше видно, что страница www.attacker.com пытается встроить субфреймом страницу с www.my-bank.com, но она будет загружена в другом процессе.Это гарантирует, что память процессов также будет изолирована.

Дополнительные преимущества изоляции сайтов

Новая архитектура не только делает Firefox безопаснее.Она даёт и другие преимущества:

Благодаря тому, что больше страниц помещается в отдельные процессы, выполнение тяжёлых вычислений на одной странице не замедлят работу других страниц.
Использование большего количества процессов для загрузки веб-сайтов позволяет распределять нагрузку по многим ядрам ЦП и более эффективно использовать железо.
Из-за дробления сайтов, сбой одного субфрейма или вкладки не повлияет на сайты, загруженные в других процессах, то есть повышается стабильность приложения.

Планы и перспективы

В настоящее время Firefox тестирует изоляцию сайтов в ночных и бета-версиях браузеров для ПК.Однако воспользоваться улучшенной архитектурой безопасности можно уже сейчас. Для этого нужно загрузить браузер Nightly или Betaотсюдаи выполнить следующие действия:

Чтобы включить изоляцию сайта в Firefox Nightly:

Перейдите к about: Preferences#Experiment
Установите флажок Fission (Site Isolation).
Перезагрузите Firefox.

Чтобы включить изоляцию сайта в Firefox Beta:

Перейдите к about: config.
Установите для параметра `fission.autostart` значение `true `.
Перезагрузите Firefox.

Теперь можно осваивать обновлённый браузер и радоваться усиленной безопасности.

Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Облачная кухня: готовим данные для мониторинга с помощью vCloud API и скороварки

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Почему ваш бизнес может быть разрушен

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Подробнее..

Категории: Информационная безопасность , Браузеры , It-компании , Софт , Блог компании cloud4y , Технологии , Mozilla , Браузер

Перевод Нам надо создать веб с чистого листа

26.08.2020 12:14:14 |

Автор: admin

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

Этот кризис влияет на платформы, творцов и потребителей.

Я попытаюсь немного проанализировать и диагностировать эту ситуацию. Если вы хотите просто прочитать мою обывательскую, непрофессиональную речь о необходимости перезагрузки веба, то можете пропустить эту часть. Идея заключается в том, что мы можем выбрать новый облегчённый (markdown) формат разметки на замену HTML и CSS, разделить веб на веб документов и приложений, вернув себе скорость, доступность и интересность сети.

В этом посте используется педантическое определение веба. Несколько раз я уже рассказывал о попытках повторного изобретения Интернета. Такие проекты, как dat, IPFS и arweave были задуманы для изобретения заново Интернета или его транспортного слоя и слоя передачи данных. Веб это то, что находится поверх этих слоёв: HTML, CSS, URL, JavaScript, работа в браузерах.

Крушение платформ

На прошлой неделе произошло важное изменение со стороны платформ организация Mozilla уволила 250 сотрудников и заявила, что это повлияет на разработку Firefox. Браузер Firefox не был вторым по популярности им является Safari, в основном из-за подневольной аудитории владельцев iPhone и iPad. Однако он был самым популярным браузером, который люди выбирали.

График с сайта statcounter

Настоящим победителем стал не сам Chrome, а движок Chrome. Одна кодовая база KHTML разделилась на WebKit (Safari) и Blink (Chrome, Microsoft Edge, Opera и т.д.)

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

Специализации и реализации

Веб эволюционировал благодаря комбинированию спецификаций и реализаций. Такие организации, как WHATWG, W3C и IETF были пространствами для сотрудничества независимых разработчиков, корпораций и учёных в области обсуждения потенциала новых возможностей веба. Браузеры тестировали их идеи на множестве разных реализаций.

Это было интересной частью структуры: такая система гарантировала всем нам, что можно развиваться вместе, и что одной из наших целей является возможность вносить вклад в веб для множества участников. Нас расстраивало, когда на caniuse появлялись пустые ячейки, однако в целом идея заключалась в том, что даже если разные браузеры могут быть лучшими в разных аспектах, рано или поздно они друг друга догоняют. Chrome не был первым браузером, который начал вводить новые возможности и оптимизации.

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

Мне кажется, лучше всего это сформулировал Майк Хили:

Вам не кажется, что веб практически монополизирован с точки зрения сложности, если движки рендеринга для него способы создавать только одна-две организации?

Сегодня не только почти невозможно создать новый браузер с нуля если вы всё-таки этого добьётесь, необходимость постоянной гонки за реализацией новых стандартов потребует целого коллектива специалистов. Об этом можно прочитать в статье Дрю Деволта Web browsers need to stop (Веб-браузерам нужно остановиться); также рекомендую прочитать и другие его материалы.

А как насчёт Flow?

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

Проблема для творцов

Для веба стало намного сложнее разрабатывать.

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

Лучший способ войти в веб-разработку в 2020 году это выбрать нишу, например Vue.js или React, и надеяться на то, что в команде есть специалист по CSS и доступности.

Для тех, кто просто хочет создать веб-страницу, а не стремится попасть в отрасль, существует сбивающее с толку множество технологий, но самые простые и, вероятно, самые лучшие, из них, стигматизированы. Люди чаще пишут резюме на React с GraphQL, чем вбивают HTML в Блокноте.

Проблема для потребителей

Мы надеемся, что все инновации создаются ради пользователя, но часто это не так. Похоже, что современные веб-сайты самые большие, медленные и забагованные за всю историю веба. Наши компьютеры почти не становятся быстрее, а скорости Интернет-подключений стагнируют (даже не пытайтесь сказать что-нибудь о 5G). Рост размера веб-страниц обгоняет рост всех остальных параметров.

Из-за всего этого я уже не жду, что страницы будут работать быстро даже с установленным в Firefox uBlock и хорошим местным оптоволоконным провайдером.

Но я не хочу во всём винить этих веб-разработчиков. Могу поделиться довольно забавной историей с моего прежнего места работы. Мы собирали данные о взаимодействии пользователей с сайтами, чтобы отвечать на простые вопросы типа для загрузки файлов на сервер люди щёлкают на кнопку или пользуются drag & drop? Поэтому мы использовали Segment инструмент, позволяющий при помощи простого скрипта добавлять конвейеры сбора данных. Однако проблема заключалась в том, что у Segment была огромная страница с сотнями поставщиков данных и компаний, занимающихся рекламными технологиями. И, разумеется, те ребята, которые в компании занимаются бизнесом, начали нажимать на все эти кнопки.

Понимаете, проблема с рекламой и отслеживанием данных заключается в том, что всё это можно делать, а разве кто-то от этого откажется? (В нашем случае я отказался и добавил CSP, блокирующий доступ новых рекламодателей на уровне страниц.)

Возврат к простоте

Невозможно прийти к простой системе, добавляя простоту к сложной системе. Ричард О'Киф

Куда же нам двигаться дальше? Самые умные люди предлагают устроить пересмотр версий веба.

Как же нам сделать веб интересным, удобным для совместного творчества и хорошим?

Во-первых, я подумал, что существуют два веба:

Веб документов

Есть веб документов: блоги, новости, Википедия, Twitter, Facebook. Насколько я понимаю, по сути, это тот веб, каким он виделся изначально (мне тогда было два года). CSS, который мы сейчас воспринимаем как инструмент, с помощью которого дизайнеры могут создавать уникальность бренда и добавлять детали с точностью до пикселя, изначально воспринимался как способ реализации читаемости документов без форматирования, позволяющий читателям этих документов настраивать их внешний вид. На самом деле, этот атрибут какое-то время сохранялся в Chrome в виде пользовательских таблиц стилей и до сих пор работает в Firefox. Однако в современном вебе это будет непростой задачей, ведь он фактически отказался от идеи семантического HTML.

Веб приложений

А ещё есть веб приложений. Он зародился как серверные приложения, построенные на основе чего-то типа Django и Ruby on Rails. До них существовало множество технологий, которые теперь вечно будут жить в корпорациях, например, сервлеты Java.

Backbone.js продемонстрировал, что многие такие приложения можно перенести в браузер, после чего React и многие его SPA-конкуренты создали для веба новый мировой порядок клиентские приложения с высокой степенью интерактивности и сложности.

Война между частями веба

Я утверждаю, что именно такая двойственная природа создаёт магию веба. Но она является и разрушительной силой.

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

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

А веб приложений страдает от характеристик документов интерактивные приложения прилагают огромные усилия к тому, чтобы избегать большинства фундаментальных характеристик HTML и CSS, и используют их только как сырьё полностью избегая непосредственного написания HTML, избегая написания CSS, избегая стандартных функций анимации, заменяя постраничную навигацию на нечто, что выглядит похоже, но работает совершенно иначе. Веб приложений использует JSX, а не HTML, и предпочитает иметь с ним дело и в самом браузере, или использует Svelte вместо JavaScript, и тоже предпочитает его.

Когда я читаю посты в блогах традиционных веб-разработчиков, которых бесит, что HTML и CSS сегодня уже недостаточно и всё стало таким сложным, то я думаю, что в основном так получилось потому, что во многих местах стек разработки приложений в создании веб-сайтов заменил стек создания документов. Там, где бы мы использовали Jekyll или рендеринг на стороне сайта, теперь применяется React или Vue.js. У такого подхода есть преимущества, но для множества веб-сайтов с минимальной интерактивностью это означает отказ от накопленных за десятки лет знаний в обмен на некие преимущества скорости, которые могут быть даже не важны.

Притягательность социальных сетей

Притягательность социальных сетей частично вызвана тем, что они позволяют нам создавать документы без размышлений о веб-технологиях и обеспечивают гарантии относительно скорости, доступности и совершенства, которые без соцсетей потребовали бы много нашего времени. Нам не приходится беспокоиться о том, чтобы пост на Facebook быстро грузился на телефонах друзей или о правильном редактировании и публикации фотографии в Instagram обо всём этом позаботились за нас.

В какой-то степени, для этого не обязательны возможности соцсетей: стандарты наподобие RSS и сервисы типа Instapaper демонстрируют, что красивое форматирование и распространение можно реализовать на уровне платформы и создать поверх уже существующих ванильных веб-сайтов.

Но ведь чёткого разделения нет

Да, кто-то может сказать: эти категории не являются точными! Существует множество приложений, не жертвующих производительностью или доступностью, и множество документальных веб-сайтов, которым точно не хватает интерактивность, и множество разработчиков, просто использующих платформу (ванильный JavaScript или веб-компоненты), которым не нужно, чтобы веб был другим. Все категории, которые мы берём из сред реального мира, будут неточными. Именно так работает нетехническая мысль: вопрос не в том, идеальны ли категории, а в том, полезны ли они для развития дискуссии.

Веб документов 2.0

Разумеется, было бы здорово реализовать объединённую теорию нового веба, в которой достаточно характеристик приложений и достаточно характеристик документов для создания всевозможных гибридных интерактивных документов, с которыми мы сегодня работаем. Но путь к разделённому вебу для нас понятнее, и о нём я подумал в первую очередь, так что давайте немного поговорим о нём.

Правило 1 не создавать подмножеств. Если заменой веба будут только те функции, которые присутствовали в Firefox 10 десять лет назад, то такая версия никому не понравится.
Правило 2 не делать его совместимым. Если альтернативный веб будет существовать параллельно, неотличимо от современного веба, то нам никогда не удастся снизить сложность, потому что альтернативные веб-браузеры всё равно будут поддерживать всё, и у людей не будет стимула покинуть старый веб.
Правило 3 сделать его лучше для всех. Преимущества должны быть для всех, находящихся в экосистеме: для людей, создающих страницы, для людей, читающих их, и для людей, которые создают технологии, позволяющие читать страницы.

Итак, допустим, мы создаём новый веб документов.

Во-первых, нам понадобится минимальный стандартизованный язык разметки для передачи документов. Вероятно, мы захотим начать с lightweight markup language, который будет заточен под генерирование HTML. Достаточно подходящим выбором кажется строгая разновидность Markdown под названием Commonmark. Это язык, на котором я писал все свои посты, самый популярный в своём семействе. Для Markdown есть множество замечательных парсеров и большая экосистема инструментов.

Далее нам нужен браузер. Уже долгое время Mozilla работала над совершенно новым браузером Servo. На прошлой неделе команду разработки уволили, и это печально. Этот проект включает в себя независимые Rust-крейты для рендеринга шрифтов, а также высококлассную реализацию Markdown на Rust и постоянно растущий набор потрясающих фреймворков приложений. Можно ли создать браузер для чистого Markdown, напрямую использующего этот конвейер? Может быть?

Я считаю, что такая комбинация позволит нам в значительной мере вернуть потерянную скорость. Мы могли бы получать страницу на экран за малую долю времени по сравнению с современным вебом. Потребление памяти может быть крошечным. Система по умолчанию будет невероятно доступной. Можно будет создавать отлично выглядящие стандартные таблицы стилей и делиться альтернативными пользовательскими страницами стилей. Благодаря значительно уменьшившемуся объёму мы сможем портировать систему на всевозможные устройства.

А как будут выглядеть инструменты редактирования веб-сайтов (что, наверно, важнее всего)? Они могут быть намного проще.

Как бы выглядело агрегирование? Если бы веб-страницы больше походили на документы, чем на приложения, то нам бы не понадобился RSS веб-сайты имели бы индекс, указывающий на документы и считыватель мог бы по умолчанию агрегировать сами веб-страницы.

Мы могли бы связать два веба при помощи чего-то вроде файла well-known протокола dat, или использовать заголовок Accept для создания браузера, понимающего HTML, но предпочитающего lightweight-страницы.

Веб приложений 2.0

У меня есть такое ощущение, что какую бы проблему веба я ни упомянул, мне автоматически ответят, что её сможет устранить WebAssembly. Может ли так быть?

Не знаю. WebAssembly на самом деле отличная штука, но должны ли веб-приложения просто рендериться на canvas, а каждое приложение тащить свою собственный графический тулкит? Действительно ли нам нужны различия в реализации сглаживания в веб-приложениях? Приложения в контейнерах существуют, взгляните хотя бы на Qubes, но на самом деле пользователи должны стремиться не к ним. Любой, кто пользовался Blender или Inkscape на Mac, примерно представляет, как бы всё это выглядело.

Или может ли WebAssembly стать новым ядром, а рендеринг UI по-прежнему будет выполняться HTML? Или мы можем создать общую связанную библиотеку, которую будут использовать WebAssembly-приложения. Она бы работала примерно как SwiftUI и предоставляла удобные для приложений стандарты типа ограничений, а не концепции наподобие высоты строки и плавающих элементов, свойственных документам.

Проблема формирования представления о вебе приложений заключается в том, что он сильно разрастается.

Чем хуже становятся Mac App Store, Windows App Store, App Store и Play Store, чем большую долю требуют эти монополии, чем больше затрат необходимо, чтобы быть разработчиком под Mac или Windows, тем активнее эти приложения перемещаются в веб. Разумеется, некоторые приложения лучше в вебе. Но многие уходят туда просто потому, что это единственное оставшееся место, где можно легко, дёшево и свободно распространять или продавать продукт.

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

Кто над этим работает?

Beaker Browser частично является повторным изобретением Интернета это простейший способ использования dat для децентрализации, но разработчики также экспериментируют с новыми типам и документов и способами их создания.
Project Gemini очень интересная альтернатива вебу с отчётливым ретро-колоритом. (Спасибо Джессу за информацию.)
Меня сильно впечатлил taizen браузер Википедии для командной строки. Он показывает, что работа с текстом может быть действительно интересной.

Что вы об этом думаете?

Существует множество возможных взглядов на эту проблему и способов её решения. Я считаю, что это на самом деле проблема (для всех, кроме Google). Идея веб-браузера как чего-то, что мы можем понять, веб-страницы как чего-то, что смогут создавать большее количество людей, кажется мне восхитительной.

Очень реалистичным кажется подход на основе markdown. Думаю, самый сильный аргумент против него заключается в том, что он высасывает из веба всю интересность, и отчасти это справедливо. Однако ранний веб не был интересным в привычном нам смысле там мы не могли творить искусство или использовать его для чего-то кроме обмена документами. Но он был потрясающе интересным, потому что делиться информацией интересно, а там это можно было делать простыми и универсальными способами. Поэтому важнее всего найти элементы, высвобождающие возможности такого плана, если, конечно, они существуют. Или найти другой план, который будет достаточно интересным.

Социальные сети обычно сильнее ограничивают, чем веб-страницы, но в то же время они более интересны по множеству важных причин, важнейшей из которых является возможность участия гораздо большего количества людей. Что если остальная часть веба имела бы такую простоту и непосредственность, не будучи при этом столь централизованной? Что если бы мы могли начать сначала?

На правах рекламы

Эпичные серверы это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Доступен широкий выбор тарифных планов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!

Подробнее..

Категории: Социальные сети и сообщества , Научно-популярное , Разработка веб-сайтов , Браузеры , Сетевые технологии , Социальные сети , Блог компании vdsina.ru — хостинг серверов , Интернет , Chrome , Интернет 2.0 , Web 3.0 , Mozilla

Перевод Невменяемый, необъятный масштаб браузеров

07.02.2021 08:23:35 |

Автор: admin

^Увидев ^{вот эту
публикацию} ^{про браузерные войны, я хотел
было написать альтернативное наблюдение за тем, как мы докатились
до такой жизни. Но Дрю ДеВолт уже всё сказал за
меня.}

Начиная с первых войн между Netscape и IE, главным инструментом в конкурентной борьбе браузеров стала функциональность. Вот только стратегия неограниченного роста и расширения совершенно безумная. Слишком долго мы позволяли ей продолжаться.

С помощью wget я скачал все 1217 спецификаций W3C, опубликованных на текущий момент¹. Существенная часть из них должна быть реализована в браузере, чтобы современный веб работал. Я подсчитал объём этих спецификаций. Как думаете, насколько сложен современный веб?

^{[1] По состоянию на 2020-03-18. Без учёта спецификаций
WebGL, за которые отвечает Khronos.}

Суммарно, на сегодня, каталог спецификаций WC3 содержит 114 миллионов слов. Если взять стандарты C11, C++17, UEFI, USB 3.2, и POSIX, добавить к ним все 8754 опубликованных RFC, а также всё из списка самых длинных литературных произведений на Википедии у W3C всё равно на 12 миллионов слов длиннее².

^{[2] Оставшееся место можно легко заполнить с помощью 5038
страниц руководства Intel по архитектуре x86. Только придётся его
скопировать где-то раз шесть.}

Мой вывод: новый веб-браузер создать невозможно. Сложность просто зашкаливает. Создание нового браузера по трудоёмкости сравнимо с отправкой человека на Луну или созданием ядерной бомбы с нуля.

Невозможно реализовать веб корректно.
Невозможно реализовать веб безопасно.
Невозможно реализовать веб в принципе.

Создать принципиально новый браузер, чтобы конкурировать с Гуглом или Мозиллой? Да это настолько глупо, что вас тут же спросят, есть ли в нём нескучные обои. Последняя серьёзная попытка Servo понемногу превратилась в наполовину инкубатор для рефакторингов Файрфокса, наполовину в развлечение для скучающих инженеров Мозиллы, где они могут безопасно поиграться с никому не нужными технологиями. Жизнеспособный современный браузер? Что это? Кому это надо, когда у нас есть WebVR! Круто же, да? Да?

Последствия очевидны. Браузеры это наиболее сложный и тяжёлый софт, который люди запускают на типичных потребительских компьютерах. Все знают, как хорошо браузеры жрут оперативку, процессор, батарейку, и т. д. В одних только браузерах найдено более 8000 уязвимостей³.

^{[3] Количество CVE в базе cve.mitre.org по ключевым словам
firefox, chrome, safari, internet explorer.}

Из-за монополии, гарантированной поистине космической стоимостью создания альтернативы, браузеры перестали служить пользователям и теперь служат своим создателям. Файрфокс тянет с собой всё больше рекламы, телеметрии, и обязательных плагинов. Хром используется Гуглом для наблюдения за вашим поведением в интернете, а также для насаждения вредоносных технологий вроде DRM и AMP. Браузерная дуополия становится всё сильнее вместе с тем как Microsoft отказывается от Edge, а WebKit давно остановился в развитии.

Исходный код большинства браузеров открыт. Обычно если open-source проект творит какую-то дичь, то сообщество может его форкнуть, чтобы создать альтернативу. Однако, для браузеров это не сработает. W3C печатает в среднем 200 новых спецификаций каждый год это 4 миллиона слов как новый POSIX каждые 4-6 месяцев. Покажите мне команду, которая сможет угнаться за всем этим развитием ещё и реализовав в срок ту гору спецификаций, что накопилась уже сейчас.

Браузерные войны затянулись. Давным давно следовало начать состязаться в стабильности и производительности браузеров, вместо производительности команд разработки измеряемой в фичах за спринт. Вы долбанулись. Астанавитесь!

Прим.: Если вам интересна методология подсчёта слов в спецификациях, то её у меня есть.

Подробнее..

Категории: Разработка веб-сайтов , Open source , Браузеры , Google , Google chrome , Firefox , W3c , Mozilla , Долбанутые , Печатный станок , Открытое программное обеспечение

Старые версии Mozilla Firefox

24.02.2021 22:18:59 |

Автор: admin

Этим вечером у меня появилось свободное время и я пустился в воспоминания о прошлом. О тех временах когда браузеры были маленькими, и быстрыми, а размер веб-страницы можно было измерять в килобайтах, а не мегабайтах. О тех временах когда у нас был другой президент.

На самом деле, всё это происходило не так уж давно - президентом в 2011 году был Дмитрий Медведев, а браузеры действительно были радикально легче. Дистрибутив Mozilla Firefox версии 1.5 занимает чуть меньше 5 мегабайт.

Что в этом толку? Этот вопрос я задал себе следующим, и тут же решил проверить - а много ли пользы от тогдашних браузеров в современном мире? Скачал и установил себе последовательно Mozilla Firefox 1.5.0.12, 10.0.2, 20.0.1, 30.0 и 40.0.3. Хотел продолжить, но дальнейшее исследование не имело смысла (позже будет понятно, почему).

Общий результат

Дистрибутивы Firefox доступны. Браузер до сих пор можно скачать с первой и до последней версии, все они могут установиться на последней Windows 10, причём так, чтобы не мешать другим установленным браузерам (даже себе же но более поздней версии), если устанавливать их в разные папки.

Я пытался зайти на несколько известных сайтов и кликнуть пару ссылок, чтобы убедиться в их работоспособности.

Как правило, если браузеру удавалось открыть страницу, то отображал он её более-менее корректно, явных проблем с вёрсткой не было заметно. Проблемы были другие.

Немного конкретики

	1.5.0.12	10.0.2	20.0.1	30.0	40.0.3
mozilla.org	-¹	-⁴	+	+	+
google.com	-¹	+/-⁵	+	+	+
yandex.ru	+²	+	+	+	+
sports.ru	-	-	-	+/-⁶	+
kremlin.ru	+³	+³	+³	+³	+³
thg.ru	+³	+³	+³	+³	+³

1 - нет общего алгоритма https, не загружается

2 - работает но выглядит не совсем корректно

3 - доступно соединение по HTTP - по нему и работает

4 - 308 permanent redirect

5 - страница загружается, но при попытке нажать на кнопку поиска вешает браузер напрочь

6 - сайт попытался показать страницу и уронил браузер до смерти

Итоги

К сожалению, мои надежды на быстроту и легковесность старых версий не оправдались. Странички рендерятся не так уж быстро, хотя и не медленнее современной версии (86.0). Должен заметить, что отсутствие поддержки современных алгоритмов шифрования для HTTPS даёт не только проблемы при отображении страниц, но и довольно забавный эффект блокировщика рекламы. Дело в том, что соединения с крупными рекламными сетями также не работают, а значит - баннеры не загружаются.

В целом, от старых браузеров очень немного пользы, но тем кто по каким-то причинам вынужден ими пользоваться (например, пользователям Windows XP недоступен Firefox версии выше 52), всё же можно не терять надежды. Веб работает, хоть и не очень хорошо.

Подробнее..

Категории: Браузеры , Mozilla , Олдскул , Совместимость , Совместимость браузеров

	Русский
	English

Mozilla

Обрабатываем данные на стороне клиента с помощью WebAssembly

Перед началом

Обработка данных

С++ часть

Клиентский код

Итог

Mozilla пользователя можно идентифицировать по посещению предпочитаемых сайтов с точностью в 99

Firefox представил новую архитектуру безопасности браузера с изоляцией сайтов

Почему так важно разделение пространства памяти

Как работала прежняя архитектура браузера

Как работает новая архитектура Firefox с изоляцией сайтов

Дополнительные преимущества изоляции сайтов

Планы и перспективы

Перевод Нам надо создать веб с чистого листа

Крушение платформ

Специализации и реализации

Проблема для творцов

Проблема для потребителей

Возврат к простоте

Веб документов

Веб приложений

Война между частями веба

Притягательность социальных сетей

Веб документов 2.0

Веб приложений 2.0

Кто над этим работает?

Что вы об этом думаете?

На правах рекламы

Перевод Невменяемый, необъятный масштаб браузеров

Старые версии Mozilla Firefox

Общий результат

Немного конкретики

Итоги

Категории

Последние комментарии