RU EN
www.

Методология

0

Принципы

Аудит — это воспроизводимое измерение, а не мнение. Каждое утверждение в публикации опирается на конкретный артефакт: HAR-файл, скриншот, фрагмент кода. Человек с минимальной технической подготовкой может повторить замер по этой методике.

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

Инструменты

Процедура

  1. Подготовка сессии. Свежий профиль браузера, очищенные cookies, отключённые расширения. Открываются инструменты разработчика, начинается запись сети.
  2. Открытие сайта. Запросы фиксируются с точными временными метками относительно начала сессии.
  3. Взаимодействие с баннером согласия (если есть): отдельно записывается состояние до клика и после выбора.
  4. При необходимости — другие страницы сайта, если трекеры могут включаться вне главной.
  5. Экспорт HAR-файла с временной меткой и контрольной суммой SHA-256.

Объём замера — какие страницы открывались и что нажималось в баннере — указывается в каждом разборе. Вывод разбора относится только к этому объёму.

Классификация запросов

Каждый сетевой запрос классифицируется по нескольким измерениям:

Состояние согласия: строка, а не ярлык

Вердикт «согласие дано / отклонено» выносится по декодированной строке TCF (IAB TC-string) из запросов к рекламным партнёрам, а не по имени события платформы согласия (CMP). CMP может отправлять событие с типом «consent.given» на любой выбор пользователя — и на приём, и на отказ; имя события фиксирует, что выбор сделан, но не какой именно. Что именно сайт сообщил партнёрам, видно из TC-строки: сигналы согласия и законного интереса по каждой цели читаются из неё однозначно. Это сигнал, переданный партнёрам, — а не оценка того, было ли согласие юридически действительным.

Если TC-строки в замере нет, состояние согласия считается неопределённым, а не данным.

Это различие само стало показательным случаем. Автоматическая проверка, читающая имя события CMP, показывала «согласие дано» там, где строка кодировала полный отказ — практика, о которой иначе можно было не узнать. Расхождение между ярлыком и декодированным состоянием — это и есть предмет проекта: заявленное против фактического. Ярлык не доказательство; доказательство — декодированное состояние.

Правовая квалификация

Технические находки сопоставляются с двумя группами норм.

ePrivacy — Директива 2002/58/EC, ст. 5(3), и национальные законы, которые её вводят (например, в Германии — § 25 TDDDG, в Эстонии — закон об электронных коммуникациях). Эта норма требует согласия на запись информации в устройство пользователя и на чтение её оттуда — cookie, localStorage, идентификаторы, — если это не строго необходимо для услуги, которую пользователь сам запросил. Вопрос «трекеры и cookie до согласия» — прежде всего вопрос ePrivacy.

GDPR — для того, что происходит с персональными данными дальше:

Аудит не делает выводов о виновности или умысле — он фиксирует факты и указывает применимые нормы.

Три регистра формулировок

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

  1. Наблюдение (факт). Что зафиксировано в HAR: «браузер отправил запрос к X до появления баннера согласия (+3163 мс)». Воспроизводимо и не зависит от толкования.
  2. Оценка (сопоставление с нормой). Как факт соотносится с нормой: «наблюдаемое поведение расходится с заявленным механизмом согласия и указывает на возможное несоблюдение Art. 6(1)». Это обоснованное мнение проекта.
  3. Правовой вывод (квалификация). «Надзорный орган установил нарушение Art. X». Используется только при наличии решения регулятора или суда — со ссылкой на документ.

По умолчанию проект работает на уровнях 1 и 2. Слово «нарушение» без решения компетентного органа не используется: вместо него — «замечание», «признак несоответствия» или «указывает на возможное несоблюдение». Это касается и шаблонов писем: в жалобе регулятору заявитель просит проверить обстоятельства, а не утверждает нарушение как установленный факт.

Доказательственная цепочка

Для каждого аудита публикуется:

Это даёт возможность проверить целостность доказательства и повторить замер.

Очистка и анонимизация HAR

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

Что удаляется

Из публикуемого HAR удаляются персональные данные автора аудита: значения куки (Cookie, Set-Cookie); заголовки авторизации (Authorization, Proxy-Authorization, CSRF- и сессионные токены, заголовки с суффиксами -token, -auth, -key, -secret, -session); тела запросов и ответов, не являющиеся доказательством (код скриптов, стили, изображения, а также любые тела крупнее 8 КБ) — обнуляются, размер и MIME-тип сохраняются; чувствительные параметры URL (token, session, password, code, signature и подобные — значение вычищается, имя остаётся); IP-адрес клиента; локальные пути в стеке инициатора.

Что сохраняется намеренно

Всё, что составляет доказательство передачи данных третьим сторонам, остаётся нетронутым: имена куки и их атрибуты (Path, Max-Age, HttpOnly) — по имени видно, какой трекер её поставил; IP-адрес сервера-получателя; инициатор запроса — какой скрипт вызвал обращение; тайминги — когда произошло каждое обращение; происхождение файла — какой браузер снял HAR; тела запросов и ответов, несущие доказательство — небольшие (до 8 КБ) ответы рекламных бирж, заявки RTB-аукциона, списки сетей, которым передаются данные, и строки согласия (TC-string). Внутри таких тел вычищаются личные поля (идентификаторы, User-Agent, email и подобные), но структура-доказательство сохраняется.

Ключевой принцип: удаляется личное содержимое, сохраняется факт передачи. Вырезано значение куки — но видно её имя, получателя, инициатор, размер и момент отправки.

Ограничение очистки: по опубликованной копии видно, кому и когда уходили запросы и какие поля в них были, но без значений идентификаторов нельзя проследить, что разные запросы несут один и тот же идентификатор. Где это важно для вывода, разбор говорит об этом прямо и опирается на оригинал (см. «Хранение оригиналов»).

Как это устроено

Очистка автоматическая — скрипт har_redact.py, без ручного вмешательства в отдельные записи. К каждому очищенному файлу создаётся карта редактирования (_redaction_map.json) — перечень того, что и в какой позиции было вычищено, что делает саму очистку проверяемой. Целостность опубликованного файла подтверждается SHA-256, указанной на странице аудита.

Хранение оригиналов

Необезличенный оригинал HAR (до очистки) хранится отдельно от сайта: на зашифрованном хранилище (Proton Drive), под двойным шифрованием и сложным паролем; доступ единоличный — только автор проекта, преемственность доступа на данный момент открытый вопрос; хранение бессрочное — оригинал является доказательной базой, его удаление лишило бы аудит проверяемости. В оригинале — данные самого автора аудита, а не посетителей проверяемых сайтов.

Мы исходим из того, что бессрочное хранение оригиналов как доказательной базы допустимо по ст. 5(1)(e) и 89(1) GDPR (архивирование в общественных интересах) — при гарантиях: шифрование, единоличный доступ, использование только для проверки разборов. Это наша позиция, а не решение регулятора; если надзорный орган сочтёт иначе, порядок хранения будет пересмотрен.

Это согласуется с принципом проекта: один человек с воспроизводимой методологией фиксирует факты и отвечает за них лично. Очистка и хранение — часть этой ответственности.

Ограничения

Если замечания устранены

Разбор фиксирует состояние на дату замера. Если сайт устранил замечания, об этом можно сообщить на contact@gdpru.eu — с указанием домена и того, что именно исправлено.

После обращения проводится повторный замер по той же методике (новый HAR, те же проверки). Если прежние замечания не подтверждаются, разбор переносится в раздел «Исправленные сайты» с датой повторной проверки, а первоначальный разбор остаётся доступным. Ответ и перепроверка — в течение 30 дней с момента обращения.

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

Что делать с результатами аудита

Если разбор показал признаки несоответствия — у вас есть право подать жалобу в орган по защите данных на основании статьи 77 GDPR. Для физического лица это бесплатно в любой стране ЕС.

Рекомендуемый порядок действий:

  1. Сначала обратитесь напрямую в компанию — дайте ей 30 дней на ответ.
  2. Если ответа не было или он не снимает вопросов — переходите к жалобе в регулятор.

Статья 77 GDPR не требует сначала обращаться к компании. Но на практике многие регуляторы ожидают, что заявитель сперва попытался решить вопрос напрямую, и жалобы без такой попытки нередко возвращают. Поэтому письмо компании — разумный первый шаг.

Вам не нужно писать эти письма самостоятельно. Под каждым разбором с замечаниями есть готовый инструмент: письмо компании (запрос доступа к данным по ст. 15 GDPR) и письмо регулятору — оба уже заполнены фактами именно этого разбора (замечания, дата, ссылка на доказательства, контрольная сумма HAR). Впишите своё имя, email и страну — и оба письма готовы к печати и подписи.

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

Это не юридическая консультация — мы не юристы, это стандартная структура жалобы, основанная на требованиях, которые сами регуляторы публикуют на своих сайтах. Точный способ подачи в конкретной стране (форма, email, срок ответа) — смотрите блок «Как подать жалобу» на странице соответствующей страны.

Никакого сбора данных в письмах-жалобах

Инструмент подачи жалоб (запрос доступа к компании и жалоба регулятору под каждым аудитом) собирает имя, email и страну только в браузере читателя, для подстановки в текст письма перед печатью. Это не наши слова на веру — вот три способа проверить это самостоятельно:

  1. В коде физически нет отправки. В коде сайта нет ни одного вызова fetch, XMLHttpRequest, sendBeacon или отправки формы — то есть механизма, которым данные вообще могли бы куда-то уйти, попросту не существует.
  2. Даже если бы он появился — браузер бы его заблокировал. Сайт отдаёт строгую политику безопасности: правила default-src 'self' и connect-src 'self' в заголовке Content-Security-Policy запрещают браузеру отправлять запросы на любой посторонний домен, вне зависимости от того, что написано в коде.
  3. Проверьте вживую. Откройте инструменты разработчика (F12) → вкладку «Сеть», впишите тестовое имя в поле на странице аудита — если за это время не появится ни одного нового сетевого запроса, значит данные никуда не ушли. Это можно увидеть своими глазами, не разбираясь в программировании.

Открытость

Методология открыта для критики. Если вы замечаете методологическую ошибку — напишите по адресу contact@gdpru.eu. Изменения в методике публикуются в дневнике проекта.