Google meet

В пятницу 4 сентября специалисты Лаборатории Касперского опубликовали отчет (расширенная версия в PDF) об атаках на системы дистанционного обучения.

Тема более чем актуальная: во II квартале миллионы школьников и студентов вынужденно перешли на онлайн-занятия. Соответственно выросло и количество атак как на пользователей платформ для дистанционного обучения, так и на сами платформы. В исследовании Лаборатории Касперского невозможно отделить сугубо образовательные сервисы от систем конференц-связи широкого профиля, поэтому отчет также дает представление об атаках на такие платформы, как Zoom и Google Meet.



Помимо платформ Zoom и Google специалисты Лаборатории Касперского изучали Moodle, Coursera, Blackboard и другие образовательные сервисы. На графике выше проблема показана под интересным углом: это количество заблокированных вредоносных программ, попавших на компьютеры пользователей под видом софта для конкретного сервиса.

Zoom со своим абсолютным лидерством ломает график количество атак на его пользователей за первое полугодие 2020-го выросло в 1400 раз. Помимо этого, число DDoS-атак на сами сервисы стало в пять раз больше. Значительно выросло и число попыток фишинга паролей для доступа к конференц-связи и учебным программам.



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

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

Что еще произошло



В канву креативного фишинга хорошо ложится исследование компании Cofense. Они обнаружили чуть более правдоподобный, чем обычно, метод кражи паролей к корпоративной почте, использующей облачную систему (как правило, на базе Office 365). Атака начинается с традиционного поддельного письма со ссылкой, но по клику по ней открывается фишинговая страница, где на фоне подгружается реальный сайт организации. В некоторых случаях e-mail потенциальной жертвы уже подставлен в поле для ввода.

Модераторы Apple случайно одобрили навязчивый рекламный софт Shlayer для запуска на компьютерах под управлением macOS (см. также новость на Хабре). Кроме того, из магазина приложений Google Play недавно удалили шесть программ со шпионом Joker.

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

Представители Microsoft анонсировали сервис Video Authenticator для борьбы с дипфейками. Конечным пользователям он не будет доступен напрямую по крайней мере, в анонсе про это ни слова. Сервис натренирован на датасете DeepFake Detection Challengе. Недавний конкурс алгоритмов на базе этого же датасета показал средние результаты передовые разработки определяли максимум 65% подделок.

В WordPress-плагине File Manager, набравшем 700 тысяч установок, закрыли уязвимость, но атаки на непропатченные страницы продолжаются.

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

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

Компания Google увеличивает бюджет программы bug bounty, которая должна ответить на вопрос: Как злоумышленники могут использовать сервисы Google во вред?. Почта, Формы, Диск и другие решения корпорации регулярно используются для рассылки спама и распространения вредоносного ПО.

Видеоконференции занимают всё большее место в работе и личной жизни людей. Чем лучше организован процесс с точки обработки видео и приватности, тем меньше отвлекается внимание человека от самой конференции. В рамках этой задачи мы недавно разработали фильтры размытия и замены фона в Google Meet. Они задействуют машинное обучение (ML) для лучшего выделения участников независимо от их окружения. В то время как другие решения требуют установки дополнительного программного обеспечения, функции Meet основаны на передовых технологиях Web ML, построенных с помощью MediaPipe, и работают непосредственно в вашем браузере никаких дополнительных шагов не требуется. Одной из ключевых целей при разработке этих функций было обеспечение производительности в реальном времени в браузере почти на всех современных устройствах, чего мы достигли, объединив эффективные модели ML на устройстве, рендеринг на основе WebGL и вывод ML на веб-стеке с помощью XNNPACK и TFLite.


Размытие и замена фона на основе MediaPipe

Обзор нашего решения Web ML

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

Главным требованием любой мобильной технологии является достижение высокой производительности. Для этого веб-конвейер MediaPipe применяет низкоуровневый бинарный формат WebAssembly, разработанный специально для веб-браузеров и повышающий скорость выполнения сложных вычислительных задач. Во время выполнения браузер преобразует инструкции WebAssembly в машинный код, который выполняется намного быстрее, чем традиционный код JavaScript. Кроме того, в Chrome84 недавно реализовали поддержку WebAssembly SIMD, где каждая инструкция обрабатывает несколько точек данных, что увеличивает производительность более чем в два раза.

Наше решение сначала обрабатывает каждый видеокадр, отделяя пользователя от фона (подробнее о модели сегментации см. ниже), используя вывод ML для вычисления маски низкого разрешения. При необходимости мы дополнительно уточняем маску, чтобы выровнять её с границами изображения. Затем маска используется для рендеринга видеовыхода через WebGL2, а фон размывается или заменяется.


Конвейер WebML: все вычислительные операции реализованы на C++/OpenGL и выполняются в браузере через WebAssembly

В текущей версии расчёт выполняется на CPU клиента с низким энергопотреблением и самым широким охватом устройств. Для достижения высокой производительности в реальном времени мы разработали эффективные модели ML с использованием библиотеки XNNPACK для ускорения расчёта. Это первый механизм видеовывода, специально разработанный для новой спецификации WebAssembly SIMD. За счёт ускорения XNNPACK и SIMD модель сегментации работает в режиме реального времени в интернете.

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

Модель сегментации

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

Общая сеть сегментации имеет симметричную структуру кодирования/декодирования. Слои декодера (светло-зелёный) симметричны слоям кодера (светло-синий). В частности, канальное внимание (channel-wise attention) с пулингом по средней величине (global average) применяется как в блоках кодера, так и в блоках декодера, что снижает нагрузку на CPU.


Архитектура модели с кодером MobileNetV3 (светло-синий) и симметричным декодером (светло-зелёный)

Для кодера мы модифицировали нейросеть MobileNetV3-small, дизайн которой спроектирован автоматически методом поиска сетевой архитектуры для достижения наилучшей производительности на слабом железе. Чтобы вдвое уменьшить размер модели, мы экспортировали её в TFLite с квантованием float16, что привело к небольшой потере точности, но без заметного влияния на качество. В полученной модели 193тыс. параметров и размер всего 400КБ.

Эффекты рендеринга

После сегментации мы используем шейдеры OpenGL для обработки видео и рендеринга эффектов. Задача состоит в эффективной визуализации без артефактов. На этапе уточнения совместный билатеральный фильтр сглаживает маску низкого разрешения.


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

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


Примеры размытия фона

При замене фона используется техника, известная как световая обёртка (light wrapping) для наложения сегментированных лиц на индивидуальный фон. Световая обёртка помогает смягчить края сегментации, позволяя фоновому свету проливаться на элементы переднего плана, увеличива реалистичность композиции. Это также помогает минимизировать артефакты ореола, когда возникает большой контраст между передним планом и фоном.


Примеры замены фона

Производительность

Чтобы оптимизировать работу на различных устройствах, мы предоставляем варианты моделей с несколькими размерами входного изображения (например, 256x144 и 160x96 в текущей версии), автоматически выбирая лучший вариант в соответствии с доступными аппаратными ресурсами.

Мы оценили скорость вывода модели и сквозной конвейер на двух популярных устройствах: MacBook Pro 2018 с 6-ядерным процессором Intel Core i7 2,2 ГГц и Acer Chromebook 11 с процессором Intel Celeron N3060. Для ввода 720p MacBook Pro может запускать более качественную модель со скоростью 120 кадров в секунду и сквозной конвейер со скоростью 70 кадров в секунду, в то время как на Chromebook модель работает со скоростью 62 кадра в секунду с моделью более низкого качества, а сквозной конвейер выдаёт 33FPS.

Скорость вывода модели и сквозной конвейер на ноутбуках высокого (MacBook Pro) и низкого класса (Chromebook)

Для количественной оценки точности модели используются популярные метрики: коэффициент Жакара (intersection-over-union, IOU) и граничная F-мера (boundary F-score). Обе модели демонстрируют высокое качество работы, особенно на такой легковесной сети:


Мы также выложили в открытый доступ карту модели для сегментации, где подробно указаны спецификации для оценки. В оценочные данные входят изображения из 17 географических субрегионов земного шара с аннотациями для тона кожи и пола. Анализ показал, что модель демонстрирует устойчиво высокий результат на различных регионах, оттенках кожи и полах, с небольшими отклонениями в показателях IOU.

Вывод

Таким образом, мы представили новое браузерное решение ML для размытия и замены фона в Google Meet. Благодаря этому решению модели ML и шейдеры OpenGL показывают эффективную работу в интернете. Разработанные функции обеспечивают производительность в реальном времени при низком энергопотреблении даже на маломощных устройствах.

Источник

Технология WebRTC (Web Real-Time Communications), которая описывает передачу аудио-, видеоданных и контента между браузерами без установки дополнительных расширений, получила статус рекомендованного стандарта. Об этом объявил консорциум W3C, который разрабатывает и внедряет технологические стандарты для сети интернет.

Все стандарты W3C проходят проверку на предмет поддержки доступности веб-контента, которая осуществляется APA (рабочей группой по архитектурам доступных платформ). Они напрямую связаны с обеспечением веб-доступности.

Помимо прочего, комитет IETF (Internet Engineering Task Force), который занимается развитием протоколов и архитектуры интернета, опубликовал документы с описанием архитектуры, элементов протоколов, видов транспорта и механизмов коррекции ошибок WebRTC. Все эти данные получили статус Предложенный стандарт.

О WebRTC

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

Технология WebRTC развивается компанией Google с 2009 года. В 2011 году компания открыла свои наработки и технологии обработки звука и видео, полученные при поглощении компании GIPS, разрабатывающей системы цифровой обработки сигналов. Тогда же Google предоставил безвозмездный доступ к патентам, связанным с WebRTC.

WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов. Процесс стандартизации технологии Google начал совместно с такими компаниями, как Mozilla, Microsoft, Cisco и Ericsson.

К слову, WebRTC (как и HTML5) стал одной из причин смерти технологии Flash. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология исчезла с рынка. О последствиях мы уже писали в блоге.

Сейчас технология WebRTC занимает второе место в топе протоколов видеосвязи после проприетарного Zoom. Стандартным протоколам H.323, SIP, Microsoft Teams и Cisco Webex пока не удается достичь ее успеха.

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

Преимущества стандарта

• Не требует установки программного обеспечения и плагинов.
• Использование современных аудио- и видеокодеков; как следствие высокое качество связи.
• Защищенные и зашифрованные соединения по протоколам DTLS и STRP.
• Есть встроенный механизм захвата контента (демонстрация рабочего стола)
• Гибкость реализации интерфейса управления на основе HTML5 и JavaScript.
• Открытый исходный код.
• Универсальность: приложение на основе стандарта хорошо работает на любой ОС, если браузер поддерживает WebRTC.

Недостатки стандарта

Для кого-то эти недостатки не будут существенными, но мы их все-таки обозначим.

• Стандарт не поддерживает удаленное управлением рабочим столом. То есть мы можем показать презентацию или график коллегам, но поработать вместе над составлением годового отчета не получится. Все ради безопасности: код Javascript не может управлять чем-либо за пределами текущего окна браузера. Для расширенных возможностей нужно использовать специально разработанные приложения.
• Приложения на WebRTC несовместимы между собой, именно поэтому мы не можем позвонить c Google Meets на какой-нибудь BigBlueButton. Но, может, это и не надо?
• Еще один недостаток состоит в том, что WebRTC определяет IP-адреса пользователей. Прокси и Tor c проблемой не справятся, скрыться помогут только VPN-сервисы.

Работа технологии на примере звонка между двумя абонентами через браузер. Источник

Из чего состоит WebRTC

На структурном уровне это:

• системы управления пользовательскими сеансами;
• движок для обработки звука: можно использовать разные кодеки и методы подавления шумов;
• движок для обработки видео;
• транспортный уровень: для передачи данных можно использовать протоколы DTLS и SRTP совместно с технологиями организации P2P-каналов связи.

Как мы уже писали ранее, работать с возможностями WebRTC можно через специально подготовленный JavaScript API. API включает в себя такие интерфейсы, как getUserMedia, RTCPeerConnection, RTCDataChannel и getStats.

Интерфейс getUserMedia отвечает за получение аудио и видео из подключенных устройств типа веб-камеры и микрофона или файла. За установку соединения между пользователями, обработку сигналов и защиту канала связи отвечает интерфейс RTCPeerConnection. Обмениваться данными во время конференции помогает RTCDataChannel (с использованием типового API WebSockets). За статистикой к интерфейсу getStats.

Что дальше

На данный момент стандартизированы только базовые части WebRTC. А что можно ожидать в следующей версии стандарта?

• Расширение, которое позволит использовать протокол QUIC в качестве транспорта и видеокодека AV1.
• API WebTransport, упрощающего организацию потокового вещания для нескольких получателей.
• API Scalable Video Coding, адаптирующий видеопоток под пропускную способность клиента.
• Сквозное шифрование видеоконференций.
• Live-обработка аудио- и видеопотоков, в том числе с помощью систем машинного обучения.
• Инструменты для установки постоянного канала связи с умными устройствами.