Information Security Policy

Organization: Sierra Digital Forge LLC Product covered: StreamWrangler (Android mobile application) Effective date: May 18, 2026 Last reviewed: May 18, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0

⚠️ DRAFT — REQUIRES LAWYER REVIEW BEFORE PUBLICATION.

1. Introduction & Purpose

Sierra Digital Forge LLC (“Sierra Digital Forge,” “we,” or “us”) develops StreamWrangler, a family TV-and-movie tracking Android application. This Information Security Policy (“Policy”) establishes the baseline practices Sierra Digital Forge follows to identify, mitigate, and monitor information-security risks across all systems that handle user data or access third-party services on the user’s behalf.

The purposes of this Policy are:

1. To protect user-supplied information against unauthorized access, disclosure, alteration, or destruction.
2. To define the minimum technical and operational controls applied across Sierra Digital Forge systems and the software it ships to end users.
3. To establish a clear and current incident-response posture so that any suspected breach receives a timely, recorded, and proportionate response.
4. To document Sierra Digital Forge’s subprocessor list and the data each subprocessor receives.
5. To provide a written reference for partners, vendors, and regulators that request evidence of operational security practices.

This Policy is operationalized — every commitment described below reflects a practice Sierra Digital Forge currently performs or is currently positioned to perform on the systems in scope.

2. Scope

This Policy applies to:

• The StreamWrangler Android application and any successor products distributed by Sierra Digital Forge.
• The developer workstation(s) on which Sierra Digital Forge stores source code, credentials, and signing keys.
• All third-party integrations (subprocessors) Sierra Digital Forge has contracted with to deliver functionality, including (without limitation) The Movie Database (TMDB), Watchmode, Trakt, Google Firebase (Authentication and Cloud Firestore), and YouTube embedded player.
• All user data Sierra Digital Forge becomes a custodian of, however briefly.

This Policy does NOT cover:

• Operations of subprocessors on their own infrastructure (each subprocessor maintains its own security posture, which Sierra Digital Forge evaluates at the point of integration).
• Streaming-service credentials (Netflix / Disney+ / Prime Video / etc.), which are never collected, stored, or transmitted by Sierra Digital Forge — the App deep-links out to each streaming service’s own surface and does not intercept the user’s authentication with that service.

3. Roles & Responsibilities

Sierra Digital Forge LLC is a member-managed limited liability company. All security responsibilities are vested in the Managing Member, who is accountable for the design, operation, and review of every control described in this Policy.

As Sierra Digital Forge grows, additional roles (engineering, support, compliance) will be added to this section with role-specific responsibilities and access scopes.

4. Information Classification

Sierra Digital Forge classifies information into four tiers. Handling requirements scale with classification.

4.1 Sensitive (Tier 1)

Account-binding data and identifiers that, if disclosed, could result in unauthorized access to a user’s StreamWrangler account or to a service the user has linked. Examples:

• Firebase Authentication credentials (session tokens, refresh tokens).
• Trakt OAuth access and refresh tokens.
• The mapping between a Firebase UID and a user’s display name / email.

Handling:

• Stored on-device only, in encrypted-at-rest storage where the platform offers it (see Section 6).
• Never transmitted to Sierra Digital Forge-controlled infrastructure other than the Firebase backend, and only over TLS-protected channels.
• Transmitted to third parties only as defined in Section 7 and only over TLS-protected channels.
• Deletable by the user at any time via the in-app “Delete Account & Wipe Data” affordance.

4.2 Confidential (Tier 2)

User-identifying or user-supplied information that is not directly account-binding but still warrants protection. Examples:

• Display name and email address (when the user signs in).
• Family-member identities the account holder has configured (Ron / Jolene / Kimberly / Alaysa / Kids / Guests, plus any custom names and avatars).
• Watchlist, watched-episode state, and Family Activity content the user has published.

Handling:

• Stored on-device for local-first reads, and in Cloud Firestore under documents scoped to the user’s UID.
• Transmitted to third parties only for the purpose of the relevant feature (e.g., a TMDB image URL the App renders).
• Deletable by user via in-app wipe.

4.3 Internal (Tier 3)

Operational data that supports the application but does not identify users. Examples:

• App preferences (theme, default tab, preferred-streamers list, hide-anime toggle).
• Anonymous diagnostic logs (local Android logcat).
• Cached TMDB / Watchmode responses inside the application’s in-memory caches.

Handling:

• Stored on-device in standard SharedPreferences or in-process memory.
• Process-lifetime only for the cached API responses.

4.4 Public (Tier 4)

Information intended for unrestricted distribution. Examples:

• Marketing copy on www.sierradigitalforge.com.
• Help content shipped inside the application.
• This Policy itself (may be shared with partners and regulators on request).

No special handling required.

5. Access Control & Authentication

5.1 Account access

• The Google Cloud Console (Firebase project), TMDB Developer Dashboard, Watchmode Dashboard, Trakt Application Console, Google Play Console, and the GitHub repository hosting StreamWrangler source code each require two-factor authentication (2FA) on the Managing Member’s account. No shared accounts are used for any of these services.
• Credentials are stored in a personal password manager protected by a strong unique master password and 2FA. Credentials are never embedded in source code committed to version control.
• API keys required at build time (TMDB, Watchmode, Trakt client ID and secret) are stored in the local.properties file on the developer workstation. That file is excluded from version control via .gitignore and is not synchronized to any cloud service.

5.2 Workstation access

• The primary developer workstation runs Microsoft Windows with full-disk encryption (BitLocker) enabled and a strong account password.
• The workstation is locked when unattended.
• Working copies of the source code reside on a local drive (D:\Projects\StreamWrangler); the OneDrive sync service is intentionally disabled for the project directory to prevent unintended cloud replication of secrets or build artifacts.

5.3 Application user access

• End users of StreamWrangler authenticate locally on their own device. The application supports email/password sign-in and optional Google Sign-In; when used, the sign-in token is held by the Android system credential manager and Firebase Authentication, not by Sierra Digital Forge.
• The Trakt OAuth flow presents Trakt’s authentication UI directly to the user via the streamwrangler://oauth/trakt deep link. Sierra Digital Forge does not see, intercept, or store Trakt usernames or passwords at any point.

5.4 Principle of least privilege

API keys are scoped to the minimum products required for the application’s functionality. The TMDB and Watchmode keys are read-only metadata keys, with no write or billing access. The Trakt OAuth scope is limited to history reads.

6. Encryption Standards

6.1 Encryption in transit

All network traffic between the StreamWrangler application and third-party services uses TLS 1.2 or later, enforced by the respective vendor SDKs:

• Firebase Authentication and Cloud Firestore — TLS managed by the Firebase Android SDK.
• TMDB, Watchmode, Trakt — HTTPS via Retrofit/OkHttp with platform-default TLS configuration.
• YouTube embedded player — HTTPS managed by the YouTube IFrame embed.

The application does not accept unencrypted HTTP connections to any first-party or third-party endpoint.

6.2 Encryption at rest — user device

• Firebase Authentication session and refresh tokens are stored by the Firebase Android SDK in App-private storage protected by the Android user-data sandbox. Trakt OAuth tokens are stored similarly.
• Application preferences not classified as sensitive are stored in standard SharedPreferences, which is protected by the Android user-data sandbox but not separately encrypted.
• Cached metadata (TMDB responses, Watchmode sources, etc.) lives in process memory or in App-private cache directories that the Android system reclaims on uninstall.
• The application supports the standard Android user-data wipe behavior — uninstalling the application or invoking the in-app “Delete Account & Wipe Data” flow removes all stored user data.

6.3 Encryption at rest — Cloud Firestore

• User data Sierra Digital Forge stores in Cloud Firestore (watchlist, viewing state, profile, settings, Family Activity) is encrypted at rest by Google Cloud’s standard storage encryption.
• Access to Firestore documents is governed by Firestore Security Rules that scope each document to the owning user’s UID; one account cannot read or write another account’s documents.

6.4 Encryption at rest — Sierra Digital Forge environment

• Developer workstation: full-disk encryption (BitLocker) enabled.
• Source code repository: hosted on GitHub under a private repository (rdwarren67/streamwrangler). GitHub’s at-rest encryption applies. The repository contains no production secrets (see Section 5.1).
• Credential storage: managed via the developer’s password manager, which encrypts credentials at rest with a master-key-derived AES-256 key.

Sierra Digital Forge does not operate a backend server beyond the Firebase project. The Firebase project is administered through the Google Cloud Console under the same access controls described in Section 5.1.

7. Vendor / Subprocessor Management

Sierra Digital Forge engages the following subprocessors. Each subprocessor was evaluated for its security posture, contractual data-protection commitments, and operational fit before integration. Each is governed by the subprocessor’s published Terms of Service or Data Processing Addendum, as applicable.

7.1 Vendor onboarding

Before integrating any new subprocessor, the Managing Member evaluates:

• The subprocessor’s published privacy and security documentation.
• Whether the subprocessor offers a Data Processing Addendum or equivalent contractual commitment.
• Whether the data shared with the subprocessor is necessary for the feature, or whether the equivalent feature can be implemented on-device.
• The subprocessor’s data-use policy, specifically whether user data submitted to the subprocessor can be used to train its models. Sierra Digital Forge selects tiers and configurations that disable training-on-user-data where the option is offered.

7.2 Vendor monitoring

• Each subprocessor’s status page is referenced when troubleshooting application incidents.
• Security incident notifications from subprocessors are routed to info@sierradigitalforge.com and acted on per the incident-response procedure in Section 8.
• New documentation or policy changes from subprocessors are reviewed at least annually.

7.3 Vendor offboarding

When a subprocessor is removed:

• API keys are rotated or revoked.
• The corresponding code path is removed or feature-flagged off in the next application release.
• Any locally cached tokens for the removed subprocessor are deleted from user devices in the same release.

8. Incident Response

Sierra Digital Forge maintains a documented incident-response procedure for suspected or confirmed information-security events.

8.1 Definitions

• Security event: An observed or reported condition that may indicate a compromise of user data, credentials, or systems in scope.
• Confirmed incident: A security event that, on investigation, is determined to have resulted in unauthorized access, disclosure, alteration, or destruction of in-scope data.
• Breach: A confirmed incident that meets the regulatory threshold for user or regulator notification in the applicable jurisdiction.

8.2 Detection

Security events may surface from:

• A user report to info@sierradigitalforge.com or ron@sierradigitalforge.com.
• A subprocessor security advisory or status notification.
• Observation by the Managing Member during development, code review, or routine operation.

8.3 Response procedure

When a security event is reported or observed:

1. Acknowledge. Log the event with date, time, source, and initial summary.
2. Triage. Assess scope and severity within 24 hours of detection. Determine whether the event qualifies as a confirmed incident.
3. Contain. If credentials are suspected to be exposed, rotate the affected API keys within 24 hours of confirmation. If a user account is affected, contact the user to coordinate remediation.
4. Notify. For confirmed incidents that meet breach thresholds:
   • Notify affected users within 72 hours of confirmation.
   • Notify any affected subprocessors per their published contact procedures.
   • Notify regulators where applicable jurisdictional law requires.
5. Remediate. Apply technical fixes (patches, code changes, configuration changes) and operational fixes (policy updates, training).
6. Record. Document the root cause, the timeline, and the remediation actions taken.
7. Review. Update this Policy or related procedures as needed to prevent recurrence.

8.4 Incident contacts

• Primary contact: info@sierradigitalforge.com (routes to Managing Member)
• Executive contact: ron@sierradigitalforge.com
• Telephone (urgent matters): 702-469-7646 (voice or text)
• Office line: 1-855-SIERRA (1-855-743-7772)

8.5 Post-incident review

For every confirmed incident, a brief written post-incident review is completed within 30 days. The review identifies root cause, timeline, response effectiveness, and any policy changes required. Post-incident reviews are retained as part of the Sierra Digital Forge security record.

9. Vulnerability Management & Patching

9.1 Application dependencies

• Third-party Kotlin / Compose / Firebase dependencies are reviewed at each StreamWrangler release.
• The Android SDK target and compile versions are tracked to the current Google-supported level.
• Known CVE-tier vulnerabilities in dependencies are patched within the following targets:
  • Critical or High severity: within 30 days of publication.
  • Medium severity: within 90 days of publication.
  • Low severity or informational: at the next regularly scheduled release.

9.2 Subprocessor advisories

When a subprocessor publishes a security advisory affecting an integrated feature, Sierra Digital Forge evaluates the advisory promptly and applies the recommended mitigation within the timeframe the subprocessor specifies, or within the severity-tier targets above, whichever is shorter.

9.3 Workstation patching

The developer workstation receives operating system and application security updates on the vendor’s standard release cadence. Major OS updates are applied within 30 days of general availability.

9.4 Penetration testing

Sierra Digital Forge does not currently engage a third-party penetration tester. Because the application has no public-facing server infrastructure beyond the Firebase project (administered through Google Cloud Console and protected by Firestore Security Rules), the attack surface visible from outside the user’s device is limited to the application binary as distributed via the Google Play Store and the encrypted communications with subprocessors. As Sierra Digital Forge scales and adds infrastructure, third-party penetration testing will be added to this Policy and contracted in advance of the relevant launch.

10. Logging, Monitoring & Audit

10.1 Application logging

• StreamWrangler writes diagnostic logs to the local Android logcat facility during development. No log content is transmitted off-device in production builds.

10.2 Sierra Digital Forge environment logging

• The developer workstation generates standard Microsoft Windows audit logs. These are retained per the operating system’s default retention policy.
• The Firebase project generates Cloud Audit Logs at Google’s standard tier. These are accessible through the Google Cloud Console for investigation when needed.

10.3 Subprocessor audit

• Firebase maintains its own logging of authentication events and Firestore reads/writes. Sierra Digital Forge can review these logs through the Firebase / Google Cloud Console.
• TMDB, Watchmode, Trakt, and YouTube maintain their own internal logging for API access. Access to those logs is available via the respective administrative consoles.

11. Data Retention & Deletion

11.1 User-controlled retention

User data created or stored by StreamWrangler resides on the user’s device and, for registered users, in Cloud Firestore under the user’s UID. The user controls retention by:

• Uninstalling the application, which causes the Android system to remove the application’s sandboxed data. (For registered users, Firestore documents remain until the user deletes their account.)
• Using the in-application “Delete Account & Wipe Data” affordance under Settings → Account, which performs an in-app wipe of all user data on the device and triggers backend deletion of the user’s Firestore documents and Firebase Authentication record.

11.2 Sierra Digital Forge-controlled retention

For registered users, Sierra Digital Forge retains Firebase Authentication records and Cloud Firestore documents under the user’s UID for as long as the account is active. On deletion, those records are removed subject to short-term backups that age out on a rolling 30-day cycle.

The Sierra Digital Forge environment otherwise retains only:

• Application source code and build artifacts in version control.
• API credentials for subprocessors (in the developer password manager and local.properties).
• Business records (incident reports, vendor agreements, this Policy).

Business records are retained for the durations required by applicable accounting, tax, and regulatory requirements.

11.3 Subprocessor retention

Each subprocessor retains data per its own retention policy. Trakt retains the OAuth linkage state until the user disconnects via the App or via Trakt directly. TMDB and Watchmode receive only stateless metadata queries and do not retain user-identifying data. Sierra Digital Forge configures each subprocessor for the most restrictive retention available.

12. Business Continuity & Disaster Recovery

12.1 Backend resilience

The Firebase project benefits from Google Cloud’s standard multi-zone redundancy. Sierra Digital Forge does not operate a separate production server beyond Firebase.

12.2 Source code resilience

Source code is maintained in a private GitHub repository with regular commits. Working copies on the developer workstation are backed up to an external storage drive on a regular schedule.

12.3 Credential resilience

Credentials are held in the developer’s password manager, which provides its own encrypted cloud sync and recovery. Build-time API secrets are reproducible by re-fetching them from each subprocessor’s dashboard.

12.4 Key-person risk

Sierra Digital Forge is currently a member-managed LLC with a sole operator. A designated successor will be identified and provided with documented emergency-access procedures (including password manager recovery, source code access, and Firebase project ownership transfer) as the company adds personnel. The successor’s identity and procedures will be recorded in Section 3 of this Policy when established.

12.5 API key compromise recovery

If a Sierra Digital Forge-held API key is suspected to be compromised:

1. Revoke the key via the subprocessor’s dashboard.
2. Generate a new key.
3. Update local.properties on the developer workstation.
4. Rebuild and release the application with the new key in the next available release.
5. Document the event per Section 8.

12.6 Pre-rotation note on TMDB and Watchmode keys

The TMDB and Watchmode keys lived in app/build.gradle.kts as plaintext literals before the genesis commit of the StreamWrangler repository. They were moved to local.properties before the first git init, so git history is clean. However:

• The keys may have been visible to anything with read access to the working tree (cloud sync, local backups, external tools).
• The APK ships them at runtime (BuildConfig embedding). Anyone with the debug APK can dump them.
• Recommendation: rotate both keys with TMDB and Watchmode before the first public build, then again before the first Production-track release. The build picks up new values from local.properties without code changes.

13. Risk Assessment & Review Cadence

13.1 Annual policy review

This Policy is reviewed in full at least once per calendar year. The review is performed by the Managing Member and considers:

• Whether each control in the Policy is still operational.
• Whether new subprocessors have been integrated since the last review.
• Whether new product features have changed the data-handling profile.
• Whether new regulatory or contractual requirements apply.
• Whether any incidents from the past year warrant procedural updates.

The “Last reviewed” date at the top of this Policy is updated on completion of each annual review.

13.2 Triggered review

In addition to the annual review, this Policy is reviewed in full or in part on the occurrence of any of the following events:

• Integration of a new subprocessor.
• Launch of a new product or major feature that materially changes the data-handling profile.
• A confirmed security incident (per Section 8).
• A new applicable regulatory requirement.
• A request from a partner or regulator that surfaces a control gap.

13.3 Risk register

Known risks and their mitigations are tracked in an internal risk register. Risks reviewed include:

• Loss of developer workstation (mitigated by backup + credential resilience).
• Compromise of a subprocessor API key (mitigated by key rotation procedure).
• Compromise of a subprocessor’s own systems (mitigated by short-lived tokens, minimum-product scoping, and incident notification from the subprocessor).
• Key-person incapacity (mitigated by designated successor procedure once established).
• Defective release introducing a data-handling regression (mitigated by version control and the ability to roll back in the Play Console).
• Firestore Security Rules regression (mitigated by rule unit tests and pre-release rule review).

14. Compliance & Regulatory Posture

14.1 Privacy

StreamWrangler is distributed in jurisdictions that include the United States and the European Economic Area. Sierra Digital Forge maintains a Privacy Policy that describes user-facing data collection, use, sharing, and rights. The Privacy Policy is published at the URL specified in the Google Play Console listing for StreamWrangler.

The Privacy Policy honors the access, correction, and deletion rights provided by the California Consumer Privacy Act (CCPA / CPRA) and the EU General Data Protection Regulation (GDPR) where they apply.

14.2 Content sourcing

StreamWrangler does not host or stream long-form video content. All title metadata, images, recommendations, and availability data is sourced from third-party APIs (TMDB, Watchmode) under those providers’ attribution and use terms. Trailers are played through the embedded YouTube player from YouTube’s own infrastructure under YouTube’s terms.

14.3 Google Play Store

Sierra Digital Forge complies with the Google Play Data Safety disclosure for StreamWrangler. Data types collected and shared with subprocessors are declared in the Data Safety form per Google’s requirements.

14.4 Trakt

Sierra Digital Forge complies with the Trakt API Terms of Service and presents Trakt’s authentication UI to the user via OAuth without intercepting credentials.

15. Policy Distribution & Contact

This Policy is made available to:

• Partners, vendors, and regulators on request, via the contact channels below.
• Internal personnel (currently the Managing Member) at all times.

Sierra Digital Forge LLC — primary contacts

16. Acknowledgment

I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the practices described in this Information Security Policy are operational as of the Effective Date, and commit to maintain, review, and update this Policy in accordance with the cadences specified herein.

Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 18, 2026