Android will soon make it easier to connect to some public Wi-Fi networks

Public Wi-Fi networks are everywhere these days, and thanks to the proliferation of technologies like HSTS and HTTPS, are generally considered safe to use even without the use of a VPN. Unfortunately, some public Wi-Fi networks are rather inconvenient to use, as they might ask you to log in using a social media account or share some of your personal data. This wouldn’t be much of an issue if the Captive Portal — the web page that pops up when you connect to public Wi-Fi — had access to your autofill data, but it doesn’t. That could change soon, though.

The reason that Captive Portals don’t have access to your autofill data is because they’re opened up in the Android System WebView app. The Android System WebView, or WebView for short, is the system component that allows apps to display web-based content without taking you out of the app. Although it’s based on the same open source code as Google Chrome and several other of the best Android browsers, it doesn’t share any autofill or session data with them. As a consequence, when a Captive Portal asks you to sign into a social media account or input your personal data, you have to fill all those details out from scratch.

If Captive Portals were instead opened in an Android Custom Tab, though, then they would have access to your autofill or session data, as Custom Tabs are simply instances of the default web browser. Android Custom Tabs have been around for a long time now, though you may know them by their previous name of Chrome Custom Tabs from back when the feature was only supported by Google Chrome. While Custom Tabs aren’t fully rendered in-app like WebViews are, they have access to your browsing session, saved passwords, payment methods, and addresses, not to mention other features that aren’t supported by the comparatively basic Android System WebView app. This makes Custom Tabs ideal for Captive Portals, as they can help you input your information faster — and thus get connected to the network more quickly.

Fortunately, Google is now preparing to have Android open these Captive Portal pages in an Android Custom Tab instead of a WebView. A set of patches tagged captive_portal_cct that adds Custom Tabs support to Captive Portal Login — the system app that contains the logic for handling Captive Portal pages — was merged a few months ago. The patches add preliminary support for this feature, introducing code to open Captive Portals in an Android Custom Tab as well as bundling the androidx.browser library that’s necessary for Custom Tab support. However, the implementation is currently disabled by default and guarded with a feature flag, so it’s not enabled yet.

Captive Portal Login is part of a Project Mainline module that’s available on all devices running Android 10 or later (Network Stack), meaning Google can push out updates to it through Play System Updates. Indeed, the latest public release of the Captive Portal Login app already contains the code that Google merged to AOSP in August, but the feature is still disabled by default right now. I don’t know when Google plans to roll this feature out, but it might be a while, as additional Custom Tab-related patches that were merged to AOSP in September have yet to make their way to the Captive Portal Login app on devices.

While I think opening Captive Portals in Android Custom Tabs will improve the convenience of accessing public Wi-Fi, I don’t suspect it will really lead to any meaningful security improvements. For instance, I don’t see how this change will impact the efficacy of evil twin attacks, which is when attackers set up a fake public Wi-Fi access point with a malicious Captive Portal designed to steal your credentials. Sure, if a fake Captive Portal asked for your social login and you recognized that something is wrong when your web browser didn’t autofill the data or automatically login using the saved cookie, you could avoid this kind of attack. However, I think few users would recognize this scenario, meaning there would be little difference between the two implementations in terms of overall security.

Even if this change doesn’t really improve security, I can’t see any major downsides to it, beyond slightly increasing the size of the Captive Portal Login app. Hopefully it rolls out soon so logging into some public Wi-Fi networks will be a little less painful.