OpenNET

Представлен релиз I2P 0.9.44, реализации многослойной анонимной распределённой сети, работающей поверх обычного интернета, активно использующей сквозное (end-to-end) шифрование, гарантирующей анонимность и изолированность. В сети I2P можно анонимно создавать web-сайты и блоги, отправлять мгновенные сообщения и электронную почту, обмениваться файлами и организовывать P2P-сети. Базовый I2P-клиент написан на языке Java и может работать на широком спектре платформ, таких как Windows, Linux, macOS, Solaris и т.п. Отдельно развивается I2pd, реализация клиента I2P на языке C++.

В новом выпуске I2P:

Предложена начальная поддержка более надёжного и быстрого метода сквозного (end-to-end) шифрования, базирующегося на связке ECIES-X25519-AEAD-Ratchet вместо ElGamal/AES+SessionTag. Реализация пока предлагается только для экспериментов и не готова для конечных пользователей;

Код маршрутизации изменён для поддержки нескольких типов шифрования;

В BitTorrent-клиенте i2psnark предложены новые встроенные мультимедийные проигрыватели на базе HTML5 и добавлены списки воспроизведения для аудиоконтента;

Изменено оформление домашней страницы консоли;

На платформе Windows данные для новых установок теперь размещаются в каталоге %LOCALAPPDIR%;

Решена проблема с построением туннелей, приводившая к задержкам при запуске;

Устранена уязвимость, которая может привести к отказу в обслуживании при обработке скрытыми сервисами новых типов шифрования.

Джереми Соллер (Jeremy Soller), основатель операционной системы Redox, написанной на языке Rust, рассказал об успешном использовании Redox на ноутбуке System76 Galaga Pro (Джереми Соллер работает в компании System76). Из уже полностью работоспособных компонентов отмечаются клавиатуры, тачпад, накопитель (NVMe) и Ethernet.

Эксперименты с Redox на ноутбуке уже позволили улучшить работу драйверов, добавить поддержку HiDPI в некоторые приложения и создать новые компоненты, такие как pkgar, упрощающие установку Redox с Live-образов. Среди задач, на которых теперь сфокусировано внимание упоминается достижение возможности самосборки системы (сборки Redox из окружения на базе Redox). Через несколько месяцев Соллер планирует на одном из компьютеров перейти к постоянной работе над Redox из рабочего окружения на базе Redox, после того как будут внесены некоторые доработки, связанные с компилятором rustc.

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

Напомним, что операционная система развивается в соответствии с философией Unix и заимствует некоторые идей из SeL4, Minix и Plan 9. Redox использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.

В системе применяется принцип "все есть URL". Например, для записи в лог может использоваться URL "log://", для взаимодействия между процессами "bus://", для сетевого взаимодействия "tcp://" и т.п. Модули, которые могут быть реализованы в форме драйверов, расширений ядра и пользовательских приложений, могут регистрировать свои обработчики URL, например, можно написать модуль обращения к портам ввода/вывода и привязать его к URL "port_io://", после чего можно использовать его для доступа к 60 порту через открытие URL "port_io://60". Наработки проекта распространяются под свободной лицензией MIT.

Пользовательское окружение в Redox построено на базе собственной графической оболочки Orbital (не путать с другой оболочной Orbital, использующей Qt и Wayland) и тулкита OrbTk, предоставляющего API, похожий на Flutter, React и Redux. В качестве web-браузера применяется Netsurf. Проектом также развивается собственный пакетный менеджер, набор стандартных утилит (binutils, coreutils, netutils, extrautils), командная оболочка ion, стандартная Си-библиотека relibc, vim-подобный текстовый редактор sodium, сетевой стек и файловая система TFS, развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust). Конфигурация задаётся на языке Toml.

Стив Лангашек (Steve Langasek) из компании Canonical обобщил результаты обсуждения с сообществом списка библиотек для архитектуры i386, которые планируется поставлять в прослойке для обеспечения сосвместимости с 32-разрядными приложениями в Ubuntu 20.04 "Focal Fossa". Из более чем 30 тысяч исходных пакетов выбрано около 1700, для которых будет продолжено формирование 32-разрядных сборок для архитектуры i386.

В основном в список вошли библиотеки, используемые в ещё находящихся в обиходе 32-разрядных приложениях, а также связанные с этими библиотеками зависимости. Кроме того, для библиотек из списка планируется сохранить используемые для тестов зависимости, но использовать их для кросс-тестирования i386-сборок библиотек в 64-разрядном системном окружении x86_64, моделируя, таким образом, окружение, которое будет применяться в реальных условиях.

По сравнению с набором 32-разрядных библиотек, поставлявшихся в Ubuntu 19.10, в состав Ubuntu 20.04 дополнительно будут включены библиотеки:

freeglut3

gstreamer1.0-plugins-base

libd3dadapter9-mesa

libgpm2

libosmesa6

libtbb2

libv4l-0

libva-glx2

va-driver-all

vdpau-driver-all

Но при этом из набора будут исключены устаревшие пакеты, которые в Ubuntu 20.04 перестанут собираться и для актуальных архитектур (привязанные к версиям пакеты, такие как libperl5.28 и libssl1.0.0, будут заменены на более новые):

gcc-8-base

libhogweed4

libnettle6

libperl5.28

libsensors4

libssl1.0.0

libhogweed4

libigdgmm5

libllvm8

libmysqlclient20

libnettle6

libtxc-dxtn-s2tc0

libvpx5

libx265-165

wine-devel-i386

wine-stable-i386

Напомним, что изначально компания Canonical намеревалась полностью прекратить сборку пакетов для архитектуры i386 (в том числе отказаться от формирования библиотек multiarch, необходимых для запуска 32-разрядных приложений в 64-разрядном окружении), но пересмотрела своё решение после изучения замечаний, высказанных разработчиками Wine и игровых платформ. В качестве компромисса было решено обеспечить сборку и поставку отдельного набора 32-разрядных пакетов с библиотеками, необходимыми для продолжения работы устаревших программ, остающихся только в 32-разрядном виде или требующих 32-разрядных библиотек.

В качестве причины прекращения поддержки архитектуры i386 упоминается невозможность сопровождения пакетов на уровне других поддерживаемых в Ubuntu архитектур, например из-за недоступности для 32-разрядных систем последних наработок в области повышения безопасности и защиты от фундаментальных уязвимостей типа Spectre. Поддержание пакетной базы для i386 требует больших ресурсов на разработку и контроль качества, которые не оправдывают себя из-за незначительной пользовательской базы (число систем i386 оценивается в 1% от общего числа установленных систем).

Представлен выпуск инструментария GNU Mes 0.21, обеспечивающего процесс бутстрэппинга (bootstrap) для GCC. Инструментарий решает задачу верифицированной начальной сборки компилятора в дистрибутивах, разрывая цепочку цикличной пересборки (для сборки компилятора требуются исполняемые файлы уже собранного компилятора).

В GNU Mes предлагается самодостаточный (self-hosting) интерпретатор для языка Scheme, написанный на языке Си, и простейший компилятор для языка Си (MesCC), написанный на языке Scheme. Оба компонента взаимособираемы. Scheme-интерпретатор даёт возможность собрать Си-компилятор MesCC, который затем позволяет собрать урезанную версию компилятора TinуCC (tcc), возможностей которого уже достаточно для сборки GCC.

В новом выпуске появилась возможность частичного (Reduced Binary Seed) бутстрэппинга дистрибутива Guix с использованием командной оболочки Gash (Guile as Shell) вместо bash и Gash Core Utils вместо coreutils, grep, sed, gzip, make, awk и tar, используя только компоненты на языке Scheme. В новой версии также подготовлен пакет с Mes для Debian GNU/Linux.

В следующих выпусках ожидается появление поддержки бутстрэппинга для NixOS, возможность использования dietlibc и uClibc для бутстрэппинга GNU (bash, binutils, gcc, tar), поддержка архитектуры ARM, дистрибутива Debian и ядра GNU Hurd, возможность компиляции Mes.c с использованием M2-Planet.

Региональный интернет-регистратор RIPE NCC, занимающийся распределением IP-адресов на территории Европы, Средней и Центральной Азии, объявил о распределении последнего доступного блока адресов IPv4. В 2012 году RIPE приступил к распределению последнего /8 блока адресов (около 17 млн. адресов) и сократил максимальный размер выделяемой подсети до /22 (1024 адресов). Вчера был выделен последний блок /22 и свободных адресов IPv4 у RIPE не осталось.

Подсети IPv4 отныне будут выделяться исключительно из пула возвращаемых блоков адресов, который пополняется за счёт закрывшихся организаций, владевших IPv4-адресами, добровольной передачи неиспользуемых блоков или изъятия подсетей после закрытия учётных записей LIR-ов. Адреса из пула возвращаемых блоков будут выдаваться в порядке очереди блоками, не превышающими 256 (/24) адресов. Заявки на помещение в очередь принимаются только от LIR-ов, ранее не получавших IPv4-адреса (сейчас в очереди 11 LIR-ов).

Отмечается, что потребность в IPv4 у операторов исчисляется миллионами адресов. Активное внедрение трансляторов адресов (CG-NAT) и возникший последние годы рынок перепродажи IPv4-адресов, являются лишь временными компромиссами, не решающими глобальной проблемы с нехваткой адресов IPv4. Без широкомасштабного внедрения IPv6 рост глобальной сети может быть ограничен не техническими проблемами или отсутствием инвестиций, а банальной нехваткой уникальных сетевых идентификаторов.

По данным, основанным на статистике запросов к сервисам Google, доля IPv6 приближается к 30%, при том, что год назад этот показатель составлял 21%, а два года назад - 18%. Наиболее высокая степень применения IPv6 отмечается в Бельгии (49.8%), Германии (44%), Греции (43%), Малазии (39%), Индии (38%), Франции (35%), США (35%). В России число пользователей IPv6 оценивается в 4.26%, Украине - 2.13%, Республике Беларусь - 0.03%, Казахстане - 0.02%.

По статистике от компании Cisco, доля маршрутизируемых префиксов IPv6 составляет 33.54%. Число пользователей IPv6 в отчётах Cisco примерно соответствует статистике Google, но дополнительно приводятся сведения о степени внедрения IPv6 в инфраструктуре операторов. В Бельгии доля внедрения IPv6 составляет 63%, Германии - 60%, Греции - 58%, Малазии - 56%, Индии - 52%, Франции - 54%, США - 50%. В России степень внедрения IPv6 находится на уровне 23%, Украине - 19%, Республике Беларусь - 22%, Казахстане - 17%.

Среди наиболее активно применяющих IPv6 сетевых операторов выделяются T-Mobile USA - степень внедрения IPv6 95%, RELIANCE JIO INFOCOMM - 90%, Verizon Wireless - 85%, AT&T Wireless - 78%, Comcast - 71%. Число сайтов из рейтинга Alexa Top 1000, доступных напрямую через IPv6, составляет 23.7%.

Компания Mozilla опубликовала финансовый отчет за 2018 год. В 2018 году доходы Mozilla уменьшились на 112 млн долларов и составили 450 млн долларов, в то время как в 2017 году компания Mozilla заработала 562 млн долларов, в 2016 году - 520 млн долларов, в 2015 - 421 млн долларов, в 2014 - 329 млн долларов, в 2013 - 314 млн, 2012 - 311 млн.

429 млн из 450 млн получены благодаря отчислениям за использование поисковых систем (Baidu, DuckDuckGo, Google, Yahoo, Bing, Yandex), сотрудничеству с различными сервисами (Cliqz, Amazon, eBay) и размещению контекстных рекламных блоков на стартовой странице. В 2017 году размер подобных отчислений составил 539 млн. 6.3 млн долларов составили пожертвования, что на 100 тысяч меньше, чем в 2017 году. Объём средств, вложенных в инвестиции в 2018 году составил 368 млн долларов (в 2017 году 414 млн, в 2016 году - 329 млн, в 2015 году - 227 млн, в 2014 году - 137 млн).

Среди затрат доминируют расходы на разработку (277 млн долларов в 2018 против 259 млн в 2017 году, в режиме полного рабочего дня трудоустроено более 1000 сотрудников), поддержку сервисов (33.4 млн долларов в 2018 против 20.7 млн в 2017), маркетинг (53 млн долларов в 2018 против 66 млн в 2017) и административные расходы (86 млн долларов в 2018 и 74 млн в 2017). 4.8 млн долларов потрачено на выплату грантов (в 2017 году - 5.4 млн). Общая сумма затрат составила 451 млн долларов (в 2017 году - 421.8, в 2016 году - 360.6, в 2015 году - 337.7, в 2014 - 317.8, в 2013 - 295 млн, в 2012 - 145.4 млн). Размер активов на начало года - 514 млн долларов, на конец года - 523 млн долларов.

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

Суть метода в том, что владельцы сайтов, желающие разместить код для отслеживания или показа рекламы, создают в DNS отдельный поддомен, ссылающийся на сервер рекламной сети или web-аналитики (например, создаётся CNAME-запись f7ds.liberation.fr, указывающая на сервер трекинга liberation.eulerian.net). Таким образом, рекламный код формально загружается с того же первичного домена, что и сайт, и поэтому не подвергается блокировке. Имя для поддомена выбирается в форме случайного идентификатора, что затрудняет блокировку по маске, так как связываемый с рекламной сетью поддомен трудно отличить от поддоменов для загрузки других локальных ресурсов страницы.

Разработчик uBlock Origin предложил использовать резолвинг имени в DNS для определения связанного через CNAME хоста. Метод реализован в выпуске uBlock Origin 1.24.2 для Firefox. Для активации проверки в расширенных настройках следует установить значение cnameAliasList в "*", в этом случае все проверки по чёрным спискам будут дублироваться и для имён, определяемых через CNAME. При установке обновления потребуется предоставить полномочия для получения сведений из DNS.

Для Chrome проверка CNAME не может быть добавлена, так как API dns.resolve() доступен только для дополнений в Firefox и не поддерживается в Chrome. С точки зрения производительности определение CNAME не должно привести к появлению дополнительных накладных расходов, кроме трат процессорных ресурсов на повторное применение правил для другого имени, так как при обращении к ресурсу браузер уже выполнил резолвинг и значение должно быть прокешировано. Метод защиты может быть обойдён при помощи прямой привязки имени к IP без применения CNAME, но такой подход усложняет сопровождение (в случае смены IP-адреса рекламной сети нужно будет добиться изменения данных на всех DNS-серверах издателей) и может быть обойдён через создание чёрного списка IP-адресов трекеров.