Skip to content

Profiles and Persona Materialization

STATIC is profile-driven through startup, validation, transport shaping, and the injected JavaScript layer.

What a profile defines

  • Identity metadata such as family, variant, and platform
  • Header shaping rules
  • JavaScript fingerprint configuration applied during injection
  • TLS and HTTP/2 behavior hints
  • Seeded overlay choices that materialize into one concrete persona for the lifetime of the process

Profile families

The shipped profile set is organized around browser families and discourages cross-engine spoofing.

Best practice:

  • Chromium-family browsers should use Blink-family profiles
  • Firefox-family browsers should use Gecko-family profiles

Neither STATIC nor the Rose base enforces this policy.

Startup rules

Proxy mode does not silently start in an ambiguous state anymore.

The active profile must come from one of these places:

  • --profile <name>
  • pipeline.default_profile in config

If neither exists, STATIC will not run.

Shared profile state

STATIC loads one shared ProfileStore and uses it in both the data plane and the localhost control plane.

That is what makes profile reads and profile selection changes coherent.

Without that shared in-memory state, the control plane and proxy pipeline drift apart.

Seeded overlays

Some profiles contain seeded_overlays.

Those overlays give STATIC:

  • Stable per-process identity
  • Internally consistent high-entropy values
  • Rotation on restart instead of noisy within-session drift

Control plane

The catalog endpoints expose profile metadata suitable for higher-level clients:

  • Key
  • Display name
  • Family
  • Variant
  • Platform