ChronoSeal v1.0.2 – Security Hardening & Runtime Improvements

ChronoSeal v1.0.2

Overview

ChronoSeal v1.0.2 focuses on security hardening, runtime reliability, validation improvements, and deployment safety. This release strengthens protocol validation, reduces panic paths, improves concurrency handling, and hardens both frontend and backend components while maintaining full protocol compatibility.

Highlights

Security Hardening

• Added security response headers:

  • Content-Security-Policy (CSP)
  • X-Content-Type-Options
  • X-Frame-Options
  • Referrer-Policy
  • Permissions-Policy

• Added request body size limits to reduce abuse potential.

• Improved fingerprint validation and input sanitization.

• Added additional protocol validation checks across server and shared components.

• Reduced panic paths in hashing, storage, and WASM-related code.

Fingerprint Validation

Fingerprint validation has been significantly strengthened:

• Added explicit bounds validation for:

  • Aspect ratio
  • Device pixel ratio (DPR)
  • Hardware concurrency

• Rejects:

  • NaN values
  • Infinite values
  • Malformed numeric strings
  • Zero or negative DPR values
  • Invalid aspect ratios
  • Hardware concurrency values outside the supported range

• Documented hardwareConcurrency range as 1..=256.

Runtime & Performance

• Replaced rate-limiter internal storage with DashMap for improved concurrent access.
• Removed unnecessary synchronization bottlenecks.
• Improved cleanup task efficiency.
• Added stack depth limits to the shared VM implementation.
• Improved mutation and VM safety checks.

Frontend Hardening

• Added CSP meta tag as defense-in-depth.
• Reduced protocol-state exposure through browser console logging.
• Added favicon assets.
• Minor frontend cleanup and reliability improvements.

Deployment Improvements

• Docker containers now run as a dedicated non-root user.
• Improved container health checks.
• Updated systemd service configuration.
• Improved development scripts with stricter shell execution settings.

Reliability Improvements

• Hardened storage handling.
• Improved configuration validation.
• Improved error handling paths.
• Improved WASM-side resilience to malformed data.
• Additional protocol validation safeguards.

Testing

All server tests pass successfully:

• Fingerprint validation tests: 5/5 passed
• Full server test suite: 38/38 passed

Verified with:

cargo check -p chronoseal-server
cargo test -p chronoseal-server fingerprint
cargo test -p chronoseal-server

Compatibility

• No protocol-breaking changes.
• Existing clients remain compatible.
• Existing configuration files remain compatible.
• No database migration required.

Notes

This release is focused on hardening and stability rather than introducing new user-facing features. It serves as a foundation for future protocol and platform enhancements while preserving ChronoSeal's core design principles.

ChronoSeal v1.0.1 - CI & Property Testing Fixes

ChronoSeal v1.0.1

Fixes:

• Added missing proptest development dependency for shared property tests.
• Restored GitHub Actions CI compatibility.
• Verified successful execution of workspace unit tests and property tests.

No protocol changes.
No API changes.
No behavioral changes.

Protocol Compatibility: v1

ChronoSeal v1.0.0 - Protocol Freeze & Audit Readiness

ChronoSeal v1.0.0 - Protocol Freeze & Audit Readiness

ChronoSeal v1.0.0 marks the first stable protocol release of ChronoSeal as a daemon-first browser attestation service.

This release completes the v1 hardening cycle, introduces protocol stability guarantees, adds black-box replay testing, fuzzing infrastructure, operational documentation, and establishes the long-term public contract for third-party integrations.

ChronoSeal is designed as a first-class Unix daemon.

The supported integration surface is the ChronoSeal protocol and REST API. Internal implementation details remain private and may evolve independently.

---

Highlights

Protocol Stability

The ChronoSeal protocol has been formalized and documented.

Added:

• docs/PROTOCOL.md
• docs/PROTOCOL_STABILITY.md
• docs/WRAPPER_GUIDE.md

The following surfaces are now considered part of the public contract:

• /init
• /hb
• JSON request/response schemas
• VM opcode semantics
• Mutation commitment rules
• Hash-chain progression rules

Third-party wrappers should depend only on documented protocol behavior and REST APIs.

---

Black-Box Replay Testing

Introduced:

chronoseal-replay

A standalone protocol validation utility that interacts with a running chronoseald instance exclusively through the public REST API.

Supported validation scenarios include:

• Valid session progression
• Replay attack rejection
• Invalid signatures
• Invalid VM execution traces
• Invalid mutation commitments
• Timestamp drift validation
• Concurrent heartbeat handling
• Rate-limiter verification

This tool enables deterministic protocol validation and regression testing without exposing internal implementation details.

---

Fuzz Testing Infrastructure

Added a dedicated fuzzing workspace:

fuzz/

Current fuzz targets:

• VM execution engine
• Environment decoder
• Protocol parsing and validation

The fuzzing framework is built using:

cargo-fuzz
libfuzzer-sys

and is intended to support long-running adversarial testing and future CI integration.

---

Property-Based Testing

Added property-based testing coverage for:

• VM execution stability
• Environment decoding robustness

Randomized testing validates that core deterministic components remain panic-free across arbitrary inputs.

---

Documentation

Added:

• docs/OPERATIONS.md
• docs/SECURITY_ASSUMPTIONS.md
• docs/WHY_IT_FAILS.md
• docs/PROTOCOL.md
• docs/PROTOCOL_STABILITY.md
• docs/WRAPPER_GUIDE.md

These documents define:

• Protocol behavior
• Operational deployment guidance
• Security boundaries
• Failure analysis
• Wrapper development guidance
• Long-term protocol compatibility expectations

---

Security & Reliability Hardening

Implemented:

• Server-side VM verification
• Session-state concurrency protection (CAS)
• Replay validation improvements
• Protocol verification enhancements
• Storage scalability improvements
• Improved observability and metrics support

The protocol now enforces:

• Stateful progression
• Mutation verification
• VM execution verification
• Replay resistance
• Concurrent update protection

---

Architecture

ChronoSeal remains intentionally:

• Daemon-first
• Protocol-first
• API-first
• Unix-first

ChronoSeal is not:

• A Rust SDK
• An embeddable library
• A framework

The intended deployment model remains:

chronoseald
      ↓
REST API
      ↓
Applications / Wrappers

This release formalizes that philosophy and freezes the protocol rather than internal implementation details.

---

New Components

Added

• chronoseal-replay/
• fuzz/
• docs/OPERATIONS.md
• docs/PROTOCOL.md
• docs/PROTOCOL_STABILITY.md
• docs/SECURITY_ASSUMPTIONS.md
• docs/WHY_IT_FAILS.md
• docs/WRAPPER_GUIDE.md

Updated

• shared/src/vm.rs
• shared/tests/

---

Upgrade Notes

This release introduces protocol stability guarantees for future wrapper and integration development.

Consumers should rely exclusively on:

• Documented protocol behavior
• Documented REST APIs
• Published protocol specifications

Internal implementation details remain subject to change.

---

Looking Ahead

Post-v1.0 development will focus on:

• Long-running fuzzing
• External security review
• Protocol validation
• Performance improvements
• Operational tooling
• Additional observability

without breaking the public protocol contract.

---

Version: v1.0.0

Status: Stable Protocol Release

Project Type: Daemon-first Browser Attestation Service

Compatibility: Protocol v1

v0.6.1

ChronoSeal v0.6.1 — Refactoring and System Upgrade

ChronoSeal v0.6.0 is a major architecture and protocol update that transforms the project from a lightweight heartbeat service into a mature Unix-native attestation daemon with deterministic mutation parity and pluggable storage backends.

Summary of Changes

• Introduced the Synthetic Gene Mutation Engine for deterministic mutation parity across server and WASM.
• Added server-side validation of mutation_step and gene_commitment.
• Centralized shared protocol logic in shared/ for server/WASM parity.
• Added support for multiple storage backend modes: sqlite-in-memory, sqlite-disk, and valkey compatibility.
• Hardened runtime architecture with systemd readiness, graceful shutdown, PID file support, and structured logging.
• Expanded CLI with rich subcommands and effective runtime configuration.
• Preserved silent rejection semantics while improving anti-replay and liveness guarantees.

Why This Refactor?

The previous model relied on heartbeat continuity and behavioral entropy alone. v0.6.0 strengthens the protocol by adding a second, deterministic state progression channel:

• each heartbeat now includes a mutation step and commitment
• the server authoritatively selects the next mutation program
• the client must preview and commit the same state locally in WASM
• the server rejects any mismatch silently

This raises the cost of developing a successful automation attack because the attacker must now maintain both a valid chain and a valid mutation progression state.

Core Architecture Changes

Shared Protocol Code

shared/ now contains:

• gene model and commitment hashing
• mutation opcode semantics
• request/response payload structures
• canonical signing support
• VM execution logic shared by server and WASM

Moving mutation semantics into shared/ eliminates subtle server/client divergence bugs and enables deterministic cross-runtime testing.

Mutation Handshake

v0.6.0 adds the following data to the protocol:

• mutation_step
• mutation_order_b64
• gene_commitment
• next_mutation_step
• next_mutation_order_b64

These fields are now part of the session initialization and heartbeat exchange.

Server Session State

The session schema now stores:

• committed gene bytes
• committed environment records
• pending mutation order
• pending mutation step

The server advances this state only after a heartbeat is accepted.

Deterministic WASM Preview

The WASM runtime exposes:

• init_gene_state()
• preview_gene_commitment()
• commit_gene_preview()
• discard_gene_preview()
• current_gene_commitment()

This makes the client-side mutation lifecycle explicit and deterministic.

Backend Abstraction

The server runtime now supports a configurable db_type.

• sqlite-in-memory — default runtime storage with ephemeral session semantics
• sqlite-disk — persistent SQLite storage for stateful deployments
• valkey — compatibility mode for alternative storage backends

This abstraction makes ChronoSeal easier to operate in both stateless and stateful environments.

CLI and Service Integration

v0.6.0 improves the CLI surface with operational commands and service introspection.

• chronoseal run
• chronoseal status
• chronoseal health
• chronoseal config
• chronoseal metrics
• chronoseal stats
• chronoseal db-type
• chronoseal completion
• chronoseal version

The runtime now includes PID file handling and graceful termination.

Testing and Validation

The refactor includes extensive tests for:

• server/WASM parity across mutation sequences
• malformed mutation payload rejection
• replay attack rejection
• mutation step mismatch rejection
• stateful session update semantics
• runtime database mode validation

The codebase now supports deterministic table-driven tests and fuzz-style random program validation.

Operational Impact

This release makes ChronoSeal suitable for production deployment in Linux environments and for integration into existing web application stacks.

The combination of deterministic mutation parity and shared protocol implementation improves both security and maintainability.

v0.6.0 — Synthetic Gene Mutation System: Evolving Cryptographic Attestation

[0.6.0] - 2026-05-29

Major Feature: Synthetic Gene Mutation System

Introduced a powerful new Synthetic Gene Mutation layer that significantly raises the bar for scrapers, headless browsers, and automated clients.

This system creates a persistent, evolving shared secret state (the "gene") that both client and server mutate in lockstep with every heartbeat, making faithful emulation extremely difficult without running the exact WASM environment.

Key Highlights

• Hybrid Lightweight Gene Model:

  • Primary gene: Vec<u8> (configurable 256–1024 bytes, default 512) representing synthetic DNA.
  • Secondary environment: Bounded record multiset Vec<(u16 symbol, u32 quantity)> (max 48 records) for lightweight Cytosol-inspired reactions.

• Server-Driven Mutation Orders:

  • Server issues compact mutation programs each heartbeat.
  • Client applies mutations to gene + environment in WASM.
  • Resulting gene state is cryptographically bound into the Blake3 hash chain.

• New Stack Machine Opcodes:

  • GENE_LOAD, GENE_STORE
  • MUTATE_POINT, INSERT, DELETE
  • TRANSCRIBE, APPLY_MUTAGEN
  • CONSUME, PRODUCE
  • FINALIZE_GENE_HASH
  • (Full list and semantics in docs/REFRACTORING-v0.6.0.md)

Architectural Improvements

• Shared gene logic between server and WASM client via shared crate for perfect determinism.
• Feature flag gene_mutations (disabled by default for smooth migration).
• Efficient in-memory gene handling with minimal performance impact.
• Full backward compatibility — sessions can still run in classic mode.

Security Enhancements

• Evolving shared secret state that diverges rapidly if not correctly executed.
• Stronger binding between browser environment and attestation.
• Improved resistance to replay, cloning, and partial emulation attacks.
• Maintained strict privacy model (ephemeral sessions only).

Testing & Reliability

• Comprehensive test suite including server-client parity tests.
• Property-based and edge-case testing for mutations.
• Multi-heartbeat chain simulation tests.
• Evasion resistance validation.

Performance

• Heartbeat overhead kept under target (<30ms on typical hardware).
• Minimal increase in WASM binary size.
• Efficient serialization and bounded data structures.

Documentation

• Complete refactoring document: docs/REFRACTORING-v0.6.0.md
• Updated architecture diagrams and opcode reference (forthcoming).

This release marks a significant evolution in ChronoSeal’s anti-automation capabilities while preserving its core values of lightness, privacy, and maintainability.

---

Ready to paste into your CHANGELOG.md.

Would you like a shorter GitHub Releases version, or should I also generate the matching README.md feature section?

ChronoSeal v0.5.1 — Architectural Cleanup & Privacy Hardening

ChronoSeal v0.5.1

Focused maintenance and architectural cleanup release improving:

• code structure
• session handling
• runtime maintainability
• and privacy-oriented internals

---

Highlights

Duplicate Code Refactoring

Significant internal restructuring performed to eliminate duplicated logic across:

• session lifecycle handling
• cleanup routines
• heartbeat processing
• initialization flows

This improves:

• maintainability
• code clarity
• consistency
• long-term operational reliability

Refactoring commit:

• 217dc5f92b905addf77e7e57126059be0740cb1c

---

Privacy-First Runtime Model

ChronoSeal continues to maintain its strict privacy-first design:

The framework intentionally does NOT store:

• IP addresses
• persistent fingerprints
• user profiles
• telemetry
• browser history
• long-term behavioral data

ChronoSeal verifies:

• session continuity
• cryptographic synchronization
• runtime coherence

without turning users into telemetry.

---

Lightweight Runtime

Server Binary

• ~8.4 MB (x86_64 Linux release build)

WASM Runtime

• chronoseal_wasm_bg.wasm
• ~218 KB

Full WASM Package

• ~720 KB total

Includes:

• WebAssembly runtime
• JavaScript glue
• TypeScript definitions

---

Unix-Native Design

ChronoSeal remains intentionally:

• lightweight
• dependency-minimal
• CLI-first
• systemd-native
• operationally transparent

No dependency on:

• React
• Angular
• Electron
• Node.js runtime
• frontend framework ecosystems

---

Repository Hygiene

Generated artefacts remain excluded from version control:

Path	Reason
wasm/pkg/	Generated WASM build output
frontend/pkg/	Generated frontend artefacts
target/	Standard Rust build artefacts

Build outputs are reproducible directly from source.

---

Runtime Improvements

• Improved internal cleanup logic
• Better session lifecycle consistency
• Reduced duplicated code paths
• Cleaner route handling
• Improved maintainability for future development

---

Philosophy

ChronoSeal is designed to prove:

“A live browser session is coherently participating right now.”

without storing:

• identity
• telemetry
• long-term history
• or surveillance-oriented client data

---

Project Status

Core architecture completed:

• Rust server runtime
• WASM attestation runtime
• cryptographic heartbeat chain
• privacy-first session model
• systemd integration
• Unix-native operational model

Active development continues on:

• CLI tooling
• runtime configuration
• deployment tooling
• operational hardening

ChronoSeal v0.5.0 - Production Architecture Refactor

ChronoSeal v0.5.0

Production Architecture Refactor

This release represents the most significant internal evolution of ChronoSeal so far.

ChronoSeal has undergone a rigorous architectural refactor focused on runtime modularity, operational resilience, configuration flexibility, daemon lifecycle management, and long-term maintainability.

The project now transitions beyond an experimental anti-automation prototype into a structured cryptographic attestation runtime designed for production-oriented deployment models.

---

Major Architectural Changes

Dynamic Runtime Configuration

• Refactored daemon configuration architecture
• Runtime-configurable heartbeat intervals
• Improved deployment flexibility
• Cleaner environment and configuration handling

Database & Concurrency Refactor

• Migrated SQLite handling toward pooled connection architecture
• Added r2d2 + r2d2_sqlite
• Reduced serialized database contention
• Improved concurrent runtime scalability

Structured Error Handling

• Added unified custom error architecture using thiserror
• Improved failure boundary clarity
• Cleaner operational diagnostics
• Better runtime observability

CLI & Operational Tooling

ChronoSeal now includes significantly expanded daemon tooling:

• chronoseal run
• chronoseal status
• chronoseal health
• chronoseal metrics
• chronoseal stats
• chronoseal config check
• chronoseal generate keypair
• shell completion generation

This release substantially improves operational ergonomics for administrators and deployments.

WASM Runtime Improvements

• Renamed WASM runtime package from antibot_wasm to chronoseal_wasm
• Improved runtime identity consistency
• Cleaner frontend/runtime integration
• Refined heartbeat scheduling model

Cleanup & Runtime Lifecycle

• Refactored cleanup subsystem
• Improved stale entry eviction handling
• Runtime-aware rate-limit cleanup
• Better lifecycle isolation

---

Internal Refactor Scope

• 33 files changed

• ~1200 lines added

• Extensive subsystem restructuring

• Protocol/runtime separation improvements

• Better module organization across:

  • server
  • shared
  • wasm
  • frontend

Lightweight Runtime Footprint

ChronoSeal continues prioritizing lean operational deployment and low runtime overhead.

Current release artifacts:

chronoseal            ~8.5 MB
chronoseal_wasm.wasm ~719 KB

Despite substantial architectural expansion, the runtime remains compact while including:

• daemon lifecycle management
• SQLite persistence
• pooled database handling
• Prometheus metrics
• structured CLI tooling
• cryptographic attestation runtime
• WASM execution environment
• behavioral continuity validation

ChronoSeal intentionally avoids:

• heavyweight frontend frameworks
• Electron-style packaging
• excessive runtime dependencies
• telemetry-heavy infrastructure
• bloated deployment models

The project remains optimized for:

• edge deployments
• lightweight containers
• low-resource systems
• self-hosted environments
• Unix-native operational workflows

---

Design Direction

ChronoSeal continues focusing on:

• privacy-preserving attestation
• ephemeral proof-of-presence
• behavioral continuity validation
• cryptographic runtime integrity
• automation cost escalation

while intentionally avoiding:

• invasive fingerprinting
• CAPTCHA dependency
• persistent tracking
• surveillance telemetry

---

Build

WASM

wasm-pack build wasm --target web --release
mv wasm/pkg frontend/pkg

Server

cargo build --release

Docker

docker compose up -d --build

---

Repository

GitHub:
https://github.com/thakares/chronoseal-rs

---

License

Dual licensed under:

• Apache-2.0
• MIT

ChronoSeal v0.3.0

ChronoSeal v0.3.0

ChronoSeal continues evolving as a lightweight, privacy-first browser attestation framework focused on raising the operational cost of AI-driven automation, scripted abuse, and stealth browser impersonation — without degrading legitimate user experience.

This release strengthens architectural clarity, deployment usability, runtime configuration, and overall project maturity.

---

Highlights

Privacy-First Design Expansion

• Expanded design philosophy documentation
• Improved explanation of behavioral continuity verification
• Refined threat-model documentation
• Clearer separation between anti-automation goals and invasive fingerprinting

Runtime & Configuration Improvements

• Added CLI configuration and runtime management support
• Improved deployment flexibility for self-hosted environments
• Better operational control for native and containerized deployments

Documentation Enhancements

• Expanded architecture documentation
• Improved security model explanations
• Refined developer onboarding material
• Better deployment and integration guidance

Infrastructure & Build

• Improved project structure consistency
• Updated CI workflow organization
• Better Docker and system deployment readiness

---

Security Notes

ChronoSeal remains intentionally:

• Stateless from a long-term tracking perspective
• Ephemeral by design
• Privacy-preserving
• CAPTCHA-free
• Non-invasive

The framework focuses on behavioral continuity and cryptographic proof-of-presence rather than persistent identity tracking.

---

Build Requirements

Rust

• Rust stable ≥ 1.87

WASM Toolchain

cargo install wasm-pack

---

Build Instructions

Build WASM Client

wasm-pack build wasm --target web --release
mv wasm/pkg frontend/pkg

Build Server

cargo build -p server --release

Development Mode

bash scripts/dev.sh

Docker Deployment

docker compose up -d --build

---

Included Components

• Rust Axum server
• WASM cryptographic client
• Behavioral entropy verification
• Blake3 chained attestations
• Ed25519 signing
• Stack-machine execution engine
• SQLite in-memory session engine

---

Known Philosophy

ChronoSeal is designed to:

• Raise scraping costs
• Increase automation complexity
• Preserve user privacy
• Remain invisible to legitimate users

It is not intended to become a surveillance framework, invasive fingerprinting platform, or CAPTCHA ecosystem.

---

Repository

GitHub:
https://github.com/thakares/chronoseal-rs

---

License

Dual licensed under:

• Apache-2.0
• MIT

Full Changelog: v0.2.0...v0.3.0

ChronoSeal v0.2.0 — Security Audit & Refactor

ChronoSeal v0.2.0

This release resolves seven bugs identified in a full security audit of v0.1.0,
two of which rendered the core cryptographic protocol non-functional as shipped.

---

Critical Fixes

Signature verification was always failing silently
server/src/crypto.rs reconstructed the canonical signing payload using
serde_json::json!({}) which preserves insertion order, while the JS client
used JSON.stringify(obj, Object.keys(obj).sort()) which sorts alphabetically.
The two strings were never equal. Every heartbeat was silently rejected.
Fixed by building the server-side payload with BTreeMap, which serialises
keys in the same alphabetical order the client produces.

Hash chain broke after the first heartbeat
frontend/heartbeat.js updated currentSalt to next_salt before computing
the new prevHash, so the client and server derived the next hash using
different salts. The chain was permanently broken after heartbeat 1.
Fixed by capturing sentSalt = currentSalt before rotation and computing
prevHash with the captured value.

---

High Severity Fixes

Mouse speed validation always rejected legitimate users
server/src/trust.rs computed avg_speed = total_dist / events.len()
(distance per event count), not distance per unit time. A user moving 300 px
across 10 captured events produced avg = 30.0, far above the 2.0 px/ms
ceiling. Fixed to total_dist / total_time_ms.

Rate limiter HashMap was unbounded
server/src/ratelimit.rs never evicted expired entries. Flooding with unique
session IDs caused unlimited memory growth. Added evict_stale() called from
the periodic cleanup loop every 60 seconds.

---

Medium Severity Fixes

VM generator misclassified NOT (0x08) as a binary op
server/src/vm.rs decremented stack depth for opcode 0x08 (unary NOT),
causing the generator to emit unnecessary PUSH instructions and produce
stunted programs. Fixed by splitting 0x08 into its own match arm with no
depth change.

WASM crypto functions panicked on uninitialised keypair
wasm/src/crypto.rs called .unwrap() on the thread_local keypair in
sign_message and get_public_key. Calling either before generate_keypair()
crashed the WASM module with no recoverable error. Replaced with
.unwrap_or_default() and added a JS-side guard in heartbeat.js.

---

Low Severity Fixes

• Dockerfile: rust:1.88-bookworm → rust:1.87-bookworm (1.88 does not exist)
• shared/Cargo.toml, wasm/Cargo.toml: removed leftover # add this comments

---

Compatibility

No API or protocol changes. Drop-in replacement for v0.1.0.
Recompile server and rebuild WASM (wasm-pack build wasm --target web --release).