Комментарии 65
Вроде давно известный факт, ещё со времён EverCookie, разве нет?
С одной стороны не вчера ETag появились. С другой — вот лично я только сегодня о их существовании узнал. Давно используемая, но совершенно не афишируемая технология, в отличие от coockies.
Это вы ещё про HSTS-кэш не слышали =)
HSTS кеш, ETag, Cookies, LocalStorage, Browser Fingerprint и т.п., используемые для отслеживания пользователя, — предмет регулирования GDPR и закона о Cookies
Манипуляции названием технологии вряд ли уберегут от возможных исков и штрафов, подобных штрафам за cookies
Манипуляции названием технологии вряд ли уберегут от возможных исков и штрафов, подобных штрафам за cookies
Ctrl F5 его(ETag) меняет.
Тоже :)
Да, лажанул автор со своим eTag :)
Да, лажанул автор со своим eTag :)
ctrl+shift+R быстро лечат
EDIT: ах да, уже написали…
EDIT: ах да, уже написали…
Нет — закрыл/открыл браузер — ид разные. (последняя версия Mozilla FireFox)
А почему используется именно iframe? Не просто картинка, скажем…
Не знаю почему автор оригинальной публикации пошёл по этому пути, рискну предположить, что на стороне сервера переопределить ETag для веб-страницы по каким-то причинам проще, чем для изображения.
Ну, начнём с того, что автор для страницы со строкой и тремя кнопками подключил Bootstrap и jQuery…
Потому, что из iframe на стороне браузера проще достать идентификатор, чем из картинки.
Кэширование на RAM-диске без сохранения кэша ломает всю малину :)
Пожалуйста, отслеживайте, отслеживайте...
Затем я использую JavaScript на стороне клиента…
…
Работает без участия JavaScript.
Как-то я завис в этом месте.
Одна часть интернета идет по пути надежной и простой аутентификации oAuth, OpenId, BrowserId и т.п. Другая неожиданно открыв для себя куки пытается с ними боротья с помощью банеров в пол экрана. Третья изобретает велосипед по отслеживанию пользователя по косвенным параметрам.
Разные инструменты решают разные задачи.
В одном случае пользователь хочет авторизоваться, а в другом — остаться анонимным.
В одном случае пользователь хочет авторизоваться, а в другом — остаться анонимным.
Лично я был бы не против нормально авторизоваться для сервиса, но остаться анонимным для всех его third-party исполняемых скриптов: отслеживание данных с целью продажи; реклама; вся цепочка аналитик, включая промежуточные ссылки из поисковиков.
Для предоставления услуг они не нужны, на минуточку. Именно это и регулирует GDPR. Они не запрещают «вообще все» cookies и регулируют не только cookies.
Для предоставления услуг они не нужны, на минуточку. Именно это и регулирует GDPR. Они не запрещают «вообще все» cookies и регулируют не только cookies.
Аналитика в целом бог с ней, если даже отданная на аутсорс она другим недоступна. Но вот нет уверенности, что тот же Гугл не использует данные GA с разных сайтов, чтобы определить круг моих интересов в целом, например чтобы показывать на айтишном сайте рекламу мебели, которую я смотрел на мебельном сайте. Вернее есть уверенность, что это не так.
Об этом и речь. :)
Было бы неплохо, если бы third-party скрипты запускались в песочнице и не имели доступа к каким-либо средствам идентификации. Пусть маркетологи/Google и увидят с какого источника человек пришёл, но не смогут как-либо определить кто именно = невозможность персонализировать.
Возможно, тогда бы и рекламу меньше блокировали.
Было бы неплохо, если бы third-party скрипты запускались в песочнице и не имели доступа к каким-либо средствам идентификации. Пусть маркетологи/Google и увидят с какого источника человек пришёл, но не смогут как-либо определить кто именно = невозможность персонализировать.
Возможно, тогда бы и рекламу меньше блокировали.
Лично я был бы не против нормально авторизоваться для сервиса, но остаться анонимным для всех его third-party исполняемых скриптовВы понимаете, что это невозможно, если сайт специально сотрудничает с 3rd-party и заинтересован, чтобы предоставлять им информацию. Тут либо полная анонимность (и для основных сервисов сайта тоже), либо полная неанонимность, либо юридические пляски: «технически вы можете, но по закону вам этого нельзя делать», что конечно же, технарям не нравится.
Вы понимаете, что это невозможноМне кажется, что таки возможно. Разрешить доступ к хранилищам (cookies, localStorage) для скриптов, которые загружены только с «текущего» домена и его поддоменов учитывая CORS политики. Всем остальным — запретить, а данные с средств, по которым можно построить отпечаток — рандомайзить.
Это многое сломает, не будет возможности использовать сторонние CDN (которые уже сейчас занимаются отслеживанием), но вполне действенно и «жить» с таким механизмом возможно.
Теоретически у владельцев сайтов останется возможность поднять нужные для функционала сервисы на поддомене, но при этом данные будут собираться исключительно в рамках просматриваемого сайта и связать их с данными других сайтов будет крайне проблематично. Будет сложно сопоставить пользователя на одном сайте с тем же пользователем на другом сайте.
Исключением может быть IPv6 без NAT'а. В таком случае будут идентифицировать банально по IP с точностью до конкретного устройства (даже не до конкретного человека).
Если я что-то упустил — сообщите, буду рад услышать.
если сайт специально сотрудничает с 3rd-party и заинтересован, чтобы предоставлять им информациюЭто значит, что на основной странице скрипт аналитики будет подключен не как
script src='https://www.google-analytics.com/analytics.js'а например, так
script src='https://www.google-analytics.com/analytics.js?realname=JohnSmith'Вот только John'ов Smith'ов в мире много и единственным вариантом нормально обменяться будет ввод уникальных идентификаторов с привязкой и корректировкой этого идентификатора как со стороны сервиса, так и со стороны условного Гугла. Об этом я писал («будет сложно сопоставить пользователя на одном сайте с тем же пользователем на другом сайте»).
Уникальный идентификатор нужно будет генерировать заново, т.к. использование ИНН и подобных будет слишком очевидным. При этом уникальный идентификатор придётся согласовывать с каждым сайтом отдельно, иначе будет невероятное разглашение пользовательских баз со всеми подряд.
В итоге такие сложности, что с каждым мелким сайтом никто (Google/Facebook) заморачиваться не станет. Подобная практика будет, да, но она будет существовать в рамках партнёров между собой, а не со всеми подряд. А партнёры даже при наличии GDPR без сторонних cookies вполне могут делиться.
Ещё нюанс. Если пользователь не авторизован, то вообще не понятно каким образом его связывать с аналитикой (т.е. какое «имя»/идентификатор передавать). Сейчас же это возможно банальными cookies аналитики без какого-либо взаимодействия сайта с аналитикой.
Уникальный идентификатор нужно будет генерировать заново, т.к. использование ИНН и подобных будет слишком очевидным. При этом уникальный идентификатор придётся согласовывать с каждым сайтом отдельно, иначе будет невероятное разглашение пользовательских баз со всеми подряд.
В итоге такие сложности, что с каждым мелким сайтом никто (Google/Facebook) заморачиваться не станет. Подобная практика будет, да, но она будет существовать в рамках партнёров между собой, а не со всеми подряд. А партнёры даже при наличии GDPR без сторонних cookies вполне могут делиться.
Ещё нюанс. Если пользователь не авторизован, то вообще не понятно каким образом его связывать с аналитикой (т.е. какое «имя»/идентификатор передавать). Сейчас же это возможно банальными cookies аналитики без какого-либо взаимодействия сайта с аналитикой.
Я это всё рассматривал только только в кейсе «нормально авторизоваться для сервиса» (через OAuth, например), отвечая на комментарий wmgeek. В этом случае, если OAuth выполняется через facebook или ГосУслуги, логин facebook/ГосУслуг и будет передаваться в аналитику как идентификатор.
Понятно, что при желании сохранить анонимность для сервиса, можно быть анонимным и для аналитики.
Понятно, что при желании сохранить анонимность для сервиса, можно быть анонимным и для аналитики.
Когда я писал «нормально авторизоваться для сервиса» я не имел ввиду OAuth от вендора аналитики. Использовать вход по OAuth от Facebook'а и одновременно прятаться от его же аналитики на этом же сайте — бред, я считаю. Если человек выбирает такой способ входа, то он явно соглашается на передачу данных этой третьей стороне.
Но возможность «войти» на сайт «в принципе» и не попасть под аналитику Facebook'а всё таки должна быть. Это я и описывал.
Также могу добавить, что лично для меня вход через сторонние сервисы уже является большой проблемой, как и хранение паролей в облаках без e2e-шифрования. Таким образом человек потенциально:
1) даёт возможность зайти под его аккаунтами
2) теряет доступ при бане в сервисе (баны в Facebook уже бывали).
Но возможность «войти» на сайт «в принципе» и не попасть под аналитику Facebook'а всё таки должна быть. Это я и описывал.
Также могу добавить, что лично для меня вход через сторонние сервисы уже является большой проблемой, как и хранение паролей в облаках без e2e-шифрования. Таким образом человек потенциально:
1) даёт возможность зайти под его аккаунтами
2) теряет доступ при бане в сервисе (баны в Facebook уже бывали).
Интересно, а кто первый придумал обычный HTTP‐заголовок «Set-Cookie» называть файлом? И почему по этой аналогии файлами не называют другие HTTP‐заголовки, например: файл User-Agent или файл Content-Length?
Тот, кто делал реализацию, в которой кукие писались в файл
Может потому, что эта информация записывается именно в файл?
Насколько я знаю, куки первым реализовал браузер Netscape, став стандартом де-факто. И у него действительно был файл (формат которого до сих пор используется), в котором он хранил куки.
Это ещё автор оригинала про режим инкогнито не знает)
А под TOR и Onion всё это работает?
Скорее всего, нет. И есть ещё и куча других способов, уже предложенных в комментариях к этой статье, чтобы обнулить слежку с помощью ETag.
Но такой способ действенен для отслеживания основной массы посетителей. Этим посетителям можно честно говорить, что «наш сайт не следит за Вами с помощью coockies», но шпионить за ними с помощью других методов.
Но такой способ действенен для отслеживания основной массы посетителей. Этим посетителям можно честно говорить, что «наш сайт не следит за Вами с помощью coockies», но шпионить за ними с помощью других методов.
Строго говоря, в EU отслеживание пользователя для его профилирования и таргетинга должно быть явно указано и согласие получено обязательно. Знаменитый Cookies Law совсем не про куки, а про любые средства отслеживания — его стоит прочитать. Просто куки стали широко известны как самое используемое средство.
Было бы интересно проверить.
Автор, их больше, тестируйте http://test.noleaks.eu/
И вполне вероятно, что подобные методы будут всё чаще использоваться перепуганной рекламной индустрией, которая наблюдает за тем, как рушится один из её столпов: coockieА какая, собственно, разница? Или они считают, что E-Tag, LocalStorage и другие технологии, которые могут быть использованы для идентификации, не регулируются GDPR? Если они так считают, то они ошибаются.
Штраф таки прилетит, если «перепуганная рекламная индустрия» будет идентифицировать пользователей без их согласия любым из возможных методов. При этом согласие должно быть явным.
Ещё одним вариантом защиты от отслеживания по E-Tag может быть популярное расширение с открытым исходным кодом — ClearURLs, рекомендуемое Mozilla. Также более «локально» могут помочь uMatrix, Decentraleyes, Facebook Container, Firefox Multi-Account Containers.
НЛО прилетело и опубликовало эту надпись здесь
CTRL+F5 нам в помощь
В Web много интересных вещей. Например, сейчас весьма популярен безопасный HTTPS. В этом стеке протоколов есть штуки, которые похожи по смыслу на Cookie и ETag, про которые говорится в статье, с теми же по сути проблемами.
Я имею ввиду SSL Session Id и TLS Session Tickets. Технически они предназначены для того, чтобы уменьшить время установки соединения. Но их так же можно использовать и трекинга пользователей www.ssl.com/article/tracking-users-with-tls.
В этом плане доступ к инфраструктуре открывает большие возможности. Например, Cloudflare писали еще в 2015, что сделали Seesion Id глобальным с ротацией примерно через каждые 18 часов ( blog.cloudflare.com/tls-session-resumption-full-speed-and-secure ). На то были технические причины. Но это так же означает, что если в такой промежуток времени вас как-то получится определить (например, вашу учётку на Facebook), то можно будет замапить и все остальные запросы в этом периоде от других сайтов, которые используют Cloudflare. Сейчас набирает популярность еще более безопасный DNS over TLS, где сервису так же отводится не последняя роль.
Я имею ввиду SSL Session Id и TLS Session Tickets. Технически они предназначены для того, чтобы уменьшить время установки соединения. Но их так же можно использовать и трекинга пользователей www.ssl.com/article/tracking-users-with-tls.
В этом плане доступ к инфраструктуре открывает большие возможности. Например, Cloudflare писали еще в 2015, что сделали Seesion Id глобальным с ротацией примерно через каждые 18 часов ( blog.cloudflare.com/tls-session-resumption-full-speed-and-secure ). На то были технические причины. Но это так же означает, что если в такой промежуток времени вас как-то получится определить (например, вашу учётку на Facebook), то можно будет замапить и все остальные запросы в этом периоде от других сайтов, которые используют Cloudflare. Сейчас набирает популярность еще более безопасный DNS over TLS, где сервису так же отводится не последняя роль.
Я вот удивляюсь, почему в браузере до сих пор не существует глобальный флажок: «Я согласен со всеми существующими и будущими методами отслеживания моих действий, пожалуйста больше не спрашивайте меня об этом»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нет Cookies, нет проблем — использование ETag для отслеживания пользователей