Мало обладать выдающимися качествами, надо еще уметь ими пользоваться

Босс, подчиненному: ...

Кеннет Рейц в поисках новых мейнтейнеров для своих репозиториев
Thu, 18 Jul 2019 07:16:37 +0300

Разработчики Fedora намерены прекратить формирование репозиториев для архитектуры i686
Wed, 17 Jul 2019 18:21:36 +0300

ISO-образы дистрибутива Nitrux стали платными
Wed, 17 Jul 2019 17:05:31 +0300

Возобновление работы по интеграции поддержки Tor в Firefox
Wed, 17 Jul 2019 10:53:05 +0300

В Firefox 70 страницы открытые по HTTP начнут помечаться как небезопасные
Wed, 17 Jul 2019 10:47:46 +0300

Компания Epic Games пожертвовала 1.2 млн долларов Blender и развивает продукты для Linux
Tue, 16 Jul 2019 06:27:05 +0300

Microsoft открыл код Quantum Development Kit для разработки квантовых алгоритмов
Mon, 15 Jul 2019 21:44:07 +0300

В ночных сборках Firefox для Linux активирован WebRender для видеокарт NVIDIA
Mon, 15 Jul 2019 09:35:10 +0300

Разработчики Haiku развивают порты для RISC-V и ARM
Fri, 12 Jul 2019 09:27:46 +0300

Mozilla заблокировала сертификаты удостоверяющего центра DarkMatter
Wed, 10 Jul 2019 09:26:28 +0300

Официально завершена сделка о покупке Red Hat компанией IBM
Tue, 09 Jul 2019 16:42:12 +0300

Компания Mozilla определила получателей грантов исследовательским проектам
Tue, 09 Jul 2019 11:34:54 +0300

В августе под Минском пройдёт международная конференция LVEE 2019
Mon, 08 Jul 2019 11:09:57 +0300

В Великобритании Firefox не будет использовать DNS-over-HTTPS из-за претензий в обходе блокировок
Sat, 06 Jul 2019 23:31:36 +0300

Для Chrome разрабатывают режим блокировки ресурсоёмкой рекламы
Fri, 05 Jul 2019 11:17:42 +0300

Новости OPENNET
Новости

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

защиты от вредоносного ПО, фишинга, шпионящей за пользователями активности, родительского контроля и обеспечения приватности.

Мотивы Google:

  • Блокирующий режим работы API webRequest приводит к большому потреблению ресурсов.
  • При использовании данного API браузер вначале отправляет дополнению все содержащиеся в сетевом запросе данные, дополнение анализирует их и возвращает для дальнейшей обработки в браузере изменённый вариант или выдаёт инструкции по блокировке. При этом основные задержки возникают не на стадии обработки трафика дополнением, а из-за накладных расходов на координацию выполнения дополнения. В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения IPC для взаимодействия с этим процессом и механизмов сериализации данных;
  • Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности. По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest. Отмечается, что ежемесячно в каталоге Chrome Web Store блокируются попытки размещения в среднем 1800 вредоносных дополнений. К сожалению рецензирование не позволяет отлавливать все без исключения вредоносные дополнения, поэтому для усиления защиты было решено ограничить дополнения на уровне API. Основная идея в том, чтобы предоставлять дополнениям доступ не ко всему трафику, а только к тем данным, которые необходимы для реализации задуманной функциональности. В частности, для блокировки контента не обязательно предоставлять дополнению полный доступ ко всем конфиденциальным данным пользователя;
  • Предложенный на замену декларативный API declarativeNetRequest берёт на себя всю работу по высокопроизводительной фильтрации контента и лишь требует от дополнений загрузки правил фильтрации. Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;
  • Google учёл многие замечания в отношении недостаточной функциональности API declarativeNetRequest и расширил лимит на число правил фильтрации с изначально предложенных 30 тысяч на каждое расширение до глобального максимума в 150 тысяч, а также добавил возможности для динамического изменения и добавления правил, удаления и замены HTTP-заголовков (Referer, Cookie, Set-Cookie) и параметров запросов;
  • Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски. Например, указанный API может применяться на предприятиях для учёта потоков трафика сотрудников и интеграции с внутренними системами;
  • Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;
  • Нежелание оставить блокирующий режим работы API webRequest наряду с новым declarativeNetRequest объясняется желанием ограничить доступ дополнений к конфиденциальным данным. Если оставить API webRequest как есть, то большинство дополнений не будут использовать более безопасный declarativeNetRequest, так как обычно при выборе между безопасностью и функциональностью основная масса разработчиков выберет функциональность.

Возражения разработчиков дополнений:

  • Проведённые разработчиками дополнений тесты показывают ничтожное на общем фоне влияние на производительность дополнений для блокирования рекламы (при тестировании сравнивалась производительность различных дополнений, но без учёта накладных расходов на работу дополнительного процесса, координирующего выполнение обработчиков в блокирующем режиме API webRequest);
  • Нецелесообразно полностью прекращать поддержку API, активно используемого в дополнениях. Вместо удаления можно добавить отдельное разрешение и жёстко контролировать адекватность его применения в дополнениях, что позволило бы избавить авторов многих популярных дополнений от полной переработки их продуктов и избежать урезания функциональности;
  • Для снижения накладных расходов можно не удалять API, а переделать на основе механизма Promise, по аналогии с реализацией webRequest в Firefox;
  • Предложенная альтернатива declarativeNetRequest не покрывает всех потребностей разработчиков дополнений для блокирования рекламы и обеспечения безопасности/приватности, так как не предоставляет полного контроля за сетевыми запросами, не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность использовать сложные правила, перекрывающие друг друга в зависимости от условий;
  • При текущем состоянии API declarativeNetRequest невозможно воссоздать в неизменном виде имеющуюся функциональность дополнений uBlock Origin и uMatrix, а также делает бессмысленным дальнейшую разработку порта NoScript для Chrome;
  • Забота о приватности надумана, так как работающий в режиме только для чтения неблокирующий режим API webRequest оставлен и по-прежнему позволяет вредоносным дополнениям контролировать весь трафик, но не даёт возможность на лету вмешиваться в него (изменить содержимое, поставить свою рекламу, запустить майнеры и анализировать содержимое форм ввода можно и после окончания загрузки страницы);
  • Разработчики браузеров Brave, Opera и Vivaldi, построенных на движке Chromium, намерены оставить в своих продуктах поддержку блокирующего режима работы webRequest.

9.1493 70.5552 0.5814 62.9451

НОВОСТИ: В ночных сборках Firefox для Linux активирован WebRender для ви ... Mon, 15 Jul 2019 09:35:10 +0300

В ночных сборках Firefox, на базе которых формируется релиз Firefox 70, включено по умолчанию применение системы композитинга WebRender для видеокарт NVIDIA на Linux-системах с драйвером Nouveau и пакетом Mesa 18.2 или более новой версией. Конфигурации с проприетарными драйверами NVIDIA пока остаются без поддержки WebRender. WebRender для GPU AMD и Intel при использовании Mesa 18+ в ночных сборках был активирован ранее. Также отмечается возобновление поддержки WebGL в ночных сборках Firefox на системах с драйверами Nouveau, которая была случайно отключена в Firefox 68 (сейчас ограничение перенесено только на проприетарный драйвер NVIDIA).

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome