Data Security Policy
1. Data Security Commitment
Quibit, Inc. ("Quibit," "we," "us," or "our") is committed to protecting the security and integrity of all data entrusted to us by users of our applications: Quibit (social platform), Kha (dating, 18+), QuiTalk (AI chat, channels, and phone calls), and QuizCoin (quiz game). This Data Security Policy outlines the comprehensive measures we implement to safeguard your information.
This policy covers all forms of data — personal information, communications, AI conversations, dating profiles, phone call metadata, game scores, financial transactions, and any other data processed across our platform ecosystem.
Every system we build is designed with security as a foundational requirement, not an afterthought. We employ defense-in-depth strategies, regular security audits, and continuous monitoring to protect your data at every layer.
2. Data Classification
We classify all data according to sensitivity levels to ensure appropriate security controls are applied consistently across all four applications:
2.1 Public Data
Data intended for public visibility:
Public profile information (display name, avatar, bio)
Published posts and comments on Quibit
Public channel content on QuiTalk
Public business listings and reviews
Leaderboard rankings on QuizCoin
Public quiz content and categories
2.2 Internal Data
Data accessible only within our systems for operational purposes:
Aggregated analytics and usage metrics
System logs and performance data
Content moderation queue data
AI model training metadata (anonymized)
Internal reporting and audit trails
2.3 Confidential Data
Sensitive user data requiring elevated protection:
Email addresses and phone numbers
Private messages and chat histories
Dating preferences and match data (Kha)
AI conversation histories (QuiTalk)
Job applications and resumes (Quibit)
Financial transaction records
Device identifiers and session tokens
Location data (when shared)
2.4 Restricted Data
Highest-sensitivity data with maximum security controls:
Authentication credentials and password hashes
Payment card information and banking details
Government-issued ID data used for verification
Encryption keys and security certificates
Law enforcement request data
CSAE investigation records
Internal security audit findings
Restricted data is accessible only to authorized personnel with specific business need, under strict access controls, full audit logging, and multi-factor authentication.
3. Encryption Standards
We employ industry-leading encryption standards to protect data at every stage of its lifecycle:
3.1 Encryption at Rest
All stored data is encrypted using strong cryptographic standards:
AES-256 encryption for all database storage (MongoDB, Redis)
AES-256 encryption for file storage and media uploads
Encrypted backup volumes with separate key management
Hardware Security Modules (HSMs) for master key storage
Automatic key rotation on a quarterly schedule
Encrypted disk volumes for all server instances
3.2 Encryption in Transit
All data transmitted between clients and servers is encrypted:
TLS 1.3 enforced for all HTTPS connections
TLS 1.2 minimum — older protocols are rejected
Certificate pinning in mobile applications to prevent MITM attacks
HSTS (HTTP Strict Transport Security) headers on all endpoints
Secure WebSocket (WSS) connections for real-time chat (Socket.IO)
Perfect Forward Secrecy (PFS) enabled on all TLS connections
Strong cipher suites only — weak ciphers disabled
3.3 End-to-End Encryption
Enhanced encryption for the most sensitive communications:
Private 1:1 messages encrypted end-to-end between participants
Dating conversations on Kha use additional encryption layers
Phone call signaling data encrypted with per-session keys
Media attachments in private chats encrypted before upload
Key exchange protocols prevent server-side message access
AI conversations on QuiTalk are encrypted in transit and at rest, but are processed server-side to enable AI responses. See the AI Data Security section for details.
4. Authentication & Access Control
We implement robust authentication and access control mechanisms across all applications:
4.1 Token-Based Authentication
Our authentication system uses secure token management:
JWT (JSON Web Token) for stateless API authentication
Short-lived access tokens with automatic refresh
Redis-backed session management with per-device isolation
Session data stored as sess:{userId}:{deviceId} for granular control
Token revocation on password change or suspicious activity
Secure token storage in device keychain (iOS) and keystore (Android)
4.2 Device Management
Users have full control over their authenticated devices:
View all active sessions and devices
Remote logout from any individual device
Logout from all devices simultaneously
New device login notifications via push and email
Device fingerprinting for suspicious login detection
Automatic session expiry after extended inactivity
4.3 Two-Factor Authentication (2FA)
Additional authentication layers for account security:
SMS-based verification codes
Email-based verification codes
Time-based One-Time Passwords (TOTP) via authenticator apps
2FA required for sensitive operations (password change, account deletion, payment methods)
Recovery codes provided during 2FA setup
Enforced 2FA for admin and moderator accounts
4.4 Role-Based Access Control
Internal access to user data follows strict RBAC principles:
Principle of least privilege — staff access only what their role requires
Separate roles: admin, moderator, support, developer, auditor
All data access logged with timestamps and user identity
Quarterly access reviews to remove unnecessary permissions
Privileged access requires multi-factor authentication
Production database access restricted and monitored
5. App-Specific Security Measures
Each application implements security measures tailored to its unique data handling requirements:
5.1 Quibit (Social Platform)
Security measures for social data:
Post visibility controls (public, friends-only, private) enforced at the database query level
Image and video uploads scanned for malware before storage
User-generated content sanitized to prevent XSS and injection attacks
Profile data access controlled by privacy settings
Job application data encrypted and accessible only to the employer and applicant
Business listing data validated and sanitized before publication
Content delivery via CDN with signed URLs for media files
5.2 Kha (Dating — 18+)
Enhanced security for sensitive dating data:
Dating profiles encrypted with additional application-level encryption
Match and conversation data isolated from other app data stores
Photo verification images processed in-memory and not permanently stored after verification
Location data for nearby discovery is approximated — exact coordinates never shared with other users
Unmatch/block immediately revokes all data access between users
Profile screenshots detection and reporting mechanisms
Identity verification documents encrypted with restricted access, deleted after verification period
Intimate photo sharing uses view-once with screenshot detection
5.3 QuiTalk (AI Chat, Channels & Phone Calls)
Comprehensive security for AI interactions, channels, and communications:
AI conversation data encrypted at rest with per-user encryption keys
Channel data isolated — channel owners control access and brain/FAQ content
Phone call metadata (duration, participants) stored separately from call content
WebRTC phone calls use SRTP (Secure Real-time Transport Protocol) encryption
DTLS key exchange for phone call security
AI provider API calls use dedicated encrypted channels
Channel brain/memory data encrypted and accessible only to channel owner and authorized moderators
Real-time Socket.IO connections authenticated per-message
Message delivery receipts do not expose message content
5.4 QuizCoin (Quiz Game)
Security measures for game data integrity:
Score submissions validated server-side — client-side scores are never trusted
Anti-cheat mechanisms detect abnormal answer patterns and timing
Leaderboard rankings computed server-side with tamper protection
In-game currency transactions logged with full audit trail
Quiz question banks encrypted to prevent data mining
Game session tokens prevent replay attacks
Rate limiting on answer submissions to prevent automated play
6. AI Data Security (QuiTalk)
QuiTalk's AI features require special data security considerations due to third-party AI provider integration:
6.1 AI Conversation Data Handling
How we handle data in AI-powered conversations:
AI conversations are encrypted at rest using AES-256
Conversation context sent to AI providers contains only the minimum data needed for response generation
Personal identifiers are stripped from AI prompts where possible
AI conversation history retention follows our data retention policy (configurable by user)
Users can delete individual AI conversations or their entire AI chat history
AI-generated responses are not used to build user advertising profiles
6.2 Third-Party AI Provider Security
We use industry-leading AI providers with strong security practices:
- Data processing agreements in place — user data is not used for model training
- All API calls encrypted with TLS 1.3
- No data retention by providers beyond active request processing
- SOC 2 Type II and/or ISO 27001 certified providers
- Paid enterprise API tiers used — data is not used for model improvement
- Used solely for text embedding generation and knowledge search
- No conversation content stored by embedding providers
- Embeddings are one-way — original text cannot be reconstructed from embeddings
6.3 AI Data Retention & Anonymization
We apply strict retention and anonymization practices to AI data:
Active AI conversations retained as long as the user maintains them
Deleted conversations are permanently purged within 30 days
Anonymized and aggregated usage statistics retained for service improvement
AI safety logs (harmful content attempts) retained for 90 days for security review
Channel brain/knowledge base data retained while the channel is active
No AI conversation data is sold or shared with third parties for marketing
7. Infrastructure Security
Our infrastructure is designed with multiple layers of security controls:
7.1 Database Security (MongoDB)
MongoDB instances are hardened with comprehensive security measures:
Encryption at rest enabled with AES-256-CBC using WiredTiger storage engine
Authentication required for all database connections (SCRAM-SHA-256)
Network-level isolation — databases accessible only from application servers
Automated backups encrypted and stored in geographically separate locations
Query audit logging for sensitive collections
Role-based database access — applications use least-privilege database users
Regular security patches and version updates
7.2 Redis Security
Redis instances used for session management and caching are secured:
Password-protected Redis instances with strong credentials
TLS encryption for Redis connections
Network isolation — Redis not exposed to public internet
Session data automatically expires based on configurable TTL
Redis persistence configured for data durability without compromising security
Memory limits enforced to prevent denial-of-service
7.3 Socket.IO Security (Real-Time Communications)
Real-time WebSocket connections are secured at multiple levels:
WSS (WebSocket Secure) enforced — unencrypted WebSocket connections rejected
Per-connection authentication with JWT validation
Namespace and room-level authorization checks
Rate limiting on message emissions to prevent flood attacks
Connection origin validation (CORS) to prevent unauthorized access
Automatic reconnection with re-authentication
Heartbeat monitoring for stale connection cleanup
7.4 Server Hardening
All production servers follow hardening best practices:
Minimal OS installations — unnecessary services and packages removed
Automated security patch management
Firewall rules restrict traffic to required ports only
SSH access limited to authorized personnel with key-based authentication
Intrusion Detection Systems (IDS) monitor for unauthorized access attempts
Container security scanning for vulnerabilities in Docker images
Infrastructure as Code (IaC) for reproducible, auditable deployments
DDoS protection through cloud provider and CDN layers
8. Incident Response
We maintain a comprehensive incident response plan to handle security breaches and data incidents:
8.1 Breach Detection
Our monitoring systems detect security incidents through:
24/7 automated security monitoring and alerting
Anomaly detection on login patterns and API usage
Real-time log analysis for suspicious activities
Automated vulnerability scanning of infrastructure and dependencies
Bug bounty program for responsible vulnerability disclosure
Regular penetration testing by third-party security firms
8.2 Breach Notification
In the event of a data breach affecting user data, we commit to:
Notifying affected users within 72 hours of breach confirmation
Reporting to relevant data protection authorities as required by law
Providing clear information about what data was affected
Detailing the steps taken to contain and remediate the breach
Offering guidance to affected users on protective measures
Publishing a post-incident report when investigation concludes
We are committed to notifying affected users and relevant authorities within 72 hours of confirming a data breach, in compliance with GDPR Article 33 and South Korea PIPA requirements.
8.3 Containment & Recovery
Our containment and recovery procedures include:
Immediate isolation of affected systems to prevent further exposure
Forensic analysis to determine scope and root cause of the breach
Credential rotation for potentially compromised accounts
Forced password resets for affected user accounts when necessary
System restoration from verified clean backups
Post-incident review to implement preventive measures
Updated security controls based on lessons learned
9. Third-Party Security
We carefully vet and monitor all third-party services that process user data:
9.1 Vendor Security Assessment
Before engaging any third-party service, we evaluate:
Security certifications (SOC 2, ISO 27001, etc.)
Data handling and retention policies
Encryption practices for data at rest and in transit
Incident response capabilities and notification procedures
Compliance with applicable data protection regulations
Business continuity and disaster recovery plans
History of security incidents and remediation actions
9.2 Data Processing Agreements
All third-party processors are bound by contractual obligations:
Written Data Processing Agreements (DPAs) with all vendors handling user data
Contractual requirements for breach notification within 48 hours
Restrictions on sub-processing without prior approval
Data deletion requirements upon contract termination
Right to audit vendor security practices
Liability provisions for security failures
9.3 AI Provider Security Requirements
All third-party AI service providers meet additional security requirements:
No user data retention beyond active request processing
No use of user data for model training or improvement
Enterprise-grade API security with key rotation
Compliance with data localization requirements when applicable
Regular security assessment reviews
Transparent AI safety and content moderation practices
10. User Security Controls
We provide users with tools and controls to manage their own security:
10.1 Password Requirements
Strong password policies protect user accounts:
Minimum 8 characters with complexity requirements
Passwords hashed using bcrypt with appropriate cost factor
Compromised password detection against known breach databases
Password change requires current password verification
Password reset via verified email or phone with time-limited tokens
No password reuse — last 5 passwords cannot be reused
10.2 Session Management
Users can manage their active sessions:
View all active sessions with device type, location, and last activity
Terminate individual sessions or all sessions at once
Automatic session timeout after configurable inactivity period
Per-device session isolation — compromising one device does not affect others
Session data stored in Redis with automatic expiration
10.3 Data Export & Deletion
Users have full control over their data:
Request a complete copy of all personal data (GDPR Article 15 / PIPA compliance)
Data export delivered in machine-readable format (JSON)
Account deletion permanently removes personal data within 30 days
Specific data deletion requests honored for individual content
AI conversation history can be independently deleted
Dating profile and match history (Kha) can be deleted without affecting other apps
Data deletion is irreversible — users are clearly warned before proceeding
10.4 Privacy & Security Settings
Comprehensive settings available to users:
Profile visibility controls (public, contacts-only, private)
Blocked user management across all apps
Two-factor authentication enable/disable
Login notification preferences
Connected third-party app management
Data sharing preferences for analytics and improvement
Location sharing controls with granular permissions
11. Regulatory Compliance
We comply with data protection regulations across all jurisdictions where we operate:
11.1 PIPA (South Korea Personal Information Protection Act)
As a company primarily operating under South Korean jurisdiction:
Compliance with all PIPA data processing and protection requirements
Appointed Personal Information Protection Officer (CPO)
Annual data protection impact assessments
Data localization for Korean user data where required
Consent management compliant with PIPA standards
Mandatory breach notification to Korea Internet & Security Agency (KISA)
Regular compliance audits per PIPA requirements
11.2 GDPR Concepts
We implement GDPR-aligned data protection principles globally:
Lawful basis for all data processing activities
Data minimization — collecting only what is necessary
Purpose limitation — data used only for stated purposes
Storage limitation — data retained only as long as needed
Right to access, rectification, erasure, and portability
Data Protection Impact Assessments for high-risk processing
Privacy by design and by default in all new features
11.3 Data Localization
We respect data sovereignty requirements:
South Korean user data stored on servers within South Korea where required
Cross-border data transfers only with appropriate safeguards
Standard Contractual Clauses (SCCs) for international data transfers
Transparency about data storage locations in privacy disclosures
Regular review of data localization requirements as regulations evolve
12. Contact Information
For questions or concerns about our data security practices:
For questions about this policy, contact [email protected]
© 2026 Quibit, Inc. · Version 2.0· Last updated 2026-03-13