Там проблема не в JA3, а в JA4 на этапе хендшейка. Порядок cipher suites отличается от chrome кардинально и присутствует extension, которого никогда не может быть в chrome. Это надо чинить.
Немного тупорылый лайфхак для андроида: указываете в настройках приложения в разделе батарея: "Ограничено". Таким образом он не будет висеть в фоне, но и уведомления получать не будет. Если нужно открыть/прочитать, помним, где и как мы подключены (сплиты дома, ВЧС (виртуальные частные сети) и так далее).
Все такие системы разворачиваются в закрытом контуре, и внутри контура все свои. Ключ для подсоединения к VPN – необходимая и достаточная часть защиты. Остальное только создаёт проблемы. Особенно при учёте того очевидного факта, что во всех реальных протоколах, которые нам встретились, логин и пароль передаются открытым текстом. То есть, если закрытый контур будет таки взломан, то первый же запуск wireshark сведёт ценность защиты паролем к абсолютному нулю.
Тут же по-разному. Напр в zero trust подходе, описанный Вами случай попросту не произошёл бы, банально потому, что смотреть особо нечего, даже располагаясь внутри одного "слоя" периметра. Понятно, что это можно вытащить всё в изолированный сегмент сети, вход в который на основании ААА. Зависит от заказчика, в общем.
Хорошо, предположим, я вас уговорил и вы не захлопнули сейчас крышку ноутбука с криком «двоичный протокол требует меньшей пропускной способности канала!» – а если захлопнули, то хотя бы посчитали, сколько вам этой полосы надо. А то в поганые 3 мегабита плохого LTE пролезает в секунду 360 пакетов размером в килобайт. И почти 4 тысячи пакетов по 128 байт.
С передачей данных могут быть разные засады. Например передать нужно по BLE 4.0. Тут будешь ужиматься, как сможешь. Или через Ямал что-то тянуть с удалённого объекта.
Не спорю - текстовый, он, конечно, удобен. Но задачи - важнее. Если стоит задача - максимально удобно его читать - то спору нет.
Небольшой бенчмарк ужималки массива данных длинной 8192 байта, как раз для нужд передачи по BLE:
Это мои личные выводы, я не претендую на звание медиума. Судя по ответу понятно, что это позиция руководства, так как "вопрос рассмотрен и заключение сделано". Если бы это был "перегибы на местах", то ответ был бы другим.
Ещё раз повторюсь - это моё личное заключение из написанного Грегом.
Also note, this issue has already been discussed in detail with the kernel maintainers and the company involved, so I would suggest you talk to the company involved if you have further questions about this.
Deleted
Там проблема не в JA3, а в JA4 на этапе хендшейка. Порядок cipher suites отличается от chrome кардинально и присутствует extension, которого никогда не может быть в chrome. Это надо чинить.
средство доступа к информации
Не смотрел пермишены, у него на BOOT тоже выставлены?
Предлагаю заменить КВН на ВЧС! :)
Немного тупорылый лайфхак для андроида: указываете в настройках приложения в разделе батарея: "Ограничено". Таким образом он не будет висеть в фоне, но и уведомления получать не будет. Если нужно открыть/прочитать, помним, где и как мы подключены (сплиты дома, ВЧС (виртуальные частные сети) и так далее).
Отлично, к гамма спектрометру подключился :)
И сразу просьба - добавить возможность ввести бодрейт руками. :)
Вроде уже пробовали ограничить тг несколько лет назад. Нифига не вышло, mtproto с random padding затащщил. Думают, что сейчас получится с fake-tls?
Привет Макс :) я уже заказал на маркете, будет 22-го
Тут же по-разному. Напр в zero trust подходе, описанный Вами случай попросту не произошёл бы, банально потому, что смотреть особо нечего, даже располагаясь внутри одного "слоя" периметра. Понятно, что это можно вытащить всё в изолированный сегмент сети, вход в который на основании ААА. Зависит от заказчика, в общем.
С передачей данных могут быть разные засады. Например передать нужно по BLE 4.0. Тут будешь ужиматься, как сможешь. Или через Ямал что-то тянуть с удалённого объекта.
Не спорю - текстовый, он, конечно, удобен. Но задачи - важнее. Если стоит задача - максимально удобно его читать - то спору нет.
Небольшой бенчмарк ужималки массива данных длинной 8192 байта, как раз для нужд передачи по BLE:
Немного не понял про проблемы парсинга XML. Генерим структуру по wsdl, делаем десериализацию... вроде всё? Или имелось что-то другое ввиду?
Это не в минус JSON сказано, просто хотел понять текст написанного.
Спасибо за статью! Очень интересная!
Сейчас проверил через отложенные сообщения - нет, пересоздаётся картинка wikipedia.org.
Скриншоты сообщений 1 и 2 в шапке поста идентичны. Так как у сообщения 2 нет признака "edited" :)
Сложилось впечатление, что статья "для галочки".
-"Вон, на хабре у нас статья."
Если бы они действительно продвигали свою JDK в массы, то первым делом бы рассказали плюсы своего форка.
А так - выглядит как типовой распил государственного бюджета, то есть - наших с вами налогов. Спиногрызы?
Соглашусь, "да не достанься она никому!"
Ну, справедливости ради, стоит отметить, что в том патчсете не все патчи от конкретно байкала. Там есть вполне патчи общего назначения.
Это мои личные выводы, я не претендую на звание медиума. Судя по ответу понятно, что это позиция руководства, так как "вопрос рассмотрен и заключение сделано". Если бы это был "перегибы на местах", то ответ был бы другим.
Ещё раз повторюсь - это моё личное заключение из написанного Грегом.
Он это мне лично в почту ответил, полагаю, что обсуждение шло в переписке. В любом случае наверное стоит дождаться официального ответа от Байкал.
К тому же на оффсайте комитета CoC лишь безымянные отчёты. :/
Там выше я выложил ответ Greg KH мне (кстати, он довольно оперативно отвечает). Сделал выводы.. :\
Ответ от Greg KH:
Also note, this issue has already been discussed in detail with the
kernel maintainers and the company involved, so I would suggest you talk
to the company involved if you have further questions about this.
thanks,
greg k-h