Чертовски хороший вопрос! Если говорить про кс: HLTV не дает себя нормально парсить. Чисто по ощущениям, в кс на про-сцене, если говорить не только про тир-1 (границы которого зависят от контекста, вчерашние диггеры CCT могут попасть на мажор) больше всего игроков из CIS региона. Чисто статистически россиян среди них преобладающее количество.
Но если провести подсчет по плотности (например, количество профилей на хлтв из определенной страны делить на количество населения в этой стране), уверен, Россия окажется не на первом месте.
Но справедливо, что ОИ - это именно топовые игроки. Которых действительно много из России.
При этом я не согласен с вашим посылом, что именно это причина топика. Киберспорт не ограничивается продуктами валв. Дота умирает. В североамериканском регионе популярен валорант. Лол, пабг, мобилки, чётам_у_китайцев_сейчас_в_топе и прочие факторы сильно влияют на принятие решения комитета - а нафига им полагаться на дисциплины, срок жизни которых так мал? Как там дела со старкрафтами у корейцев? Тут и фактор владельца авторских прав, кстати, емнип не в последнюю очередь из-за близзов дисциплина умерла. А ведь тоже были турниры со сборными стран в свое время.
Извините, я далек от обсуждаемой темы. Мне казалось, что Kubernetes и подобные ему системы оркестрации - это то, что используется в коммерческой разработке, о которой речь в этой ветке.
Вся цепочка доверия (Secure Boot, TPM) - нужна в том числе для защиты от атак типа evil maid. Если вам поставили буткит, о котором система ничего не знает, то все ваши меры предотвращения угроз на уровне пользователя ничего не стоят. Безопасность - это всегда комплекс мер. Вытащите один кирпич - рухнет пирамида.
Я не знаю, как там у тбанка сейчас реализовано и как будет завтра, но у меня какое-то другое приложение (то ли другого банка, то ли маркетплейса, не помню точно) с месяц показывало эту плашку про впн при подключении просто к домашнему вайфаю. Безо всяких впн и средств обхода. И недавно перестало.
Чего там разработчики за логику понакрутили - остается только догадываться.
Повторюсь. У вас цель - убрать плашку и заставить приложение работать прямо сейчас. Цель, заявленная в статье изначально, несколько иная. И она указанным в статье способом не может быть достигнута.
Из заголовка и посыла статьи сложилось впечатление, что смысл - отправить приложения, которые собирают информацию о наличии тоннеля, в песочницу, чтобы ограничить им такую возможность. Что на текущий момент средствами ОС Android нереализуемо.
Если смысл просто пустить приложение в обход тоннеля, не заботясь о том, известно ли приложению о наличии тоннеля - ну ок, сегодня засовывание приложения в рабочий профиль работает, завтра перестанет 🤷 Это ж все упирается в реализацию детекта в самом приложении, и в общем случае приложению для детектирования тоннеля трафик куда-то слать необязательно.
Что касается сетевого анализатора для телефона - да, есть такой, PCAPdroid называется. Вот только он свой VpnService имплементирует, чтобы собирать трафик без использования root-доступа. Другими словами, с ним у вас банковское приложение не запустится.
Не понимаю, что вы собираетесь проверить с помощью сетевого анализатора. Факт отправки трафика в тоннель и факт получения информации о наличии тоннеля в системе в общем случае тоже не связаны.
ТС добавил в статью ссылку на само исследование (которое делали не в Шкоде). Выше в комментариях я привел цитату из него со скришотом графика АЧХ. Это не похоже на то, что делалось специально, либо же это сделано в какой-то одной модели, и из-за нее поехала статистика общая (график усредненный для всех моделей, коих там всего 6 штук, видимо самых продаваемых). Тон сигналов в самолете стандартизирован, их там всего 2, они лежат в диапазоне около 540Гц (хотя пишут, что у Эирбаса они как раз 800-1000Гц, но источника инфы у меня нет). На этой и соседних частотах никакого падения уровня аттенюации нет, исследовались в целом не программные методы автоматического отключения шумодава, а работа его как такового.
К самой методике исследования лично у меня вопросов нет. У меня до сих пор остались вопросы к результатам. Нет сводной таблицы по всем моделям на всех видах тестирования.
Собственно, про исследование разных шумодавов там не очень подробно (в плане метрик, там уже готовые результаты), хоть и выводы любопытные (эпл давит лучше всех, например). Что касается ачх, то вот:
Figure 3 shows the average third-octave band attenuation spectrum across all headphones for the test signals. It can be seen that for signals which contained broadband noise, there is an increase in attenuation above 2 kHz, corresponding to approximately 6 dB. However, for tones-in-tones signals, this increase is not observed. There is a local dip of approximately 3 dB in the attenuation curve for tone-in-tone and mixed signals in the 800 Hz band. When controlling for differences between headphones it was found that tone-in-tone signals were attenuated by 4.9 dB less than mixed signals and 8.9 dB less than noise-in-noise signals (p< 0.05). There was no statistically significant association between impulsivity of the sounds or the decay time of the sounds.
То есть на частоте 800Гц средний шумодав аж в 2 раза хуже давит тональный сигнал, чем на соседних частотах.
Если честно, это удивляет. Жалко, что в исследовании только методика измерений и средний результат, нет подробных метрик по всем устройствам. Я не исключаю проблем со статистикой.
Если так, то "пусть в известное место себе эту звенелку засунет" - типичные и, что характерно, резонные мысли среднестатичтического пешехода на такой дорожке.
То есть, в целом, эту проблему звонок не решает.
Но как часть мер по безопасности движения - пусть лучше будет, чем нет.
The company intends to make the underlying research findings and insights publicly available.
Это текст из оригинальной статьи. А у вас тут написано:
Skoda не продаёт этот звонок, но результаты исследований находятся в свободном доступе.
Так вот приведите, пожалуйста, ссылку на эти результаты исследований британских ученых, которые Шкода только собирается опубликовать.
Потому как к "слепой зоне" есть вопросы. Инфографика в виде АЧХ с провалом на 780Гц - это, конечно, красивый маркетинговый булщит, но хочется увидеть, что они там реально наизмеряли для разных производителей ANC.
Оу, благодарю за линк. Последний раз поддержку в опенврт я смотрел лет 5 назад, а там как раз указано что поддерживается с версии 22.03.0. У меня устаревшие данные стало быть, как-то умудрились разработчики запилить поддержку BCM53xx. И за линк на flowtable тоже) Интересно.
> Да потому что эта функция нужна в РФ, да в Китае МБ. Нене, я про hairpin NAT, это когда машины из локальной сети могут получить доступ к внутренним сервисам при обращении на внешний адрес роутера (при условии проброшенных портов, естественно). Если включать HW NAT offloading, то просто перестает работать вот это правило: `-A POSTROUTING -s $lan_subnet -d $lan_subnet -o $lan_bridge_if -j MASQUERADE` Сами пакеты проходят через проброшенные порты, но вот после рукопожатия (когда обработка потока уходит в железо) напрочь отключается SNAT и сервер начинает получать от роутера пакеты с адресом клиента в локальной сети, а не с адресом роутера.
Впрочем, возможно дело именно в MASQUERADE, который сам по себе довольно тяжелый и требует получать информацию о текущем адресе на интерфейсе, а таблицам в железке неоткуда угадывать этот адрес. Надо будет попробовать просто SNAT вместе с HW offloading.
Мы все еще про киберспорт? Общая сумма призовых падает год от года, организации перестраивают экономику, сокращается количество инвестиций.
Чертовски хороший вопрос! Если говорить про кс: HLTV не дает себя нормально парсить. Чисто по ощущениям, в кс на про-сцене, если говорить не только про тир-1 (границы которого зависят от контекста, вчерашние диггеры CCT могут попасть на мажор) больше всего игроков из CIS региона. Чисто статистически россиян среди них преобладающее количество.
Но если провести подсчет по плотности (например, количество профилей на хлтв из определенной страны делить на количество населения в этой стране), уверен, Россия окажется не на первом месте.
Но справедливо, что ОИ - это именно топовые игроки. Которых действительно много из России.
При этом я не согласен с вашим посылом, что именно это причина топика. Киберспорт не ограничивается продуктами валв. Дота умирает. В североамериканском регионе популярен валорант. Лол, пабг, мобилки, чётам_у_китайцев_сейчас_в_топе и прочие факторы сильно влияют на принятие решения комитета - а нафига им полагаться на дисциплины, срок жизни которых так мал? Как там дела со старкрафтами у корейцев? Тут и фактор владельца авторских прав, кстати, емнип не в последнюю очередь из-за близзов дисциплина умерла. А ведь тоже были турниры со сборными стран в свое время.
Извините, я далек от обсуждаемой темы. Мне казалось, что Kubernetes и подобные ему системы оркестрации - это то, что используется в коммерческой разработке, о которой речь в этой ветке.
Например, через совместное использование слоев с привилегированным контейнером.
А вообще, ждем вторую часть от исследователей, обнаруживших уязвимость, под названием "From Pod to Host", в которой они обещают описать побег из контейнера.
Вся цепочка доверия (Secure Boot, TPM) - нужна в том числе для защиты от атак типа evil maid. Если вам поставили буткит, о котором система ничего не знает, то все ваши меры предотвращения угроз на уровне пользователя ничего не стоят.
Безопасность - это всегда комплекс мер. Вытащите один кирпич - рухнет пирамида.
Я не знаю, как там у тбанка сейчас реализовано и как будет завтра, но у меня какое-то другое приложение (то ли другого банка, то ли маркетплейса, не помню точно) с месяц показывало эту плашку про впн при подключении просто к домашнему вайфаю. Безо всяких впн и средств обхода. И недавно перестало.
Чего там разработчики за логику понакрутили - остается только догадываться.
Повторюсь. У вас цель - убрать плашку и заставить приложение работать прямо сейчас. Цель, заявленная в статье изначально, несколько иная. И она указанным в статье способом не может быть достигнута.
Из заголовка и посыла статьи сложилось впечатление, что смысл - отправить приложения, которые собирают информацию о наличии тоннеля, в песочницу, чтобы ограничить им такую возможность. Что на текущий момент средствами ОС Android нереализуемо.
Если смысл просто пустить приложение в обход тоннеля, не заботясь о том, известно ли приложению о наличии тоннеля - ну ок, сегодня засовывание приложения в рабочий профиль работает, завтра перестанет 🤷 Это ж все упирается в реализацию детекта в самом приложении, и в общем случае приложению для детектирования тоннеля трафик куда-то слать необязательно.
Что касается сетевого анализатора для телефона - да, есть такой, PCAPdroid называется. Вот только он свой VpnService имплементирует, чтобы собирать трафик без использования root-доступа. Другими словами, с ним у вас банковское приложение не запустится.
Не понимаю, что вы собираетесь проверить с помощью сетевого анализатора. Факт отправки трафика в тоннель и факт получения информации о наличии тоннеля в системе в общем случае тоже не связаны.
"Перестал просить отключить VPN" и "перестал получать информацию о наличии VPN" - утверждения со слабой причинно-следственной связью.
ТС добавил в статью ссылку на само исследование (которое делали не в Шкоде). Выше в комментариях я привел цитату из него со скришотом графика АЧХ.
Это не похоже на то, что делалось специально, либо же это сделано в какой-то одной модели, и из-за нее поехала статистика общая (график усредненный для всех моделей, коих там всего 6 штук, видимо самых продаваемых).
Тон сигналов в самолете стандартизирован, их там всего 2, они лежат в диапазоне около 540Гц (хотя пишут, что у Эирбаса они как раз 800-1000Гц, но источника инфы у меня нет). На этой и соседних частотах никакого падения уровня аттенюации нет, исследовались в целом не программные методы автоматического отключения шумодава, а работа его как такового.
К самой методике исследования лично у меня вопросов нет. У меня до сих пор остались вопросы к результатам. Нет сводной таблицы по всем моделям на всех видах тестирования.
Благодарю!
Собственно, про исследование разных шумодавов там не очень подробно (в плане метрик, там уже готовые результаты), хоть и выводы любопытные (эпл давит лучше всех, например). Что касается ачх, то вот:
То есть на частоте 800Гц средний шумодав аж в 2 раза хуже давит тональный сигнал, чем на соседних частотах.
Если честно, это удивляет. Жалко, что в исследовании только методика измерений и средний результат, нет подробных метрик по всем устройствам. Я не исключаю проблем со статистикой.
Если так, то "пусть в известное место себе эту звенелку засунет" - типичные и, что характерно, резонные мысли среднестатичтического пешехода на такой дорожке.
То есть, в целом, эту проблему звонок не решает.
Но как часть мер по безопасности движения - пусть лучше будет, чем нет.
Это текст из оригинальной статьи. А у вас тут написано:
Так вот приведите, пожалуйста, ссылку на эти результаты исследований британских ученых, которые Шкода только собирается опубликовать.
Потому как к "слепой зоне" есть вопросы. Инфографика в виде АЧХ с провалом на 780Гц - это, конечно, красивый маркетинговый булщит, но хочется увидеть, что они там реально наизмеряли для разных производителей ANC.
А у кого преимущество на такой дорожке?
А еще постучать на "недоступный" STUN этого TG и узнать, с какого выходного адреса он доступен.
Оу. My bad, сложно следить за всей этой конъюнктурой.
Гарем чтоли?
С каких пор Ашманов - противник анонимности?
Его заявления говорят об обратном.
У них еще md5 от пароля в куках хранилось.
Оу, благодарю за линк. Последний раз поддержку в опенврт я смотрел лет 5 назад, а там как раз указано что поддерживается с версии 22.03.0. У меня устаревшие данные стало быть, как-то умудрились разработчики запилить поддержку BCM53xx.
И за линк на flowtable тоже) Интересно.
> Да потому что эта функция нужна в РФ, да в Китае МБ.
Нене, я про hairpin NAT, это когда машины из локальной сети могут получить доступ к внутренним сервисам при обращении на внешний адрес роутера (при условии проброшенных портов, естественно). Если включать HW NAT offloading, то просто перестает работать вот это правило:
`-A POSTROUTING -s $lan_subnet -d $lan_subnet -o $lan_bridge_if -j MASQUERADE`
Сами пакеты проходят через проброшенные порты, но вот после рукопожатия (когда обработка потока уходит в железо) напрочь отключается SNAT и сервер начинает получать от роутера пакеты с адресом клиента в локальной сети, а не с адресом роутера.
Впрочем, возможно дело именно в MASQUERADE, который сам по себе довольно тяжелый и требует получать информацию о текущем адресе на интерфейсе, а таблицам в железке неоткуда угадывать этот адрес. Надо будет попробовать просто SNAT вместе с HW offloading.