I've been building a small open-source project called FISE, a rule-based "semantic envelope" for web/API data. It's not cryptography and it doesn't try to replace TLS/AES. The goal is to raise the cost of scraping and reverse-engineering client-visible data while keeping the hot path simple and fast (linear-time, parallelizable, works for JSON and media segments).

Key ideas:

- Keyless by design: no long-lived client-side decrypt keys. - Rules-as-code: offsets, length encoding, salt/meta layout, and optional transform are defined as per-app/per-session rules. - No protocol-level universal decoder: each deployment (and even each session/time bucket) can have its own rule family. - Temporal & distribution polymorphism: rotate rules per session/route/time so any decoded pipeline tends to be short-lived and non-reusable. - Simple local ops → emergent complexity: the core ops are just linear byte transforms, but the rule space and rotation make envelopes hard to generalize at scale. - Works for JSON and media (video segments) with framed/chunked mode, block-local decode, and parallel workers.

Threat model:

- In scope: automated scraping, bulk API harvesting, cheap cloning of curated datasets. - Out of scope: strong secrecy for secrets/PII (use TLS/AES/etc.), full client compromise, nation-state adversaries.

Engineering whitepaper (v1.0): - https://github.com/anbkit/fise/blob/main/docs/WHITEPAPER.md

Code: - https://github.com/anbkit/fise

Demo: - https://demo.fise.dev/demo

I'm a full-stack developer, not a cryptographer. FISE came out of working on real projects where API JSON data was exposed on the client side and could be easily scraped. I built it as a simple, rule-based layer to raise scraping cost, and I'm sharing it so others can review, critique, and improve it.

I'd love feedback on:

- The security model & threat boundaries (what did I miss?), - The "rules-as-code" design and the idea of temporal/distribution polymorphism, - Practical deployment concerns (CDN/normalization, mobile/TV/edge), - Any obvious pitfalls or prior art I should explicitly reference.

Thanks for taking a look.