We don’t want to know who you are. We consider user attributable information to be a liability.
This moral foundation defines the core of every technology decision we make at Guardian. Rather than take my word for it, we encourage anyone, willing or interested, to use an intercepting proxy (such as Charles or Burp) to review traffic from our app being sent over the network. We’re going to go on a journey to break down what information is being sent, what it means for you, and how we maintain a high standard of user privacy and security for Guardian subscribers.
As Guardian continued to grow throughout 2020 and our roadmap began to expand with new feature and product concepts, we needed a system that we could rely on without dependence on a centralized server, or even any sort of access by our Guardian Firewall nodes to a centralized server. One that could allow us to add other payment options without updating our entire infrastructure and risking downtime for users, as well as allowing isoloation of actual subscriber information from anything used to access Guardian Firewall nodes. After searching for just the right fit, we decided to implement JSON Web Tokens (JWT), and we have no regrets.
JWT is historically battle-tested and is defined as an open standard, which means cross-platform compatibility. It allows us to validate proof of payment once and hand Guardian Firewall a signed pseudonymous token, which the Guardian Firewall app then sends as proof of payment. This means that no record of this token needs to be stored on our actual servers or in a separate database. Our Guardian Firewall nodes validate and trust the provided token, which removes any need for extra network calls or connections from Guardian Firewall nodes to a centralized server altogether. In-app purchase receipt validation or lookup of customers who subscribed directly through Guardian happens entirely separate from our Guardian Firewall nodes. There will never be a need for Guardian Firewall nodes to contain, process, or have access to personal information. We are proud that user data and user traffic will never exist on the same host at the same time, ever.
Because our Guardian Firewall nodes are only looking for a valid and signed JWT, this allows us to add payment methods, such as purchasing Guardian Pro from our website, and the flexibility to add support for partner iOS/Android apps without needing to change or update the Guardian Firewall infrastructure at all. Being able to confidently remove yourself from the success of a product launch is incredibly reassuring because it ensures you made the correct decision.
The JWT standard clearly defined a few claims (JSON key/value combinations) that will only be used for predefined use cases. For example, you can set the “exp” field with a Unix timestamp to define when the token expires.
The flexibility of the JWT standard allows us to add our private claims to the token, providing each Guardian Firewall node with minimal information about the user, such as the subscription type. This is how our servers identify Pro customers to allow them to use Pro features such as real-time Push Notifications for alerts. We call this token a Subscriber Credential.
Now, let’s look at how the Subscriber Credential is created and authenticates your connection to our Guardian Firewall nodes. In this example, assume the user has an active in-app purchase subscription but has not connected to a Guardian Firewall node, which means the device does not have a valid Subscriber Credential yet.
When you tap the shield to connect, the Guardian Firewall smartphone app performs a few basic checks locally on the device to determine how to authenticate with our separate payment validation server in order to obtain a new Subscriber Credential. Next, it sends the encrypted in-app purchase receipt to an API endpoint on this payment validation server, which forwards it to Apple, verifies that the response from Apple contains a valid subscription, and sends back a signed Subscriber Credential that looks like this:
The Guardian Firewall smartphone app uses this Subscriber Credential to pseudonymously prove that you are a paying user to our Guardian Firewall nodes when establishing an encrypted connection from your device to our gateway. Neither our payment validation server nor the Guardian Firewall node ever store or log valid Subscriber Credentials. It exists only in memory on our servers while processing or safely on your device encrypted in its local keychain.
When the Guardian Firewall node receives a valid Subscriber Credential, it will generate a new set of EAP credentials every time, which is only valid for this server for a set lifetime. EAP credentials exist only once on any given server, and multiple devices belonging to the same user will never share the same Guardian Firewall node authentication credentials, even if they connect to the same Guardian Firewall node.
We make it simple for users to force the app to generate a new Subscriber Credential or EAP Credentials by simply connecting to a new Guardian Firewall node or choosing to select “Reset Configuration” and “Clear Local Cache” in the settings menu. This highly aggressive disconnect of user data and user traffic within our system allows us to maintain our guarantee of user privacy.
Carefully developing the authentication process in this way provides a guaranteed level of privacy that should give any user the confidence to trust Guardian as their mobile security solution of choice.
Take back control of your privacy and network-connected devices.