У чому сенс останніх оновлень Chrome? З 2016 Chromium підтримує параметр куків SameSite, який, як випливає з назви, обмежує передачу куків межами одного сайту. У параметра є три стани, які дозволяють передачу куків:

1. Strict - виключно всередині сайту;
2. Lax - всередині сайту і для прямих переходів по посиланню;
3. None - за всіма міжсайтовими запитами.

В теорії SameSite допомагає убезпечити дані від необґрунтованого трекінгу і міжсайтових підробок запиту - CSRF. Але якщо розробники сайту не налаштували параметр, сервер автоматично виставляє SameSite = None і поводиться з куками як зі сторонніми, вільно відправляючи їх направо і наліво. Спойлер: за даними Google на березень 2019, SameSite був проставлений лише у 0,1% куків.

Тому в травні 2019 Google з Microsoft опублікували проект "Incrementally Better Cookies", де запропонували за замовчуванням вважати всі куки куками першого порядку. У вигляді експерименту ці налаштування були введені для невеликого числа користувачів Chrome ще в жовтні 2019 року. А вже в лютому 2020 Google офіційно вніс нові правила в Chrome 80 Stable. Тепер відправляти куки стороннім доменам можна тільки через HTTPS, попередньо помінявши атрибут потрібних куків з дефолтного SameSite = Lax на SameSite = None.

Поки що нові налаштування викотили серед кількох відсотків користувачів Chrome 80 Stable і збільшують це число поступово. З виходом Chrome 81-82 Canary / Dev / Beta нові правила поширяться на 50% користувачів, і їх число також буде розширюватися.

Аналогічні настройки будуть вводити Microsoft Edge і Mozilla Firefox.

Налаштування змінилися, що далі?

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

Веселощі почнуться з наступним кроком в сторону куків, так як в розумінні Google хороші куки - це мертві куки. Google розраховує позбутися від сторонніх куків за 2 роки і натомість пропонує використовувати HTTP State Tokens і набір API. Ця ініціатива отримала назву Privacy Sandbox.

Інтернет на куках тримається. Аутентифікація, історія переглядів сайтів, сторінок і медіа-елементів (вшитий плеєр, банер, кнопка репоста), метрики / лічильники / трекінг, підстроювання сторінок під пристрій, браузер і призначені для користувача налаштування - всюди потрібні куки для зберігання і передачі відповідних даних від сервера до браузера і назад.

Але універсальність куків легко перетворюється в мінус, тому що сприяє безконтрольному трекінгу користувачів.

Натомість Google пропонує використовувати HTTP State Tokens. Процес в теорії виглядає так: браузер відправляє закриптований токен сервера сайту через заголовок http - тільки по одному токену на джерело і тільки через безпечне з'єднання.

Значення токена контролюються клієнтом, а не сервером, і виглядають як випадковий набір байтів фіксованої довжини. Відповідно, сервер не знає про користувача нічого, але може підписати верифіковані токени своїм закриптованим ключем і вказати у відповіді додаткові атрибути: дату створення токена, допустимий контекст передачі (same origin, same site [default], cross site), час дії токена [1 годину - default], значення.

Що зміниться з відмовою від cookies?

Оскільки сайти не зможуть відстежувати користувачів без даних про користувача (опустимо фінгерпрінтінг та інші обхідні шляхи), доведеться повністю переглянути принципи і механізми монетизації, зав'язаної на онлайн-рекламі. Швидше за все, таргетинг на рівні окремих користувачів піде в минуле.

Google запропонував ряд API для вирішення деяких завдань:

1. Боротьба з fraud: сайт через Trust Token API видаватиме неперсоналізовані закриптовані токени довірені користувачам, які потім зможуть їх пред'являти іншим сайтам.
2. Лічильник конверсії: в поточному варіанті число переглядів з його допомогою не визначити, тільки агреговані дані про кліки.

Браузер формує звіти про конверсії на основі редиректів і відправляє їх скопом кілька разів на день за розкладом, розбавивши дані шумом. У цих звітах вказуються метадані про показ, про конверсії, про внесок показу в конверсію (від 0 до 100).

1. Агреговані звіти: API визначає число і частоту переглядів рекламної кампанії унікальними користувачами серед кількох доменів.
2. Орієнтування по інтересам: Federated Learning of Cohorts (FLoC). Браузер на основі історії переглядів виділяє широкі когорти користувачів зі схожими інтересами за допомогою алгоритмів машинного навчання і вносить цю інформацію в Client Hints (замінить User Agent string).
3. Ретаргетинг: Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE).

Рекламодавці формують групи інтересів - списки користувачів для ретаргетінга. Браузер регулярно запрошує рекламу для окремої групи і зберігає креативи "про запас". Коли користувач відкриває сторінку сайту, браузер запитує у рекламодавців контекстуальну рекламу, а потім проводить аукціон між контекстуальною рекламою і заздалегідь завантаженою рекламою по інтересам.

Добре це чи погано?

Загальна тенденція - передати контроль над власними даними користувачеві - звичайно ж правильна. Використання криптографії теж можна оцінювати тільки позитивно. У той же час відмова від куків врятує тільки від трекінгу по кукам, залишається ще багато способів відстежити унікального користувача, на які він вже не зможе вплинути.

Набагато більш серйозні проблеми спливають у онлайн-реклами. Слідом за даними на сторону користувача (тобто- браузера) перетікає важлива функціональність, і як цей переїзд втілити, ще ніхто не нає. Запропоновані Google API зачіпають далеко не всі процеси і ще зовсім сирі.

Як на монетизацію рекламодавців вплине зникнення персоналізованої реклами? Як зміняться відносини між ad-tech, видавцями, рекламодавцями і тепер ще і браузером? Чи можливо за два роки продумати і втілити безболісний перехід до інтернету без куків? За чий рахунок? Зрештою, індустрія реклами використовує куки і відстежує окремих користувачів, тому що без цього ніяк або просто тому що може? Час покаже.