Where your authenticator data lives—and what still leaves the browser

Guest input stays in the current browser workflow

Guest 2FA Live accepts a user-supplied Base32 TOTP key or supported otpauth URI, computes time-based codes locally, and displays a countdown. The normal guest flow does not need to upload the seed to an OTP-generation endpoint. Multiple valid and invalid lines are processed in the browser, and the guest state is designed to be cleared when the tab is reloaded or left. It is not a persistent cloud account or automatic backup service.

A secret briefly handled by a browser can still be visible to local threats while the page is active. System clipboard tools, extensions, operating-system screen capture, malware, and people with access to your screen are outside the guarantee of application state clearing. Browser garbage collection does not provide proof that plaintext bytes have been physically erased from device memory.

QR camera frames and local image files are credentials

A QR containing a TOTP setup URI or Google Authenticator migration payload can reveal long-lived seeds. The source implements local browser QR decoding for supported camera and image flows, without relying on an external image-analysis API to parse the secret. Camera capture follows an explicit user action; resource-cleanup logic aims to stop camera streams and release temporary image references when the import concludes or is canceled.

A photo or screenshot that already exists outside the application follows the retention and access rules of the device, gallery, messaging app, or cloud album where you stored it. 2FASync cannot delete those copies. Avoid sending QR exports to generic support forms and revoke or rotate credentials at their originating service if such an image has been disclosed.

Member identity is separate from Vault ciphertext

When a member signs in with Google, the system must recognize an authorized user and session. Its data contract includes an opaque internal user identifier, Google subject binding, optional profile information, active sessions, associated devices, and revision records. Those facts are not encrypted TOTP items. A Google account session permits fetching account-scoped encrypted records but does not itself unlock the secret-bearing data.

Member Vault items carry account labels, issuers, TOTP seeds, user notes, and preferences inside authenticated encrypted payloads. Server persistence and synchronization are designed to use ciphertext, nonces, crypto versions, wrapped key slots, and tombstone markers without needing plaintext item content. This limits one class of server disclosure while still leaving real account and infrastructure metadata to protect.

Passphrases, recovery keys, and backup files have different homes

Vault passphrases and recovery keys are entered to unwrap keys in the browser; the normal application architecture does not call for sending their plaintext to the cloud account database. A high-entropy recovery key gives you a distinct unlock route and can be used with a matching encrypted backup file. That backup is downloaded on explicit request, so it may reside in your downloads folder, local backup drive, or another location you intentionally choose.

If you store the recovery key with the same unprotected file, someone who copies that location may acquire both parts of the recovery mechanism. If you lose the key, the server cannot promise a reset or decrypt your ciphertext just from proof of identity. Previously downloaded backups may survive account deletion, key changes, or device revocation; control their storage separately.

Operational logs are narrower than the full activity

The security logging contract excludes the setup key, complete otpauth URI, migration data, current OTP, Vault passphrase, recovery key, decrypted account labels, request credentials, and raw sensitive payloads. Allowlisted event information can include opaque identity, event class, status, request ID, server revision, counts, and timing. Those details can still reveal that a sign-in, change, or device event occurred, which is why the accurate privacy statement is not that the system stores nothing.

Web hosting, authentication providers, and network infrastructure may process additional connection and access metadata under their own configured controls. The source-level data design alone cannot certify the behavior of every external processor or establish a complete legal retention schedule. This page describes the observable application design; any binding legal notice or operator contact needs separately verified governance information before public reliance.

The browser can keep encrypted state and device references

A signed-in member browser can retain opaque identifiers, encrypted cache entries, synchronization revisions, or browser-managed key material according to an approved device profile. The source forbids intentional plaintext TOTP seeds and recovery keys in localStorage or sessionStorage. A trusted-browser unlock path may use a Web Crypto non-extractable key, subject to physical-device acceptance; this term describes an API property and should not be mistaken for a blanket claim of hardware security.

Locking, sign-out, page lifecycle handling, and revocation attempt to reduce the time during which decrypted material is available to the application. They cannot make every operating-system cache, extension, or prior export disappear. If you are using a shared computer, prefer temporary guest use only when you can control the environment and clear the browser session afterward.

Account deletion and revocation cannot erase outside copies

Member controls include account-data deletion, device revoke, and session revoke paths that require appropriate authentication. The intention is to end future server-authorized access and remove or crypto-shred applicable server-side ciphertext and key-slot material according to the deletion contract. A successful cloud operation does not delete an encrypted backup file on a disconnected laptop, a screenshot sent through a separate service, or a plaintext seed someone extracted before revocation.

If a long-lived authenticator secret has escaped, visit the original website and re-enroll its factor to invalidate the old shared key where supported. Deleting a Vault entry, removing the local image, or signing out of Google is not the same as rotating the original website's secret. For privacy-sensitive accounts, keep a deliberate inventory of which copies and recovery routes exist.

Understand third-party and browser limitations

The Vault security contract prohibits advertising scripts, third-party analytics, and social embeds inside sensitive member views. The public pages are a different area and should never transmit guest setup input as analytics content. Google is the member authentication provider; that relationship alone does not grant 2FASync access to Google Authenticator's stored code data or to unrelated Google account contents.

No encryption product can guarantee secrecy on a browser completely controlled by malware or malicious page scripts. Browser cryptography protects certain data flows, not every endpoint in the user's environment. Security claims in marketing should remain bounded to the verified implementation, with production HTTP behavior, browser storage, and operational logging validated separately before release.

Questions worth asking before you store a valuable code

Decide whether you need temporary guest generation or a persistent member Vault. Determine where your current secret originated, whether you intend to retain a second copy, whether your recovery key can survive loss of a device, and who else can access the browser or encrypted backups. These practical choices affect privacy more than any generic assurance that software is secure.

For a privacy-related defect report, share only redacted behavior, app route, approximate date, and a non-sensitive error category. Never transmit a real TOTP setup URI, exported QR, live OTP, recovery key, or decrypted backup. A verified public operator contact and disclosure destination remain governance requirements; an email address or support guarantee must not be invented from the product domain.

Does guest mode create a server-stored authenticator account?

No. Guest 2FA Live is a browser-local flow. Saving encrypted entries for later use is a separate member Vault capability.

Does encrypted sync mean that the server knows nothing about me?

No. Member identity, sessions, devices, encrypted record metadata, revisions, and bounded security event metadata can still be stored even though TOTP item content is encrypted.

Can 2FASync remotely delete a leaked QR screenshot?

No. Remove copies you control and rotate the original site's authenticator seed if you suspect exposure.