Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
We Eliminated Local Execution on User Devices – By Architecture
1 point by MOHDLZE 35 days ago | hide | past | favorite | 4 comments
We Didn’t Secure Local Execution. We Eliminated It.

Most systems still assume this premise is unavoidable: User devices must execute code.

Everything else follows from that assumption: sandboxes, secure enclaves, SDKs, hardening, policies.

We rejected the premise itself.

Execution is not a feature. Execution is the attack surface.

So we removed local execution from user devices — architecturally.

No runtime. No SDK. No application logic. No execution state.

The device becomes a User Gateway only: • captures raw input (touch, text, voice, camera) • renders non-executable interface data • produces cryptographic proof that zero local execution occurred

All execution happens 100% inside the cloud.

If execution does not traverse a sovereign execution path, it is treated as non-existent — not denied, not blocked, not sandboxed. It simply does not exist.

This is not: • Remote Desktop • Secure Execution • Trusted Enclaves • Policy Enforcement

All of those still assume local execution must exist.

We removed that assumption.

What this enables (as a consequence, not a goal): • A Cloud Store with no app downloads • A Cloud Wallet with no cards or keys on the device • Provable execution sovereignty for banks, governments, and regulated systems

Covered by a filed U.S. patent application.

Open question for discussion: If execution is the real attack surface, why do we still allow it to exist on user devices at all?



> If execution is the real attack surface, why do we still allow it to exist on user devices at all?

A device that relies on external services to operate (outside of specialized devices such as communications) is one that is not suitable for any use case I have. There's far too much exposure to risk involved. Privacy and security risks, outage risks, risks of the service being discontinued, risks of having the provider get mad at and shutting you out, etc. You'd be at the mercy of the provider in terms of them changing things up on a whim or according to the current fad. It would require internet service, which is problematic in a lot of use cases. Also, presumably, the service would require regular ongoing payments.

For me, this idea is a complete nonstarter.


‘Access’ that can be permanently revoked for arbitrary and capricious reasons is of intrinsically limited value. Ppl don’t invest deeply in those places, they just sh!tpost there.

You can build an impenetrable walled garden you think is beautiful. You can’t force anyone else to live there.


We eliminated local execution on user devices — not by restriction, but by architectural removal.

Most security models try to control local execution: sandboxes, secure enclaves, SDKs, policies.

We removed the execution surface itself.

No runtime. No SDK. No application logic on the device.

The device becomes a User Gateway only: raw input in, non-executable interface out, plus cryptographic proof that Zero Local Execution on Device actually holds.

All execution happens 100% in the cloud. If execution leaves the sovereign execution path, it is considered non-existent.

This is not Remote Desktop. Not VDI. Not secure execution. Those still assume local execution exists.

Covered by a filed U.S. patent application.

Open question for engineers here: If execution is the real attack surface, why are we still allowing it to exist on user devices at all?


Copy pasting the post without adding anything does not add to the conversation. Please pay attention to the guidelines: https://news.ycombinator.com/newsguidelines.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: