Comments 20
Идея классная!
Но не хватает примера с десятком сайтов для теста.
Но не хватает примера с десятком сайтов для теста.
Произвольная иконка для страницы
Или проверка реферерра при запросе favicon
Ибо нефиг!
<link rel="shortcut icon" src="fig-vam-a-ne-favicon.ico" />
Или проверка реферерра при запросе favicon
RewriteCond %{HTTP_REFERER} ^(?!your.domain.com)(.+)$
RewriteRule ^favicon.ico$ [R=404,L]
Ибо нефиг!
А если стоит блокировщик реферера?
Но что нефиг согласен.
Но что нефиг согласен.
Описанные вами способы защиты работать не будут. Правильным решением было бы использовать Content Security Policy.
Проверкой реферера вы только облегчите работу этому скрипту. Если в браузере в кэше есть «favicon.ico», она нормально отдастся скрипту. Если в кэше её нет, вернётся ошибка 404, которую отловить легче, чем экспериментировать с «threshold».
var diffTreshold = 200; // Порог времени, который необходимо преодолеть, чтобы считать, что пользователь посетил сайт.
visited: diff > diffTreshold
Ну наоборот же, елы-палы. Преодолели порог, значит не посещали сайт. Вы свой froof-of-concept сами хоть проверяли?
Ну и по мелочи:
saveResult(host, start, new Date() — забыли закрывающую скобку;
threshold, а не treshold;
Если сделать достаточное количество запросов, то можно даже попытаться применить кластерный анализ, вместо непонятно что означающего «среднего значения между минимальным и максимальным временем загрузки».
А ещё, можно делать два запроса: на favicon.ico и на favicon.ico?randomhashhere.
Тогда можно знать за сколько скачивается та же фавиконка, но без кеша.
А ещё, можно делать два запроса: на favicon.ico и на favicon.ico?randomhashhere.
Тогда можно знать за сколько скачивается та же фавиконка, но без кеша.
Я не думаю, что делать свое решение для кластерного анализа будет целесообразно в каждом конкретном случае. Однако, его можно попытаться продать как отдельный сервис или стать частью более крупного решения.
Тут отлично подойдёт самый простой алгоритм «k-средних» (а у нас тут k=2), да и пишется он на коленке за пол часа.
И для каждого конкретного случая писать его снова не нужно. В том и прелесть, если сравнению с Threshold=200.
Продать «k-средних» как отдельный сервис, это к маркетологам. -)
И для каждого конкретного случая писать его снова не нужно. В том и прелесть, если сравнению с Threshold=200.
Продать «k-средних» как отдельный сервис, это к маркетологам. -)
Насколько я понимаю, к-средних может быть все равно не точным, если среди тестовой выборки нет гарантированного промаха и попадания в кеш. Потому что без наличия таких калибровочных значений в выборке, алгоритм кластеризации не сможет разделить случаи, когда вся выборка принадлежит к одному из двух классов. С этой точки зрения, предрассчитанная пороговая константа работает лучше.
На моем компьютере, скорость кэшированной картинки редко превышает 10 миллисекунд, а скорость загрузки с сервера редко быстее 100 миллисекунд. Тут нужно еще учитывать, что раз пользователь не был на сайте, то браузер, скорее всего, будет еще и dns lookup делать.
На моем компьютере, скорость кэшированной картинки редко превышает 10 миллисекунд, а скорость загрузки с сервера редко быстее 100 миллисекунд. Тут нужно еще учитывать, что раз пользователь не был на сайте, то браузер, скорее всего, будет еще и dns lookup делать.
«боливар не выдержит двоих.»
Такой трюк только один раз можно будет провернуть.
Такой трюк только один раз можно будет провернуть.
Интересно!
Также есть замечательное исследование тайминг атак с BH-13 media.blackhat.com/us-13/US-13-Stone-Pixel-Perfect-Timing-Attacks-with-HTML5-WP.pdf
Ребята заметили, что отрисовка элементов занимает некоторое время, увеличили это время с помощью фильтров и выводили среднее время задержки рендеринга для посещенной и непосещенной ссылки. На данный момент затронутая ими проблема пофиксена в ff/chrome/ie.
Также есть замечательное исследование тайминг атак с BH-13 media.blackhat.com/us-13/US-13-Stone-Pixel-Perfect-Timing-Attacks-with-HTML5-WP.pdf
Ребята заметили, что отрисовка элементов занимает некоторое время, увеличили это время с помощью фильтров и выводили среднее время задержки рендеринга для посещенной и непосещенной ссылки. На данный момент затронутая ими проблема пофиксена в ff/chrome/ie.
Насколько я знаю, там было не детектирование посещения, а считывание содержимого страницы.
Не знал, что это собираются фиксить =)
В копилку, есть детектор социалок от bushwhackers. Еще прошу обратить внимания на детект посещения с помощью HSTS :)
Не знал, что это собираются фиксить =)
В копилку, есть детектор социалок от bushwhackers. Еще прошу обратить внимания на детект посещения с помощью HSTS :)
Для тех, кого раздражают сайты, качающие что-то с других сайтов без вашего разрешения (например, как в этом посте):
addons.mozilla.org/ru/firefox/addon/requestpolicy
Куда менее агрессивный, чем noscript, и после минимальной настройки позволяет практически исключить любые подобные трюки.
addons.mozilla.org/ru/firefox/addon/requestpolicy
Куда менее агрессивный, чем noscript, и после минимальной настройки позволяет практически исключить любые подобные трюки.
Попробуйте uMatrix вместо RequestPolicy. Позволяет не просто блокировать запросы, а выбирать какой контент (куки, картинки, скрипты, стили, плагины и т.д.) блокировать, а какой нет. Так же есть более удобный интерфейс (быстрее можно настроить блокировку) и дополнительные штуки типа рандомизации реферера для сторонних запросов и т.д.
У этого же автора есть uBlock — аналог adblock plus, но более эффективный по памяти и процессору.
У этого же автора есть uBlock — аналог adblock plus, но более эффективный по памяти и процессору.
Это только половина дела. Надо взять топ 100000 сайтов по версии quantcast с демографией.
Пора кажется пользователям каждый сайт запускать в своей песочнице.
<link rel=«icon» type=«image/png» href=«example.com/myicon.png»> вот вам
Sign up to leave a comment.
Сниффинг истории браузера с помощью favicon