Tabs
New member
Меня всегда напрягало то, как навязчиво Google AdSense подсовывал контекстную рекламу в зависимости от моих старых запросов в поисковике. Вроде бы и времени с момента поиска прошло достаточно много, да и куки и кеш браузера чистились не раз, а реклама оставалась. Как же они продолжали отслеживать меня? Оказывается, способов для этого предостаточно.
Небольшое предисловие
Идентификация, отслеживание пользователя или попросту веб-трекинг подразумевает под собой расчет и установку уникального идентификатора для каждого браузера, посещающего определенный сайт. Вообще, изначально это не задумывалось каким-то вселенским злом и, как и все, имеет обратную сторону, то есть призвано приносить пользу. Например, позволить владельцам сайта отличить обычных пользователей от ботов или же предоставить возможность хранить предпочтения пользователей и применять их при последующем визите. Но в то же самое время данная возможность очень пришлась по душе рекламной индустрии. Как ты прекрасно знаешь, куки — один из самых популярных способов идентификации пользователей. И активно применяться в рекламной индустрии они начали аж с середины девяностых годов.
С тех пор многое изменилось, технологии ушли далеко вперед, и в настоящее время отслеживание пользователей одними только печеньками не ограничивается. На самом деле идентифицировать юзеров можно разными способами. Самый очевидный вариант — установить какие-либо идентификаторы, наподобие куков. Следующий вариант — воспользоваться данными об используемым юзером ПК, которые можно почерпнуть из HTTP-заголовков отправляемых запросов: адрес, тип используемой ОС, время и тому подобное. Ну и напоследок можно отличить пользователя по его поведению и привычкам (движения курсора, любимые разделы сайта и прочее).
Явные идентификаторы
Данный подход довольно очевиден, все, что требуется, — сохранить на стороне пользователя какой-то долгоживущий идентификатор, который можно запрашивать при последующем посещении ресурса. Современные браузеры предоставляют достаточно способов выполнить это прозрачно для пользователя. Прежде всего это старые добрые куки. Затем особенности некоторых плагинов, близкие по функционалу к кукам, например Local Shared Objects во флеше или Isolated Storage в силверлайте. HTML5 также включает в себя несколько механизмов хранения на стороне клиента, в том числе localStorage, File и IndexedDB API. Кроме этих мест, уникальные маркеры можно также хранить в кешированных ресурсах локальной машины или метаданных кеша (Last-Modified, ETag). Помимо этого, можно идентифицировать пользователя по отпечаткам, полученным из Origin Bound сертификатов, сгенерированных браузером для SSL-соединений, по данным, содержащимся в SDCH-словарях, и метаданным этих словарей. Одним словом — возможностей полно.
Cookies
Когда дело касается хранения какого-то небольшого объема данных на стороне клиента, куки — это первое, что обычно приходит на ум. Веб-сервер устанавливает уникальный идентификатор для нового пользователя, сохраняя его в куках, и при всех последующих запросах клиент будет отправлять его серверу. И хотя все популярные браузеры уже давно снабжены удобным интерфейсом по управлению куками, а в Сети полно сторонних утилит для управления ими и их блокировки, куки все равно продолжают активно использоваться для трекинга пользователей. Дело в том, что мало кто просматривает и чистит их (вспомни, когда ты занимался этим последний раз). Пожалуй, основная причина этого — все боятся случайно удалить нужную «печеньку», которая, например, может использоваться для авторизации. И хотя некоторые браузеры позволяют ограничивать установку сторонних куков, проблема не исчезает, так как очень часто браузеры считают «родными» куки, полученные через HTTP-редиректы или другие способы во время загрузки контента страницы. В отличие от большинства механизмов, о которых мы поговорим далее, использование куков прозрачно для конечного пользователя. Для того чтобы «пометить» юзера, необязательно даже хранить уникальный идентификатор в отдельной куке — он может собираться из значений нескольких куков или храниться в метаданных, таких как Expiration Time. Поэтому на данном этапе довольно непросто разобраться, используется ли конкретная кука для трекинга или нет.
Local Shared Objects
Для хранения данных на стороне клиента в Adobe Flash используется механизм LSO. Он является аналогом cookies в HTTP, но в отличие от последних может хранить не только короткие фрагменты текстовых данных, что, в свою очередь, усложняет анализ и проверку таких объектов. До версии 10.3 поведение флеш-куков настраивалось отдельно от настроек браузера: нужно было посетить менеджер настроек Flash, расположенный на сайте macromedia.com (кстати, он доступен и сейчас по следующей ссылке). Сегодня это можно выполнить непосредственно из контрольной панели. К тому же большинство современных браузеров обеспечивают достаточно плотную интеграцию с флеш-плеером: так, при удалении куков и других данных сайтов будут также удалены и LSO. С другой стороны, взаимодействие браузеров с плеером еще не настолько тесное, поэтому настройка в браузере политики для сторонних куков не всегда затронет флеш-куки (на сайте Adobe можно посмотреть, как вручную их отключить).
Удаление данных из localStorage в Firefox
Изолированное хранилище Silverlight
Программная платформа Silverlight имеет довольно много общего с Adobe Flash. Так, аналогом флешевого Local Shared Objects служит механизм под названием Isolated Storage. Правда, в отличие от флеша настройки приватности тут никак не завязаны с браузером, поэтому даже в случае полной очистки куков и кеша браузера данные, сохраненные в Isolated Storage, все равно останутся. Но еще интересней, что хранилище оказывается общим для всех окон браузера (кроме открытых в режиме «Инкогнито») и всех профилей, установленных на одной машине. Как и в LSO, с технической точки зрения здесь нет каких-либо препятствий для хранения идентификаторов сессии. Тем не менее, учитывая, что достучаться до этого механизма через настройки браузера пока нельзя, он не получил такого широкого распространения в качестве хранилища для уникальных идентификаторов.
Где искать изолированное хранилище Silverlight
HTML5 и хранение данных на клиенте
HTML5 представляет набор механизмов для хранения структурированных данных на клиенте. К ним относятся localStorage, File API и IndexedDB. Несмотря на различия, все они предназначены для обеспечения постоянного хранения произвольных порций бинарных данных, привязанных к конкретному ресурсу. Плюс, в отличие от HTTP- и Flash-куков, здесь нет каких-либо значительных ограничений на размер хранимых данных. В современных браузерах HTML5-хранилище располагается наряду с другими данными сайта. Однако как управлять хранилищем через настройки браузера — догадаться очень трудно. К примеру, чтобы удалить данные из localStorage в Firefox, пользователю придется выбрать offline website data или site preferences и задать временной промежуток равным everything. Еще одна неординарная фишка, присущая только IE, — данные существуют только на время жизни табов, открытых в момент их сохранения. Плюс ко всему вышеперечисленные механизмы не особо-то стараются следовать ограничениям, применимым к HTTP-кукам. Например, можно писать в localStorage и читать из него через кросс-доменные фреймы даже при отключенных сторонних куках.
Настройка локального хранилища для Flash Player
Кешированные объекты
Все хотят, чтобы браузер работал шустро и без тормозов. Поэтому ему приходи
Небольшое предисловие
Идентификация, отслеживание пользователя или попросту веб-трекинг подразумевает под собой расчет и установку уникального идентификатора для каждого браузера, посещающего определенный сайт. Вообще, изначально это не задумывалось каким-то вселенским злом и, как и все, имеет обратную сторону, то есть призвано приносить пользу. Например, позволить владельцам сайта отличить обычных пользователей от ботов или же предоставить возможность хранить предпочтения пользователей и применять их при последующем визите. Но в то же самое время данная возможность очень пришлась по душе рекламной индустрии. Как ты прекрасно знаешь, куки — один из самых популярных способов идентификации пользователей. И активно применяться в рекламной индустрии они начали аж с середины девяностых годов.
С тех пор многое изменилось, технологии ушли далеко вперед, и в настоящее время отслеживание пользователей одними только печеньками не ограничивается. На самом деле идентифицировать юзеров можно разными способами. Самый очевидный вариант — установить какие-либо идентификаторы, наподобие куков. Следующий вариант — воспользоваться данными об используемым юзером ПК, которые можно почерпнуть из HTTP-заголовков отправляемых запросов: адрес, тип используемой ОС, время и тому подобное. Ну и напоследок можно отличить пользователя по его поведению и привычкам (движения курсора, любимые разделы сайта и прочее).
Явные идентификаторы
Данный подход довольно очевиден, все, что требуется, — сохранить на стороне пользователя какой-то долгоживущий идентификатор, который можно запрашивать при последующем посещении ресурса. Современные браузеры предоставляют достаточно способов выполнить это прозрачно для пользователя. Прежде всего это старые добрые куки. Затем особенности некоторых плагинов, близкие по функционалу к кукам, например Local Shared Objects во флеше или Isolated Storage в силверлайте. HTML5 также включает в себя несколько механизмов хранения на стороне клиента, в том числе localStorage, File и IndexedDB API. Кроме этих мест, уникальные маркеры можно также хранить в кешированных ресурсах локальной машины или метаданных кеша (Last-Modified, ETag). Помимо этого, можно идентифицировать пользователя по отпечаткам, полученным из Origin Bound сертификатов, сгенерированных браузером для SSL-соединений, по данным, содержащимся в SDCH-словарях, и метаданным этих словарей. Одним словом — возможностей полно.
Cookies
Когда дело касается хранения какого-то небольшого объема данных на стороне клиента, куки — это первое, что обычно приходит на ум. Веб-сервер устанавливает уникальный идентификатор для нового пользователя, сохраняя его в куках, и при всех последующих запросах клиент будет отправлять его серверу. И хотя все популярные браузеры уже давно снабжены удобным интерфейсом по управлению куками, а в Сети полно сторонних утилит для управления ими и их блокировки, куки все равно продолжают активно использоваться для трекинга пользователей. Дело в том, что мало кто просматривает и чистит их (вспомни, когда ты занимался этим последний раз). Пожалуй, основная причина этого — все боятся случайно удалить нужную «печеньку», которая, например, может использоваться для авторизации. И хотя некоторые браузеры позволяют ограничивать установку сторонних куков, проблема не исчезает, так как очень часто браузеры считают «родными» куки, полученные через HTTP-редиректы или другие способы во время загрузки контента страницы. В отличие от большинства механизмов, о которых мы поговорим далее, использование куков прозрачно для конечного пользователя. Для того чтобы «пометить» юзера, необязательно даже хранить уникальный идентификатор в отдельной куке — он может собираться из значений нескольких куков или храниться в метаданных, таких как Expiration Time. Поэтому на данном этапе довольно непросто разобраться, используется ли конкретная кука для трекинга или нет.
Local Shared Objects
Для хранения данных на стороне клиента в Adobe Flash используется механизм LSO. Он является аналогом cookies в HTTP, но в отличие от последних может хранить не только короткие фрагменты текстовых данных, что, в свою очередь, усложняет анализ и проверку таких объектов. До версии 10.3 поведение флеш-куков настраивалось отдельно от настроек браузера: нужно было посетить менеджер настроек Flash, расположенный на сайте macromedia.com (кстати, он доступен и сейчас по следующей ссылке). Сегодня это можно выполнить непосредственно из контрольной панели. К тому же большинство современных браузеров обеспечивают достаточно плотную интеграцию с флеш-плеером: так, при удалении куков и других данных сайтов будут также удалены и LSO. С другой стороны, взаимодействие браузеров с плеером еще не настолько тесное, поэтому настройка в браузере политики для сторонних куков не всегда затронет флеш-куки (на сайте Adobe можно посмотреть, как вручную их отключить).
Удаление данных из localStorage в Firefox
Изолированное хранилище Silverlight
Программная платформа Silverlight имеет довольно много общего с Adobe Flash. Так, аналогом флешевого Local Shared Objects служит механизм под названием Isolated Storage. Правда, в отличие от флеша настройки приватности тут никак не завязаны с браузером, поэтому даже в случае полной очистки куков и кеша браузера данные, сохраненные в Isolated Storage, все равно останутся. Но еще интересней, что хранилище оказывается общим для всех окон браузера (кроме открытых в режиме «Инкогнито») и всех профилей, установленных на одной машине. Как и в LSO, с технической точки зрения здесь нет каких-либо препятствий для хранения идентификаторов сессии. Тем не менее, учитывая, что достучаться до этого механизма через настройки браузера пока нельзя, он не получил такого широкого распространения в качестве хранилища для уникальных идентификаторов.
Где искать изолированное хранилище Silverlight
HTML5 и хранение данных на клиенте
HTML5 представляет набор механизмов для хранения структурированных данных на клиенте. К ним относятся localStorage, File API и IndexedDB. Несмотря на различия, все они предназначены для обеспечения постоянного хранения произвольных порций бинарных данных, привязанных к конкретному ресурсу. Плюс, в отличие от HTTP- и Flash-куков, здесь нет каких-либо значительных ограничений на размер хранимых данных. В современных браузерах HTML5-хранилище располагается наряду с другими данными сайта. Однако как управлять хранилищем через настройки браузера — догадаться очень трудно. К примеру, чтобы удалить данные из localStorage в Firefox, пользователю придется выбрать offline website data или site preferences и задать временной промежуток равным everything. Еще одна неординарная фишка, присущая только IE, — данные существуют только на время жизни табов, открытых в момент их сохранения. Плюс ко всему вышеперечисленные механизмы не особо-то стараются следовать ограничениям, применимым к HTTP-кукам. Например, можно писать в localStorage и читать из него через кросс-доменные фреймы даже при отключенных сторонних куках.
Настройка локального хранилища для Flash Player
Кешированные объекты
Все хотят, чтобы браузер работал шустро и без тормозов. Поэтому ему приходи