Pull to refresh

Comments 65

Вроде давно известный факт, ещё со времён EverCookie, разве нет?
С одной стороны не вчера ETag появились. С другой — вот лично я только сегодня о их существовании узнал. Давно используемая, но совершенно не афишируемая технология, в отличие от coockies.
Это вы ещё про HSTS-кэш не слышали =)
HSTS кеш, ETag, Cookies, LocalStorage, Browser Fingerprint и т.п., используемые для отслеживания пользователя, — предмет регулирования GDPR и закона о Cookies

Манипуляции названием технологии вряд ли уберегут от возможных исков и штрафов, подобных штрафам за cookies
Тоже :)
Да, лажанул автор со своим eTag :)
Вообще говоря, подавляющее большинство пользователей не использует Ctrl+F5 для постоянной перезагрузки страницы (и даже просто не в курсе о такой комбинации клавиш). Может условный 1% пользователей и «противостоит» слежке таким образом, но за остальными 99% можно следить, используя ETag.

IE в Windows 10 вообще не получает ID в примере автора статьи.

Нет — закрыл/открыл браузер — ид разные. (последняя версия Mozilla FireFox)
Это от настроек зависит, да хоть даже вышеупомянутое в статье элементарное отключение кеширования.

Я запустил в последней Мозилле, ID сохраняются
Firefox Android. Закрыл браузер свайпом — ид сменился.
Заголовок спойлера

image


тоже

А почему используется именно iframe? Не просто картинка, скажем…
Не знаю почему автор оригинальной публикации пошёл по этому пути, рискну предположить, что на стороне сервера переопределить ETag для веб-страницы по каким-то причинам проще, чем для изображения.
имхо серверу абсолютно все равно какой content-type отдавать по http…
Ну, начнём с того, что автор для страницы со строкой и тремя кнопками подключил Bootstrap и jQuery…
Потому, что из iframe на стороне браузера проще достать идентификатор, чем из картинки.
А зачем это все на стороне браузера? Только для этого примера?

Он же говорит: чтобы потом отдать этот идентификатор скрипту аналитики.

Кэширование на RAM-диске без сохранения кэша ломает всю малину :)
У меня так и настроен Firefox. Кеш в RAM, гарантированно сотрётся при перезапуске браузера. Да ещё и размер пару сотен мегабайт. Хватает, чтобы получить ускорение от кеширования, но через небольшое время старые файлы вытесняются.

image
Пожалуйста, отслеживайте, отслеживайте...

UFO just landed and posted this here
Блокируя js, вы можете заблокировать всю функциональность сайта. В итоге, либо придётся включить js, либо не пользоваться сайтом.

Аналогично с IE в Windows 10, вряд ли кто будет пользоваться этим браузером (кроме корпоративных условий, где бизнес исторически на IE заточен), но код не выдает так же.

Затем я использую JavaScript на стороне клиента…

Работает без участия JavaScript.

Как-то я завис в этом месте.

Наверное, JavaScript используется именно для кнопок, а не для отслеживания с помощью ETag.

Одна часть интернета идет по пути надежной и простой аутентификации oAuth, OpenId, BrowserId и т.п. Другая неожиданно открыв для себя куки пытается с ними боротья с помощью банеров в пол экрана. Третья изобретает велосипед по отслеживанию пользователя по косвенным параметрам.

Разные инструменты решают разные задачи.
В одном случае пользователь хочет авторизоваться, а в другом — остаться анонимным.
Лично я был бы не против нормально авторизоваться для сервиса, но остаться анонимным для всех его third-party исполняемых скриптов: отслеживание данных с целью продажи; реклама; вся цепочка аналитик, включая промежуточные ссылки из поисковиков.

Для предоставления услуг они не нужны, на минуточку. Именно это и регулирует GDPR. Они не запрещают «вообще все» cookies и регулируют не только cookies.

Аналитика в целом бог с ней, если даже отданная на аутсорс она другим недоступна. Но вот нет уверенности, что тот же Гугл не использует данные GA с разных сайтов, чтобы определить круг моих интересов в целом, например чтобы показывать на айтишном сайте рекламу мебели, которую я смотрел на мебельном сайте. Вернее есть уверенность, что это не так.

Об этом и речь. :)

Было бы неплохо, если бы 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 аналитики без какого-либо взаимодействия сайта с аналитикой.
Я это всё рассматривал только только в кейсе «нормально авторизоваться для сервиса» (через OAuth, например), отвечая на комментарий wmgeek. В этом случае, если OAuth выполняется через facebook или ГосУслуги, логин facebook/ГосУслуг и будет передаваться в аналитику как идентификатор.

Понятно, что при желании сохранить анонимность для сервиса, можно быть анонимным и для аналитики.
Когда я писал «нормально авторизоваться для сервиса» я не имел ввиду OAuth от вендора аналитики. Использовать вход по OAuth от Facebook'а и одновременно прятаться от его же аналитики на этом же сайте — бред, я считаю. Если человек выбирает такой способ входа, то он явно соглашается на передачу данных этой третьей стороне.

Но возможность «войти» на сайт «в принципе» и не попасть под аналитику Facebook'а всё таки должна быть. Это я и описывал.

Также могу добавить, что лично для меня вход через сторонние сервисы уже является большой проблемой, как и хранение паролей в облаках без e2e-шифрования. Таким образом человек потенциально:
1) даёт возможность зайти под его аккаунтами
2) теряет доступ при бане в сервисе (баны в Facebook уже бывали).
А если войти через facebook, а прятаться от гугла?
А если войти через ГосУслуги, а прятаться от гугла/фейсбука?

Интересно, а кто первый придумал обычный HTTP‐заголовок «Set-Cookie» называть файлом? И почему по этой аналогии файлами не называют другие HTTP‐заголовки, например: файл User-Agent или файл Content-Length?

Тот, кто делал реализацию, в которой кукие писались в файл

Может потому, что эта информация записывается именно в файл?
Насколько я знаю, куки первым реализовал браузер Netscape, став стандартом де-факто. И у него действительно был файл (формат которого до сих пор используется), в котором он хранил куки.
Это ещё автор оригинала про режим инкогнито не знает)
Скорее всего, нет. И есть ещё и куча других способов, уже предложенных в комментариях к этой статье, чтобы обнулить слежку с помощью ETag.

Но такой способ действенен для отслеживания основной массы посетителей. Этим посетителям можно честно говорить, что «наш сайт не следит за Вами с помощью coockies», но шпионить за ними с помощью других методов.

Строго говоря, в EU отслеживание пользователя для его профилирования и таргетинга должно быть явно указано и согласие получено обязательно. Знаменитый Cookies Law совсем не про куки, а про любые средства отслеживания — его стоит прочитать. Просто куки стали широко известны как самое используемое средство.

Работают только Cookie и Redirect. Firefox 79.0b1

И вполне вероятно, что подобные методы будут всё чаще использоваться перепуганной рекламной индустрией, которая наблюдает за тем, как рушится один из её столпов: coockie
А какая, собственно, разница? Или они считают, что E-Tag, LocalStorage и другие технологии, которые могут быть использованы для идентификации, не регулируются GDPR? Если они так считают, то они ошибаются.

Штраф таки прилетит, если «перепуганная рекламная индустрия» будет идентифицировать пользователей без их согласия любым из возможных методов. При этом согласие должно быть явным.

Подтверждаю, uMatrix по дефолту так:

UFO just landed and posted this here
ID разные. Если у вас включён JavaScript, то различные техники цифровых отпечатков наверняка смогут определить.
UFO just landed and posted this here
Это точно ID вообще? У меня одинаковый из локального браузера и по RDP с работы. Думаю, это уже слишком сложная магия XD

Сейчас там 2890439
UFO just landed and posted this here
В 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, где сервису так же отводится не последняя роль.
Я вот удивляюсь, почему в браузере до сих пор не существует глобальный флажок: «Я согласен со всеми существующими и будущими методами отслеживания моих действий, пожалуйста больше не спрашивайте меня об этом»

Возможно эта функция будет платной, когда все устанут подтверждать тогда идея и выстрелит в виде какого-нибудь стартапа )

Sign up to leave a comment.