VPN by Google One white paper

VPN by Google One, explained

At Google, keeping our users safe online means continuously protecting the privacy and security of their personal information. We focus on three core principles: keeping data secure by default, building products that are private by design and putting our users – you – in control.

When it comes to networking privacy and security, we've long encouraged the use of Transport Layer Security (TLS) and other protections across the wider web and app ecosystems. Unfortunately, not every online service provider is committed to implementing rigorous data protection standards1, leaving gaps in how well consumers are protected and in how much control they have over who accesses their network traffic. And even if security protections are properly implemented, sensitive data such as your IP address and the sites that you visit can be visible to others2.

When securely implemented, a VPN provides additional protection by:

  • Providing encrypted transit that hides your data and network activity from hackers and network nodes along the way, such as public Wi-Fi hotspot or other service providers
  • Masking your IP address from trackers, sites and apps that you visit, which could be used to track your location or your network activity
how a VPN connection works

Figure 1: How a VPN connection works

While a VPN removes the ability for intermediaries to snoop on your traffic, it puts the VPN provider in a privileged position to potentially access your sensitive data. Therefore, it is important to choose a VPN provider that provides robust privacy and security guarantees. Unfortunately, not all VPN providers have been proven to be trustworthy: some services are vulnerable3, others request unnecessary access or monetise their users' network data, and others fail to deliver on the promise of not logging their users' online activity4.

With growing demand for VPNs5 in a mixed landscape of solutions, we have used our expertise in privacy, cryptography and networking infrastructure to build a Google-grade VPN. With VPN by Google One, users' network traffic is not identifiable to the VPN and never logged by the VPN. We will never use the VPN connection to track, log or sell your online activity.

Transparent and verifiably private

We believe that a VPN must be robust and transparent. To demonstrate how our design works and provide independent assurance of our data and security practices, we have open sourced our client APIs (here) and conducted third-party audits of our system (here).

In addition to this transparency and external verification, we've built VPN by Google One to address some of the potential vulnerabilities of traditional architectures. A traditional VPN could compromise a user's sensitive data by linking their identity to their network traffic by means of a session ID. This ID could allow VPN operators, or attackers that compromise their infrastructure, to 'eavesdrop' and identify users and their network activity.

We wanted to eliminate that vulnerability by separating the authentication of the user from their use of the service. By employing a cryptographic blind-signing step between user authentication and connecting to the VPN, we give users a stronger guarantee that their network activity can't be tied back to their identity.

VPN by Google One’s authentication with blind signatures image

Figure 2: VPN by Google One's authentication with blind signatures

Architecturally, we’ve split authentication from the data tunnel setup into two separate services:

  • Authentication service: This service validates users’ access to VPN by Google One. The client first generates an OAuth token and a blinded token (see below for definition). Then, the authentication service validates and exchanges the OAuth token for a signed blinded token.
  • Key Management Service: The client can then ‘unblind’ this signed blinded token using cryptographic blinding. When the client connects to the data tunnel server, it provides only this signed unblinded token to the data tunnel server. Thus, the only piece that links the authentication server to the data tunnel server is a single, public key, used to sign all blinded tokens presented during a limited period of time.

The blinding algorithm employed was first described by Chaum in 19826, and is commonly referred to as 'RSA Blind Signing'. The goal is to never use the same identifier in the authentication server and the key management service. To accomplish this, the client generates a token, hashes it using a Full Domain Hash, and combines it with a random value and the server's public signing key to produce a blinded token. That blinded token is then signed by our authentication server. When the client wants to connect to the VPN, it can unblind the blinded token and its signature using the random value that only it knows. The unblinded token and the signature are then verifiable by our key management server.

The servers are physically distinct and only share a cryptographic root of trust to validate the signed unblinded token; they strictly share no other information. Due to this careful authentication architecture, it would be infeasible for an attacker to break the cryptographic protections of one of the services with enough time to break the second, and thus be able to associate a user with their network activity. We've calculated that it would take years to break both services, even when using the equivalent of roughly Google's entire global computational capacity.

VPN logging practices

The authentication step has already separated the user’s identity from the data tunnel that handles your network traffic. On top of that protection, the following data is never logged:

  • Network traffic, including DNS
  • IP addresses of the devices connecting to the VPN
  • Bandwidth utilized by an individual user
  • Connection timestamps by user

The VPN authentication and data plane services only record aggregate metrics —without any user identifiable information— for service reliability and performance optimization. These include aggregate throughput, uptime, latency, CPU/memory load and failure rates. Client applications running on the user's device may log additional metrics to understand product and feature adoption and engagement, prevent fraud, and to ensure VPN connection health. Client applications also provide the option to send feedback and errors to us, which include application and system logs, and are used for debugging purposes.

Using a VPN shouldn’t require that you completely turn over your trust to the VPN provider. A VPN provider should be able to transparently demonstrate how their service keeps your data private. Our VPN client-side code is open sourced so that users and privacy experts alike can verify how user data is handled, and we open up our implementation to rigorous external audits so you can be confident in our VPN’s privacy and security guarantees.

We believe an easy to use, highly private and performant VPN will significantly help improve user privacy online. So it should come as no surprise that we want to make VPN technology available to as many users as possible.

For more information about how VPN works, see: