Що відбувається: 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 зачеплять ваш трафік і офери — зв’яжіться з нашою командою.