gov.chaloot.com Privacy and Security Policy

Chaloot Technologies Inc. Version 2.0

1. Who we are and what this covers

Chaloot Technologies Inc. (“Chaloot,” “we,” “us”) is a technology company. We operate web platforms, restricted-access media delivery, and a separate access-controlled portal for government and institutional evaluators.

1.1 Two distinct roles

Chaloot’s obligations differ depending on which role we occupy for a given set of data. Which role applies depends on the data and the relationship in question.

This Policy governs the Controller column. Where we act as a Processor, we act only on documented customer instruction, and we do not use customer data to train models, build profiles, or enrich our own datasets.

1.2 What this Policy does not cover

• Third-party sites reached via links from our properties.
• A customer’s own processing conducted using our platform.
• Employment candidate data, which is covered by a separate recruitment notice.

2. Scope of the system

The system comprises:

1. Public web presence — marketing and informational pages.
2. Restricted content tier — gated by a per-recipient access code.
3. Administrative tier — internal credential and access management. Not reachable by customers or evaluators.
4. Government evaluation portal — a separately gated environment with a materially stronger control set than tiers 2 and 3. See §6.
5. Media delivery tier — video assets served from a CDN under signed, expiring, path-scoped tokens.

Chaloot’s production environment is not authorized to process Controlled Unclassified Information (CUI), classified information, Protected Health Information, or payment card data. No such data may be placed into the system.

3. Data we collect

We collect the minimum required for the system to function and to defend itself.

We do not collect payment card numbers, government-issued identity document numbers, biometric templates, precise geolocation, or special-category / sensitive personal data as defined under GDPR Article 9.

On biometrics specifically: the government portal supports passkey (WebAuthn) authentication. Where a device uses a fingerprint or face to unlock a passkey, that biometric is processed entirely on your device by your operating system. It is never transmitted to Chaloot and we never possess it. We receive only a public key and a cryptographic signature.

4. Why we process it, and our lawful bases

We do not sell personal data, share it for cross-context behavioural advertising, or subject anyone to solely automated decision-making producing legal or similarly significant effects.

5. Security architecture — layered enforcement

Access decisions are made server-side at the edge, before any protected content is retrieved or rendered. No protected resource relies on client-side logic for its protection.

        Request
           │
           ▼
  ┌─────────────────────────────────────────────────────┐
  │ 1. EDGE / TRANSPORT                                 │
  │    TLS in transit · security response headers       │
  │    Bot challenge (Turnstile) on public forms        │
  └────────────────────────┬────────────────────────────┘
                           ▼
  ┌─────────────────────────────────────────────────────┐
  │ 2. SERVER-SIDE AUTHORIZATION MIDDLEWARE             │
  │    Ordered gates · deny-by-default · fail-closed    │
  │    Gated prefixes evaluated BEFORE any allowlist    │
  └────────────────────────┬────────────────────────────┘
                           ▼
  ┌─────────────────────────────────────────────────────┐
  │ 3. IDENTITY VERIFICATION                            │
  │    Gov portal: IP allowlist + TOTP/passkey + HMAC   │
  │    Content tier: access code + server revalidation  │
  │    All comparisons constant-time                    │
  └────────────────────────┬────────────────────────────┘
                           ▼
  ┌──────────────────────────┬──────────────────────────┐
  │ 4a. DATA LAYER           │ 4b. MEDIA LAYER          │
  │  Row-Level Security      │  SHA-256 signed tokens   │
  │  Least-privilege keys    │  Directory-scoped        │
  │  Server-only secrets     │  Time-limited + geo-fence│
  └──────────────────────────┴──────────────────────────┘
                           ▼
  ┌─────────────────────────────────────────────────────┐
  │ 5. AUDIT & DETECTION                                │
  │    Per-access logging · anomaly/sharing detection   │
  └─────────────────────────────────────────────────────┘

5.1 Deny-by-default authorization ordering

Our authorization middleware evaluates gated route prefixes before any static-asset allowlist. This ordering is a deliberate, documented control.

The naive ordering — allowlisting by file extension first — creates a bypass in which a resource inside a protected directory is served unauthenticated purely because of how its filename ends. Our middleware permits requests past the gate based on what the resource is, never on how its name ends. Extension-based pass-through is only reached for paths that have already been proven to fall outside every gated prefix.

5.2 Fail-closed posture

Where an authorization secret is absent or misconfigured, the check returns deny. A missing API key does not degrade to “unauthenticated access permitted.” Absence of configuration is treated as absence of authorization.

5.3 Build-time secret leakage prevention

Server secrets in the government portal are resolved at request time from the platform environment, not through the bundler’s compile-time environment object. This is a specific, verified countermeasure: a dynamic lookup against the build-time environment causes the bundler to inline the entire environment — every secret — verbatim into the emitted server bundle. We resolve secrets through a runtime accessor to prevent this.

5.4 Transport and response headers

The following headers are set on all responses:

6. Government portal — elevated control set

The government evaluation portal enforces materially stronger controls than the general content tier. Reviewers should assess it separately.

7. Media protection

Video assets are not public objects with obscure names. They are cryptographically gated.

• Signed access. Each URL carries a SHA-256 token derived from a server-held key, the scoped path, and the expiry. Unsigned requests are rejected by the CDN with 403 — verified empirically against the production zone for both streaming manifests and direct-download fallbacks.
• Directory-scoped, not file-scoped. One token authorizes a single asset directory. It confers no access to any other asset.
• Time-limited. Tokens expire. A leaked link stops working.
• Optional geographic restriction. Tokens support country allow/deny constraints.
• Anti-hotlinking. A copied URL cannot be embedded elsewhere past expiry.

8. Access control and credential management

9. Attack surface reduction and abuse defence

10. Audit and accountability

• Every authentication event is recorded with credential identity, source IP, user agent, device identifier, and timestamp.
• Every access to a gated page is recorded with the credential, the exact path, source IP, user agent, and timestamp.
• Every authentication failure increments a per-source counter with block state and block timestamp.
• Administrators have a live interface to review blocked sources, associated credential holders, failure counts, and access history, and to reverse a block.

Consequence: access to restricted material is attributable to an individual issued credential, not to an anonymous shared password.

11. Data retention and disposal

An extension applies only where a record is subject to an active security investigation or a legal hold. Extensions are decided by a named individual, not by default.

12. Subprocessors and supply chain

Our production dependencies:

Data residency and international transfers:

• Data residency. The primary compute region is US-based (sfo1). CDN edge nodes are globally distributed by design; media segments and request metadata therefore transit edge locations outside the United States. We cannot currently offer a US-only-infrastructure or in-country deployment guarantee. If your requirement is data residency confined to a single jurisdiction, this architecture does not meet it today and you should raise it before contracting.
• Bunny.net is EU-headquartered (Slovenia). This is relevant to both EU adequacy analysis and to US requirements concerning foreign-controlled providers.
• International transfers rely on Standard Contractual Clauses or equivalent safeguards where applicable.
• We do not consent to subprocessor use of our customers’ data for model training.

We maintain a versioned dependency manifest and can furnish a Software Bill of Materials (SBOM) on request. Dependency installation is gated by an internal review process including a minimum package-age requirement, to reduce exposure to newly published malicious package versions.

13. Incident response

• Triage begins on detection or credible report.
• Containment may include immediate credential revocation, source blocking, and token invalidation — all of which take effect server-side without a client-side dependency.
• Notification: where Chaloot is Controller and an incident is likely to result in a risk to individuals’ rights and freedoms, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, in line with GDPR Article 33. Affected individuals are notified where the risk is high.
• Where Chaloot is Processor, we notify the customer-controller without undue delay so that they can discharge their own notification duties. We do not notify regulators or data subjects on a controller’s behalf unless contractually instructed.
• Post-incident: root-cause analysis, corrective action, and control update.

Report a suspected vulnerability or incident to security@chaloot.com. We do not pursue legal action against good-faith security researchers who report privately, avoid privacy violations and service degradation, and allow reasonable time to remediate before disclosure.

14. Your rights

Where Chaloot is Controller, and subject to your jurisdiction, you may have the right to: access your personal data; correct it; request erasure; restrict or object to processing; receive it in a portable format; withdraw consent; and appeal a decision on your request. Under US state privacy laws you may also have the right to know, to delete, to correct, and to opt out of sale or sharing — noting that we do not sell or share personal data for cross-context behavioural advertising.

We do not discriminate against anyone for exercising these rights.

Requests: privacy@chaloot.com. We respond within 30 days (extendable where permitted, with notice). We may need to verify your identity before acting; the data used for verification is used for that purpose only. You retain the right to complain to your supervisory authority.

15. Changes

Material changes are reflected in the version number above. Where a change affects the rights of identifiable individuals, we notify them where feasible. Prior versions are retained and available on request.

16. Contact

Chaloot Technologies Inc.