# Security Policy **Platform**: MyFinalVideo (myfinalvideo.com) **Effective Date**: May 26, 2026 **Draft revision**: 22 September 2026 — deployment/access evidence and operator review pending **Contact**: support@myfinalvideo.com --- ## 1. Our Security Commitment MyFinalVideo is a post-mortem video dispatch platform. The content entrusted to us — personal video messages intended for loved ones — represents some of the most sensitive data a person can store. We take this responsibility seriously. Videos are encrypted in the browser before normal v2 upload. Recipient delivery uses server-assisted key re-wrapping protected by Cloud KMS. Application permissions and infrastructure access controls are essential; we do not claim absolute operator inaccessibility. This draft describes the revised design and distinguishes controls that still need deployment and operational verification. --- ## 2. Encryption Architecture ### 2.1 Client-Side Encryption Model (v2) The supported v2 upload flow encrypts video **in your browser** before upload, using **AES-256-GCM envelope encryption**. Historical records require separate inventory; this description is not proof of every stored object's format. 1. **Data Encryption Key (DEK)**: When you record or upload a video, your browser generates a unique, cryptographically random **32-byte (256-bit) Data Encryption Key** for that video. The upload sends wrapped key material. During recipient delivery, the server unwraps the DEK in memory to re-wrap it for the recipient. 2. **Initialization Vector (Nonce)**: Each encryption operation uses a random **12-byte nonce**, generated by the Web Crypto API. Random generation does not guarantee uniqueness. 3. **Browser-Side Encryption**: Normal v2 upload encrypts video bytes in your browser using AES-256-GCM and uploads ciphertext. Account, recipient and other metadata are processed separately; not all application data is encrypted with the video key. 4. **Key Wrapping (Owner)**: The DEK is wrapped using a key derived from your account password via PBKDF2 (600,000 iterations, SHA-256), creating an `owner_wrapped_dek` stored in Firestore. 5. **Key Wrapping (Dispatch)**: A separate `dispatch_wrapped_dek` is also created — the DEK is wrapped using a key derived from a `dispatch_secret`, which is then encrypted by Google Cloud KMS and stored in Firestore. This allows the system to re-wrap the key for recipients at dispatch time without your password. 6. **Storage Split**: - **Cloud Storage** holds video ciphertext. - **Cloud Firestore** holds metadata, the nonce, salts, owner- and dispatch-wrapped DEKs and the KMS-encrypted dispatch secret. KMS protects the dispatch secret; it does not directly wrap both DEK copies. Owner access uses the password-derived wrapping key. Recipient dispatch uses KMS and the dispatch wrapping path. ### 2.2 Security Boundaries Ciphertext in GCS is separated from wrapped key metadata in Firestore. The dispatch path uses KMS-protected material to unwrap and re-wrap the video key in server memory. Access to both data and the relevant key permissions can permit decryption; separate storage alone does not prevent a sufficiently privileged operator or attacker from obtaining access. ### 2.3 Privileged Access Privileged IAM, service-account and deployment access must be restricted, reviewed and audited. This document does not assert that administrators lack all KMS permissions, that a service account is the sole possible decryption principal, or that an independent security audit has been completed. Those claims require separate evidence. --- ## 3. Access Controls ### 3.1 Video Dispatch Engine — Key Re-Wrapping Encrypted videos are dispatched to recipients through a **server-assisted key re-wrapping flow** that requires explicit emergency-contact confirmation, a 48-hour cooldown, any annual date hold, completed uploads and enabled email delivery. The Dispatch Engine performs the following steps: 1. Google Cloud KMS decrypts the `dispatch_secret` for that video; 2. The Dispatch Engine uses PBKDF2 + AES Key Unwrap (RFC 3394) to unwrap the `dispatch_wrapped_dek`; 3. The DEK is re-wrapped using key material derived from a recipient token and salt; the token is not consumed after one viewing; 4. The recipient portal checks token access and provides recipient-wrapped key metadata and access to ciphertext; any issued storage URL has its own expiry; 5. The recipient's browser performs the final AES-256-GCM decryption locally. Normal v2 dispatch re-wraps keys instead of decrypting video bytes. Because it temporarily handles the raw DEK, sufficiently privileged code or infrastructure access can still permit video decryption. This describes the implemented flow, not a technical impossibility. ### 3.2 Ciphertext and Link Expiry Recipients use a time-limited portal token to obtain encrypted video and recipient-wrapped key material. Normal v2 delivery uses the stored ciphertext; it does not create a decrypted copy in a temporary dispatch bucket. Access is checked against token expiry, blocking and owner state. Expired records are cleaned by the retention job; copies already downloaded cannot be recalled. ### 3.3 Sub-Account and Family Plan Isolation Under the Family Plan, the account owner creates sub-accounts for family members. The ordinary account API scopes vault access to the authenticated owner. Family/enterprise owners can see member information needed to manage their accounts and billing. Account deletion can queue child-account cleanup. Server-side SDK access is governed by IAM and application authorization; this document does not claim that Firestore client security rules constrain privileged backend access. ### 3.4 No Cross-User Access Ordinary vault endpoints are intended to enforce owner authorization. Family/enterprise management exposes member information needed for those features. Cross-account, management-role and recipient boundaries require continued regression and staging verification; this policy does not establish that every possible authorization defect has been excluded. --- ## 4. Infrastructure Security ### 4.1 Cloud Platform The inspected API and scheduled runtimes are in europe-west1, while the Firestore database and video bucket are in us-central1. The video bucket uses a KMS key path in us-central1. Cloud provider certifications are not a security audit of this application or proof of its particular IAM/configuration. ### 4.2 Cloud Storage Access The design uses authenticated API checks and time-limited signed storage access. Production bucket IAM, public-access prevention, object versions and signing principals must be verified. A signed URL is sensitive and may remain usable until expiry even after the application's token is revoked. ### 4.3 Transport Security Production access is intended to use HTTPS. Verify the deployed edge, supported TLS versions, redirects and provider connections; local configuration does not prove every live transport setting. ### 4.4 Custom Authentication System User authentication is managed by our custom backend application. The system handles session token issuance, expiry, and revocation. All authenticated API calls are validated against system-issued JWTs before any data access is permitted. ### 4.5 Database Security Firestore stores account/contact/recipient metadata, wrapped keys and operational records; normal v2 video bytes remain in object storage. Backend SDK access is governed by service-account IAM and application authorization. Firestore client rules do not by themselves constrain privileged backend access. Cross-account and family boundaries require end-to-end verification. ## 5. Authentication Security ### 5.1 Password Storage The authentication implementation stores a bcrypt password hash rather than the submitted password. Registration, login and password-change/reset handlers process submitted passwords in server memory to hash or verify them. The current hashing helper uses bcrypt with a cost of 12. ### 5.2 Plaintext Passwords Passwords are submitted to the authentication service over the intended HTTPS connection; transport encryption is distinct from the password being available to the receiving application. Passwords must not enter application logs or support captures. Deployed transport, request logging and privileged access require verification. Browser-side video encryption does not make authentication passwords inaccessible to the backend. ### 5.3 Session Management Authenticated sessions are managed via system-issued JWTs with defined expiry periods. Sessions can be revoked by the user (via account management) or by us in the event of a suspected security incident. Revoked tokens are invalidated immediately on the server side. ### 5.4 Credential Security Recommendations We recommend that you: - Use a strong, unique password for your MyFinalVideo account - Enable any additional authentication security offered by your email provider - Never share your account credentials with anyone --- ## 6. Payment Security Checkout uses the provider selected for the transaction. Dodo and Creem integrations exist; source code alone does not establish which merchant accounts are live or their contract/certification status. The application records relevant provider references and entitlement/refund state. Historical payments need reconciliation with the revised receipt flow. Card entry belongs on the selected provider's checkout. Do not send card details to support. Verify actual checkout, webhook signatures, repeat handling and refund behavior before enabling paid use; do not claim a provider certification or universal no-card-data exposure without evidence. --- ## 7. Incident Response ### 7.1 Detection and Assessment Security incidents (including suspected unauthorised access, data breaches, or infrastructure compromise) are assessed within **24 hours** of detection by our operations team. ### 7.2 Regulatory Notification In the event of a personal data breach meeting the threshold under GDPR Article 33 or KVKK, we will notify the relevant supervisory authority **within 72 hours** of becoming aware of the breach, as required by law. ### 7.3 User Notification Where a breach is likely to result in a high risk to your rights and freedoms (GDPR Article 34), we will notify affected users **without undue delay** via the email address registered on your account. The notification will include: - A description of the nature of the breach - The likely consequences - Measures taken or proposed to address the breach ### 7.4 Containment Upon confirming a breach, we will take immediate steps to contain it, including revoking compromised credentials, isolating affected services, and engaging Google Cloud's incident response processes where applicable. --- ## 8. Vulnerability Disclosure ### 8.1 Reporting a Vulnerability If you discover a security vulnerability in MyFinalVideo — including but not limited to: authentication bypasses, injection vulnerabilities, encryption weaknesses, or improper access controls — please report it to us **before public disclosure**: **Email**: support@myfinalvideo.com **Subject line**: `SECURITY VULNERABILITY REPORT` Please include: - A clear description of the vulnerability - Steps to reproduce it - The potential impact you have assessed - Any proof-of-concept (redacted to avoid risk of exploitation) ### 8.2 Our Response Commitment We will acknowledge your report **within 5 business days** and provide a timeline for investigation and remediation. We will keep you informed of our progress. ### 8.3 Responsible Disclosure Policy We will not pursue legal action against security researchers who: - Report vulnerabilities to us in good faith before public disclosure - Do not access, modify, or delete user data beyond what is necessary to demonstrate the vulnerability - Do not perform denial-of-service attacks or social engineering against our users or staff We ask researchers to give us a reasonable remediation period (typically 30–90 days depending on severity) before any public disclosure. --- ## 9. What We Cannot Protect Against While we have implemented strong technical and procedural controls, the following risks are outside our ability to mitigate: ### 9.1 Device Compromise If the device you use to access MyFinalVideo is infected with malware, compromised by a keylogger, or physically accessed by an unauthorised party, your account may be at risk. We cannot protect against threats originating on your own device. ### 9.2 Credential Sharing If you share your account login credentials with another person, that person will have full access to your account, including the ability to view recipient lists, modify check-in settings, or delete your content. We cannot distinguish authorised from unauthorised access when valid credentials are used. ### 9.3 Incorrect Recipient Information If you provide an incorrect email address or phone number for a video recipient or emergency contact, dispatched messages may be delivered to an unintended party. We dispatch to the contact information you supply, and we cannot verify ownership of email addresses or phone numbers provided by users. You are responsible for ensuring recipient contact details are accurate. --- ## 10. Penetration Testing and Security Reviews Local regression, SDK/emulator and cryptographic interoperability tests have been run. They are not an independent penetration test, production security audit or proof of complete browser/cloud coverage. External review, staging acceptance, live access verification and a restore rehearsal remain open. Testing production infrastructure requires prior written authorization and an agreed scope. Follow the Vulnerability Disclosure Program for reporting; do not assume unrestricted testing permission. --- ## 11. Changes to This Policy We may update this Security Policy to reflect changes to our infrastructure, practices, or legal requirements. We will post the updated policy at myfinalvideo.com/legal/security-policy with a revised "Last Updated" date. For significant changes, we will notify users by email. --- *MyFinalVideo — myfinalvideo.com* *Contact: support@myfinalvideo.com*