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.