Screening Room Privacy Policy

Effective Date: August 27, 2026

1. Scope

This Privacy Policy applies to Screening Room, also known as 私映 (the “App”), and explains how the App accesses, uses, stores, and protects information related to users, including the App’s file-encryption and escrow-recovery mechanism.

2. Information We Process and Collect

During ordinary use, the App does not require users to register a developer-operated account, does not include advertising SDKs, does not track users across apps or websites, and does not automatically upload user files, file content, filenames, file paths, App passwords, recovery codes, file encryption keys, or escrow recovery data to developer-controlled servers merely because a user creates, opens, plays, encrypts, or decrypts a file.

We do not sell, rent, or share personal information for advertising or marketing purposes.

If a user voluntarily contacts us through email or another support channel, or voluntarily submits a file for recovery or technical support, we process the information the user provides. See Section 8 for details.

3. User Files and Content

The App accesses files in Files, iCloud Drive, NAS devices, cloud drives, or compatible third-party file providers only after the user selects or authorizes access to them. Access is used solely to perform user-requested actions such as playback, preview, encryption, decryption, import, export, or file management.

Unless the user chooses to copy, move, export, or save a file elsewhere, the App does not intentionally change the file’s original storage location. Files may remain stored or synchronized by Apple iCloud or a third-party file provider selected by the user. Those services process data under their own privacy policies and terms.

To support playback, preview, encryption, or decryption, iOS or the App may create necessary temporary files or caches on the device. Such data is not automatically uploaded to developer-controlled servers and is removed by the system or the App when no longer needed.

4. Face ID, Touch ID, and Device Authentication

When Face ID, Touch ID, or device passcode protection is enabled, the App uses Apple’s system authentication framework to request authentication. The App cannot read, store, or export facial data, fingerprints, or other biometric templates. It receives only the authentication result, such as success, failure, or cancellation.

5. File Encryption, Recovery Codes, and the Escrow Recovery Mechanism

5.1 File Encryption

The App uses a randomly generated file encryption key to encrypt files selected by the user. Ordinary encryption and decryption operations are performed on the user’s device. App passwords and user recovery codes protect or restore the user-side ability to decrypt files, and users are responsible for keeping them safe.

5.2 Escrow Recovery Data in .efl Files

Every .efl encrypted file created by the App contains developer-managed escrow recovery data. When an encrypted file is created, the App additionally encrypts the file encryption key using the developer’s public key and stores the resulting encrypted key inside the .efl file.

The escrow recovery data does not contain the file encryption key in plaintext, and the developer’s public key alone cannot decrypt the file. However, a party possessing the corresponding developer private key may, after obtaining the relevant .efl file, have the technical ability to recover the file encryption key and subsequently decrypt the file content.

The escrow recovery mechanism is a fixed component of the current .efl encrypted-file format. The current version does not provide an option to disable or remove it.

5.3 No Automatic Upload

The escrow recovery data is generated on the user’s device and written into the .efl file. The App does not automatically upload the file, file encryption key, escrow recovery data, or plaintext content to developer-controlled servers merely because the user creates, opens, plays, encrypts, or decrypts an .efl file.

The developer does not automatically obtain user files during ordinary use and cannot remotely browse or decrypt files stored on a user’s device, in Files, iCloud Drive, a NAS device, a cloud drive, or another location without first obtaining the relevant file or necessary data.

5.4 Use of the Escrow Recovery Capability

If a user voluntarily submits an .efl file or related recovery data to the developer and expressly requests file recovery or technical support, the developer may use the escrow recovery mechanism to attempt to recover the file encryption key and file content.

The developer will not use the escrow recovery capability for advertising, profiling, marketing, or purposes unrelated to file recovery, technical support, security response, or legal compliance.

The developer may be required to process data lawfully obtained by the developer where required by applicable law, a binding court order, or another legally enforceable request.

5.5 Data Processed During Recovery

When a user voluntarily submits a file for recovery or technical support, the developer may access or process:

• the submitted .efl encrypted file and its format metadata;
• the escrow recovery data contained in the file;
• temporary file encryption keys generated during recovery;
• the decrypted file content, if recovery is successful; and
• the user’s email address, issue description, logs, screenshots, or other attachments voluntarily provided by the user.

This information is used only to process the user’s recovery or support request. Unless retention is required by law, the developer will delete file copies, temporary keys, and recovery data that are no longer reasonably necessary within a reasonable period after the request is completed.

Before submitting a file, the user should confirm that the user is authorized to provide it to the developer and understand that successful recovery may allow the developer to access the file content while processing the request.

5.6 Security of the Escrow Private Key and Recovery Limitations

The developer will apply technical and organizational measures appropriate to the risks associated with the escrow recovery capability and will restrict access to and use of the escrow private key. Although reasonable safeguards will be used, no key-escrow, electronic-storage, or data-processing mechanism can guarantee absolute security.

The escrow recovery mechanism does not guarantee that every file can be successfully recovered. File corruption, format incompatibility, damage to the escrow recovery data, unavailable private keys, or other technical conditions may prevent recovery.

6. In-App Purchases

The App may offer Pro features or other in-app purchases through the Apple App Store. Apple processes payments, billing, and payment credentials. The App does not receive or store users’ payment card numbers, Apple ID passwords, or complete payment information.

The App may receive product information, transaction status, and entitlement results from Apple as necessary to verify purchases and restore previous purchases. Apple’s terms and privacy policy also apply to this processing.

7. Diagnostics and Analytics

The current version does not integrate third-party advertising SDKs or user-behavior analytics SDKs. Depending on the user’s device privacy and analytics settings, Apple may independently process App Store transaction information, crash reports, or platform diagnostics. Such processing is governed by Apple’s privacy policy.

If a future version introduces third-party analytics, advertising, developer-operated cloud synchronization, user accounts, developer-operated servers, or other data-collection functionality, we will update this Privacy Policy before enabling the relevant feature and obtain any authorization required by applicable law or platform rules.

8. Voluntary Contact and Recovery Requests

If a user contacts us by email or through another support channel, we receive information voluntarily provided by the user, which may include an email address, issue description, device model, operating-system version, logs, screenshots, or other attachments.

If a user voluntarily submits an .efl file for recovery or technical support, the developer may also process the file, escrow recovery data, temporary keys generated during recovery, and decrypted file content if recovery is successful.

We use this information only to respond to requests, provide technical support, attempt file recovery, address complaints or feedback, diagnose problems, and improve the App. Unless a longer period is required by law, we retain such information only for as long as reasonably necessary for those purposes.

Users may contact us using the details below to request deletion of support correspondence and recovery data that are no longer required.

9. Data Retention and Deletion

App settings, authorization states, caches, security verification material, and .efl files are generally stored on the user’s device or in a storage location selected by the user. Users may delete relevant local data through features provided by the App, through iOS file-management tools, or by uninstalling the App.

Uninstalling the App may not delete original or .efl files that remain in Files, iCloud Drive, NAS devices, third-party cloud drives, or another external location. Users must manage and delete those files from the relevant storage location.

Support or recovery data voluntarily submitted to the developer is retained and deleted as described in Sections 5.5 and 8.

10. Third-Party Services

The App may use system services provided by Apple, including Files, document pickers, iCloud Drive, Face ID, Touch ID, device passcode authentication, StoreKit, system media playback, and file-access frameworks.

Users may also choose files managed by third-party cloud drives, NAS devices, or file providers. Those third parties process data under their own privacy policies and terms. The developer does not control their data-processing practices.

If a user connects a Microsoft OneDrive or Google Drive account, the App communicates directly with Microsoft or Google using the authorization granted by the user. See Section 11. Microsoft and Google process the data they receive under their own privacy policies and terms.

11. Cloud Drive Accounts (OneDrive and Google Drive)

11.1 Connecting an Account

Connecting a cloud drive account is optional. A user may connect a Microsoft OneDrive account, a Google Drive account, or both, in order to browse and play media stored in that account. If no account is connected, the features described in this Section are not used.

Accounts are connected through the provider’s own OAuth 2.0 authorization page (with PKCE), presented in the system browser. The App never sees or stores the user’s cloud account password. The resulting access and refresh tokens are stored only in the device Keychain, protected so that they are available only while the device is unlocked and are never copied to another device. Tokens are never transmitted to developer-controlled servers.

11.2 What the App Accesses, and Why

With the authorization granted by the user, the App accesses only what is required to provide its user-facing features:

• the identifier and email address of the connected account, displayed in the App so that the user can distinguish accounts and so that the same account is not connected twice;
• the names, folder structure, sizes, modification times, and thumbnails of items inside the folders the user has added to the App, so that the App can list the media contained in those folders;
• file content, read by byte range, in order to stream playback directly from the cloud drive (including range reads of the App’s .efl encrypted files);
• uploads, when the user chooses to save a file back into the user’s own cloud drive; files encrypted by the App are encrypted on the device before upload;
• moving a file to the cloud drive’s trash, when the user deletes that file from within the App;
• storage quota information, displayed in the App.

The App requests folder-level access because its core feature is adding a cloud folder and automatically listing the media inside it, including files the user adds to that folder later.

All of these requests are made directly between the user’s device and Microsoft or Google. No developer-operated server participates in, proxies, or receives this traffic. The App does not write tokens, email addresses, filenames, or request URLs into logs.

11.3 Google API Services User Data Policy (Limited Use)

Screening Room’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In particular, data obtained through the Google Drive API is:

• used only to provide and improve the user-facing features described in Section 11.2;
• processed only on the user’s device, and never transmitted to, stored on, or processed by developer-controlled servers;
• never sold, and never used for advertising, marketing, profiling, or for training generalized artificial-intelligence or machine-learning models;
• never transferred to third parties, except when the user explicitly directs it or where required by law;
• never read by a human, except where the user explicitly submits the data to us for support of a specific issue, where required for security purposes such as investigating abuse, or where required by law.

11.4 Disconnecting an Account and Deletion

A user may disconnect a cloud drive account at any time in the App’s settings. Disconnecting removes the stored tokens from the device Keychain and deletes the App’s local record of that account, including cached folder listings, thumbnails, and downloaded copies. Deleting the App removes the same data.

Disconnecting does not delete anything stored in the user’s cloud drive. Users may additionally review or revoke the App’s access at any time in their provider account settings, for example at Google Account → Third-party apps & services, or in the equivalent Microsoft account page.

12. Children’s Privacy

The App is not specifically directed to children. We do not knowingly collect children’s personal information through the App. A parent or guardian who believes that a child submitted personal information or files to us may request deletion using the contact information below.

13. Data Security

We use technical and organizational measures appropriate to the App’s functionality and escrow recovery capability and rely on security capabilities provided by iOS where reasonably practical.

However, no electronic storage, encryption, key-escrow, or data-processing method can guarantee absolute security. Users should protect their device passcode, App password, recovery code, encrypted files, important file backups, and accounts used with iCloud, cloud drives, or other storage services.

14. Your Rights

Subject to applicable law, users may request access to, correction of, or deletion of personal information and recovery data they voluntarily submitted to us.

Because the App’s primary files and data are stored on the user’s device or in storage services selected by the user, the developer generally cannot access or delete content stored in those locations. Unless the user voluntarily provides the relevant .efl file or necessary data, the developer cannot remotely recover or access the file.

15. Changes to This Policy

We may update this Privacy Policy when the App’s features, file format, escrow recovery mechanism, data-processing practices, legal requirements, platform rules, security requirements, or operating practices change. The updated version will be posted on this page with a revised effective date. Where reasonably practicable, material changes will also be communicated through an in-app notice or another appropriate method.

16. Contact Us