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. Основное ограничение — скорость внедрения операторами. Но направление задано, и масштабирование идёт быстро.

Общая картина: паника преувеличена, но действовать нужно

Сведём всё в таблицу:

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