В целом так и должно быть. Вы правы, можно инициировать локальный сервер, открыть браузер, UID которого может отличаться (особенно если это External Browser Intent / Custom Browser Tabs, обрабатываемым установленным браузером), то оно без проблем добудет exit IP, вернет локальному серверу.
Палевно ли это? Ну, так авторизация в самом приложении может работать. Приложение закидывает тебя в браузер авторизоваться (который идет через VPN), а само втихаря там делает черную работу.
Но embedded WebView всё равно будет переиспользовать тот же UID, а вот вызванный Intent, такой как CustomTabsIntent - нет, у него будет свой UID.
Идем дальше, даже если и приложение и хочет внутри приложения что-то открыть, то WebView тут не нужен. Большинство приложений используют новый Custom Tabs, который, позволяет загружать веб-контент в том браузере, который предпочитает пользователь..
Прямого тезиса “Custom Tabs используют отличный UID от приложения которое его запустило” я не обнаружил, но есть косвенные и довольно жесткие на то доказательство изходя из архитектуры Android. Кто-то выложил Issue по Custom Tabs и в его логах фигурировал UID chrome, а не его приложения.
Таким образом, в то время как наверняка ваш дефолтный браузер в системе будет идти через VPN, то и грязные Get-IP запросы в Secure Tabs, что и будет обрабатывать движок вашего дефолтного браузера, пойдут через VPN чтобы узнать Exit IP.
Это я ещё молчу про то что в любое “Open in Browser” событие можно вставить MITM-redirect. Допустим пользователь открывает ссылку, оно забрасывает на MITM сервер и Exit IP сливается автоматически (так как браузер открылся который из VPN шел) и тут же redirect происходит на обычный сайт куда пользователь и хотел. Так даже YouTube делает часто, когда из YouTube на любую ссылку нажимаешь, оно сначала на свой сервер забрасывает. Чтобы это было не палевно делать такое не всегда.
Координировать атаку сразу с нескольких подконтрольных РКН приложениев. Макс - один exit IP в логах сервера, потом в то же временное окно через ВК/Yandex/А-может-ещё-чего-от-РФ-разработчиков (трекеры можно вставить и не в совсем очевидные вещи от неочевидных разработчиков) - другой exit IP в логах сервера. На Android вроде в фоне приложения могут какую-то сетевую активность генерировать.
Здесь и кроется вся проблема “А пустим это в DIRECT”, можно узнать твой домашний IP, затем ты точечно узнаешь ТСПУ, который обрабатывает этот домашний IP, затем из логов провайдера корреляцией по времени ищешь внутренний NAT IP пользователя. И в то же окно времени видишь к какому ещё одному IP шел трафик. А ведь при split-tunneling так и будет, будет два разных IP (ну или пачка подконтрольных и какой-то ещё IP потенциального туннеля) в одно и то же время. Очевидно это требует кореляционной атаки по времени, но в долгосрочной перспективе это легко будет сопоставить, особенно, если туннелируются все девайсы.
А для чего же ещё им надо узнавать внутренние NAT IP, как ни для этого, например?)
Поэтому я и топлю за перенос точки наблюдения вообще в целом. Векторов атак много, не лучше ли вместо того чтобы ловить тараканов по одному, просто закрыть им дверь?)