QLYNK ACCOUNT · INFORMATION

Privacy Policy

This draft explains what QLYNK Account handles during Google, Discord and GitHub sign-in. It should be reviewed and finalized before the service is offered broadly.

This is a draft information page for the static preview, not a final legal document.

1. Account information from your provider

When you sign in with Google, Discord or GitHub, QLYNK receives a provider account identifier and the profile fields made available for the requested sign-in scopes. Depending on the provider and your settings, these may include display name, username, avatar URL, email address and an email-verification status. QLYNK does not receive your provider password. Provider access tokens are used to retrieve your profile during the callback and are not intentionally stored in the QLYNK database.

A first successful sign-in may create a QLYNK account. The account record contains a QLYNK user ID, display name, optional email and avatar, provider/identity linkage, account timestamps and the latest sign-in context. Email addresses are not used to automatically merge accounts from different providers.

2. Sign-in security and abuse prevention

After a successful sign-in, QLYNK stores the most recent sign-in IP address when it is supplied by Cloudflare, the user-agent string, and a limited allowlist of request headers: Accept-Language, Cloudflare's country header and selected browser client hints. It does not intentionally persist the entire request header set; cookies and Authorization headers are excluded. This context is overwritten on the next successful sign-in rather than kept as a full login-history trail in the user record.

QLYNK uses Cloudflare Turnstile to check sign-in initiation requests. A successful challenge result is recorded as a security signal; the challenge token itself is not stored. A basic automated-user-agent pattern check is also used. These checks reduce some automated abuse but do not guarantee that every bot is detected.

3. IP address enrichment and IPinfo

For abuse prevention, QLYNK may send the sign-in IP address to IPinfo to obtain approximate country/network information. Available results are saved alongside the latest sign-in context. VPN, proxy, Tor, relay or hosting flags are stored only when the configured IPinfo plan returns them; unavailable signals are recorded as unknown, not as false. IP-based country and network classifications can be inaccurate, and QLYNK does not treat VPN use alone as proof of abuse.

4. Sessions and database storage

After authentication, the browser receives a secure, HttpOnly, host-only session cookie. The database stores a hash of the random session token, its account ID and expiry—not the raw cookie token. Expired sessions are rejected even if automated database cleanup has not yet removed the record.

Account, provider-identity and active-session information is stored in MongoDB. The current sign-in implementation does not upload account images or notification files to Hugging Face; those storage and weekly-backup systems remain future work. When another provider is integrated, its data transfer and retention behavior will be documented before activation.

5. Service providers and sharing

Authentication involves the provider you choose, Cloudflare (hosting, request handling and Turnstile), MongoDB hosting, and IPinfo when IP enrichment is configured. Those services process data according to their own terms and privacy practices. QLYNK does not need to share your provider password, raw session cookie or raw QLYNK session token with IPinfo.

6. Retention, deletion and choices

The last sign-in context is replaced on a later successful login. Session records expire and are periodically cleaned up by MongoDB. Account records and provider identity links remain until an account-deletion process is implemented; self-service account deletion is not available in this initial version. QLYNK should publish and apply a retention period and a contact channel for access, correction and deletion requests before broad release.

7. Policy status

This is an implementation-informed draft and is not a substitute for legal review. It describes the current intended sign-in data path; it should be updated if the app adds email/password authentication, account linking, historical security logs, images, notifications or automated backups.