Cookie

Привет, меня зовут Вика Бегенчева, я QA-инженер в Redmadrobot. Я расскажу, как злоумышленники крадут наши данные, и что можно сделать, чтобы от этого защититься.

Термин тестирование безопасности звучит довольно серьёзно. Многие боятся погружаться в эту тему, думая, что их ждут непроходимые дебри из непонятных слов, сложной литературы и загадочных аббревиатур. Я разберу основы тестирования безопасности и вы убедитесь, что на самом деле это просто и интересно.

Статья написана для начинающих тестировщиков безопасности и тех, кому непонятно, что за фрукты эти хакеры и чем они там занимаются. Мы рассмотрим примеры самых частых уязвимостей и постараемся разобраться, как грамотно проверить проект на слабые места и сформировать у себя образ мышления, который в дальнейшем станет вашим верным помощником в тестировании.

Что хранят cookie

Допустим, мы зашли на сайт интернет-магазина ошейников для собак и выбрали французский язык (почему бы и нет). Добавили в корзину пару шлеек и поводок. Что будет, если мы закроем вкладку и зайдём на сайт снова? Всё останется прежним: интерфейс на французском и три товара в корзине. Магия? Нет, cookie.

Cookie один из инструментов, который формирует так называемый фингерпринт каждого пользователя в сети. Его можно сравнить с отпечатком пальца, по которому можно узнать, что за человек покупает ошейник для собаки.

На вашем устройстве есть текстовый файл, в котором содержится различная информация о пользователе для каждого сайта cookie. Она хранится для разных целей, в том числе и для удобства пользования сайтом. Cookie бывают временные (cookie-сессии)и постоянные. Давайте взглянем на них поближе.

Открываем панель разработчика в Chrome и переходим на рандомную статью на Хабре. Во вкладке Network находим первый запрос, и в хедерах реквеста видим как проставляются cookie:

И в респонсе (запросе) видим cookie:

Set-Cookie: fl=ru; expires=Fri, 25-Feb-2022 08:33:31 GMT; Max-Age=31536000; path=/

Тут уже работает логика и Google (если очень нужно): cookie типа fl=ru (параметр, вероятно, отвечающий за язык) или те, которые хранят товары в корзине постоянные cookie. Они не меняются, если пользователь их не трогает. Нас же интересуют временные или сессионные cookie. Они хранят информацию, которая помогает сайту понять, что это всё тот же пользователь в текущей сессии.

Например, при авторизации на сайте, в файл cookie проставляется условный session_id уникальный идентификатор сессии на данный момент времени, к которому привязаны текущий браузер и пользователь.

Когда мы совершаем действия, доступные только этому пользователю, мы отправляем в хедер запроса (заголовок запроса, в него передаётся способ общения с сервером) и данные, которые локально сохранили в cookie, чтоб подтвердить, что это мы, а не условный программист из Финляндии. Временные cookie имеют срок годности и стираются в конце сессии, или становятся неактуальными с течением времени.

Как понять, что ваши данные в опасности

Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?

Во-первых, нужно проверить, не хранятся ли пароли от сайтов в cookie. Удивительно, но в 2021 году до сих пор существуют сайты, которые это делают. Информация о сессиях должна иметь ограничения быть временной или заменяться с каждой новой сессией.

Во-вторых, нужно проверить, чтобы все конфиденциальные cookie были с флагом httpOnly и secure.

Cookie с флагом secure передаются на сервер только по протоколу HTTPS. Как правило, в этом случае есть сертификат SSL или TLS. Cookie с флагом httpOnly защищены от манипуляция JavaScript через документ, где хранятся cookie.

Открываем в Chrome инструменты разработчика и переходим во вкладку Application.

Проверяем, не хранятся ли пароли в LocalStorage в этом же разделе инструментов разработчика.

Теперь рассмотрим сценарии кражи пользовательских данных и как от них защититься.

HTTP и HTTPS

Гуляя по сайтам мы до сих пор встречаем предупреждения браузеров о незащищённом соединении. Иногда строгий браузер вообще не пускает нас на сайт, потому что не хочет нести за него ответственность. А чего он боится?

А боится он протокола HTTP он древний и небезопасный. Все современные сайты общаются по протоколу HTTPS и вот их браузер любит. Разница между HTTP и HTTPS всего в одной букве, но эта буква означает много Secure. Безопасность передачи данных главный приоритет современных браузеров.

Сайты, которые общаются с сервером по протоколу HTTPS, используют сертификат TLS (его предшественник SSL). Такой сертификат может защищать как один домен, так и группу поддоменов.

Вернёмся в магазин мы решили всё-таки купить ошейник своей собаке. Переходим в корзину, вводим данные банковской карты для оплаты, нажимаем на большую кнопку Оплатить и наши данные улетают на сервер для обработки запроса. Допустим, злоумышленники решили перехватить данные нашей банковской карты в момент отправки запроса.

Если сайт общается по протоколу HTTPS, то между магазином и сервером построен безопасный мост. SSL-сертификат позволяет шифровать данные нашей карты и преобразует их в нечитаемый набор символов.

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

Чтобы защититься от кражи данных, убедитесь:

1. Что сайт общается через HTTPS, а не через HTTP.

2. Есть редирект с http:// на https:// злоумышленник может разместить ссылку с http://, тогда данные можно будет угнать. Редирект насильно переводит пользователя на https:// ради его же блага. И все счастливы.

3. Включен HSTS.

Brute force атаки

Допустим, в нашем любимом магазине ошейников для питомцев есть админка. Владелец сайта решил оставить ссылку админки по адресу https:// [].com/admin. Злоумышленник переходит по этому адресу и его ждёт страница входа в панель администратора. Допустим, наш хакер вводит логин admin, а пароль подбирает с помощью скрипта, который сам будет перебирать пароли.

Если логин верный, то узнать пароль дело нескольких часов. Запустил скрипт на ночь, лёг спать, а утром уже есть доступ к панели администратора. Такой перебор и есть brute force атака.

Защититься от взлома можно несколькими способами (про авторизацию/аутентификацию и oauth2 мы поговорим ниже). Но, если речь идёт о brute force атаке, то простейшая защита тут установка лимита на попытки ввода пароля.

Лимиты устанавливают в зависимости от специфики продукта и решения проектной команды:

• ограниченное число попыток в единицу времени;

• ограниченное число попыток с последующей блокировкой функционала (например, с восстановлением доступа через почту когда попытки закончились);

• установление тайм-аута после n попыток ввода.

Естественно, это не избавит от всех проблем, но сильно усложнит жизнь злоумышленнику.

Токены и сессии

Давайте представим, что мы захотели вступить в тайный клуб любителей настольных игр. Туда просто так не попасть. Сначала нужно доказать, что мы подходим на роль члена клуба любим настолки.

Итак, в клубе знают наше имя и фамилию, мы доказали, что любим игры, и теперь нам выдадут специальный пропуск, по которому мы сможем проходить в здание закрытого клуба. Теперь не нужно каждый раз доказывать, что мы это мы. У нас есть волшебный ключ-пропуск, который открывает двери тайного клуба.

А что будет, если наш пропуск-ключ украдут? По нему просто войдут в здание и узнают все секреты закрытого клуба. Токены сессии это ключи к ресурсам нашего сайта. Когда мы логинимся на сайте, мы отправляем запрос на авторизацию/аутентификацию пользователя. На сервере проверяются его права и генерируется токен.

Access-token определяет права пользователя и доступность ресурсов для него. Выглядит он как длинный набор символов. Можно сказать, что токен тот самый пропуск, который нам выдали в нашем тайном клубе.

При каждом следующем обращении к ресурсам теперь нам не нужно вводить логин и пароль, чтоб доказать, что мы имеем право на доступ. Просто в каждым запросе на ограниценный ресурс отправляем наш пропуск access-token.

Хорошей и частой практикой является использование время жизни токена. После логина и формирования access-токена, фиксируется время жизни дата, до которой токен считается действительным. Это как абонемент на месяц в тайный клуб.

На разных ресурсах, требования ко времени жизни токена разные. На одном сайте токен живёт год, а на другом всего лишь час. После того как срок действия токена истечёт, система попросит пользователя снова авторизоваться. Чтобы не вводить всё время логин и пароль после истечения access-токена, придумали refresh-токен.

У refresh-токена только одна цель обновлять access-токен. Это работает так:

• отправляем запрос на закрытый ресурс с истекшим аксесс-токеном;

• сервер возвращает ошибку о протухшем токене;

• клиент видит эту ошибку и сразу формирует запрос на обновление аксесс-токена;

• в хедеры этого запроса проставляется значение рефреш-токена;

• сервер сверяет рефреш-токен с базой данных, формирует новый аксесс-токен и отправляет его обратно на клиент;

• клиент автоматически повторяет запрос на закрытый ресурс уже с новым аксесс-токеном.

Готово! А пользователи сайта даже ничего не увидели и не поняли. Как этим пользуются хакеры?

Access- и refresh-токены это токены сессии. Если злоумышленнику удастся перехватить их, то он докажет, что он это мы, просто подставив в запрос. Он получит доступ к нашим ресурсам и сможет совершать действия от нашего имени.

Чтобы защититься, нужно:

• проверить, что токены сессии не храняться в файлах Cookie или LocalStorage;

• убедиться, что все запросы с токенами передаются по зашифрованному HTTPS;

• проверить, что нет доступа к ресурсу без предъявления токена отправить запрос без токена;

• проверить, что нет доступа с чужим токеном, а также проверить запросы с несуществующим токеном;

• проверить запросы с истекшим токеном;

• поменять в базе данных вручную время жизни токена (продлить/просрочить);

• удалить access-token токен из базы данных и отправить запрос.

Авторизация и аутентификация

Чтобы обеспечить безопасность системе и разрешить взаимодействовать с ней разным ролям пользователей (админы, модераторы и т.д.), важно понимать различия между авторизацией и аутентификацией.

Давайте представим, что мы приглашены на конференцию по автоматическому тестированию. Мы приходим, а на входе нас встречают добродушные помощники организаторов, которые спрашивают наше имя. Лаврентий Куашников, отвечаем мы и показываем паспорт. Организаторы ищут нас в списке и видят, что мы спикер. Нам выдают бейдж и проводят в отдельное помещение, где мы можем расположиться и подготовиться к выступлению.

Аутентификация это проверка на соответствие заявленного имени пользователя (паспорта) с идентификатором в системе (Лаврентий Куашников). Авторизация это предоставление нам прав в соответствии с нашей ролью в системе (отдельная комната для спикера).

Вернёмся к примеру с админкой нашего магазина ошейников. Снова переходим по адресу админки и нас ждёт страница с вводом логина и пароля. Логин это идентификатор пользователя в системе. Пароль это доказательство пользователя, что он это он (ведь только он может знать пароль).

Когда в запросе мы отправляем эти данные, сервер проверяет их на соответствие это аутентификация. Если аутентификация прошла успешно, то сервер смотрит в базе данных на нашу роль в системе и какие возможности у нас есть это авторизация.

В разных сервисах авторизация и аутентификация могут проходить как одновременно, так и по отдельности. В первом случае при входе в админку у нас проверяется сразу как пароль, так и разрешение на переход в панель управления сайтом. Во втором случае авторизация проходит тогда, когда уже аутентифицированный пользователь пытается что-то изменить в системе.

А ещё наш сервер умный, и он знает, как реагировать на ошибки авторизации/аутентификации. У него есть два кода ошибок:

• 401 если логин/пароль не совпадают или если для доступа к ресурсу нужна аутентификация;

• 403 когда сервер понял, что за юзер к нему ломится, но отказывает ему в доступе.

Если хакер доказал, что он это мы, то система примет его с распростертыми объятиями. Злоумышленник получит доступ к информации и действиям, доступным только нам.

Самый простой способ помочь хакеру пройти авторизацию в системе передать логин и пароль в запросе в незашифрованном виде. Ну и хранить информацию в cookie, конечно. Но мы не хотим помогать хакерам. Так что делать?

Есть ряд проверок, которые снижают вероятность взлома:

• проверьте, что пароли авторизации не хранятся в cookie. Токены хранятся только в httpOnly куках;

• все запросы, где используется авторизация, передаются по зашифрованному соединению https.

Также проверьте пользовательский доступ к ресурсам с кэшем страницы:

1. Авторизуйтесь в системе.

2. Откройте ту же страницу в соседней вкладке, при этом пользователь должен быть авторизован.

3. Разлогиньтесь из второй вкладки.

4. Вернитесь на первую вкладку (кэш сайта покажет, что вы ещё в системе).

5. Попробуйте перейти на страницу с ограниченным доступом из первой вкладки, например, в личный кабинет.

Доступ должен быть запрещён. То же самое проделайте при условии, что вы не просто вышли во второй вкладке, а зашли под другой учётной записью.

Проверьте также время жизни токенов в системе. Можно попросить разработчика поменять время жизни на 3 минуты, вместо 7 дней. Также можно попросить поменять время сервера. Но время жизни токена в любом случае должно быть ограничено.

Проверьте API:

1. Отправьте запрос без хедеров авторизации.

2. Отправьте запрос с чужими значениями параметров авторизации.

3. Проверьте запрос с истекшим токеном или с тем же токеном после логаута (после логаута токен должен стать недействительным).

4. Проверьте, чтобы логин/пароль не передавались в параметрах запроса. Пример, как не нужно передавать логин/пароль в параметрах http запроса: http://site.ru/page.php?login=testqa&password=12345678.

Так же в некоторых системах с повышенными требованиями к безопасности можно применять дополнительные опциональные проверки. Первое,что мы можем сделать, так этоможно проверить авторизацию при смене пароля:

1. Авторизуйтесь в системе в одном браузере.

2. Авторизуйтесь в системе в другом браузере (или во вкладке инкогнито).

3. Смените пароль в системе через первый браузер.

4. Проверьте доступ к ресурсам на втором браузере.

Тут мы проверяем, достаточно ли системе только сохранённых данных в cookie. При смене пароля все токены должны быть недействительными.

Второе: можно проверить наличие и работоспособность функции Выход со всех устройств. При этом запросе мы говорим серверу, что аннулируем все действительные токены, кроме текущего.

Третье:проверьте наличие постоянного тайм-аута сессии(Session-Timeout), они бывают нескольких видов. Наличиепостоянного тайм-аута запрещает доступ к ресурсу через n минут после авторизации. Наличиединамическоготайм-аута запрещает доступ к ресурсу через n минут после последнего запроса. Другими словами, динамический тай-маут закрывает доступ из-за вашего бездействия в системе.

И напоследок, не забудьте проверить, доступна ли двухфакторная аутентификация на сайте.

Двухфакторная аутентификация

Если в вашей входной двери есть замок только одного типа, то грабителю нужна только одна отмычка (отмычка одного типа). Если же у вас есть ещё и дополнительная защита (цепочка, навесной замок, собака), то грабителю будет сложнее вас ограбить. Скорее всего он передумает.

Так работает и двухфакторная аутентификация. У нас есть основной замок логин и пароль. И у нас есть второй тип защиты чаще всего это код, приходящий по SMS, электронной почте или отображаемый в программе двухфакторной аутентификации (например, в Google Authenticator).

Ещё неплохой практикой является использование на сайте протокола oAuth2. Простыми словами, oAuth2 это когда мы авторизуемся в одном сервисе с помощью другого. Например, когда регистрируемся/логинимся на сайте с помощью Gmail.

SQL-инъекции кода

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

Недобросовестный официант анализирует и понимает, что на кухне не раздумывая выполняют любой запрос. Поэтому можно внести свои собственные изменения в заказ и повара безоговорочно приготовят блюдо. И он пишет на очередном рецепте:

ДОБАВИТЬ перец И УБРАТЬ сахар.

Вот и всё. Пранк удался. Но мы на стороне добра, так что вместо того, чтобы заменять заказ, мы проверим, как на кухне умеют фильтровать изменения. Как этим пользуются хакеры? SQL injection это намеренное внесение в базу данных извне. В нашем примере, кухня это база данных. SQL-запросы заказы от официантов.

Если у базы данных нет фильтрации запросов, то злоумышленник может манипулировать данными: получать данные пользователей (в том числе логин и пароль), размещать файлы, заменять значения. Как же злоумышленник может отправлять такие запросы? Это можно сделать через параметры HTTP, добавив в адресной строке параметры:

http://some.site.ru/test/index.php?name=1 UNION SELECT 1,2,3,4,5 + &password=1234

Не углубляясь в то, как мы можем сами попробовать хакнуть свою базу данных, разберёмся в причинах уязвимости и посмотрим, как можно защититься.

Во-первых, в запросе должно быть экранирование спецсимволов игнорирование исполняемым кодом спецсимволов, которые используются в синтаксисе языка программирования. Если один из спецсимволов пропал, то сервер воспринимает его, как часть команды уязвимость есть.

Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка Unknown column 4 in order clause говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.

Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций. Например, библиотека node-mysql для node.js.

XSS

XSS расшифровывается как Cross-Site Scripting. Эта уязвимость входит в список OWASP TOP-10. Её смысл в том, что злоумышленник принудительно внедряет JavaScript-код через инпут на сайте: в поле ввода пушит код, который сохраняется на странице. Впредь он будет исполняться каждый раз при вызове страницы. Это происходит потому, что на сайте отсутствует экранирование спец символов.

У хакера много вариантов воспользоваться этой уязвимостью: от отображения алерта (всплывающего окна) с рекламой до кражи cookie и редиректа на сайт-зеркало.

Не забывайте, что проверять наличие уязвимостей на чужом сайте по законодательству РФ (и многих других стран) запрещено. Это воспринимается, как попытка намеренного причинение вреда сайту. И что тогда делать?

Первым деломвводим во инпуты на сайте скрипты например. Если уязвимость есть, то при перезагрузке страницы появится алерт со значением test.

После этоговводим во инпуты строку:

\\ test :grin: /?.&&*@#$%^*;~`  <iNpUt type=text />фыва.&%\ <b>t_e_st</b>:sunglasses:<img src=x onerror=alert(xss)/>

Это универсальная проверка сразу на несколько кейсов.Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля.

В конце вводим скрипт или спецсимволы в окно фронтенда вставляем прям в код сайта через dev tools в браузере.

Напутствие

Мы рассмотрели лишь несколько уязвимостей из множества существующих. Но это поможет войти в прекрасный мир тестирования безопасности. Чтобы ничего не забыть, мы с железными тестировщиками подготовили чеклист.

Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра! :)

В последнее время активно освещается проблема приватности пользовательских данных. Скандал с Cambridge Analytica и Facebook, внедрение GDPR, многомиллионные штрафы для Google за установку файлов cookie без ведома пользователей, обновление iOS 14 (с ограничениями трекинга) все это оказывает давление на рекламодателей, рекламные платформы и заставляет всерьез озаботиться обеспечением приватности данных.

Компания Google разработала и активно тестирует новую технологию, которая может заменить традиционный таргетинг рекламы на основе cookie-файлов Federated Learning of Cohorts (FLoC). В статье рассказываем, что это за технология и чего ждать рекламодателям.

Чем не угодили cookie и почему нельзя просто так взять и отказаться от них

Основная претензия к cookie-файлам отсутствие гарантии конфиденциальности пользовательских данных. Сторонние cookie, установленные на сайтах, собирают слишком много информации о пользователях. С помощью этих данных (история поисковых запросов, просмотров страниц, заполнение полей в формах ввода данных и т. д.) можно идентифицировать конкретного человека, что является серьезной угрозой приватности.

Вместе с тем просто убрать cookie не получится слишком многое держится на них:

• рекламные системы используют cookie для ретаргетинга и поиска релевантной аудитории для показа определенных рекламных объявлений. Чем релевантнее (и эффективнее) реклама, тем больше денег получают рекламные системы от рекламодателей;

• рекламодатели с помощью рекламных систем получают возможность запускать более результативные рекламные кампании (и получать больше прибыли);

• сайты-издатели и вебмастеры зарабатывают на размещении рекламы. Они напрямую заинтересованы в том, чтобы реклама была выгодна рекламодателям и размещений было много.

И, наконец, сами пользователи привыкли к многим удобствам, которые обеспечивают cookie:

• сохранение настроек авторизации и параметров;

• юзабилити, основанное на поведении пользователя;

• персонализация интерфейса, контента, рекламы.

Как использовать данные с сохранением конфиденциальности

Есть хороший пример, в котором сочетаются те же задачи, что и в вопросе с cookie, медицина. Например, для повышения эффективности тестов на определение заболевания нужно собрать обучаемую модель. При этом:

• нужно получить как можно больше данных об обследованиях пациентов;

• данные должны быть обезличенные (медицинские учреждения не делятся данными конкретных пациентов из соображений конфиденциальности).

Решение этой задачи обрабатывать данные на стороне каждого медицинского учреждения и передавать общей модели обобщенные данные (без раскрытия персональных данных отдельных пациентов).

Именно такая концепция лежит в основе Federated Learning.

Что такое Federated Learning

Google разработала и активно тестирует новую технологию Federated Learning of Cohorts (FLoC).

Federated Learning распределенная модель, которая использует алгоритмы машинного обучения для анализа пользовательских данных и формирования когорт. Когорта группа обезличенных данных пользователей (браузеров) с похожими свойствами. Данные пользователей (которые могут содержать чувствительную и конфиденциальную информацию) не поступают напрямую ни в один централизованный обработчик или сервер: вычисление и назначение когорты происходит на стороне браузера.

Остальным сервисам (рекламным платформам, сайтам и т. д.) передается только идентификатор когорты, без данных, по которым можно идентифицировать отдельных пользователей.

Для справки. Еще в 2017 году Google тестировал технологию Federated Learning в приложении Gboard для Android. Когда Gboard показывает предлагаемый запрос, смартфон пользователя локально сохраняет информацию о текущем контексте и клике на предложение (или отсутствии клика). Federated Learning обрабатывает эту историю на стороне устройства и предлагает улучшения для следующей итерации модели предложений Gboard.

Для чего может применяться FLoC

• Показ рекламных объявлений людям, чьи браузеры принадлежат к когорте, которой характерно определенное поведение (например, посещение сайта рекламодателя) или интерес к определенным продуктам.

• Применение моделей машинного обучения для прогнозирования вероятности конверсии на основе когорты пользователя (и корректировки ставки на рекламном аукционе с использованием полученной вероятности).

• Рекомендация релевантного контента пользователям.

Как работает FLoC

Разберем на примере, как работает FLoC на практике. Для понимания процесса определим трех основных участников:

• рекламодатель компания, которая хочет показать свои рекламные объявления целевой аудитории и платит за показ. В нашем примере это будет интернет-магазин обуви;

• издатель новостной сайт, который продает рекламные места (размещает у себя рекламные объявления и получает вознаграждение от рекламной системы);

• рекламная система платформа, предоставляющая инструменты для размещения рекламы.

Рассмотрим этот процесс подробнее, для примера возьмем двух пользователей, которых зовут Сергей и Антон (имена выбраны рандомно). Изначально их браузеры принадлежат к одной и той же когорте, допустим, 1354.

1. FLoC-сервис

FLoC-сервис, используемый браузером, создает математическую модель с тысячами когорт. Каждая из когорт соответствует тысячам браузеров с похожей недавней историей активности и имеет свой уникальный номер, по которому ее можно идентифицировать.

2. Браузер

Из FLoC-сервиса браузер Сергея получает данные, описывающие FLoC-модель. Браузер пользователя определяет свою когорту: для вычисления подходящей когорты используется специальный алгоритм, который соотносит браузерную историю с наиболее подходящей когортой. В нашем примере это будет когорта под номером 1354. Обратите внимание, браузер Сергея не передает никаких данных FLoC-сервису.

Точно так же браузер Антона вычисляет идентификатор своей когорты. История браузера этого пользователя отличается от истории браузера Сергея. Однако они достаточно похожи, поэтому им присваивается одинаковая когорта 1354.

3. Взаимодействие с рекламодателем

• Сергей посещает сайт рекламодателя (shoe.com).

• Сайт запрашивает ID когорты браузера пользователя и получает значение 1354.

• Сергей ищет кроссовки для бега.

• Сайт сохраняет информацию о том, что браузер из когорты 1354 выявил интерес к беговым кроссовкам.

• Позже на сайте зафиксирован дополнительный интерес к товарам со стороны когорты 1354, а также со стороны других когорт.

• Время от времени сайт собирает информацию о когортах и проявленному интересу к товарам и передает ее рекламной системе.

4. Издатель новостной ресурс news.com

• Антон посещает новостной сайт news.com.

• Сайт издателя запрашивает у браузера пользователя его когорту.

• Затем сайт отсылает запрос рекламной системе и включает в этот запрос ID когорты браузера Антона 1354.

5. Рекламная система

Рекламная система может подобрать подходящее для Антона рекламное объявление, основываясь на данных от издателя и рекламодателя:

• когорта браузера Антона (1354) эти данные рекламной системе передает издатель;

• интересы, которые соответствуют данной когорте, передаются от рекламодателя (Браузеры из когорты под номером 1354 могут быть заинтересованы в беговых кроссовках).

Рекламная система подбирает подходящее объявление беговые кроссовки от shoe.com.

На сайте отображается объявление кроссовок.

Ключевая особенность такого подхода

Сейчас показ релевантных рекламных объявлений базируется на технологиях отслеживания файлов cookie и цифровых отпечатков устройств. Эти технологии используются рекламодателями для отслеживания поведения в сети отдельных пользователей.

FLoC позволяет сохранить релевантность, но без ущерба для приватности данных: браузер не делится браузерной историей ни с FLoC-сервисом, ни со сторонними службами. Браузер вычисляет подходящую когорту на стороне устройства пользователя. История браузера при этом никогда не покидает пределы устройства.

Браузерная когорта может меняться

Важно понимать принцип определения и назначения когорт. Когорта это не группа пользователей (как привычно воспринимаются сегменты аудитории), а совокупность (кластер) схожих историй браузерной активности.

Характеристики активности каждой когорты в основном постоянны. Поэтому когорты хорошо подходят для подбора рекламных объявлений, так как объединяют схожие поведенческие характеристики. Условно, когорта 1354 будет объединять людей, заинтересованных в беговых кроссовках, сегодня, через месяц и через полгода. Только сегодня это может быть одна группа людей, а через месяц совершенно другая.

Браузеры отдельно взятых пользователей могут переходить от когорты к когорте по мере того, как их история браузинга меняется. Ожидается, что браузер будет пересчитывать свою когорту каждые 7 дней.

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

На какой стадии сейчас находится технология и что ждать в ближайшее время

30 марта Google запустил тестирование технологии в браузере Chrome. Первичные тесты проводятся на небольшой группе пользователей в таких странах:

• Австралия;

• Бразилия;

• Канада;

• Индия;

• Индонезия;

• Япония;

• Мексика;

• Новая Зеландия;

• Филиппины;

• США.

Со временем тестирование будет расширяться и на другие регионы.

Главные вопросы к Federated Learning

Что с релевантностью рекламы?

Вопрос, который больше всего интересует рекламодателей. Они опасаются ухудшения эффективности рекламы при отказе от привычных cookie.

По заявлениям Google, беспокоиться не стоит: при тестировании FLoC Google определил, что использование новой технологии обеспечивает как минимум 95% конверсий по сравнению с использованием традиционного показа рекламы на основе cookie.

Решит ли FLoC проблему приватности пользовательских данных?

Размер когорты должен быть достаточным, чтобы сохранялась анонимность

В каждой когорте могут быть тысячи браузеров. Чем меньше размер когорты, тем более персонализированной будет реклама, но при этом уменьшится степень приватности (и наоборот).Для обеспечения анонимности пользователей в когорте Google использует обобщение данных k-анонимность. Под термином k-анонимность понимается метод, который позволяет скрыть персональную информацию нескольких лиц в наборе данных, если эти лица похожи друг на друга. Если упрощенно, k количество пользователей в группе с похожими свойствами. Чем больше это число, тем более анонимна группа и сложнее отследить отдельно взятого пользователя. Подробнее о k-анонимности можно почитать тут.

k-анонимность не гарантия

Несмотря на заявления Google об обезличивании данных пользователей в когортах (с помощью вычисления ID когорты на стороне браузера и размера когорт), многие игроки в отрасли высказывают опасения по поводу того, что новая технология не решает проблему сохранения анонимности:

• при авторизации на сайте через аккаунт Google сайт может сопоставить пользовательские данные с ID когорты FLoC в этом случае уже нет полной обезличенности данных;

• деперсонализация может быть возможной благодаря пересечению нескольких характеристик, например идентификатора когорты и IP-адреса пользователя;

• также есть мнение о том, что данные все равно хранятся у Google (пусть и частично обезличенные), а это дает частной компании неоправданно широкие возможности и власть над информацией.

Чего ожидать рекламодателям и чем закончится борьба за приватность пользовательских данных

Пока FLoC все еще находится на стадии тестирования и не является окончательным вариантом выводы делать рано. Возможно, будут рассмотрены другие альтернативы трекингу с помощью файлов cookie. Но ясно одно все основные участники рынка (рекламодатели, рекламные платформы и издатели) заинтересованы в нахождении баланса:

• между приватностью пользователей, за которую активно борются регуляторы, общественные организации и отдельные компании (привет, Apple);

• и трекингом, который позволял бы сохранить возможность показывать пользователям релевантную рекламу и извлекать из этого прибыль.

Если говорить про Google, рекламный бизнес занимает львиную долю в структуре доходов корпорации и снижать его эффективность явно не входит в планы IT-гиганта. Поэтому с большой долей уверенности можно сказать, что Google приложит все усилия для поиска решения, которое удовлетворит всех (и позволит компании продолжать получать миллиарды выручки с рекламы).

Google недавно объявил о развертывании технологии Federated Learning of Cohorts (FLoC) в рамках инициативы Privacy Sandbox, направленной на замену сторонних файлов cookie новым методом профилирования пользователей, который собирает данные, генерируемые непосредственно браузером.

Организация Electronic Frontier Foundation (EFF) выпустила обзор FLoC и связанных с ним угроз, а также разработала полезный инструментдля проверки, используется ли браузер пользователя для сбора данных и снятия цифрового отпечатка устройства.

Примечания: EFF отмечают, что вместо устранение проблемы, Google создает новые. Если любой сайт сможет получить данные о когортах, возникнут условия для предварительной жесткой фильтрации целых групп пользователей, исходя из обобщенных предпочтений. Среди новых рисков также выделяют появление фактора для более интенсивного использования методов косвенной идентификации пользователя(browser fingerprinting), использующих специфичные настройки и особенности оборудования.

Plausible Analytics также присоединился к статье, в которой объясняется, какое отношение FLoC имеет к пользователям и разработчикам.- что послужило источником вдохновения для этого краткого руководства.

Заголовок FLoC

Основной способ, с помощью которого конечный пользователь может избежать FLoC, это просто не использовать Chrome, а вместо этого выбрать браузер, уважающий конфиденциальность, например Mozilla Firefox.

Но владельцы веб-сайтов также могут гарантировать, что их веб-серверы не участвуют в этой огромной сети, отказавшись от FLoC.

Для этого необходимо добавить следующий кастомный заголовок HTTP-ответа:

Permissions-Policy: interest-cohort=()

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

NGINX

Добавьте в файл конфигурации NGINX следующее:

# /etc/nginx/sites-available/default.confserver {    location / {add_header Permissions-Policy interest-cohort=();...

Перезапустите NGINX с помощью команды service nginx restart

Apache

Добавьте следующую директиву в свой файл конфигурации Apache:

# /www/htdocs/example.com/.htaccess <IfModule mod_headers.c>  Header always set Permissions-Policy: interest-cohort=()</IfModule>

Перезапустите Apache с помощью команды service apache2 restart

Caddy

Добавьте следующее в свой Caddyfile:

# Caddyfileexample.com {header Permissions-Policy "interest-cohort=()"...

Перезапустите Caddy с помощью команды caddy reload

Lighttpd

Добавьте в файл конфигурации Lighttpd следующее:

# /etc/lighttpd/lighttpd.confserver.modules += ( "mod_setenv" )setenv.add-response-header = ( "Permissions-Policy" => "interest-cohort=()" )

Перезапустите Lighttpd с помощью команды service lighttpd restart

Netlify

Добавьте в файл конфигурации Netlify следующее:

# netlify.toml[[headers]]  for = "/*"  [headers.values]    Permissions-Policy = "interest-cohort=()"

Если вы предпочитаете использовать _headers файл вместо файла конфигурации TOML, добавьте в этот файл вместо указанных выше строчек следующее:

# _headers/*  Permissions-Policy: interest-cohort=()

При следующей сборке или развертывании Netlify добавит и обслужит заголовки.

GitHub Pages

В настоящее время не существует возможности добавлять кастомные заголовки HTTP при использовании GitHub Pages. Однако есть обходной путь добавление метатегов на сами страницы.

Добавьте в раздел <head> HTML-кода следующее:

<meta http-equiv="Permissions-Policy" content="interest-cohort=()"/>

GitLab Pages

Как и в случае с GitHub, при использовании GitLab Pages нет возможности добавлять кастомные заголовки HTTP. Таким образом, придется воспользоваться тем же методом, что и выше, и устанавливать директивы в самом HTML.

Однако, если вы пользуетесь GitLab Community Edition, можно установить заголовки, добавив в свой gitlab.rbфайл следующее:

# gitlab.rbgitlab_pages['headers'] = [ "Permissions-Policy: interest-cohort=()" ]

Вы также можете указать заголовки при запуске GitLab Pages binary:

./gitlab-pages -header "Permissions-Policy: interest-cohort=()"

CloudflareWorkers

Вы можете создать следующий Worker Script, чтобы установить заголовки ответа:

addEventListener('fetch', event => {  event.respondWith(handleRequest(event.request))})async function handleRequest(request) {  let response = await fetch(request)  let newHeaders = new Headers(response.headers)  newHeaders.set("Permissions-Policy", "interest-cohort=()")  return new Response(response.body, {    status: response.status,    statusText: response.statusText,    headers: newHeaders  })}

Добавьте этот Worker Script в домен, установив этот домен в качестве Worker Route.

WordPress

WordPress позволяет устанавливать заголовки из своей кодовой базы с помощью хуков. Добавьте следующий код в конец functions.php файла активной темы:

function disable_floc($headers) {    $headers['Permissions-Policy'] = 'interest-cohort=()';    return $headers;  }add_filter('wp_headers', 'disable_floc');}

Сохраните файл в админ-панели WordPress. Все новые запросы будут содержать необходимый заголовок.

Если вы используете какие-либо механизмы кэширования и плагины (например, FastCGI Cache от NGINX, W3 Total Cache и т. Д.), необходимо очистить кэш, чтобы он был повторно заполнен с указанными выше дополнениями.

Дата-центр ITSOFT размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.

Здравствуй, уважаемый читатель!

Многие из нас слышали о слежке за пользователями в интернете и о сборе персональных данных, некоторые сталкивались с этим не понаслышке.

Неважно, являетесь вы домашним или корпоративным пользователем, все мы посещаем различные сайты, которые в той или иной мере вытягивают с наших устройств информацию о нас. Еще больше данных о себе и своем устройстве вы отдаёте, посещая вредоносные сайты.

Собирая эти данные и обрабатывая их, тот, кто ими завладел, может составить ваш цифровой портрет, состоящий из цифровых отпечатков или следов, оставленных в сети и этим уже занимаются злоумышленники, взломавшие 120 рекламных серверов.

Согласно результатам исследованияEFF (Electronic Frontier Foundation), уникальность отпечатка браузера очень высока, и он содержит в себе нижеописанные данные:

• user-agent (включая не только браузер, но и версию ОС, тип устройства, языковые настройки, панели инструментов и т.п.);

• часовой пояс;

• разрешение экрана и глубину цвета;

• supercookies;

• настройки cookie;

• системные шрифты;

• плагины к браузеру и их версии;

• журнал посещений;

• другие данные.

  Если говорить о статистике, то только раз на 286 777 случаев случается полное совпадение отпечатков браузеров двух разных пользователей.

Согласно ещеодному исследованию, точность идентификации пользователя при помощи отпечатка браузера составляет 99,24%.

Рассмотрим вершину айсберга и приведём простые примеры, что может случиться с собираемыми о вас данными:

сбор данных для ведения статистики;

сбор данных для показа рекламы;

сбор данных для продажи организациям;

сбор данных для осуществления незаконных действий;

сбор данных для проведения целенаправленных атак;

сбор данных для кражи и мошенничества;

многое другое.

А контролируете ли вы передачу этих данных, если да, то как? Какими средствами защиты информации и плагинами вы пользуетесь? На этот вопрос каждый из вас может ответить в комментариях.

Если еще сильнее углубиться в данную проблему, то какие данные могут утекать не только у обычных домашних пользователей, но и у сотрудников компаний? И к чему это может привести? Чтобы ответить на этот вопрос, предлагаю ознакомиться с рисунком 1.

Многие из нас сталкивались с различными проблемами и неприятностями в офисе, и для наилучшего решения этих проблем некоторые прибегают к поиску решения в сети.

Ряд сотрудников IT, юридического, финансового и других отделов уже понимают, о чём речь. И эту информацию мы тоже отдаем неизвестным нам ресурсам, трекерам и маячкам, не говоря уже о злоумышленниках.

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

Под прицелом остаются организации, ведущие разработки для оборонно-промышленного комплекса, космонавтики, медицины, научной деятельности и т.д.

Многие компании и их сотрудники становятся уязвимыми для целенаправленных ATP-атак, а это уже влечет за собой более крупные риски и ущерб. Готовы ли мы принимать эти риски?

Согласно проведённому мной опросу, многие руководители, специалисты и рядовые граждане не готовы к этим рискам, так как при их возникновении они сталкиваются или могут столкнуться с рядом проблем:

понижение заработной платы;

лишение премии;

увольнение с работы;

финансовые и репутационные риски организации.

На рисунке ниже вы можете ознакомиться с данными компании PositiveTechnologies за 2019 год и сделать выводы о типах украденных данных. Для статистики были взяты данные за 2019 год, так как отчет за весь 2020 год от PositiveTechnologies еще не сформирован.

Этот вопрос мы прояснили, но давайте постараемся ответить на вопрос А как эти данные крадутся ещё?. Для ответа на этот вопрос мы обратимся к статистике от той же организации и рассмотрим ее на рисунке 3.

Помимо сбора информации о нас для формирования цифрового портрета, данные о нас собирают вредоносные сайты, которые не всегда блокируются средствами защиты информации, некоторые даже не оповещают об этом и для закрытия этого вектора угроз нужна эшелонированная защита. На рисунке 3 мы видим, что первые два места по распространению вредоносного ПО занимают веб-сайты и электронная почта.

Для решения этих проблем была начата разработка двух версий продукта Nemezida DNT:

Nemezida DNT Enterprise Edition версия продукта, созданная для более глубокой защиты компаний и корпоративного пользователя.

Nemezida DNT Home Edition бесплатная версия для домашнего пользователя с функцией режима защиты Перископная. Начиная с режима защиты Рабочая, продукт будет монетизироваться.

На рисунке 4 вы можете ознакомиться c функциями продукта, которые планируются к реализации, часть из них уже реализованы.

На текущий момент у нас реализован следующий функционал:

подмена Fingerprint;

подмена cookie;

подмена user agent;

VirusTotal;

Cisco Talos.

Последние два модуля будут доработаны, в частности, будет больше информативности о посещенном сайте, также посещение вредоносного сайта будет блокироваться.

Особенность нашей разработки заключается в мультифункциональности, она показана на рисунке 5.

Нашими дизайнерами было создано несколько тем для нашего плагина, Home Edition и Enterprise Edition. На рисунке 7 Вы можете ознакомиться с Home Edition темой нашего плагина, она будет доступна по умолчанию для всех режимов защиты, но сменить ее можно будет на другую, только имея лицензию с уровня защиты Рабочая.

Для версии Nemezida DNT Enterprise Edition была разработана тема в трех тонах: Белый, Черный, Синий, с которыми вы можете ознакомиться на рисунках 8, 9 и 10.

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

Многие интересовались, на каком стеке мы ведем разработку нашего продукта, ответ на этот вопрос находится на рисунке 11.

Ниже вы можете ознакомиться с членами нашей команды, которые участвуют в разработке решения.

Выйти в релиз мы планируем через 3-4 месяца благодаря вашей обратной связи о нашем проекте, прохождению опроса и поддержке разработки на платформе Boomstarter.

В комментариях к этой статье вы можете оставить обратную связь, поделиться информацией, как вы решаете описанную в статье проблему, является ли это для вас реальной проблемой, какие средства защиты используете и какие у них есть плюсы и минусы для вас как для пользователя.

Спасибо за внимание!

Google планирует заменить cookie на новую технологию сбора информации о пользователях для рекламодателей. В Евросоюзе опасаются монополии IT-гиганта в области обезличенных данных (ОД) и деанонимизации. Представители бизнеса и эксперты соглашаются с тем, что американская компания только формально будет соблюдать законы стран о защите персональных данных (ПД). По факту Google получит IT-инструмент не только маркетингового, но и идеологического манипулирования гражданами.

Cookie vs FLoC

Организация Electronic Frontier Foundation (EFF), защищающая права пользователей в интернете,раскритиковалановую разработку Google Federated Learning of Cohorts (FLoC), которая придет на замену cookie. По мнению экспертов EFF, новая технология не позволяет сохранять анонимность.

IT-гигант в январе этого годапредставил FLoC систему таргетирования на основе интересов пользователей. IT-продукт будет реализован на базе Chrome. На данный момент он уже включен в качестве экспериментальной функции в следующую сборку браузера и будет запущен в марте этого года.

FLoC будет собирать данные о пользователях через установленный в гаджетах браузер, обезличивая их с помощью машинного обучения, а затем передавать деперсонализированную информацию на серверы компании. Разработчики уверяют, что в данных не будет конкретной истории поиска или посещений сайтов.

Основная цель FLoC создать на стороне браузера маркетинговый полуфабрикат, который бы классифицировал пользователей по определенным когортам (группам). Эта информация позволит выстраивать компаниям таргетированную рекламную стратегию для продвижения своих товаров. Для сервера пользователь становится не Иваном Ивановым, а представителем определенной целевой группы. Например, ценителем антиквариата и оперы, рассказывает RSpectr ведущий аналитик СёрчИнформ Леонид Чуриков.

В EFF отмечают, чтоGoogle, решая проблему с cookie, создает новые болевые точки.

У cookie сложился токсичный имидж. Людям не нравится, когда за их действиями наблюдают. Тем более что их даже не уведомляли о сборе данных во время веб-активности, объясняет Л.Чуриков.

Эксперт отметил, что регуляторов в ЕС, в свете европейского регламента по защите персональных данных (GDPR) и других законов о приватности, смущает возможность по cookies однозначно идентифицировать пользователя. В свою очередь, бизнес начал испытывать проблемы из-за регламента, который обязывает уведомлять пользователей о сборе данных. В итоге они чаще отказываются их предоставлять. Как результат, без веб-портрета клиента начала падать эффективность рекламы и объемы продаж, поэтому разработка нового решения ожидаемое для рынка событие FLoC довольно хитрый инструмент. Формально данные полностью обезличиваются, но их сбор происходит по старой схеме: информация о действиях пользователя, его местонахождении, устройстве.

Леонид Чуриков, СёрчИнформ:

Процедура обезличивания с внесением в когорту предполагает сбор, сравнение данных с другими, анализ, группировку пользователей по интересам. Таким образом, персональная информация все равно попадает в Chrome, а значит в Google. Это одна из главных претензий к FLoC с точки зрения безопасности и этики. Технология выглядит как попытка уйти от ответственности по GDPR (и перед пользователями, и перед регуляторами). К тому же ведет к монополизации большого объема чувствительных данных в руках крупного игрока. Притом что с партнерами и рекламодателями Google чистыми данными больше не делится компания может получить конкурентное преимущество, предлагая более персонализированную рекламу.

Инженер-программист Рексофт Максим Жук подтверждает, что через обезличенные когорты можно вычислить возраст, пол, гастрономические и политические предпочтения пользователей. Когда подобные данные разрозненно собираются разными сайтами, из них сложно восстановить цифровой портрет человека. Но при наличии владельца единого хранилища информации задача становится довольно тривиальной, поясняет эксперт.

О том, как это происходит, порталу RSpectr рассказал генеральный директор IT-компании Omega Алексей Рыбаков: При регистрации с помощью почты или при аутентификации через аккаунт Google сайт может соотнести FLoC-группу по интересам с введенными ПД. Это значит, что информация уже не будет обезличена. При наличии данных о нескольких пользователях из одной когорты есть большая вероятность, что у них будут общие признаки. Соответственно, подобная информация о пользователе может быть раскрыта на основе FLoC-группы.

Google опасается, что малое количество людей в когортах по интересам позволит деанонимизировать пользователей, поэтому в каждой категории должно быть несколько тысяч людей, отметил в разговоре c RSpectr преподаватель Moscow Digital School Олег Блинов.

"Вседержитель" данных

Казалось бы, в одну группу попадает много людей, что снижает их идентификацию. Но браузер также передает сайтам данные об устройстве пользователя. ОД будут идти с конкретного серийного номера аппарата, что упростит алгоритм деанонимизации, сообщил RSpectr руководитель центра бизнес-аналитики RAMAX Group Сергей Левашов.

О.Блинов добавляет, что деперсонализация возможна благодаря тому, что будет пересечение неуникальных характеристик, например, IP-адреса и когорты.

Можно отключить передачу большей части этих данных, но нельзя запретить полностью. Как правило, большинство пользователей даже не знают о возможности отключения этой функции. Именно эти детали позволяют отсеять других пользователей из группы интересов и идентифицировать конкретного человека. Таким образом, FLoC-технология может применяться для деперсонализации под самые разные задачи.

Президент ассоциации РУССОФТ Валентин Макаров сообщил, чтоGoogle стремится стать самым крупным держателем обезличенных и персональных данных.

Представитель Рексофт считает, что это более серьезная проблема, чем сам факт деанонимизации.

Максим Жук, Рексофт:

Владельцем всех пользовательских данных будет одна организация. Не общественная, а частная компания. Это дает власть над информацией, даже если она обезличена. Важным свойством интернета является децентрализованность, которая обеспечивает высокий уровень устойчивости. Усиление одной корпорации это путь к воплощению в жизнь антиутопии. IT-гиганты давно идут по собственному пути к доминированию в области владения ОД, и FLoC это крупный шаг Google в этом направлении.

Эксперт считает, что будет правильно, если исходный код нового IT-решения будет открытым, что защитит данные пользователей от прямого сбора.

При этом аналитики признают, что группирование ПД и торговля их обезличенными пачками действительно один из самых простых в реализации способов преодолеть проблемы cookies. При внедрении FLoC все останутся при своем: браузеры, коммерция продолжат собирать данные, регуляторы номинально получат деперсонализацию. Главные проблемы FLoC создаст для здоровой конкуренции в бизнесе, но с учетом лоббистских возможностей крупных корпораций, мнение более мелких игроков рискует остаться неуслышанным, делает выводы Л.Чуриков.

Кого защитит закон

Учитывая, что сформированные FLoC-когорты могут являться идентификаторами человека, сбор таких данных без согласия пользователей в России запрещен, рассказала RSpectr консультант по информационной безопасности Cross Technologies Наталья Иванова. Также гражданам необходимо знать сроки такой обработки, цели и основания. Говоря о согласованности FLoC с европейскими нормами защиты данных, эксперт подчеркнула, что разработка Google может попасть под ограничения GDPR, касаемые профилирования данных. При нарушении этих требований будет нарушен регламент GDPR.

В последние годы по всему миру происходят изменения законодательной базы в отношении сбора и защиты ПД, но каждая из стран делает акцент на кардинально разных моментах.

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

Власти США в 2020 году обязали YouTube, Facebook, Google и другие компании рассказать о методах сбора и обработки ПД, поскольку западные IT-платформы не раз оказывались в центре подобных скандалов, рассказывает А.Рыбаков.

Алексей Рыбаков, Omega:

Например, Google тайно собирал личные данные о лечении пациентов и следил за своими сотрудниками. Twitter сливал рекламодателям телефонные номера и адреса электронной почты. YouTube для показа рекламы собирал данные о детях, а Facebook информацию о пользователях, и предлагал на этом заработать. В США до сих пор отсутствует федеральный закон, охватывающий все штаты, который бы регламентировал защиту персональных данных.

Летом 2020 года Европейский суд в Люксембурге отменил соглашение о трансфере данных между ЕС и США, известное как Privacy Shield (Щит конфиденциальности). Причина опасения по поводу слежки со стороны американских властей. В итоге был вынесен запрет на хранение персональных данных граждан ЕС на территории США, что американцам, конечно, не понравилось, сообщил А.Рыбаков.

Со стороны Евросоюза стоит ожидать пояснений европейских регуляторов о том, должны ли сайты получать отдельное согласие от пользователей на сбор информации для группы по интересам, отметил О.Блинов.

Еврокомиссия ЕС представила новые правила, позволяющие компаниям получать доступ к ОД граждан для развития новых цифровых сервисов. Эти изменения похожи на решение Google. Эксперты считают, что IT-компаниям ЕС будет сложно конкурировать с предложением американского digital-гиганта.

Рекламировать нельзя манипулировать

В Google утверждают, что с новой системой FLoC рекламодатели получат конверсию на уровне 95% за каждый вложенный в продвижение доллар.

В EFF считают, чтоесли данные о когортах сможет получить любой сайт, то возрастут риски агрессивного таргетинга в отношении пользователей.

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

Эксперты также отмечают риски нецелевого использования новой технологии.

Валентин Макаров, РУССОФТ:

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

О.Блинов не исключает контроля со стороны государств. Если вы периодически заходите на сайты госуслуг, то может быть собрана информация о вашей когорте. На ее основе построят предположения, какие конкретно сайты вы посещали, чем интересуетесь, считает эксперт.

Для бизнеса FLoC тоже станет расширенным по функционалу инструментом. Компании смогут узнавать о пользователях значительно больше, чем знали до этого. Сейчас бизнесу доступна информация только о действиях посетителя в их интернет-магазине. Технология FLoC предполагает, что группа по интересам формируется на основании всех посещаемых человеком сайтов. Получив вашу когорту, интернет-магазин может узнать, чем вы интересуетесь за его пределами, отмечает О.Блинов.

В последние месяцы стало много разговоров о cookie и том, что срок их жизни станет гораздо меньше, чем мы привыкли. Вместе с Владом Флаксом, CEO OWOX, разобрались в том, какие нововведения нас ждут и как адаптироваться маркетологам в новой реальности.

Что происходит?

Браузеры начинают ограничивать срок жизни cookie, игнорируя то время, которое устанавливается javascript или сервером сайта. Например, в Safari cookie сейчас хранятся 2 недели. Это означает, что если пользователь не заходит на сайт в течение 14 дней, то в следующий визит он получит новую cookie и может быть определен как новый пользователь. В новых версиях стандарта ITP 2.2 это ограничение становится еще более жесткими и для third party cookie (установленные сторонними сервисами) срок жизни сокращен до одного дня. Это ограничивает возможности для ретаргетинга сторонними площадками до одного дня, в течение которого, если пользователь не провзаимодействует с сайтом вновь, то cookie будут удалены.

Второй блок изменений связан с ограничениями возможностей отслеживания кампаний на уровне пользователя. Раньше сервисы могли выгружать данные с точностью до конкретного пользователя. Сейчас эта возможность недоступна и это одно из ограничений для аудиторных закупок, FTP рекламы и анализа когорт пользователей.

Третье платформы iOS, Android и браузеры ограничивают отслеживание на уровне пользователя. Например, iOS ограничивает использование IDFA это аналог cookie для устройств Apple. Ограничение вступит в силу с начала 2021 года и будет заключаться в том, что использование IDFA в рамках мобильного приложения будет отключено, пока пользователь явно не даст свое согласие на сбор и хранение данных. Можем предположить, что процент пользователей, которые зароются так глубоко в настройки, будет невелик. А без этого идентификатора все действия, которые может отправлять приложение, не будут связаны с конкретным устройством.

Кроме того, сейчас обсуждается даже ограничение в использовании User Agent в Google Chrome, что сделает невозможным применением методик Fingerprint.

Какие альтернативы?

Для отслеживания эффективности рекламных кампаний Google предлагает Ads Data Hub, который консолидирует в себе всю информацию о рекламных кампаниях, доступную Google, и делает ее доступной для анализа рекламодателем, но не дает выгружать отчеты на уровне пользователя.

У Apple своя реализация это инструмент SKAdNetwork, который так же позволяет получить оценку на уровне рекламной кампании, но не на уровне пользователя. Если рекламный сервис подключен к этой платформе, то из мобильного приложения можно отправлять конверсии и сигналы в этот сервис, а из него получать оценку того, какая ценность и какие были взаимодействия между конкретной рекламной кампанией и пользователями. Здесь появляется гораздо больше ограничений, например, до 100 рекламных кампаний в одном аккаунте, и нарезать эти кампании так, чтобы отследить конкретного пользователя не получится.

Как работает сбор данных о кампаниях и пользователях

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

Суть проблемы в том, что CRM рекламодателя, как и прежде, содержит информацию о заявках на уровне пользователя. Но пользователь обычно взаимодействует с несколькими рекламными сервисами и перед маркетологом стоит задача отследить эти посещения и связать конкретное конверсионное действие в браузере с источником, который привлек пользователя. Теперь же данные в сервис аналитики больше не будут поступать на уровне пользователя. В случае с данными, которые отправляются с мобильной платформы, например, iOS, не будет доступен идентификатор IDFA, который служит признаком для объединения данных на разных платформах. Есть аналог IDFA, который может использоваться для аналитики внутри одного приложения, но он не позволит объединять данные рекламных кампаний с данными приложения.

Второе изменение, о котором уже упоминали выше, cookie, которые устанавливаются пользователю на сайте в веб-окружении, будут удаляться спустя сутки неактивности. И если такой пользователь, взаимодействовал с сайтом в понедельник утром и вернулся во вторник вечером, то он получит источник трафика direct, так как связи с предыдущей сессией не будет и ему будет назначен новый cookie.

Некоторые сервисы аналитики имеют исключительную интеграцию с рекламными сервисами, например, Google Analytics с Google Ads и Firebase или Яндекс.Метрика с Яндекс.Директ. То есть сервисы от вендоров дают дополнительную информацию, но по очевидным причинам, они не могут выступать медиатором, и каждый из них собирает свое подмножество данных. Маркетологам же нужно комплексно оценивать рекламные кампании. И так как рекламные кампании не могут быть связаны на уровне пользователя, то это ведет к следующим последствиям.

С чем столкнутся маркетологи

1. Увеличится доля новых пользователей в отчетах. Хотя мы понимаем, что это вернувшиеся пользователи, которых мы не можем идентифицировать из-за того, что браузер присвоил им новый cookie.

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

3. Уменьшится длина конверсионной цепочки. Если раньше можно было наблюдать, как пользователь делает несколько кликов до совершения конверсии, то теперь сократится количество касаний, которые можно будет связать с одним пользователем.

4. Значительно ограничатся когортные отчеты, потому что они строятся на основе свойств пользователей, которые теперь станут недоступны для того, чтобы объединить последовательность действий, вовлечение в продукт или заказ.

5. Снизится качество атрибуции. Если раньше можно было полагаться на условно простые методы, например, по последнему клику, и напрямую связывать кампании с источниками, то сейчас результат этой операции станет менее точным.

6. Кампании будут выглядеть более ласткликово. Потому что для сервиса аналитики станет доступна только та история, которая произошла с пользователем в течение одного дня. Соответственно, их оценка станет ближе к последнему клику.

7. Вырастет роль ассоциированных конверсий в оценке кампаний. Уже сейчас многие рекламные каналы рекламодатели оценивают с учетом ассоциированных конверсий, так как по той доле пользователей, которая явно кликнула на рекламу, их оценить невозможно.

Какие изменения затронут рекламные кампании

1. Вырастет стоимость привлечения клиента. Прежде всего, потому что рекламные сервисы будут обладать меньшей информацией для таргетинга рекламного объявления подходящему пользователю. И чем меньше возможности у рекламного сервиса определить, что это предложение или этот креатив соответствует интересам пользователя, тем менее релевантно оно будет снизится CTR, увеличится CPA.

2. Снизится охват Look-a-like кампаний, если он вообще сохранится, ведь фактически он будет сохраняться до тех пор, пока живет third party cookie. Если пользователь после получения third party cookie заходит на сторонний сайт, например, Google, то срок жизни такого cookie будет продлеваться. И значит ретаргетинг в Google, Facebook или любом другом Walled Garden будет жить дольше, чем ретаргетинг от условного Сreteo (так как у последнего меньший охват через свои площадки). Недоступность данных на уровне пользователя не позволяет строить Look-a-like креативы.

3. С рынка уйдут небольшие игроки. То, что себе может позволить большой рекламный сервис в качестве аргументации того, как его кампании драйвят продажи рекламодателя за счет ассоциированных конверсий, то маленьким игрокам эта стратегия не подойдет. Для этого нужно будет пробрасывать post-back конверсии во все рекламные сервисы. Ассоциированные конверсии работают от той информации о конверсиях, которую с сайта или приложения отправляет рекламодатель. И большинство имеют конверсионные пиксели от Google, Facebook или Яндекса, но если рекламодатель использует десятки рекламных сервисов, то в каждый из них пробрасывать свои конверсии он, скорее всего, не будет.

Как это отразится на отчетах

Рассмотрим на примере:

Здесь несколько веб и мобайл рекламных кампаний. В таблице видно, что есть некоторое количество ассоциированных конверсий, которые по данным рекламного сервиса относятся к конкретной кампании. И есть конверсии, которые относятся к конкретной рекламной кампании, согласно атрибуции по модели последнего не прямого клика. Сумма всех конверсий равна 100, а сумма ассоциированных конверсий при этом 195, потому что с одной конверсией взаимодействовало несколько рекламных кампаний и было совершено несколько кликов.

Что произойдет после изменений? Значительно уменьшится количество рекламных каналов, которые можно проассоциировать с конкретной конверсией. И число таких конверсий, связанных с кампанией, будет меньше, потому что информация на уровне пользователя в контексте мобильного приложения или браузера станет недоступна. Конечно эти конверсии не исчезнут, они будут аллоцированы в рамках рекламного сервиса аналитики в direct канал. То есть это будет выглядеть так, будто новый пользователь пришел из ниоткуда и совершил конверсию. Сами ассоциированные конверсии где-то вырастут, где-то уменьшатся. Вероятнее всего их число вырастет у больших игроков, и их не будет у мелких.

Как эти изменения влияют на бизнес и что сделать, чтобы не потерять в эффективности

1. Если рекламодатель оценивает эффективность рекламных кампаний непосредственно в кабинете рекламного сервиса (например, использует только Facebook Ads и не использует другие рекламные сервисы), то влияние изменений будет низкое и рекламодатель сможет продолжать работать, как и раньше.

2. Если же работать с охватными кампаниями в Walled Garden (крупнейшие сервисы Google, Facebook и Яндекс), то влияние будет среднее, потому что охватные кампании направлены на метрики, которые собираются вокруг кампаний, а не пользователя, и доступны в рекламном кабинете так же на уровне сегментов.

3. Если рекламодатель оценивает рекламные кампании с помощью сквозной аналитики, которая объединяет действие пользователей в разных точках касания, то влияние будет высоким.

4. Если сейчас рекламодатель использует аудиторные сегменты и кросс-девайс отчеты, объединяя действия пользователей до отправки их в рекламные сервисы, то влияние будет очень высоким.

Как проверить, насколько это повлияет на вас

Компания Orange Valley подготовила дашборд, который помогает ответить на вопрос, какая доля дохода находится в зоне риска. Для этого она предлагает сравнить долю новых пользователей в браузере Safari и других браузерах. На картинке видно, что в Сафари на 10% больше новых пользователей, но мы уже понимаем, что они не новые, они просто получили новый идентификатор cookie.

Что делать дальше

Самое главное собирать first party и second party данные.

First party это те данные, которые компания может собрать в своем приложении или на своем сайте, которые пользователи предоставили напрямую. Second party это данные, собранные рекламным сервисом, например, данные из рекламных кабинетов.

1. Чтобы это сделать, надо в первую очередь внедрить Marketing Data Lake. Это нужно, чтобы данные принадлежали и контролировались вами, а не рекламным сервисом. Пока данные о пользователях хранятся в разных системах, особенно тех, которые не принадлежат вам, например, в рекламном аккаунте, CRM, никакой анализ рекламной кампании не возможен.

2. Собирать сырые данные о действиях пользователей с сайта и мобильного приложения. Сырые это значит, что каждая строчка в базе и каждое действие приводит к его регистрации и сохранению, это не агрегированные данные. Здесь не должно быть метрик это каждое взаимодействие записанное отдельным хитом. Важно, что здесь надо собирать данные с такими полями, которые могут быть использованы для связи неавторизованных пользователей. Например, UserAgent и FingerPrint.

3. Импортируйте в Data Lake максимально гранулированные данные из рекламных кабинетов. Многие ограничиваются только utm-метками для отслеживания переходов из рекламных кабинетов. Но этого недостаточно для построения аналитики без связи с конкретным пользователем. Например, Facebook Ads позволяет выгрузить до 200 полей.

4. Мотивация пользователей авторизоваться на сайте и в приложении. Это недооцененная активность, которая позволяет рекламодателю собирать данные в контексте конкретного пользователя без IDFA и cookie, а использовать собственный идентификатор и объединять по нему пользователя на разных платформах.

Что делать с собранными данным

• Прежде всего нужно построить свою таблицу cross-device matching. Эта таблица объединяет все доступные идентификаторы пользователя в один уникальный профиль. Это расширит знания о пользователе и его действиях, которые могут быть связаны. Не всех пользователей можно объединить с помощью такого подхода, но увеличить количество сессий, идентифицировано связанных с профилем, можно в разы. В зависимости от того, насколько много используется источников, можно расширить долю тех взаимодействий с пользователем, которая будет объединена. Если раньше это были сессии неконвертировавшихся пользователей, то теперь можно увидеть, что они участвовали в цепочке cross-device и cross-browser.

Вот пример такого объединения. Столбец ProfileID уникальный профиль пользователя, который объединяет в себе несколько идентификаторов Google Analytics 360 (столбец GoogleAnalytics.fullVisitorID) и несколько Client ID (столбец GoogleAnalytics.clientId).

• Построить отчеты по рекламным кампаниям на внутренних данных и сравнить их с отчетами рекламных сервисов. Они не должны полностью совпадать, но это позволит найти ошибки и провести соответствие между тем способом объединения и подсчета данных, который есть внутри компании, с рекламным сервисом. Это поможет откалибровать маркетинг-микс и его показатели на те данные, которые предоставляет каждый из рекламных сервисов.

• Применить cross-device профиль пользователя для расчета атрибуции рекламных кампаний. Это даст более объективную оценку, потому что с его помощью большая доля сессий будет оценена с точки зрения вклада в привлеченные конверсии. Раньше они заканчивались ничем, потому что пользователь не авторизовался и не оформил заказ, но позже он проявлял себя как покупатель (проверял статус заказа или переходил из письма, отправленного ему из CRM) и таким образом технически есть возможность связать его с идентифицированным пользователем. Этот подход позволит значительно увеличить качество оценки рекламных кампаний.

• Применить cross-device профиль при отправке аудиторных сегментов. Даже с учетом ограничений, работа с аудиторными сегментами сохранится, потому что для их использования не нужно знать конкретный идентификатор пользователя во внутренней системе. Достаточно знать соответствие с идентификатором в рекламном сервисе. Проведя это соответствие и сохранив его в своей базе, в рекламные сервис будет отправляться идентификатор из рекламного же сервиса. Таким образом, применив cross-device профиль, можно увеличить охват тех аудиторных сегментов, которые применяются.

• Использовать накопленные данные для машинного обучения и прогнозирования лучшего маркетинг-микс. Доступность гранулированных данных из рекламных сервисов это основное условие для выполнения вычислений. Очевидно, что проделать эту работу необходимо до того, как доступ к этим данным будет утерян. Потому что откалибровав свою систему аналитики и свои метрики, станет возможным в условиях изменяющегося окружения давать оценку своим кампаниям то ли что-то поменялось в активностях компании, то ли это изменения связано с обновлением браузера и операционных систем. Как оценить вклад кампаний на основе ассоциированных конверсий на эти вопросы будет возможно ответить.

Вот как может выглядеть схема сбора и движения данных, если собирать их из мобильного приложения (AppsFlyer), сайта (Google Analytics), подключить Ads Data Hub, как инструмент объединения данных о рекламных кампаниях; подключить сбор данных из других рекламных кабинетов с помощью коннектора, добавить данные из CRM и на основе этого строить отчеты и атрибуцию.

Пусть никакие обновления не застают вас врасплох и may the force data be with you!