Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
Надо бы такое прикрывать. Так же и враги трафик могут гнать.
Так вы врагов не заводите, и не кому будет.
проблема нерешаемая.
утопическая мечта не ведет к отчаянию, и нет никакой лжи в том, чтобы медленно варить лягушку. Страшно то, что язык искажается мыслью, а мысль искажается языком
Бей своих чтоб чужие боялись. Отличный подход, очень перспективный. Но тогда для своих не очень понятно чем они отличаются от чужих и почему бьющий для них является своим.
Так выгоните врагов из кремля и не смогут
Это имело бы смысл, если бы блокировки были от "них"
Мой враг - чей-то друг. За каждую жизнь, что обрывается под клинком, умирает одно добро и одно зло. Закон равновесия.
Враги покупают симки в СНГ странах. Интернет на зарубежных симках не блочат.
Меня, в целом, не удивляет такое число людей, верящих мошенникам. Судя по персонажам, на полном серьезе принимающим рассказы про защиту от врагов за чистую монету
10 лет комментов не было от тебя и сегодня ты пишешь про каких-то безымянных врагов? А они не в Кремле или бункере случайно?
похоже во врагах сейчас по большей части население страны. А учитывая, что ТСПУ не блочат роуминговый трафик иностранных симкарт так и вообще подозрения переходят в уверенность.
Был очень счастлив почувствовать на себе белые списки, когда даже до домашней видеокамеры и файлсервера не достучатся.
Вы и есть враги
Очень годно, ввиду последних событий, мерси. 👍
P.S. жаль что реклама 🤔
Хоть я живу в регионе где нету БС (Слава тебе Господи), похоже на очень очевидный блок Телемоста или DC траффика. Уже видел подобные реализации для ВК, у всех кто пользовался таким перебанило аккаунты, ваще некомельфо одним словом...
Проект крутой, но это всё же игра в кошки мышки, лучше сидеть дома и работать на удалёнке если разрешают :)
чтобы заблокировать этот VPN придется запретить MAX и Yandex
но самое главное - этот способ теоретически не заблокировать не отключив MAX / Telemost
по факту этот метод вечный и не блокируемый
При этом в том же списке описан тысяча и одна способ, которым Яндекс может ограничить работу решения (порезать datachannel-трафик). Видеоканал с QR-кодами блокировать можно банально беря случайный кадр из потока и проверяя, является ли он QR-кодом.
Очень много пафоса для статьи, у которой вычитка хуже, чем у надписи на заборе.
ты текст вообще читал? прямым текстом написано - метод бл не блокируемый, его можно подавить ( скорость упадет потому что будет осуществлен переход на видеоканал ) но не заблокировать, я перечислил ПРОБЛЕМЫ РЕАЛИЗАЦИИ а не проблемы протокола BareBone22
единственный способ его заблокировать - блокировка Yandex телемост.
Яндекс может блокировать аккаунты. Если не ошибаюсь, для регистрации в Я требуется номер телефона. Так симок не напасаешься.
протокола BareBone22
Призрачное название, которое не гуглится, не ищется в канале OLC, не ищется в чате OLC, которое ни разу не упоминается в репозитории OLCRTC, а в статье упоминается без единого пояснения, что это за протокол и в чём его суть. Где тогда проводится грань между протоколом и реализацией? Передача с помощью QR-кодов является частью протокола?
Ну допустим не qr код а поле для игры в го, на котором кто то ооочень быстро переставляет фишки.
Можно транслировать записи созвонов. Через нейросеть делать запись уникальной. Пересоздавать постоянно комнаты созвона.
Сами данные передавать в определенных пикселях видеопотока. Причем это можно сделать так что визуально вообще не понятно что передаются какие-то данные. Уже есть такие методы скрытой передачи данных через изображения.
Я думаю в конце концов к этому и придем. Либо им придется резать зарубежный трафик.
Просто заведите друзей в странах СНГ, пусть вслух читают/пересказывают нужные вам вещи из свободного интернета) Для конспирации можно придумать свой язык типа клингонского
звонок через Макс какому-нибудь Махмоджону: ну что, родной, давай рассказывай что там пишут в моем любимом телеграмм-канале. Он вам: wej De’ chu’ tu’lu’, vay’ wIloSlI’ Hoch
Вместо QR кодов можно использовать другие способы кодирования данных в видеопотоке. Стеганографию не вчера придумали.
только потери будут огромные , ну а так вы правы, просто QRы самое легкое для реализации пока что
Представляю себе сколько ресурсов потребуется при массовом использовании для декодирования налету для анализа.
не понял, как это решит проблему белых списков. Если исходящие соединения тоже будут фильтроваться, а это необходимо, иначе есть способы и попроще обойти блокировки, то телемост никак не поможет. Просто абоненты из-за рубежа не смогут пользоваться телемостом.
Сейчас пока все таки белого списка нет в большинстве регионов РФ. Поэтому большинство методов и так работает. Были некоторые перебои до 7 апреля, но сейчас все в порядке. Все адаптировались. Многие перешли на тг прокси, телеграм обновил поддержку прокси.
в созвоне телефон и домашний пк/местный сервер могут обмениваться трафиком, а там уж что куда
ниже человек сказал "в созвоне телефон и домашний пк/местный сервер могут обмениваться трафиком", дальше думаю все понятно
во вторых "Просто абоненты из-за рубежа не смогут пользоваться телемостом" так купите RU VPS, даже айпи не надо ловить кек
Посмотрите реализации VK TURN, WB TURN, DataChannel. Все они используют инфраструктуру белосписочных сервисов, чтобы передавать данные. Проблема на той стороне известная, VK каждую неделю дрючит свой апи и пытается прикрутить капчу, рано или поздно они эту проблему решат, останется только кодировка данных в видео, но там скорости хуже модема будут, как я писал выше уже быстрее будет голубей отправлять.
Нет, если передавать данные прямо в битстриме, то скорость будет не настолько уж и плохая, 1.7 мегабит и до 3.5мбит если вам 1080p разрешат. Вот только без сквозного шифрования будет видно на сервере, что видео не раскодируется.
Это вы без потерь и коррекции ошибок посчитали, или какое-то готовое решение такие цифры заявляет? Я бы посмотрел.
Можно в видео-фреймы потока просто байты данных класть. Соблюдая только обертку. Да, оно не будет как видео раскодироваться, но ведь вам и не надо. А сервер в норме только конверт раскрывает и байты перекладывает не разжимая.
Это сырой битрейт передачи данных. Небольшие потери будут автоматически восстановлена средствами webrtc (NACK/RTX) и вы их даже не заметите. Но при достаточно больших потерях случится страшное: будет запрос на новый ключевой кадр или получатель просто дропнет какой-то фрейм. Вместе с большим и нестабильным RTT это может сделать TCP трафик медленным. Но это должно быть весьма редкое событие.
Какой предполагается фреймрейт использовать для передачи данных, неужели родной и без CRC? Потому что все решения по трансляции видео, что я видел, далеки от простого воспроизведения условного youtube видео в плане стабильности. Плюс еще большой вопрос, как P и B фреймы отнесутся к блокам, которые меняются каждый кадр - это чуть ли не каждый кадр уже должен быть I-фреймом.
Фреймрейт будет стандартный, 30 фреймов в секунду. Но это не важно. CRC там уже есть на уровне пакетов в DTLS.
В RTC видео нет никаких P/B фреймов и I-frame пытаются посылать как можно реже.
Смотрите на это так: вот у вас есть энкодер, он выдает какой-то битстрим. Какие-то бинарные данные. 1.7mb/s. И эти данные как-то сами без ошибок и перестановок попадают на декодер на другом конце. В удачном случае целиком. В неудачном случае с редкими пропусками куска. Вам не важно что там с фреймрейтом, как устроены фреймы, что за кодек. Вот есть у вас тоннель.
Вы эти данные на отправителе переписываете на свои собственные (с какой-то служебной информацией, чтобы можно было их на нормальные IP пакеты порезать на другом конце), и получаете на другом конце.
Вы не предаете ваши данные в виде пикселей, которые энкодер потом как-то квантует. Там все будет действительно очень грустно, потому что сжатие с дикими потерями.
Для этого придется собирать свой собственный хром, с пропатченными энкодерами/декодерами. Если надо, я даже подскажу где и как это сделать. Энкодер вместо условного h264 битстрима вставляет (зашифрованные, конечно) ваши данные и тупо игнорирует входной видео-поток. Декодер полученный битстрим выдает из тоннеля, и выдает очередной кадр из фиктивного видео файла назад в web приложение.
Не знаю, может и не нужен целый хром. Может можно просто прикидываться веб-приложением и посылать всякие http запросы и DTLS/RTP трафик. Но это проще детектить будет. А если пропатченный хром еще и реалистичные задержки ставит и прикидывается, что он что-то там кодирует/раскодировывает, то это очень сложно обнаружить. Это надо попытаться видео на сервере перекодировать. Это дорого и без особой надобности этого не делают обычно. А если еще и E2E шифрование на клиенте работает, то это вообще невозможно.
В RTC видео нет никаких P/B фреймов и I-frame пытаются посылать как можно реже.
Подождите, как это "нет p/b фреймов", все консьюмерские кодеки буквально на них и работают. Пошел проверить, может это я чего-то не понимаю:
https://developer.mozilla.org/en-US/docs/Web/API/RTCEncodedVideoFrame
There are many different codecs, such as H.264, VP8, and VP9, each that have a different encoding processes and configuration, which offer different trade-offs between compression efficiency and video quality.
The
RTCEncodedVideoFramerepresents a single frame encoded with a particular video encoder.
Ни один из этих кодеков не подразумевает стриминг lossless видео (ну то есть там конечно есть CRF 0, но им никто в здравом уме не пользуется, особенно в Интернете).
Абсолютно все потребительские кодеки жмут видео как минимум P-фреймами, их буквально в стандартном видео файле (обычно 1 из 30 кадров ключевой).
Или вы про передачу данных не через видео, а через сопутствующий DataStream? Их уже давно начали резать ЕМНИП.
UP: все, перечитал
Вы не предаете ваши данные в виде пикселей, которые энкодер потом как-то квантует. Там все будет действительно очень грустно, потому что сжатие с дикими потерями.
Хотелось бы увидеть реализацию.
Подождите, как это "нет p/b фреймов"
Я не это имел ввиду. Там почти везде каждый фрейм ссылается на предыдущий и все. Очень простая структура. Но это не важно.
RTCEncodedVideoFrame
Вы этот Encoded transform незаметно не сможете навесить наверно, думаю приложение как-то сможет изменение повдедения. Хотя эта идея очень близка к моей и даже проще в реализации. Этот трансформ - это lossless изменение битстрима. Им, например, можно сделать E2E шифрование. А можно тупо заменять закодированные данные на то, что вы хотите передать. Это и есть мое предложение.
Ни один из этих кодеков не подразумевает стриминг lossless видео (ну то есть там конечно есть CRF 0
Еще раз, никакого видео кодирования в этой схеме вообще не происходит. Наш волшебный кодек вместо h264 битстрима выдает содержимое тоннеля. Вообще игнорируя видео с камеры, настройки и все что угодно кроме только битрейта. А декодер это содержимое выливает в сеть на своей стороне и выдумывает видео картинку для обдуривания приложения. Если выдерживать правдоподобные размеры закодированных фреймов на отправителе, то это будет не видно никак приложению. Или можно не удалять настоящий кодек, а просто перезаписывать им произведенные данные с тем же размером. Задержку только реалистичную надо еще на декодере проэмулировать.
Или вы про передачу данных не через видео, а через сопутствующий DataStream? Их уже давно начали резать ЕМНИП.
Нет, я про передачу данных ВМЕСТО видео. Вместо закодированного видео. Еще раз, данные не сжимаются кодеком. Данные тупо перезаписывают его работу. Раскодировать это в видео, конечно, не получится никак. На принимающей стороне надо будет видео просто "выдумать". На уровне хрома это просто - декодер выдает видео фрейм из локального файла.
В коде хрома всё ещё массив байт, который он получает от какого-то кодека. Если врезаться здесь, то никакой перекодировки уже не случится. И если хром на той стороне или mitm не будет пытаться читать это как кадр видео, то вот ваш канал. Не надо подменять пользовательский видеопоток своим. Прям на низком уровне самой библиотеки webrtc сказать, что там условный VP9, а положить сырые данные.
для доступа в интернет можно и капчу решать периодически
Нужно. Но капча - это первый и самый простой шаг. Дальше количество и сложность костылей будет только расти.
Проблема в том, что ее надо будет решать и со стороны выхода канала - на том сервере, который в свободном интернете. Для этого надо туда доступ как-то получить, а для этого нужен рабочий тоннель.
мне самому забанили VPS за перебор IP в Yandex Cloud
после этого пассажа к статье доверия 0. Ну отсканировал ты подсети Яндекса и что? Адреса выдаются свободные из пулов по очереди и не факт, что тебе нужный адрес выпадет. Это не считая того, что облако у Яндекса ваще не дешевое. Или автор пишет письмо в саппорт с просьбой дать ему именно тот IP, который он хочет. Афигенские истории короче.
технически идея хорошая, но непонятен пафос про "непотопляемость" метода
способов сломать такой канал передачи - куча:
Участие в конференциях/созвонах только для верифицированных аккаунтов (по номеру телефона, а то и по паспорту). Мгновенный бан за неправомерное использование канала - устанете симки покупать
Про использование датаканала и так все сами написали - анализ трафика простейший на аномалии
Попытка пропихнуть данные через видеоканал - тоже не проблема, раз в минуту дергаем случайный кадр из видеопотока, при аномалиях роняем частоту кадра или качестве видео на пару секунд - люди на совещании это переживут, а ваш тайный канал захлебнется
4. Самое простое, судя по тому, что это первое, что сделал ВК после появления аналогичного инструмента для их звонков - капча на присоединение к конференции (я в курсе, что там это уже порешали, но это, как говорится, не столько заслуга решивших, сколько недоработка ВК).
P.S. Вообще двойственные ощущения от статей, раскрывающих эту тему. С одной стороны, дело нужное. С другой - чем больше информации про какой-то способ засвечено, тем быстрее его прикроют.
а ваш тайный канал захлебнется
никуда он не денется, тупо упадет скорость причем далеко не до нулевого уровня
или надо деградировать видеоканал до неприемлемого качества от чего постродают люди на совещаниях
Кстати непонятно зачем вообще видеосовещания нужны в ситуации белых списков. Типа если уж взялись ломать вообще всё, не оглядываясь на ущерб, то странно будет ожидать, что качественная видеосвязь станет препятствием на их пути. Ну значит видеосвязь не позволяет защитить наших детей от педофилов, привыкайте созваниваться голосом, скажите спасибо что мы тут вообще вам пытаемся хоть какую-то связь обеспечить, а не просто рубильник дёрнули
Неужели яндекс может так спокойно посмотреть любой кадр из видеопотока? Кто тогда вообще пользуется таким сервисом?
Неужели яндекс может так спокойно посмотреть любой кадр из видеопотока?
...о некоторых вещах лучше сильно не задумываться...
вы знаете что рядовой операционист в банке может смотреть в какой вы ресторан ходите и какую зарплату получаете, вы после этого перейдете на наличку полностью отказавшись от безнала?
а ведь так и есть, там чуть ужесточили доступ, но в целом оно всёравно примерно так и осталось, какойнить начальник разработки или админов или ИБ всёравно имеет полный доступ
Вообще, может. И гугл может. Там соединение происходит с сервером. Сервер потом ваше видео раздает всем остальным клиентам. Потому что каждому из нескольких собеседников отдельно ваше видео передавать - никакой пропускной способности у вас не хватит. Гугл вообще умеет ваше видео перекодировывать на лету, если получатель не умеет раскодировать то, что вы можете посылать. Или накладывать фильтры вроде замены фона, если ваш комп не тянет.
У гугл meet есть отдельный режим работы со сквозным шифрованием, если кому-то особо важно, и некоторые корпоративные клиенты им пользуются. Но там всякие дополнительные плюшки обработки на серверах не работают. Есть ли такое у Яндекса и можно ли частникам такое себе замутить я не знаю.
Но с другой стороны, никто ваше видео смотреть не будет. Хранить его экономически нецелесообразно. А для товарища майора хватит и записи звука.
Но точно также почти все мессенджеры могут ваши сообщения читать. Есть режимы вроде секретных чатов в телеграмме, но ими без особой надобности не пользуются, потому что неудобно.
Так что если вам важна строгая гарантия приватности - не пользуйтесь корпоротивным мейнстримом. Поднимайте свой собственный сервер jitsi meet или еще чего-то такого.
Тема эта давно в воздухе летает. И где-то уже видел подобное. Вся проблема в Geo-fencing мне кажется. Ибо РКН увидит что ты подключаешься прокладке.Но также мысли были хотя бы узкий канал использовать для мессенджеров. И как идея если накроется трех буквенный из клиентской сети. То как вариант OlcRTC + Матрешка, надо пробовать. Но опять же. ХЗ как у них реализован белый список. Если из вне в мост зайти на списке нельзя то и смысла нет.
проблема в сложности всего этого, каким бы подход не был убиваемым - его сложность будет расти бесконечно
даже вот люди в коментариях некоторые не понимают как это вообще работают от чего делают не верные выводы
вообщем, не решаемая проблема
В Google Meet есть вариант с E2E шифрованием трафика. Поддерживает ли такое Телемост?
Вообще, данные можно гонять в видео потоке напрямую. Надо лишь собрать собственный хром для двух клиентов, там енкодер/декордер тупо игнорируют данные с камеры и выдают данные для тунеля/из тунеля. Или какой-то паддинг, если нечего передавать. Надо только размер каждого закодированного фрейма выдавать случайного размера, но примерно в зависимости от установленного битрейта.
Это яндекс вообще никак отследить не сможет. Обычный хром клиент, передает какое-то видео, и посмотреть его из-за Client-Side-Encryption никак. Возможно надо будет переодически начинать новую конференцию и переподключатся с разными пользователями, а то видеозвонок висящий 24/7 все сломает.
Можно и без своей криптографии, но тогда яндекс может заметить ботву в видеопотоке.
Данные кодируются в QR-коды, передаются в видеотреке с 1 FPS
Можно проапгрейдиться до 106 КБ/сек: https://github.com/sz3/libcimbar ;)
Странно. Были подобные идеи, спрашивал у знакомых кто с бс часто сталкивается. Сказали что Телемост не работает. Возможно зависит от оператора. На Т2 допустим у меня бс вообще не работают, просто нет интернета мобильного, даже когда он есть у всех вокруг на других операторах.
возможно с 17 марта что-то изменилось
Телемост по большей части не работает, VK и WB Turn проверял буквально сегодня - работают.
Как я понял, ВК усложняет капчу на звонки не по дням, а по часам: https://github.com/MYSOREZ/vk-turn-proxy-android/issues/26#issuecomment-4199792629
Боюсь, к концу месяца эта лавочка будет прикрыта окончательно, как в своё время с телемостом произошло.
у меня работает, идк
Как быстро заблокируют видеозвонки за границу?
на 4pda писали что через телемост лавочку прикрыли, вроде еще месяц назад
Пока какие-нибудь пинги ходят за бугор или DNS резолвится - проще их, наверное, юзать)
эта наша еженедельная борьба молота и наковальни восхищает и печалит одновременно)) вроде уже достигли дна, нет уж, вот вам еще свежие приколы) даже в завтрашнем дне нету стабильности!
следующий уровень. в ВК самому себе слать голосовухи -- ну и там как модем шипеть, или голосом команды отдавать -- а дома пк расшифровывает, лезет в "небелый" чебурнет, и в личку вк шлет ответ) такой вот гипертекстовый фидонет...
Данные кодируются в QR-коды
Избыточно. DataMatrix плотнее, свой собственный формат без дополнительных прицельных "приспособлений" будет ещё более эффективен
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BAREBONE2022: чтобы заблокировать этот протокол придется запретить MAX и Yandex