80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Всеки банер за бисквитки дава едно и също имплицитно обещание: натиснете „Отхвърляне" и проследяването спира. Банерът изчезва и вие сърфирате спокойно. Това е сделката, върху която е изграден моделът за съгласие -- идеята, че потребителите имат смислен, приложим избор.

Тествахме това обещание на 28 891 уебсайта в ЕС. На 80,4% от тях обещанието е нарушено. Проследяването продължава, след като потребителят изрично натисне отхвърляне. Бисквитките остават. Рекламните пиксели продължават да се задействат. А на 1 642 сайта бисквитки, които действието за отхвърляне първоначално изчиства, се връщат при следващото зареждане на страницата -- модел, който наричаме consent respawn.

Това не е маргинална констатация за няколко погрешно конфигурирани сайта. Това сочи към системен проблем в механизма, на който стотици милиони жители на ЕС разчитат за правата си на поверителност.

Какво трябва да прави „Отхвърляне" -- правно

Правната рамка е ясна. Съгласно Член 5(3) на Директивата за ePrivacy, съхраняването или достъпът до информация на крайното оборудване на потребителя изисква предварително съгласие, с тясно изключение за бисквитки, строго необходими за услуга, която потребителят изрично е поискал. Член 7(3) на GDPR добавя, че оттеглянето на съгласие трябва да бъде толкова лесно, колкото и даването му, и администраторът на данни трябва да действа по това оттегляне.

Насоките 05/2020 на EDPB относно съгласието по GDPR уточняват какво означава това за бутоните за отхвърляне: ако уебсайт предлага опция „Приеми всички", той трябва също да предложи еднакво видна и еднакво достъпна опция за отказ. И този отказ трябва да бъде ефективен -- трябва действително да предотврати обработката, която съгласието би разрешило.

CJEU подкрепи това в Planet49 (C-673/17): съгласието изисква ясно утвърдително действие и предварително отметнатите полета не представляват валидно съгласие. Логическото следствие е, че отказът -- изрично отрицателно действие -- трябва да бъде уважен толкова категорично, колкото и приемането. Ако кликването на „Приеми" включва проследяването, кликването на „Отхвърляне" трябва да го изключи. Не частично. Не временно. Изцяло и постоянно.

Това казва законът. Нашите данни показват какво наистина се случва.

Как тестваме потока за отхвърляне

Нашият тест за потока за отхвърляне е проектиран да бъде възможно най-близо до преживяването на реален човешки потребител, натискащ отхвърляне, с добавянето на всеобхватна инструментация. Ето процеса стъпка по стъпка:

Стъпка 1: Чиста сесия на браузъра. Скенерът стартира чист екземпляр на Chromium -- без бисквитки, без локално хранилище, без кеширани ресурси, без история на сърфиране. Това е истински нов посетител без предишно състояние на съгласие. Стъпка 2: Навигация и записване на състоянието преди съгласие. Скенерът зарежда целевия URL и изчаква страницата да се стабилизира. Преди каквото и да е взаимодействие, записва всяка бисквитка в браузъра, всяка направена мрежова заявка и всеки контактиран домейн на трета страна. Това е базовата линия преди съгласие -- какво прави сайтът, преди потребителят да е имал възможност да направи избор. Стъпка 3: Откриване на банера за съгласие. Използвайки нашата библиотека за откриване, покриваща 45 известни CMP и общи евристики, скенерът идентифицира механизма за съгласие и намира бутона за отхвърляне. Тази стъпка използва многослоен подход: първо проверява за известни подписи на CMP скриптове и техните асоциирани DOM структури, след което се връща към общо откриване на елементи с фиксирана позиция със свързан със съгласието текст и етикети на бутони като „Reject All", „Decline", „Refuse" или еквивалентни преводи. Стъпка 4: Кликване на отхвърляне. Скенерът кликва бутона за отхвърляне и изчаква страницата да се установи. „Установяване" означава изчакване чакащите мрежови заявки да приключат, DOM мутациите да спрат и всички анимации или преходи да завършат. Използваме щедри таймаути, за да избегнем фалшиви положителни резултати от бавни реализации на CMP. Стъпка 5: Снимка след отхвърляне. Скенерът записва пълното състояние отново: всички бисквитки, цялата мрежова активност, всички домейни на трети страни. Тази снимка се сравнява с базовата линия преди съгласие, за да се определи какво се е променило. Стъпка 6: Презареждане и проверка за respawn. Скенерът презарежда страницата и изчаква отново да се стабилизира. След това прави финална снимка. Тази стъпка е критична: тя разкрива дали действието за отхвърляне е постоянно (уважено при повторно зареждане) или бисквитките и проследяването се активират отново при ново зареждане на страницата. Ако бисквитки, премахнати в Стъпка 5, се появят отново в Стъпка 6, това е consent respawn.

Всяка стъпка произвежда доказателства с времеви печат и архивен характер: пълни описи на бисквитки с имена, стойности, домейни, дати на изтичане и флагове; пълни логове на мрежови заявки с URL адреси, методи, кодове за отговор и тайминг; и пълноекранни снимки. Тази верига от доказателства позволява всяка отделна констатация да бъде проверена и оспорена.

Резултатите: 80,4% неуспех

От 28 891 уебсайта, на които успешно завършихме пълния тест на потока за отхвърляне:

• 5 650 (19,6%) преминаха. След кликване на отхвърляне несъществените бисквитки бяха премахнати, заявките за проследяване спряха и отхвърлянето остана в сила при повторно зареждане на страницата.
• 23 241 (80,4%) не преминаха. Проследяването продължи в някаква форма, след като потребителят изрично натисна отхвърляне.

Неуспехите не са еднородни. Те попадат в отделни категории, които се припокриват -- един сайт може да показва множество видове неуспех едновременно.

Устойчиви бисквитки: 10 848 сайта

На 10 848 сайта (37,5% от тестваните) несъществени бисквитки останаха в браузъра след завършване на потока за отхвърляне. Това са бисквитки, класифицирани като аналитични, маркетингови или свързани с проследяване, които трябваше да бъдат премахнати или да не бъдат поставяни след действие за отхвърляне.

Най-честите устойчиви бисквитки принадлежат на Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) и различни рекламни платформи. В много случаи CMP успешно премахва някои бисквитки, но не улавя всичките -- което предполага непълна интеграция между платформата за управление на съгласието и пълния набор от скриптове на трети страни на сайта.

Наличието на тези бисквитки след отхвърляне не е просто естетичен проблем. Всяка от тях е устойчив идентификатор, който свързва текущата сесия на потребителя с минали и бъдещи посещения. Бисквитката `_ga`, например, е уникален клиентски идентификатор, който Google Analytics използва, за да изгради надлъжен профил на поведението на потребителя между сесиите. Ако тя остане след отхвърляне, сърфирането на потребителя продължава да се проследява и агрегира, независимо от изразения отказ.

Устойчиви тракери: 14 547 сайта

На 14 547 сайта (50,3% от тестваните) услугите за проследяване останаха активни след отхвърляне -- което означава, че браузърът продължи да прави заявки към известни домейни за проследяване, дори след като потребителят натисна бутона за отхвърляне.

Това е отделен вид неуспех от устойчивостта на бисквитките. Тракер може да бъде активен без да поставя бисквитка: пикселни заявки, beacon извиквания и зареждания на скриптове предават информация (най-малко IP адреса на потребителя, препращащата страница и данни за тайминг) към сървъри на трети страни, независимо дали бисквитка е съхранена. Това понякога се нарича „проследяване без бисквитки" и става все по-често, тъй като браузърите затягат ограниченията за бисквитки от трети страни.

Разликата между числото за бисквитки (10 848) и числото за тракери (14 547) е значителна. Тя означава, че на приблизително 3 700 сайта действието за отхвърляне успешно е изчистило бисквитките, но не е успяло да предотврати заявките за проследяване. CMP се е справил с почистването на бисквитки, но не е блокирал скриптовете, които генерират трафик за проследяване на първо място. Това сочи към често срещан архитектурен проблем: CMP е конфигуриран да управлява бисквитки (да ги изтрива при отхвърляне, да ги предотвратява при зареждане), но не да управлява изпълнението на скриптове.

Consent respawn: 1 642 сайта, 4 932 бисквитки

Consent respawn е най-тревожният модел, който идентифицирахме. На 1 642 уебсайта бисквитки, успешно премахнати от действието за отхвърляне, се появиха отново след презареждане на страницата. При тези сайтове 4 932 индивидуални бисквитки показаха това поведение на respawn.

Consent respawn не е бъг в един CMP или една конфигурация. Това е структурен проблем в начина, по който съгласието е реализирано в целия уеб стек.

Как бисквитка се връща след изтриване. Когато потребител кликне отхвърляне, правилно конфигуриран CMP прави две неща: изтрива съществуващите несъществени бисквитки (като задава изтичането им на минала дата) и обновява запис за съгласие (обикновено бисквитка или запис в localStorage), който казва на блокиращата логика на CMP да предотврати изпълнението на несъществени скриптове при бъдещи зареждания на страницата. Ако и двете работят, потребителят е чист: няма бисквитки за проследяване, няма скриптове за проследяване.

Consent respawn се случва, когато изтриването успее, но блокирането се провали. Най-честият сценарий:

1. CMP изтрива бисквитката `_ga`, когато потребителят кликне отхвърляне.

2. CMP задава бисквитка за състояние на съгласие, записваща, че потребителят е отказал анализи.

3. При следващото зареждане на страницата CMP проверява състоянието си и знае, че потребителят е отказал.

4. Но: скрипт тагът на Google Analytics е вграден директно в шаблона на страницата (извън мениджъра на тагове) или се зарежда от правило в мениджъра на тагове, което не проверява състоянието на съгласие.

5. GA скриптът се зарежда, вижда, че няма бисквитка `_ga`, и създава нова.

6. Решението на потребителя за отхвърляне е било отменено.

Вариации на този модел включват: скриптове от трети страни, заредени чрез твърдо кодирани `