Security & Data Protection Standards
An in-depth overview of the engineering controls, encryption protocols, and zero-trust perimeters designed to safeguard creator assets and API credentials on ScenoraEdits.
In Plain English (Key Takeaways)
- Enterprise Encryption: All data in transit is protected by TLS 1.3; all project metadata and credentials are encrypted at rest with AES-256.
- Isolated BYOK Secret Vault: Your personal provider keys are encrypted with dedicated salt hashes and decrypted only during ephemeral worker execution.
- Local GPU Sandboxing: Intermediate diffusion latent tensors and render caches stay strictly in your local VRAM and physical NVMe drive.
- Zero-Trust Identity: Role-based access control (RBAC), short-lived Firebase tokens, and IP-isolated admin routing.
- Continuously Audited: Regular dependency vulnerability scanning via automated CI/CD security pipelines.
01Core Security Principles
ScenoraEdits is built upon three non-negotiable security tenets:
Least Privilege
Zero excess permissions across internal databases and API dispatch workers.
Zero Knowledge
We cannot read your raw BYOK keys once committed to the encrypted secret vault.
Local Sovereignty
Local GPU computations never mirror intermediate raw video buffers to cloud disks.
02Encryption at Rest & in Transit
All network ingress and egress connections to ScenoraEdits endpoints require modern cryptographic standards:
- Data in Transit: 100% of HTTPS and WebSocket traffic is protected via TLS 1.3 (with TLS 1.2 fallback using strict forward-secrecy cipher suites like ECDHE-RSA-AES128-GCM-SHA256). Non-secure HTTP requests are automatically rewritten and redirected with HSTS headers.
- Data at Rest: Database records, Video Bible manifests, and user project metadata are stored in Google Cloud Firestore and encrypted with AES-256 with Google-managed key infrastructure.
03The BYOK Secret Key Vault
Because ScenoraEdits empowers creators to bring their own API keys, our credential protection architecture is subject to rigorous isolation:
- Keys are stored in an encrypted sub-collection indexed only by salted account hash.
- In the client dashboard, keys are permanently masked (e.g., `key-••••••••••••••••3A9F`).
- You can revoke or rotate any connected key instantly with one click from API Key Settings.
04Local GPU Sandboxing & Worker Isolation
When you run our local background engine on your NVIDIA RTX hardware:
- The local worker daemon binds strictly to your loopback address (`127.0.0.1`), rejecting external non-local connections.
- Model weights loaded into your GPU memory (VRAM) reside strictly in your operating system’s physical graphics address space.
- Rendered MP4 and PNG frames are written to your local working directory and never uploaded to public bucket storage unless explicitly shared by you.
05Identity, Authentication & Zero-Trust Access
Our access perimeter is governed by Firebase Enterprise Authentication:
- Password hashing utilizes multi-round bcrypt/scrypt algorithms with individualized cryptographic salts.
- Session tokens expire automatically and are signed with asymmetric RS256 private keys.
- Administrative endpoints (`/admin/*`) are protected by server-side role verification middleware that cross-checks cryptographic UID claims against immutable admin rosters.
06Responsible Vulnerability Disclosure
We welcome collaboration with cybersecurity researchers. If you identify a potential security vulnerability within our web application, backend API, or local daemon, please report it directly to our security engineers via our Support & Security Desk.
We commit to acknowledging valid security reports within twenty-four (24) hours and will not pursue legal action against researchers acting in good faith.
Questions about our legal terms or commercial licenses?
Our creator relations and legal engineering team is available to assist with custom enterprise agreements, indemnification inquiries, or license verification.