Why Attacks Fail
Common security questions and how Glide's architecture prevents attacks.
TS.43 Protocol Only
All attack scenarios below refer specifically to the TS.43 (Android Digital Credentials API) authentication strategy. Link / App Clip attack vectors are covered separately and are currently under security review.
Can an attacker create a fake Glide integration and capture a session to replay it?
No. The client-side artifact is a temporary encrypted blob generated by the carrier's TS.43 service. It's encrypted using Glide-provided keys and can only be decrypted by Glide's backend. Even if captured, it's cryptographically bound to the specific session and cannot be replayed.
What prevents someone from spoofing a phone number?
The carrier's SIM-level authentication (EAP-AKA) determines which physical SIM is making the request. Anyone can request a session for any phone number, but the credential they receive will only work for the phone number of their own SIM. The carrier verifies the actual SIM, not a claimed phone number.
Can an attacker intercept the communication between the app and carrier?
No. The TS.43 service communicates directly with the carrier over a secure channel established at the OS level. This channel is protected by the carrier's infrastructure and is not accessible to applications or network-level attackers.
What if an attacker gets access to the client-side code?
The client only transports an encrypted, single-use token produced through the carrier-to-SIM interaction. All validation happens server-to-server between Glide and the carrier. Access to client-side code provides no path to forging or intercepting credentials.
Can tokens be reused across different sessions?
No. Tokens are single-use and bound to a specific session context. Once used, they're invalidated. Additionally, tokens have a short TTL (time-to-live) and expire quickly even if unused.
What about man-in-the-middle attacks?
The aud (audience) parameter in TS.43 is set by the browser to the origin where the Digital Credentials API was invoked. An attacker running from attacker.com would get aud: "attacker.com", which Glide would reject when validating against your registered domain.
Security Summary
Glide's architecture ensures that authentication is cryptographically secure at every step. The combination of carrier-level SIM authentication, encrypted credentials, server-side validation, and domain binding makes it extremely difficult for attackers to compromise the system.