Комментарии 17
«Среднее время на появление сайта в блог-листе» — может быть все-таки в «блэк» или «блок»?
Как всегда, «исследования» по заказу Microsoft жгут. Достаточно лишь прочитать не статью-выжимку с красивыми графиками, а чуть более подробный отчёт и сразу понятно где обман.
Источник
То есть, вообще непонятно, что они там тестировали.
Given the nature of the feeds and the velocity of change, it is not possible to validate each site(выделение моё)
in depth before the test, since the sites could quickly disappear.
Источник
То есть, вообще непонятно, что они там тестировали.
Ну вы же выдрали фразу из контекста, выделили нужные вам слова и сделали нужный вам вывод…
Given the nature of the feeds and the velocity of change, it is not possible to validate each site in depth before the test, since the sites could quickly disappear. Thus, each of the test items was given a cursory review to verify it was present and accessible on the live Internet.
In order to be included in the Execution Set, URLs must be live during the test iteration. At the beginning of each test cycle, the availability of the URL is confirmed by ensuring that the site can be reached and is active (e.g. a non-404 web page is returned).
По-моему более чем логично. Так как тестирование производится в реальном времени и на актуальных ссылках, то делается беглый осмотр, что это за ссылка. Перед каждым тестом проверяется, что сайт доступен и активен.
Какой смысл тратить кучу времени на глубокое изучение, если сайт за это время может пропасть совсем или попасть во все черные списки? Намного интереснее посмотреть, как это все работает вживую и сколько времени занимает внесение сайта в список у каждой из систем.
А поповоду «исследования» — вы это NSS Labs скажите, а заодно в PCI Security Standards Council и AMTSO.
Given the nature of the feeds and the velocity of change, it is not possible to validate each site in depth before the test, since the sites could quickly disappear. Thus, each of the test items was given a cursory review to verify it was present and accessible on the live Internet.
In order to be included in the Execution Set, URLs must be live during the test iteration. At the beginning of each test cycle, the availability of the URL is confirmed by ensuring that the site can be reached and is active (e.g. a non-404 web page is returned).
По-моему более чем логично. Так как тестирование производится в реальном времени и на актуальных ссылках, то делается беглый осмотр, что это за ссылка. Перед каждым тестом проверяется, что сайт доступен и активен.
Какой смысл тратить кучу времени на глубокое изучение, если сайт за это время может пропасть совсем или попасть во все черные списки? Намного интереснее посмотреть, как это все работает вживую и сколько времени занимает внесение сайта в список у каждой из систем.
А поповоду «исследования» — вы это NSS Labs скажите, а заодно в PCI Security Standards Council и AMTSO.
Ну-ну. Если бы Google SafeBrowsing API по первому зову без проверки блокировал сайты, все были бы недовольны. Как пользователи браузеров, так и владельцы сайтов. Первые бы боялись, что их браузер может по чьей-то глупости, ошибке или (несмешной) шутке заблокировать нормальный сайт. Вторые бы боялись, что доступ к их сайту заблокируют по тем же глупым причинам. А тем временем сами «исследователи» не удосуживаются провести такую же (или даже более внимательную) проверку. Для Google это постоянная работа и тем не менее они вкладывают в это много сил и денег. А для «исследователей» единоразовая акция, так что для хороших результатов денег на специалистов не должно быть жалко.
А почему сразу по первому зову? Никто не говорит, что сайты должны попасть в блок-листы сразу. Как раз наоборот — исследователи измеряли, сколько проходит времени перед тем, как сайт попадает.
Схема очень простая: 1) берем список потенциально опасных сайтов (про источники таких ссылок можно прочитать в отчете). Оставляем из них те, которые активны на момент проведения теста, неактивные выкидываем. Положим у нас N сайтов.
2) Смотрим, на сколько из них браузеры блокируют (выдают предупреждение) — получаем покрытие.
3) Далее для каждой из заблокированных ссылок смотрим, сколько времени понадобилось на блокировку.
Заметьте, исследователи не задаются вопросами типа как работает алгоритм внутри Google SafeBrowsing API или Smart Filter. Напротив, для сайтов, попавших в блок-лист они замеряют время между появлением сайта и занесением в список.
Кстати, почему вместо того, чтобы приводить какие-то конструктивные аргументы вы пытаетесь списать результаты на некую несостоятельность исследования или исследователей? ;)
Схема очень простая: 1) берем список потенциально опасных сайтов (про источники таких ссылок можно прочитать в отчете). Оставляем из них те, которые активны на момент проведения теста, неактивные выкидываем. Положим у нас N сайтов.
2) Смотрим, на сколько из них браузеры блокируют (выдают предупреждение) — получаем покрытие.
3) Далее для каждой из заблокированных ссылок смотрим, сколько времени понадобилось на блокировку.
Заметьте, исследователи не задаются вопросами типа как работает алгоритм внутри Google SafeBrowsing API или Smart Filter. Напротив, для сайтов, попавших в блок-лист они замеряют время между появлением сайта и занесением в список.
Кстати, почему вместо того, чтобы приводить какие-то конструктивные аргументы вы пытаетесь списать результаты на некую несостоятельность исследования или исследователей? ;)
Кстати, почему вместо того, чтобы приводить какие-то конструктивные аргументы вы пытаетесь списать результаты на некую несостоятельность исследования или исследователей? ;)
Потому что во всех исследованиях по заказу Microsoft прослеживается связь: исследования спонсированы — малоизвестные исследователи — мутные и расплывчатые абзацы, описывающие технику проведения измерений — продукт Microsoft лучше всех с отрывом раза в два.
К тому же, красноречиво говорит простой поиск в Google по названию компании. Уже на 3-м и 4-м месте — мнения других людей о том, что результаты подстроены и технология проведения измерений скорректирована так, чтобы «спонсор» исследований окаказлся лучше всех.
3-й результат: Can you trust the NSS Labs report touting the benefits of IE8?
4-й результат: Malware report from NSS Labs manipulates statistics?
Пара вопросов:
1. Как вы измеряете известность/неизвестность исследователей? По тому, что Вы лично слышали?
2. Я правильно понимаю, что по Вашему мнению Microsoft в принципе не может выпустить продукт, который в чем-то будет значительно лучше конкурентов?
В приведенных Вами ссылках (одна из которых — о-ужас — отзыв фаната Opera) — обе по предыдущему тестированию — однако, интересны не только сам текст, но и коментарии.
В первой из ссылок автор манипулирует над количеством протестированных ссылок, дальше пытается уличить в использовании «неправильных» версий браузера. Под конец аппелирует к наличию плагинов/аддонов для защиты, возможностям настроек безопасности и антивирусам. (Хотя исследователи ставят цель протестировать именно чистые версии)
Во второй почти аналогично, см. также комментарий сотрудника NSS Labs.
1. Как вы измеряете известность/неизвестность исследователей? По тому, что Вы лично слышали?
2. Я правильно понимаю, что по Вашему мнению Microsoft в принципе не может выпустить продукт, который в чем-то будет значительно лучше конкурентов?
В приведенных Вами ссылках (одна из которых — о-ужас — отзыв фаната Opera) — обе по предыдущему тестированию — однако, интересны не только сам текст, но и коментарии.
В первой из ссылок автор манипулирует над количеством протестированных ссылок, дальше пытается уличить в использовании «неправильных» версий браузера. Под конец аппелирует к наличию плагинов/аддонов для защиты, возможностям настроек безопасности и антивирусам. (Хотя исследователи ставят цель протестировать именно чистые версии)
Во второй почти аналогично, см. также комментарий сотрудника NSS Labs.
Тут безопасность зависит не только от браузера, но ещё и от ОС в которой он запущен, например я считаю что Safari в OS X намного больше обезопасен, чем тот-же Safari в Windows.
В OS X например установка какого-либо вредоносного ПО невозможна без запроса админского пароля.
В OS X например установка какого-либо вредоносного ПО невозможна без запроса админского пароля.
Исследователи также отдельно превели сравнение Windows и Mac-версий Safari. Разницы в уровене защиты не обнаружено.
Mac OS X защищает от фишинга? :)
По поводу теста у меня есть три вопроса.
1. Не браузерское это дело — запрещать загрузку вредоносного ПО. Куда больше пользы будет от защиты критических мест системы (ну хотя бы тот же UAC, да и антивирусные мониторы) и сигнатурного сканирования уже загруженного ПО.
2. Может быть, IE поднял уровень ложных тревог до недопустимо высокого? Есть явно «белые» сайты, которые и с бодунища не заблокируешь. Есть явно «чёрные», которые должны быть заблокированы. И есть куча «серых» — чьи-то личные странички, зачастую на бесплатном хостинге. Их настолько много, что любая выборка нерепрезентативна. И они принципиально не могут попасть в какой-либо тест, поэтому Microsoft вполне мог «отыграться» на них.
3. Они отбрасывали эксплойты. Интересно было бы увидеть статистику: какой браузер больше всего ломают?
1. Не браузерское это дело — запрещать загрузку вредоносного ПО. Куда больше пользы будет от защиты критических мест системы (ну хотя бы тот же UAC, да и антивирусные мониторы) и сигнатурного сканирования уже загруженного ПО.
2. Может быть, IE поднял уровень ложных тревог до недопустимо высокого? Есть явно «белые» сайты, которые и с бодунища не заблокируешь. Есть явно «чёрные», которые должны быть заблокированы. И есть куча «серых» — чьи-то личные странички, зачастую на бесплатном хостинге. Их настолько много, что любая выборка нерепрезентативна. И они принципиально не могут попасть в какой-либо тест, поэтому Microsoft вполне мог «отыграться» на них.
3. Они отбрасывали эксплойты. Интересно было бы увидеть статистику: какой браузер больше всего ломают?
1. Антивирус, если он стоит, срабатывает в момент загрузки или установки. Защита в браузере срабатывает раньше — в момент открытия страницы, при этом она не запрещает загрузку, а весьма недвусмысленно предупреждает, что все может не очень хорошо закончиться. В идеале подобные механизмы должны работать и при публикации/пересылке ссылок на плохие страницы, чтобы мешать их распространению.
Кстати, уверен, что списки фишинговых страниц и страниц со всякой заразой пополняются в том числе не без участия антивирусных компаний.
2. В данном случае скорее следует говорить об обратном: 100% — это те ссылки, которые NSS Labs посчитала фишинговыми страницами (или страницами с зловредным ПО). Источники ссылок — как собственная большая сеть ловушек для спама и огромный накопленный архив подтвержденных примеров, так и внешние (сторонние организации, специализирующиеся на безопасность) — уверен между ними есть внутренняя сеть с циркулирующей информацией о новых угрозах.
Если брать первый отчет, то там изначально была взята выборка в 12000 подозрительных сайтов, из них выбрали 2171 потенциально опасных ссылок, которые работали и были активны на момент проведения теста. После дополнительной проверки/валидации осталось 608 ссылок, которые были именно ссылками на загрузку зловредного ПО, а не ссылками эксплуатирующими те или иные уязвимости браузеров, и браузер на них не падал.
Статистически, это дает погрешность в 3,91% при доверительном интервале в 95%.
Возвращаясь к 100%, я бы исходил из обратного: даже для IE8 с 80 млн страниц в Smart Filter 19% обнаруженных зловредных пропускается — еще есть над чем работать.
Еще один важный вывод из исследования — это скорость добавления ссылок в фильтры (см. например, последнюю страницу).
3. В данном исследовании эксплойты не рассматривались, то есть страницы, эксплуатирующие дыры в безопасности в тесты не включались.
Грубо говоря, оба эксперимента проверяли, насколько баузеры и используемые ими фильтры помогают «бороться» с самой главной проблемой безопасности (системы, данных и т.д.) — «человек посередине».
Кстати, уверен, что списки фишинговых страниц и страниц со всякой заразой пополняются в том числе не без участия антивирусных компаний.
2. В данном случае скорее следует говорить об обратном: 100% — это те ссылки, которые NSS Labs посчитала фишинговыми страницами (или страницами с зловредным ПО). Источники ссылок — как собственная большая сеть ловушек для спама и огромный накопленный архив подтвержденных примеров, так и внешние (сторонние организации, специализирующиеся на безопасность) — уверен между ними есть внутренняя сеть с циркулирующей информацией о новых угрозах.
Если брать первый отчет, то там изначально была взята выборка в 12000 подозрительных сайтов, из них выбрали 2171 потенциально опасных ссылок, которые работали и были активны на момент проведения теста. После дополнительной проверки/валидации осталось 608 ссылок, которые были именно ссылками на загрузку зловредного ПО, а не ссылками эксплуатирующими те или иные уязвимости браузеров, и браузер на них не падал.
Статистически, это дает погрешность в 3,91% при доверительном интервале в 95%.
Возвращаясь к 100%, я бы исходил из обратного: даже для IE8 с 80 млн страниц в Smart Filter 19% обнаруженных зловредных пропускается — еще есть над чем работать.
Еще один важный вывод из исследования — это скорость добавления ссылок в фильтры (см. например, последнюю страницу).
3. В данном исследовании эксплойты не рассматривались, то есть страницы, эксплуатирующие дыры в безопасности в тесты не включались.
Грубо говоря, оба эксперимента проверяли, насколько баузеры и используемые ими фильтры помогают «бороться» с самой главной проблемой безопасности (системы, данных и т.д.) — «человек посередине».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита от вредного ПО и фишинга в браузерах