Chrome VPN API: ChromeOS Only, Not a Desktop Tunnel

Three products all call themselves a Chrome VPN, and only one of them is the thing the vpnProvider documentation describes. That API is available on ChromeOS, where an extension can implement the client side of a VPN connection instead of talking to an installed one. A browser proxy extension changes where Chrome sends requests. An extension that drives a separate desktop client is a control panel for software running outside the browser. Knowing which of the three you are looking at answers most of the questions people bring to this comparison.

The platform note is the first filter

The official vpnProvider reference states its availability restriction in its own text, and the permission named there belongs to that contract. Adding vpnProvider to a manifest on Windows does not create the interface.

Read the platform line before the permission list, because the permission is only meaningful where the API exists.

Proxy extension: the browser is the boundary

A proxy extension uses the browser's proxy settings to send Chrome's requests through a server. It is cross-platform and it is honest about its scope. Other applications keep their own connections, and some browser traffic may still not follow the configured route. That is a browser-level change, not a system tunnel.

If the requirement is "this one site, in this one browser", it is the right tool.

Extension plus companion app: the app's owns the tunnel

A desktop VPN client usually installs a service and a virtual adapter, and its extension is a remote control that calls into the app. The tunnel exists at the operating-system level, so it covers applications the browser never sees. The extension's permissions describe the control channel rather than the encryption. Removing the extension leaves the tunnel intact, while removing the app breaks the extension.

That asymmetry is the quickest test. Disable the extension and watch whether other applications still use the VPN.

ChromeOS provider: the extension implements the client

On ChromeOS the provider model differs in kind. The extension receives configuration and platform messages, creates a configuration object, reports connection state back to the platform, and supplies traffic through the API instead of through a separate installed client. It is closer to writing a VPN client than to configuring one. The API also assumes an endpoint you already operate, so it does not supply a service.

That is why the reference talks about implementing a client rather than connecting to one.

Reading a product claim against the three

Ask which operating systems are supported, then ask which component owns the connection. If the answer is a browser proxy, expect browser scope. If the answer is a companion application, expect system scope while that application runs. If the answer is a ChromeOS provider, expect it to work on ChromeOS and nowhere else. A product page that says "Chrome VPN" without answering those two questions has not told you what it does.

Check the permissions against the advertised job as well. Website access and proxy control are different grants, and neither becomes justified because another platform's API happens to share a name.

What none of them tell you

The interface says nothing about who operates the endpoint, what it logs, or whether the service is available where you live. Those are properties of the provider, not of the API. A tunnel that exists is not automatically a tunnel you should trust, and a permission that exists is not a capability on your platform. Keep the two judgements separate.

Then test the claim on the device you actually use, with an application that is not the browser.