Chrome Custom Tabs (CCT), and Custom Tabs (CT) more generally, allow Android app developers to use the user's default browser to serve embedded web content in their apps.
CT, unlike Android's WebView API, share the same browser state (such as cookies) with the browser app. Chromium therefore imposes a strict boundary between the embedding app and the browsing engine, and the app can normally only get very limited access to web page data and state.
All considered, there are four parties to consider when evaluating Custom Tabs: the user, the embedding app, the web publisher, and the browser. The native app chooses how they want to bring the web in their app, and users choose which apps to install and use.
Given this distinct trust relationship between the embedding app and the user (which is in general a higher degree of trust than between users and websites they happen upon in their browser), we accept some data exchange between Chrome and the underlying app. This is intentional because we believe this incentivizes apps to use CT rather than WebView, which was never designed as a full browser embedding API and has a number of security shortcomings.
CCT session specific signals can be shared back to the embedder without user action. Session specific signals are low-entropy signals about the user's interaction with the tab or page that do not reveal information about the content or identity of the page. Examples of session specific signals include Custom Tab callbacks and engagement signals. Session specific signals are designed to avoid malicious actors inferring details about the content or the state of the web page. As such, engagement signals are disabled in some circumstances, such as when pages are opened using text fragments.
Current page URL can be shared with the embedder with explicit user action. When a user taps on an embedding app action in CCT, the embedding application can see the full URL and origin of the currently visited page. In some instances, verifiable Google app entities can access the current page URL without user intent.
Developers can send and receive messages as if they were a website which they can prove they control. The postMessage API can be used by developers to establish a 2-way communication channel between the main frame inside the Chrome Custom Tab. For non-verifiable Google entities, this functionality is only supported if a Digital Asset Link relationship has been established between a website and the embedding app. The website is then used as the origin for the window.postMessage() Web API, which enables cross-origin communication.
The app may be able to draw over parts of the Chrome browser UI or the website. Unlike the Chrome browser app which is always displayed in its own Android Task, Custom Tabs are most commonly displayed in the same Android Task as the embedding app. This makes Custom Tabs susceptible to certain tap jacking and phishing attacks. For example, a malicious actor could launch an Activity positioned over the web content or CT toolbar and draw UI to steal a password. The presence of pre-existing browser state and cookies may make the embedded web experience appear more trustworthy and therefore increase the likelihood of the phishing attack succeeding. Note that Android has been pursuing protections within the OS to mitigate against some attacks, and Chrome will continue to work with Android to protect users on older OS versions.
Developers can add app specific actions into CCT. Chrome provides customization options to embedding apps. The appearance of the bottom toolbar and its contents can be customized and can change during runtime. While this UI surface could be used for malicious purposes, we accept this risk because, overall, CCT has better security properties than WebView, and a high level of UI customisability is necessary to drive Custom Tab adoption. Furthermore, the space that can be occupied by the bottom toolbar is limited and the position is fixed, lowering the risk that users will fall for attacks launched from this surface.
Embedders cannot access data unrelated to the CCT session. This includes:
Any future access would require explicit permissions to be accepted.