Privacy & Data Handling

Flagpool SDKs evaluate flags locally. Evaluation context is supplied to the SDK and is not part of its flag-fetch request; enabled analytics and the rest of your application still need their own data-flow review.

Local evaluation and data flows

Unlike remote evaluation services, Flagpool SDKs evaluate downloaded flag configuration locally:

Traditional approach:               Flagpool approach:
─────────────────────               ──────────────────
Your App → sends evaluation context →  Your App → evaluates locally
Remote Server → returns result         Context is not part of the SDK flag request

What the SDK sends to Flagpool

• The SDK is configured with an environment-specific SDK API key. Browser applications expose this configuration to their users.
• Flag downloads use a URL derived from the project ID and decryption key; depending on SDK and enabled features, the SDK API key is used for optional analytics or streaming requests.
• Flag evaluation counts may be sent only if analytics is explicitly enabled (opt-in).

What is not included in SDK flag-evaluation requests

• User IDs, emails, names, or context attributes supplied to the local evaluator.
• Application data or business logic.

How it works

1. Flag configurations are exported to the CDN as a JSON payload.
2. The SDK downloads configuration and evaluates flags against the application-supplied context locally.
3. When enabled, the exported target-list object is AES-256-GCM encrypted; flag definitions and targeting rules remain readable.
4. A client that has the decryption key can decrypt and inspect target-list values. Browser delivery is not a confidentiality boundary.

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   Flagpool   │  Flag   │     SDK      │  Local  │    Your      │
│     CDN      │  config │   (Cached)   │  eval   │ Application  │
└──────────────┘ ──────▶ └──────────────┘ ──────▶ └──────────────┘
                                                          ↑
                                               User data stays here

Target-list encryption

Target lists may contain email addresses, user IDs, account identifiers, or other potentially sensitive values. Encrypting target-list values in exported payloads reduces casual or accidental disclosure if an export is inspected, cached, copied, downloaded, or shared. It does not hide the lists from a browser user when the browser receives the key and evaluates membership.

Only the target-list object is encrypted—not flag configuration or targeting rules. SDK caches also differ; do not assume all caches, browser storage, or logs stay encrypted. If membership must remain confidential from end users, evaluate on a server and keep both the decryption key and plaintext target lists out of browser-delivered code and data. Feature flags and target-list rules are not authorization controls; enforce access permissions and entitlements on the server.

Encryption can be one part of a privacy or security review, but encryption alone does not guarantee GDPR compliance or satisfy any particular regulatory requirement.

Data encryption at every layer

Comparison with remote evaluation

Next steps

• Security Overview — full security model including API keys and audit logging
• Crypto adapter guide — encrypted target-list contract and SDK-specific setup
• Access Control — roles, permissions, and team management
• Architecture & Performance — CDN and caching architecture