Что происходит: 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 затронут ваш трафик и офферы — свяжитесь с нашей командой.