ant76

Там не полноценное решение, а только сканер на вирусы. Полноценного решения под Linux для домашних решений пока что нет.

Это пока конкурентов нет в вашем регионе, как только появляются то сразу и ЗП вырастают и сахаром начинают снабжать, чтобы народ не уходил. Везде так.

А как вы себе представляете например блокировку JS кода средствами файрвола??? На таком же принципе все блокировщики рекламы и банеров работают - анализируют код и блокируют не нужный JS, CSS и HTML исходя из своих баз ресурсов.

Должен в нативном 64-м режиме шустрее работать, так как минуется цепочка преобразования в 64 бита (эмулятор). Тут как-то уже писали почему не считают нужным делать 64-х битную версию, так как многие переживают что больше памяти потреблять будет ПО, а видеть больше 4 ГБ нет надобности. Хотя это предубеждение все же, так как помню по Eset когда они перевели полностью на 64 бита свое ПО то больше потреблять не стало памяти.

И контроль изменений, т.е в следующую версию ПО та же самая ошибка попасть не может.

Не факт ещё, предположение пока что.

Если последние версии боаузеров установлены то там уже включено.

Ничего делать не нужно, сайт автоматом в доверенные добавлен (проверяется по сведениям о сертиыикате). Я уже писал, что особо патч уже не спасает. По HTTP/3 уже тоже тормоза наблюдаются. Видимо РКН научился и по этому протоколу определять.

QUIC в связке с HTTP/3 поддержку реализовывать пока не планируют. Вам же представитель компании ответил. В патче сделали только исключение для проверки зашифрованного трафика для Youtube (доверенным ресурсом стал с сертификатом от Google), соответственно на таком ресурсе будет работать родной протокол QUIC/HTTP/3, но в самом продукте этой поддержки как не было так и нет. Касперский ничего не ломал, а из-за того что блокировка до этого происходило на уровне протоколов http 1.1 и http/2 и раз Youtube как не доверенный ресурс у Касперского работал через проверку зашифрованного трафика, то раз продукты Касперского не поддерживают парсинг HTTP/3 на базе QUIC, то применялся http/2 и подпадало под блокировку. Но теперь и HTTP/3 РКН блочит тоже, хоть там скорость и чуть выше у трафика. Но опять же будут твердить, что виноват Касперский. В такой ситуации уже даже Google официально заявила, что их оборудование не виновато и работает исправно в России. Причина именно что в ограничениях которые РКН ввела с прохождением трафика Youtube.

Так потому что изначально и писали, что проблема в блокировке трафика Youtube от РКН, а не в Касперском. Видимо РКН теперь научился и с QUIC определять трафик Youtube.

Ясно. А для встроенной проверки шифрованных соединений когда будет в продукте реализована поддержка данных протоколов??? Eset как писал выше уже реализовал, тем более данные протоколы уже не экспериментальные. И для всех остальных - МТС и Билайн уже тоже сообщают о проблемах с трафиком Youtube.

Т.е реализуете поддержку QUIC и HTTP/3???

А чего тут дожидаться расследования??? Уже же пояснили, что причина в замедлении от РКН.

Стандарт и ISO тоже. И под тем и другим уже официально вышло. Так что он не экспериментальный, а официально утвержденный и стабильный протокол.

HTTP/3 QUIC уже как год или чуть более как не экспертментальный протокол, а принятый через RFC стандарт, т.е уже стабильный. Теперь понятно почему Касперский по сравнению с Eset не торопится реализовывать у себя поддержку этого протокола. Eset зимой этой реализовал у себя поддержку данного протокола.