У 2026 році цей опис уже застарілий.
Chrome не запровадив загального, обов'язкового вимкнення third-party cookies за колишнім графіком. Google вирішив зберегти поточну модель, у якій користувачі можуть керувати доступом до таких cookies в налаштуваннях Chrome. Компанія також відмовилася від плану впровадити новий, окремий prompt щодо third-party cookies.
Однак це не означає повернення до стану, що був до Privacy Sandbox.
Third-party cookies все ще можуть бути недоступні через:
- рішення користувача,
- режим Incognito,
- організаційні політики Chrome Enterprise,
- обмеження конкретного браузера,
- налаштування сайту,
- експериментальну групу Chrome,
- механізми партиціювання та захисту від відстеження.
Водночас Google вирішив вивести з експлуатації значну частину API Privacy Sandbox, зокрема Topics, Protected Audience, Attribution Reporting, Shared Storage і Related Website Sets. Натомість залишаються рішення, корисні для функціональних сценаріїв використання, такі як CHIPS, Storage Access API, FedCM, партиціювання storage і Private State Tokens.
Найважливіший висновок: розворот Chrome не означає, що можна знову проєктувати вхід, вбудовані віджети, аналітику й платежі, виходячи з припущення, що непартиційовані third-party cookies завжди будуть доступні. У 2026 році правильна архітектура має підтримувати обидва стани: cookie доступні та cookie заблоковані.
Статус і документацію перевірено 23 липня 2026 року.
TL;DR
| Питання | Відповідь на 2026 рік |
|---|---|
| Чи вимкнув Chrome third-party cookies для всіх користувачів? | Ні |
| Чи Chrome усе ще планує новий окремий prompt? | Ні |
| Чи може користувач їх заблокувати? | Так |
| Чи блокуються вони за замовчуванням у Incognito? | Так |
| Чи має застосунок припускати їхню доступність? | Ні |
| Чи зникає весь Privacy Sandbox? | Ні |
| Чи виводяться з експлуатації рекламні API, такі як Topics і Protected Audience? | Так |
| Чи залишається CHIPS підтримуваним? | Так |
| Чи залишається Storage Access API? | Так |
| Чи залишається FedCM? | Так |
Чи гарантує SameSite=None; Secure роботу cookie? |
Ні |
| Чи стосується одна дата видалення всіх API? | Ні |
1. Що таке third-party cookie?
Cookie - це значення, яке зберігається браузером і передається відповідно до правил домену, шляху, протоколу, часу життя та атрибута SameSite.
Cookie вважається third-party в ситуації, коли воно використовується в контексті сайту, відмінного від сайту, що знаходиться вгорі вкладки браузера.
Приклад:
Użytkownik otwiera:
https://shop.example
Strona osadza:
https://chat.vendor.example/widget
Якщо вбудований віджет намагається використати непартиційоване cookie домену chat.vendor.example, він робить це в контексті сторонньої сторони.
Типова конфігурація, що дозволяє надсилати cookie в контексті cross-site, виглядає так:
Set-Cookie: widget_session=abc123;
SameSite=None;
Secure;
HttpOnly;
Path=/
SameSite=None дозволяє надсилати cookie в cross-site запитах, а Secure є обов'язковим для cookies з SameSite=None у сучасних браузерах.
Однак це лише технічна умова. Це не гарантія того, що браузер допустить third-party cookie. Налаштування користувача або політика браузера все ще можуть його заблокувати.
2. Як змінювався план Chrome?
Етап 1: анонс світу без third-party cookies
Privacy Sandbox постав як набір пропозицій, покликаних обмежити відстеження між сайтами й водночас забезпечити рішення для реклами, вимірювання, запобігання зловживанням і роботи з ідентичністю.
У січні 2024 року Chrome розпочав обмеження third-party cookies для 1% користувачів у межах тесту Tracking Protection.
Етап 2: відмова від загального phase-out
У липні 2024 року Google оголосив про зміну курсу: замість загального вимкнення cookies було запропоновано підхід, що ґрунтується на виборі користувача.
22 квітня 2025 року Google уточнив рішення:
- Chrome зберігає поточний підхід до вибору користувача,
- новий окремий prompt не буде впроваджено,
- користувачі й далі керують cookies в налаштуваннях Privacy and Security,
- Incognito й далі блокує third-party cookies за замовчуванням.
Саме це і є найважливіший «розворот Chrome».
Етап 3: скорочення Privacy Sandbox
17 жовтня 2025 року Google оголосив, що після аналізу впровадження та відгуків екосистеми виведе з експлуатації значну частину технологій Privacy Sandbox.
У січні 2026 року release notes Chrome 144 перелічили депрекацію та заплановане видалення Private Aggregation, Shared Storage і Protected Audience.
Однак не варто зводити всю зміну до Chrome 144. Офіційний статус охоплює більше технологій, а процес їхнього виведення з експлуатації розтягнутий у часі та ведеться відповідно до процедур Chrome та Android.
3. Що означає «Chrome зберігає поточний підхід»?
Це не означає:
- гарантії доступності cookies у кожній інсталяції,
- повернення до необмеженого cross-site відстеження,
- скасування партиціювання storage,
- ідентичної поведінки Chrome, Safari і Firefox,
- гарантії, що наявна інтеграція SSO чи iframe працюватиме.
Це означає, що Chrome не замінив поточну модель одним глобальним вимкненням і новим prompt, що охоплював би всю базу користувачів.
Офіційна документація Chrome й далі описує кілька причин блокування cookies:
- налаштування користувача,
- обмеження браузера,
- тестові прапорці,
- політики Chrome Enterprise.
Та сама документація, оновлена 18 грудня 2025 року, й далі повідомляє про групу 1% користувачів, для якої third-party cookies обмежені за замовчуванням із метою тестування.
Для розробника практичний висновок простий:
third-party cookie availability = stan runtime,
a nie właściwość gwarantowana przez nazwę przeglądarki
4. Які технології Privacy Sandbox виводяться з експлуатації?
Офіційний статус використовує кілька різних категорій:
- Deprecate and remove - API призначене для депрекації та видалення.
- Discontinue - проєкт завершено або виводиться з експлуатації.
- Do not launch - технологію не буде запущено.
- Scheduled for phaseout - заплановано поступове виведення з експлуатації.
Не варто подавати їх як одне одночасне «вимкнення Privacy Sandbox».
Основні вебтехнології, призначені для депрекації та видалення
| Технологія | Початкове застосування | Статус |
|---|---|---|
| Attribution Reporting API | вимірювання атрибуції без cross-site ідентифікатора | deprecate and remove |
| Aggregation Service | агрегація звітів для Attribution Reporting | scheduled for phaseout |
| Topics API | інтереси користувача для реклами | deprecate and remove |
| Protected Audience API | ремаркетинг та аукціони interest-group у браузері | deprecate and remove |
| Private Aggregation API | агреговані cross-site вимірювання | deprecate and remove |
| Shared Storage API | cross-site storage з контрольованими операціями | deprecate and remove |
| SelectURL | вибір варіанта URL на основі Shared Storage | виводиться з експлуатації разом із Shared Storage |
| Related Website Sets | декларування пов'язаних доменів | deprecate and remove |
requestStorageAccessFor() |
запит доступу від імені ресурсу пов'язаного сайту | deprecate and remove |
| Related Website Partition | спільна партиція для пов'язаних сайтів | discontinue |
Технології, завершені або невпроваджувані
| Технологія | Статус |
|---|---|
| IP Protection | discontinue / scheduled for phaseout |
| Partitioned Popins | discontinue |
| Fenced Storage Read | do not launch |
| Private Proofs | do not launch |
| Probabilistic Reveal Tokens | do not launch |
| Script Blocking | do not launch |
Android Privacy Sandbox
Google також виводить з експлуатації:
- Attribution Reporting,
- On-Device Personalization,
- Protected App Signals,
- Protected Audience,
- SDK Runtime,
- Topics.
5. Що саме зникало в Chrome 144?
Chrome 144, випущений як stable у січні 2026 року, містив формальні пункти депрекації для:
- Private Aggregation API,
- Shared Storage API,
- Protected Audience API.
Release notes говорять про план депрекації та видалення, а не про гарантію того, що всі елементи негайно перестали працювати в кожній інсталяції.
Це важливо під час міграції. Сигнали можуть з'являтися поетапно:
- повідомлення Intent to Deprecate,
- попередження в консолі або документації,
- зміна стану за замовчуванням,
- видалення коду,
- можливий deprecation trial або перехідний період.
Команда має відстежувати Chrome Platform Status і release notes, а не покладатися на одну дату зі статті.
6. Що залишається підтримуваним?
Privacy Sandbox не зникає як єдиний пакет. Офіційний статус вказує технології, що залишаються в підтримці.
CHIPS
CHIPS дозволяє позначити cookie атрибутом Partitioned. Браузер створює окрему «банку» cookie для кожного сайту верхнього рівня.
Set-Cookie: __Host-widget_session=abc123;
Secure;
HttpOnly;
Path=/;
SameSite=None;
Partitioned
Якщо chat.vendor.example вбудований на:
shop-a.example
shop-b.example
то він отримує дві окремі партиції. Cookie, встановлене в контексті shop-a.example, недоступне у вбудуванні на shop-b.example.
CHIPS придатний, серед іншого, для:
- віджетів чату,
- карт,
- вбудованих платежів,
- стану компонента для кожного сайту,
- ресурсів, що потребують сесії, обмеженої одним вбудовувачем (embedder).
CHIPS не є заміною, коли той самий ідентифікатор має бути спільним для незалежних сайтів. Саме відсутність такої можливості є механізмом захисту приватності.
Storage Access API
Storage Access API дозволяє вбудованому документу перевірити, чи має він доступ до непартиційованих cookies, і попросити браузер про такий доступ.
async function ensureStorageAccess() {
if (await document.hasStorageAccess()) {
return true;
}
try {
await document.requestStorageAccess();
return true;
} catch {
return false;
}
}
Доступ:
- може потребувати активності користувача,
- може викликати prompt,
- підпорядковується політикам браузера,
- може бути відхилений,
- потребує безпечного контексту,
- може бути заблокований через Permissions Policy.
Не можна розглядати requestStorageAccess() як автоматичний обхід приватності.
FedCM
Federated Credential Management API призначене для федеративних потоків ідентичності без залежності від third-party cookies і класичних навігаційних перенаправлень.
FedCM має сенс для:
- «Увійти через постачальника ідентичності»,
- One Tap,
- федеративного створення облікових записів,
- потоків, у яких браузер посередничає між RP та IdP.
Це не універсальна заміна всіх cookies. Воно не розв'язує проблему стану віджета, аналітики чи кожної функції OpenID Connect.
Партиціювання storage і мережевого стану
Chrome й далі підтримує партиціювання storage і мережевого стану. Мета - обмежити можливість пов'язувати активність користувача між різними сайтами верхнього рівня.
Private State Tokens
Private State Tokens залишаються підтримуваними як механізм, що допомагає передавати обмежені сигнали довіри без класичного відстеження користувача між сайтами.
Інші підтримувані елементи
Статус також перелічує:
- bounce tracking mitigations,
- Fenced Frames,
frame-ancestors,- User-Agent Client Hints і редукцію User-Agent.
Не всі з них є замінами third-party cookies. Це окремі механізми платформи приватності та безпеки.
7. Чи достатньо SameSite=None; Secure?
Ні.
Це один із найважливіших міфів.
Set-Cookie: session=abc;
SameSite=None;
Secure
означає, що cookie може надсилатися в контексті cross-site, якщо браузер дозволяє непартиційовані сторонні cookies.
Це не означає, що:
- користувач їх не заблокував,
- Incognito їх допустить,
- Safari чи Firefox поведуться так само, як Chrome,
- Chrome Enterprise не застосує політику,
- iframe має Storage Access,
- механізм захисту від трекінгу не обмежить доступ.
Код має виявляти реальну доступність.
8. Як виявляти доступність cookies у вбудуванні (embed)?
Chrome описує два основні методи.
document.hasStorageAccess()
const hasAccess = await document.hasStorageAccess();
Метод дозволяє вбудованому документу перевірити, чи має він доступ до непартиційованих cookies.
Sec-Fetch-Storage-Access
Починаючи з Chrome 133 credentialed requests можуть містити заголовок:
Sec-Fetch-Storage-Access: active
Можливі значення:
none,inactive,active.
Приклад на стороні сервера:
const storageAccess =
request.headers.get("sec-fetch-storage-access");
if (storageAccess !== "active") {
// Nie zakładaj dostępu do unpartitioned third-party cookies.
}
Що не варто використовувати як єдиний тест?
navigator.cookieEnabled
Ця властивість надійно не повідомляє, чи має конкретний iframe доступ до конкретного third-party cookie. Вона може лише вказувати на загальну підтримку cookies.
9. Що з requestStorageAccessFor()?
Це не те саме, що:
document.requestStorageAccess()
requestStorageAccessFor() було розширенням, пов'язаним із Related Website Sets, що дозволяло сайту верхнього рівня просити про доступ від імені ресурсу з пов'язаного сайту.
Оскільки Related Website Sets виводиться з експлуатації, requestStorageAccessFor() також має статус deprecate and remove.
MDN позначає цей метод як deprecated і non-standard.
Звичайний requestStorageAccess() залишається підтримуваним, міжбраузерним напрямом для вбудованих документів, що потребують непартиційованого стану.
10. Наслідки для входу в систему
Найбільш уразливі потоки, які припускають, що IdP, вбудований в iframe, завжди прочитає власне cookie.
Можливі напрями:
| Випадок | Краще рішення |
|---|---|
| федеративний вхід | FedCM або добре спроєктований top-level OAuth/OIDC flow |
| сесія власного застосунку | first-party cookie на домені застосунку |
| embed, що потребує доступу до наявного облікового запису | Storage Access API з чітким UX |
| незалежний стан віджета | CHIPS |
| зв'язок parent ↔ iframe | postMessage() з валідацією origin |
| backend між власними сервісами | токени та сесії на стороні сервера, а не відстежувальні cross-site cookies |
Не варто автоматично переносити токени в localStorage. Така зміна не розв'язує всіх проблем і може посилити наслідки XSS.
11. Наслідки для аналітики
Розворот Chrome означає, що third-party cookies не було глобально видалено, але вони й далі залишаються нестабільним фундаментом вимірювання.
Дані можуть відрізнятися між:
- користувачами, які блокують cookies,
- звичайним і приватним режимом,
- Chrome, Safari і Firefox,
- пристроями, керованими організацією,
- користувачами з блокувальними розширеннями,
- розгортаннями зі згодою (consent) і без неї.
Attribution Reporting API, яке мало бути одним із механізмів вимірювання Privacy Sandbox, виводиться з експлуатації. Однак Google заявляє про подальшу роботу над інтероперабельним стандартом атрибуції в межах процесу вебстандартів.
Це не гарантія готової заміни.
Практичний підхід охоплює:
- first-party measurement,
- явну згоду (consent) там, де вона потрібна,
- моделювання відсутніх даних,
- агрегацію,
- server-side збір із контролем приватності,
- вимірювання обмежень і покриття даних,
- уникнення обіцянок повного відстеження користувача між сайтами.
12. Наслідки для реклами
Виводяться з експлуатації три центральні стовпи рекламного Privacy Sandbox:
- Topics,
- Protected Audience,
- Attribution Reporting.
До цього додаються Shared Storage, SelectURL, Private Aggregation і Aggregation Service.
Це означає, що не варто розпочинати нову стратегічну реалізацію, засновану виключно на цих API, без перевірки поточного статусу та плану міграції.
Це автоматично не означає, що галузь повертається до єдиної стабільної моделі third-party-cookie-based advertising. Доступність cookies залишається фрагментарною, а решта браузерів застосовують власні механізми захисту.
13. Наслідки для віджетів і вбудованих сервісів
Типовий віджет:
<iframe src="https://support.vendor.example/widget"></iframe>
може потребувати:
- розпізнавання сесії,
- запам'ятовування налаштувань,
- доступу до облікового запису користувача,
- зв'язку з батьківською сторінкою.
Вибір рішення має залежати від мети:
Стан лише для одного вбудовувача (embedder)
Використайте CHIPS.
Доступ до наявної, непартиційованої сесії
Використайте Storage Access API, із fallback і зрозумілим повідомленням.
Федеративний вхід
Розгляньте FedCM.
Стан, який можна передати явно
Передайте мінімальні дані з parent до iframe через postMessage() після суворої валідації origin.
14. Аудит third-party cookies
Chrome рекомендує аудит DevTools і Privacy Sandbox Analysis Tool.
Крок 1: інвентаризуйте cookies
Для кожного cookie запишіть:
| Поле | Приклад |
|---|---|
| назва | widget_session |
| setter | chat.vendor.example |
| контекст | iframe |
| мета | стан розмови |
| потрібне cross-site? | так |
| потрібне спільне використання між сайтами? | ні |
| альтернатива | CHIPS |
Крок 2: знайдіть SameSite=None
grep -R "SameSite=None" .
Це не виявить cookies, які створюються зовнішніми скриптами, тому потрібно також скористатися DevTools і мережевими логами.
Крок 3: тестуйте з блокуванням
Chrome документує прапорець:
chrome://flags/#test-third-party-cookie-phaseout
а також запуск:
google-chrome --test-third-party-cookie-phaseout
Документація й далі рекомендує цей режим для тестування збоїв за обмежених cookies.
Крок 4: тестуйте реальні шляхи
- вхід,
- вихід,
- оновлення токена,
- платіж,
- чат,
- карта,
- embedded media,
- consent,
- аналітика,
- cross-domain checkout,
- відновлення облікового запису.
Крок 5: тестуйте різні браузери
Не обмежуйте тестування лише Chrome. Розворот Chrome не змінив політик Safari і Firefox.
15. Приклад прогресивної стратегії віджета
async function initializeWidget() {
if ("hasStorageAccess" in document) {
const hasAccess = await document.hasStorageAccess();
if (hasAccess) {
return startWithUnpartitionedSession();
}
}
const partitionedSession = await tryPartitionedSession();
if (partitionedSession) {
return startWithPartitionedSession();
}
return startAnonymousMode();
}
Після свідомої дії користувача можна запропонувати доступ:
button.addEventListener("click", async () => {
try {
await document.requestStorageAccess();
location.reload();
} catch {
showManualLoginFallback();
}
});
Логіка має враховувати відмову. Prompt не є обов'язком користувача.
16. Чого не робити?
Не припускайте, що розворот Chrome розв'язав проблему
Third-party cookies й далі не є передбачуваною залежністю (dependency).
Не переносьте все до фінгерпринтингу
Заміна cookies агресивним збором сигналів пристрою не є privacy-first рішенням.
Не переносьте автоматично сесію в localStorage
Це може підвищити ризик за XSS і не дає автоматичної можливості спільного використання даних cross-site.
Не використовуйте CHIPS для cross-site identity
CHIPS навмисно ізолює cookie за top-level site.
Не використовуйте Storage Access API без fallback
Доступ може бути відхилений.
Не починайте новий проєкт на API, що виводиться з експлуатації
Перевірте статус Topics, Protected Audience, Attribution Reporting, Shared Storage і RWS перед інвестицією.
Не ототожнюйте «deprecated» з «уже не працює»
Депрекація та видалення є процесом. Перевірте версію Chrome і Chrome Platform Status.
17. Рекомендована архітектура у 2026 році
Для звичайного застосунку
- first-party session cookie,
Secure,HttpOnly,- розумний
SameSite, - CSRF protection,
- відсутність залежності від cross-site iframe.
Для віджета
- CHIPS для стану, ізольованого для кожного сайту,
- anonymous fallback,
- Storage Access лише для функції, що потребує наявної сесії,
postMessage()з валідацією origin.
Для федеративного входу
- FedCM, якщо він підходить для підтримуваного потоку,
- стандартний redirect OAuth/OIDC як сумісний fallback,
- first-party session після повернення до застосунку.
Для аналітики
- first-party collection,
- згода та мінімізація даних,
- явне звітування про відсутнє покриття,
- агрегація замість обіцянки повної cross-site ідентифікації.
18. Чекліст міграції
Інвентаризація
- Список усіх cookies.
- Визначені setter і domain.
- Визначений контекст first-party або third-party.
- Відома бізнес-мета.
- Відомий власник інтеграції.
- Відомі наслідки блокування.
- Видалені невикористовувані cookies.
Безпека cookies
-
Secureна сесійних cookies. -
HttpOnlyтам, де JavaScript не потребує доступу. - Мінімальний
Domain. - Мінімальний
Path. - Відповідний
SameSite. - Короткий час життя.
- Префікс
__Host-там, де він підходить.
Cross-site
- Відсутність припущення, що
SameSite=Noneгарантує доступ. - Виявлення
hasStorageAccess(). - Обробка відмови
requestStorageAccess(). - CHIPS для ізольованого стану.
- FedCM для підтримуваного федеративного входу.
- Fallback без сторонніх cookies.
- Тест у Incognito.
- Тест із блокуванням third-party cookies.
Privacy Sandbox
- Відсутність нової залежності від Topics.
- Відсутність нової залежності від Protected Audience.
- План відмови від Attribution Reporting API.
- План відмови від Shared Storage і SelectURL.
- План відмови від Private Aggregation.
- План відмови від Related Website Sets.
- Видалене використання
requestStorageAccessFor(). - Моніторинг Chrome release notes.
Тести
- Chrome звичайний.
- Chrome Incognito.
- Chrome із ручним блокуванням.
- Safari.
- Firefox.
- Обліковий запис із входом і без входу.
- Новий і наявний користувач.
- Embed на щонайменше двох top-level sites.
- Офлайн-режим і помилки API.
- Політики Chrome Enterprise, якщо вони стосуються продукту.
19. Інструменти POLPROG
Під час аудиту варто поєднати аналіз cookies з іншими шарами:
- Стан сайту допомагає знайти технічні проблеми та проблеми продуктивності.
- Інспектор заголовків безпеки дозволяє перевірити CSP, HSTS та інші механізми захисту.
- Інспектор DNS і SSL перевіряє шар домену та TLS.
- FlowTrace допомагає простежити потік запиту, сесії та даних між браузером, CDN і backend.
- У базі знань POLPROG є матеріали про приватність, безпеку та вебархітектуру.
Вердикт
Chrome не виконав колишнього плану глобального вимкнення third-party cookies. Користувачі й далі мають вибір, а новий окремий prompt не було впроваджено.
Однак це не означає, що third-party cookies повернули собі статус стабільного стандарту, на який можна безпечно спиратися під час створення продукту.
У 2026 році:
- частина користувачів має заблоковані cookies,
- Incognito блокує їх за замовчуванням,
- організаційні політики можуть їх обмежувати,
- інші браузери застосовують власні правила,
- storage дедалі частіше партиціюється,
- багато рекламних API Privacy Sandbox виводиться з експлуатації,
- функціональні рішення, такі як CHIPS, Storage Access API і FedCM, залишаються.
Найкраща архітектура не намагається вгадати майбутнє рішення Chrome. Вона працює правильно незалежно від того, чи доступні непартиційовані third-party cookies.
