Chrome переходить на HTTPS за замовчуванням: що насправді станеться з carrier billing і як підготуватися

Що відбувається: Chrome переходить на HTTPS за замовчуванням

У жовтні 2025 року Google оголосив: з виходом Chrome 154 у жовтні 2026 року браузер увімкне налаштування «Always Use Secure Connections» для всіх користувачів за замовчуванням. Chrome автоматично намагатиметься завантажити будь-який сайт через HTTPS і запитуватиме дозвіл користувача перед переходом на HTTP-сторінку.

Перший етап стартує раніше — з квітня 2026 року Chrome 147 активує цю функцію для користувачів із увімкненим Enhanced Safe Browsing. Це понад мільярд людей.

Для звичайних користувачів зміна практично непомітна — за даними Google, 95% трафіку Chrome вже йде по HTTPS, і менше 3% навігацій викликають попередження в тестах. Але для індустрії mVAS і carrier billing цей крок зачіпає ключовий механізм: HTTP header enrichment.

Що саме ламається — і що ні

Перш ніж аналізувати рішення, важливо зрозуміти: не всі DCB-потоки однаково вразливі.

В індустрії carrier billing використовуються кілька типів білінгових потоків:

• 1-click — MSISDN визначається автоматично через header enrichment, користувач підписується одним натисканням
• 2-click — те саме, але з додатковим підтвердженням
• 1-click + PIN / 2-click + PIN — після кліку користувач отримує SMS з PIN-кодом і вводить його для підтвердження
• PIN flow (без header enrichment) — користувач вводить номер вручну, отримує SMS PIN, підтверджує

Що ламається: 1-click і 2-click потоки, які цілком залежать від автоматичної ідентифікації через HTTP header enrichment. Якщо оператор використовує лише HTTP-заголовки для визначення MSISDN — ці потоки перестануть працювати на HTTPS-трафіку.

Що НЕ ламається: PIN-based потоки. Якщо користувач вводить номер вручну й підтверджує через SMS PIN — header enrichment не бере участі взагалі. Ці потоки не залежать від HTTP/HTTPS і продовжать працювати як раніше.

Це важливий контекст. Коли звучать прогнози про «падіння конверсії DCB на 40–55%», йдеться про конкретну підмножину потоків — автоматичну ідентифікацію через HTTP header enrichment. Не про carrier billing загалом.

Як працює header enrichment і чому HTTPS його ламає

Header enrichment — технологія, за якою шлюз мобільного оператора автоматично вставляє ідентифікатор абонента (зазвичай MSISDN — номер телефону) в HTTP-заголовки запиту, коли той проходить через мережу оператора.

При HTTP-з’єднанні запит передається у відкритому вигляді. Шлюз оператора бачить заголовки, додає X-MSISDN: 66812345678 і відправляє далі. Мерчант читає заголовок і знає, хто перед ним.

При HTTPS-з’єднанні запит зашифрований від браузера до сервера мерчанта. Шлюз оператора бачить лише зашифрований потік — прочитати або модифікувати заголовки він не може. Header enrichment неможливий.

Це фундаментальне обмеження, закладене в сам протокол TLS: саме для того, щоб ніхто між відправником і отримувачем не міг втручатися в трафік.

Шлях 1: TLS Termination з Header Enrichment

Суть: Оператор розгортає TLS-проксі у своїй мережі. Проксі перехоплює HTTPS-з’єднання від пристрою абонента, термінує TLS (розшифровує), вставляє MSISDN у заголовки, потім встановлює нове TLS-з’єднання з сервером мерчанта й пересилає збагачений запит.

Плюси:

• Зберігає звичний flow для мерчантів — вони продовжують читати MSISDN із заголовків
• Не вимагає інтеграції на боці мерчанта
• Користувацький досвід зовні не змінюється

Підводні камені:

• Це MITM (man-in-the-middle). Технічно оператор ставить себе між користувачем і сайтом, розриваючи наскрізне шифрування. Для цього пристрій повинен довіряти сертифікату проксі оператора. Якщо сертифікат не встановлено — браузер покаже попередження безпеки.
• Certificate Transparency. Сучасні браузери, включаючи Chrome, вимагають, щоб усі публічні сертифікати були зареєстровані у відкритих логах Certificate Transparency. Сертифікати оператора, що використовуються для TLS-перехоплення, можуть не пройти цю перевірку.
• Висока вартість і складність. Розгортання TLS-проксі в ядрі мережі оператора — масштабний інфраструктурний проєкт, що потребує апаратних ресурсів для дешифрування/шифрування трафіку в реальному часі.

Вердикт: Робоче рішення, яке використовується низкою операторів. Але це важкий і дорогий шлях, а з посиленням вимог браузерів до Certificate Transparency його життєздатність у довгостроковій перспективі під питанням.

Шлях 2: API-based IP Lookup (MSISDN Resolution за IP)

Суть: Мерчант фіксує IP-адресу користувача й відправляє її оператору через REST API. Оператор зіставляє IP із записами у своїх системах (AAA/PCRF) і повертає MSISDN.

Плюси:

• Не вимагає втручання в HTTPS-трафік
• Відносно проста інтеграція

Підводні камені:

• Carrier-Grade NAT (CGNAT). Головна проблема. Через нестачу IPv4-адрес більшість мобільних операторів, особливо на ринках, що розвиваються, використовують CGNAT — технологію, за якої сотні й тисячі абонентів виходять в інтернет через одну й ту саму публічну IP-адресу. Мерчант бачить цю спільну IP і не може визначити, який саме абонент за нею стоїть. Для точної ідентифікації потрібен IP + порт, але мерчант зазвичай бачить лише IP.
• VPN-трафік. Якщо користувач використовує VPN, його IP належить VPN-серверу. Оператор не може зіставити цю IP з абонентом.
• Затримка та ненадійність. API-виклик додає крок у платіжний потік і створює точку відмови. Якщо API оператора недоступний або повільно відповідає — конверсія падає.
• Інтеграція з кожним оператором. Мерчанту потрібно підключатися до API кожного оператора окремо. Немає єдиного стандарту.

Вердикт: Слабке рішення. В умовах повсюдного CGNAT на мобільних мережах, IP-based ідентифікація ненадійна. Це радше fallback для окремих випадків, ніж повноцінна заміна header enrichment.

Шлях 3: Redirect через сторінку оператора

Суть: Замість автоматичної ідентифікації через заголовки, мерчант перенаправляє користувача на сторінку ідентифікації оператора (наприклад, https://id.operator.com/verify). Оскільки це власний домен оператора, оператор контролює сервер і може ідентифікувати абонента на своєму боці — через внутрішню мережу, без header enrichment. Після ідентифікації оператор видає токен і перенаправляє користувача назад до мерчанта.

Плюси:

• Працює по HTTPS без втручання в шифрування
• Не вимагає перехоплення трафіку або MITM
• Оператор ідентифікує абонента всередині своєї інфраструктури — надійно й точно
• Токен захищений від підробки

Підводні камені:

• Додатковий редирект. Користувач проходить через ще одну сторінку — це додає крок і може знижувати конверсію. Кожен редирект — втрата частини трафіку.
• Час життя токена. Токени зазвичай валідні 60–120 секунд. Якщо процес затягується — потрібна повторна ідентифікація.
• Нестандартизованість. Кожен оператор реалізує свою сторінку та свій API по-своєму. Мерчанту потрібно адаптуватися під кожного оператора.
• Користувацький досвід. 1-click перетворюється фактично на 2-click або 3-click. Для ринків, де звикли до безшовної підписки, це може бути болісно.

Вердикт: Надійне й чисте рішення з точки зору безпеки. Багато операторів вже використовують його для PIN-based потоків. Основний мінус — погіршення конверсії через додатковий крок.

Шлях 4: GSMA Open Gateway / CAMARA Number Verify

Суть: GSMA і Linux Foundation розробили стандартизований API — Number Verify, який дозволяє безшумно верифікувати номер телефону користувача через мобільне з’єднання. Запит ініціюється з пристрою користувача, проходить через мережу оператора, і оператор усередині своєї інфраструктури підтверджує, що номер збігається з SIM-картою в пристрої.

Ключова відмінність від IP Lookup: при Number Verify оператор бачить внутрішню IP пристрою у своїй мережі (до CGNAT), а не публічну IP, яку бачить мерчант. Тому CGNAT не проблема — оператор верифікує на рівні мережі, а не на рівні інтернет-IP.

Плюси:

• Працює по HTTPS, не вимагає header enrichment
• Не вимагає MITM або TLS termination
• CGNAT не перешкода — верифікація на боці оператора
• Стандартизований — один API для всіх операторів-учасників
• Вже розгорнутий комерційно: 300+ API-інстансів, 86 операторських груп, 65 ринків, 60+ партнерів-агрегаторів
• Безшовний користувацький досвід — верифікація відбувається у фоні

Підводні камені:

• Покриття. Не всі оператори підключені. Станом на березень 2026 року — 86 операторських груп, що значно, але далеко не 100% світового ринку. На ринках, що розвиваються, де DCB особливо популярний, впровадження може відставати.
• Залежність від мобільного з’єднання. Number Verify працює лише коли пристрій підключений через мобільну мережу. Запит повинен іти саме через мобільний інтернет, щоб оператор міг верифікувати SIM.
• Інтеграція. Мерчантам потрібно інтегрувати новий API. Це не drop-in заміна header enrichment — потрібна зміна платіжного потоку.
• Зрілість. Попри активне масштабування, екосистема все ще розвивається. Не всі API однаково стабільні у всіх операторів.

Вердикт: Найперспективніше й найчистіше рішення. Стандартизоване, безпечне, не ламає TLS, вирішує проблему CGNAT. Основне обмеження — швидкість впровадження операторами. Але напрямок задано, і масштабування йде швидко.

Загальна картина: паніка перебільшена, але діяти потрібно

Зведемо все в таблицю:

Рішення	Надійність	Складність впровадження	CGNAT	Майбутнє
TLS Termination + HE	Висока	Дуже висока	Не проблема	Під питанням (Certificate Transparency)
IP Lookup API	Низька	Середня	Критична проблема	Глухий кут
Redirect через оператора	Висока	Середня	Не проблема	Робочий, але конверсія нижча
GSMA Open Gateway	Висока	Середня	Не проблема	Індустріальний стандарт

А тепер головне: Chrome HTTPS-by-default — не раптова загроза. Це фінальний крок у процесі, який триває роками. HTTPS став стандартом вебу задовго до 2026 року. 95% трафіку Chrome вже зашифровано. Те, що частина операторів у 2026 році все ще покладається виключно на HTTP header enrichment — це технічне відставання, а не проблема, створена Google.

Важливо пам’ятати: PIN-based потоки не зачеплені взагалі. А вони складають значну частку DCB-ринку, особливо в регульованих юрисдикціях, де PIN-підтвердження обов’язкове.

Що робити прямо зараз

Операторам:

• Провести аудит: який відсоток DCB-потоків покладається на HTTP-only header enrichment?
• Якщо значний — запустити міграцію. Варіанти: HTTPS-сумісний header enrichment (TLS termination), redirect-based flow або підключення до GSMA Open Gateway.
• Якщо оператор ще не бере участі в GSMA Open Gateway — час підключитися. Екосистема зростає, і відставання обійдеться дорожче, ніж інтеграція.

Паблішерам і афіліатам:

• З’ясувати в кожного оператора, через якого йде трафік: чи готова їхня інфраструктура до HTTPS?
• Диверсифікувати потоки: не покладатися цілком на 1-click header enrichment. PIN-based потоки — надійний fallback.
• Слідкувати за впровадженням GSMA Open Gateway на ключових ринках.

Мерчантам і рекламодавцям:

• Уточнити у платіжних партнерів: який метод ідентифікації використовується? Якщо лише HTTP header enrichment — вимагати план міграції.
• Готуватися до інтеграції GSMA Number Verify API, коли він стане доступним у потрібних операторів.

Підсумок

Chrome HTTPS-by-default — не загроза для carrier billing. Це дедлайн для інфраструктурного оновлення, яке багато операторів відкладали роками. Технології для роботи з HTTPS-трафіком існують — від TLS termination до GSMA Open Gateway. PIN-based потоки взагалі не зачеплені.

Індустрії не потрібна паніка — їй потрібна міграція. Інструменти є. Стандарти визначені. Хто оновиться — продовжить працювати. Хто ні — зіткнеться з наслідками власної бездіяльності, а не дій Google.

В Affiliate Dragons ми працюємо з операторами й паблішерами на глобальних ринках і уважно стежимо за цим переходом. Якщо хочете зрозуміти, як зміни Chrome зачеплять ваш трафік і офери — зв’яжіться з нашою командою.