Examine account login, data-access permissions and chat-key recovery separately; one login button does not answer all three.
“Sign in with Google” neither automatically means Google can access chat plaintext nor comes without a trust cost. It brings an identity provider into the login process; the information transferred and account dependency must be assessed against the service’s actual permissions and design.
To make a decision, separate account login from permission to access Google data and from conversation encryption keys. One login button does not answer all three questions.
How do OAuth and OpenID Connect differ?
OAuth is a framework for granting access to resources. OpenID Connect provides an authentication layer on top of it. The Google sign-in documentation describes an OpenID Connect flow for identifying users.
So the claim that “OAuth gives the messenger your Google password” is incorrect. The service must validate the relevant token correctly and secure its own session. Permission for Gmail, Drive or other data is also separate from merely signing in. Explanation of permissions and scopes.
What information might be exchanged?
A login flow usually provides the service with an identifier and, depending on permissions, information such as an email address or profile details. The identity provider also participates in authentication requests. But the name of the login method does not establish that every app opening, every message or the entire usage history is sent to that provider.
| Question | What to check |
|---|---|
| What account information does the messenger receive? | The consent screen, scopes and privacy policy |
| Has access to additional data been requested? | The distinction between signing in and accessing email, files or contacts |
| When does the identity provider become involved again? | The implementation’s session and token-refresh policies |
| Do chat keys depend on this login? | Key storage and recovery documentation, not merely the login button |
Avoid granting permissions that cannot be explained by your needs. At the same time, do not interpret a specific permission request as “reading all messages” without examining it.
What risks come with dependence on a central account?
If your only way to sign in to a messenger is an account that becomes inaccessible, fresh logins may be disrupted. The impact on existing sessions, local data and recovery depends on the service’s design. “A Google account being blocked necessarily destroys every chat” is therefore not a valid conclusion.
Before an emergency, check whether the service offers an alternative login method or recovery process, and how adding it affects account security. An alternative route should not become an easier route for an attacker. Do not change or remove an account connection without ensuring you can sign in afterward.
Does direct SRP login remove all these risks?
Direct login can reduce dependency on a third-party identity provider. When implemented correctly, SRP also proves knowledge of a password without sending the password itself in protocol messages. But the messenger still processes account names, login events and related operational information; “leaving no digital footprint” is not an accurate description.
The stored SRP verifier also needs protection. RFC 5054 describes the risk of password guessing after a verifier is exposed. Login-page, session, recovery and device security remain essential.
No technical principle says SRP is the only private login method or that every federated login is inherently unsafe. Implementation quality and the threat model should determine the choice.
The boundaries of Livara’s claims
The Livara security page describes SRP for authentication and explicitly acknowledges retaining some operational data. This does not mean the account’s identity is hidden from the service itself. The same page distinguishes cryptographic identity recovery from chat history.
For a practical comparison, ask each service the same questions: what data does it receive, which third parties are involved, how does it terminate sessions and how are chat keys recovered? Documented answers are more useful than “zero-knowledge” slogans.
Before choosing a login method
Secure your main account and recovery routes, read the requested permissions, review connected devices and understand your plan for losing account access. Then choose a login method that fits your needs and ability to manage it; convenience and independence both matter, but neither alone guarantees security.
