Authentication
Users authenticate through Google Sign-In managed by Firebase Authentication. Silent Key does not receive the user’s Google password. Firebase provides the signed-in user identity used by the application and Firestore security rules.
Account security therefore depends partly on the security of the selected Google account. Users should protect that account with a strong password, recovery information and multi-factor authentication where available.
Authorization
Firestore security rules are the real server-side boundary. Interface controls alone are not security controls because browser code can be inspected and modified. Production rules should limit users to permitted profile, conversation and message operations; reserve moderation actions for the configured administrator; validate field types and lengths; and restrict the announcement document to authorized writes.
The deployment package cannot silently publish Firestore rules through Netlify. Rules must be deployed separately in Firebase Console or with the Firebase command-line tools.
Data in transit and at rest
Traffic between the browser, Google and Firebase is sent over HTTPS. Firebase stores application data in Google-managed infrastructure. These protections reduce common network and storage risks, but they are not the same as end-to-end encryption.
No end-to-end encryption claim
Silent Key administrators can perform moderation and message deletion actions, and messages are stored in Firestore in a form the application can retrieve. Therefore users must assume that authorized service operators and the backend provider may be able to access stored content. Do not use Silent Key for secrets requiring cryptographic protection from the service itself.
Browser and device risks
A secure backend cannot repair an infected device, stolen unlocked laptop, malicious browser extension, shared account or screenshot taken by a recipient. Sign out on shared systems, keep browsers updated, review installed extensions and use device-level screen locking.
Input and interface protections
React renders announcement and message text as text rather than raw HTML in the normal interface, reducing straightforward script injection through those fields. Nicknames and messages have configured length limits. Uploaded avatars are validated as images, size-limited and compressed before storage.
Security headers
The Netlify configuration sends headers that deny framing, prevent MIME sniffing, use a strict referrer policy and disable camera, microphone and geolocation permissions because the current app does not require them. Private application routes also receive noindex directives.
Reporting security concerns
Do not publish exploit details or private user data in a public review. Use the contact page and include the affected page, browser, time of occurrence, reproducible steps and the least amount of sensitive information necessary. A responsible report gives maintainers enough evidence to fix the problem without creating a second one.
Data minimization and operational access
The service should collect only fields needed for authentication, discovery, messaging, moderation and support. Administrators should use elevated access only for maintenance, abuse review and account actions, not casual browsing. Firestore Console and Google Cloud accounts should be protected with strong authentication, limited sharing and regular review of who retains access.
Public pages avoid embedding private application data. Private routes use a separate application shell with no advertising script and noindex directives, reducing accidental exposure to crawlers and ad systems. This separation is architectural rather than cosmetic: the public homepage cannot silently turn into a chat screen through a client-side route.
Workspace & Creator Essentials
Discover minimalist mechanical keyboards, artisan keycaps, and ergonomic desk accessories from our partner TwinCraft.
