Firefox отказывается в обозримом будущем от перехода на многопроцессную модель.
Разработчики Mozilla приняли решение приостановить разработку проекта Electrolysis, а рамках которого велись работы по переводу Firefox на многопроцессную модель, при которой пользовательский интерфейс и обработка контента обрабатываются разными процессами. В качестве причины прекращения развития проекта в обозримом будущем называется необходимость внесения слишком значительных изменений на уровне архитектуры.
Перевод уже сложившегося продукта, изначально построенного на базе однопроцессной модели, на совершенно другую архитектуру требует вложения значительных ресурсов и привлечения к работе различных команд разработчиков, от разработчиков занимающихся интерфейсом и дополнениям до команд развивающих фронтэнд и ответственных за выпуск релизов. При этом нет гарантии, что после перехода на многопоцессную модель удастся обеспечить полную работоспособность всех уже созданных дополнений, без внесения в них изменений.
В то же время, отмечаются другие пути повышения отзывчивости интерфейса, реализация которых требует значительно меньших вложений и времени на реализацию. Именно таким проектам разработчики намерены уделить внимание в первую очередь. Среди достижимых малой кровью заметных улучшений отмечается переработка кода обслуживания внутренних баз данных, оптимизация работы сборщика мусора и вынос выполнения плагинов в отдельные процессы. По мнению разработчиков, уделив внимание подобным небольшим инициативам, за более короткое время можно достигнуть впечатляющих результатов в плане повышения отзывчивости работы браузера.
Тем не менее, кроме решения проблем с отзывчивостью интерфейса, многопроцессная архитектура обладает рядом дополнительных достоинств, которые проблематично реализовать в рамках однопроцессной модели. Например, можно упомянуть повышение производительности при работе на многоядерных процессорах; решение проблем с фрагментацией памяти и отдачей освобождённой памяти обратно операционной системе; обеспечение защиты от сбоев (в случае сбоя закроется лишь одна вкладка, не повлияв на работоспособность браузера в целом); повышение безопасности (связанный с текущей вкладкой код выполняется в своей "песочнице", независимо от обработчиков других сайтов; для эксплуатации уязвимостей требуется преодоление нескольких уровней изоляции).
Вот и обратная сторона гонки версий.
Очень странной выглядит ссылка на возможную потерю совместимости дополнений, при условии что от версии к версии и так часть дополнений отваливается и без переработки не запускается (переработка != выключение проверки версий).
Печально все это... как бы при следующем обновлении процессора не пришлось на хром переползать.
Вот и хорошо, что реально оценили свои силы и отложили сверхзадачу до лучших времен.
Идиоты. Простите, у меня больше слов нет.
Печально все это...
Как страшно жить©®™ 
Вот и хорошо, что реально оценили свои силы и отложили сверхзадачу до лучших времен.
Полностью согласен. Кроме того, я считаю, что от многопроцессорности вреда будет больше, чем пользы.
Кроме того, я считаю, что от многопроцессорности вреда будет больше, чем пользы.
Почему?
DarkHeavy
Частично об этом я написал в теме про ночнушки. Есть три очень значительных пункта:
1. Самый главный. Потребление памяти и процессорного времени. Опыт пользования хрома показывает, что многопроцессорность негативно влияет на потребление ресурсов системы. Точнее: дикий отжор наблюдается.
2. Не самая лучшая интуитивность. Лично я легко путаюсь, когда собираюсь убить в диспетчере задач какую-то конкретную вкладку или подсчитать потребление ресурсов. Например, если десять вкладок потребляет по 1% ЦП, то это не так уж и заметно. Но в целом в ветке это будет 10%+родительский процесс+плагины+etc. А это не так уж и мало. Но я обычным способом этих цифр не вижу и сижу гадаю, куда это у меня производительность подевалась?
3. Нагрузка на ОС. Я не знаю, как с этим в других системах, но винда постоянно мониторит каждый процесс на предмет зависания и ещё каких-то параметров, уже точно и не помню каких. Суть в том, что она эти процессы постоянно опаршивает, а они должны зависать. И когда браузер генерирует процессов больше, чем создаётся самой системой плюс десятком других приложений это тоже негативно сказывается на общей производительности. Я уже молчу об антивирусном комплексе, который должен мониторить каждый процесс на предмет подозрительной активности, вирусных сигнатур и других параметров.
Ну а насчет повышения безопасности путем изоляции браузера в "песочнице" я лично делаю так:
sandbox - X firefox
... и ВСЁ(!) - можно быть уверенным, что НИЧТО внутрь ОС не прорвется.
Только надо одномоментно соответствующее правило для SELinux настроить. Делается это очень просто (сразу после срабатывания системы безопасности):
(Это просто пример. Здесь иллюстрируется сработка системы безопасности на действия pptp)
# grep firefox /var/log/audit/audit.log | audit2allow - M mypol.pp
# semodule -i mypol.pp
Так что преимущества "песочницы" в самом браузере меня мало волнует - надо поступать глобальнее: весь браузер засовывать в песочницу. 
Rosenfeld
В FAQ по безопасности?
P.S. На ![[chrome]](img/browsers/chrome.png "chrome")
я сейчас почти вынужденно, так что не сочтите за провокацию.
Я уже думал о том, чтобы занести в ФАК. Но уж больно специфичная вещь: касается только тех ОС, где в качестве системы безопасности установлен SELinux (Security-Enhanced Linux), т.е. т.н. "Linux с улучшенной безопасностью".
Оставаясь в рамках дискреционной системы контроля доступа, ОС имеет фундаментальное ограничение в плане разделения доступа процессов к ресурсам — доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях — владелец, группа-владелец и остальные.
В SELinux права доступа определяются самой системой при помощи специально определенных политик. Политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux действует после классической модели безопасности Linux. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав некоторых дистрибутивов входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) — это основной механизм SELinux. Две других формы контроля доступа — доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП (для служебного пользования), секретно, совершенно секретно, ОВ (особой важности)).
Самый простой для работы и поддержки с точки зрения поддержки тип политики — так называемая «целевая» политика, разработанная в рамках проекта Fedora. В рамках политики описано более 200 процессов, которые могут выполняться в операционной системе. Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений дискреционной системы контроля доступа.
Кроме «целевой» политики, в состав некоторых дистрибутивов входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula).
Третий вариант политики — «строгий». Тут действует принцип «что не разрешено, то запрещено» (принцип наименьших прав). Политика основывается на Reference Policy от компании Tresys.
SELinux был разработан Агентством национальной безопасности США, и затем его исходные коды были представлены для скачивания.
From NSA Security-enhanced Linux Team:
«NSA Security-enhanced Linux is a set of patches to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access control (MAC) architecture into the major subsystems of the kernel. It provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements, which allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications. It includes a set of sample security policy configuration files designed to meet common, general-purpose security goals.»
SELinux включён в состав ядра (начиная с версии 2.6).
Пионером в области применения SELinux является RHEL (ну и конечно же Fedora). Насколько я понимаю, в остальных дистрибутивах это достаточно невостребованная вещь, которую из-за невероятно тоталитарных предустановок стараются отключить сами пользователи (зря-зря-зря).
Имхо, выносить каждую вкладку в оддельный процесс, как это сделано в хроме и не нужно, максимум, что нужно - перенести обработку самого интерфейса в оддельный процесс... Плагины уже тами, или скоро все будут там, что не может не радовать.
выносить каждую вкладку в оддельный процесс, как это сделано в хроме и не нужно, максимум, что нужно - перенести обработку самого интерфейса в оддельный процесс
Вот под этим я подписываюсь!