How Croftry works
Clear boundaries make software easier to trust.
Croftry gives every app only the capabilities it declares, then tells you how far its data can reach.
Software is becoming personal: easier to make for one need, and easier to share when that same need belongs to someone else. Sharing it responsibly takes more than a maker’s promise. The software itself needs boundaries.
Every app starts sealed.
An ordinary web page can use many browser features by default. A Croftry app cannot. It runs as a sealed Keel or WebAssembly guest, without direct access to the browser’s network, sockets, page, or peer-to-peer connections. To do something outside its own computation, it must ask the Croftry host.
An app gets only what it names.
Before an app can be deployed, its maker lists the capabilities it needs: perhaps a file chosen by you, the camera, local storage, an account field, or a connection to a named service. Croftry validates that list at publication and exposes only those capabilities at runtime. Undeclared access is absent, not merely hidden.
When a capability needs your participation, the permission is shown separately. The mark comes from the shipped app and its enforced capability list—not from the maker’s description.
A boundary is useful only when you can see where it ends.
One mark answers one question.
Croftry’s marks describe the widest path available to app-readable data. They do not score whether an app is clever, well made, or right for you.
Mark A
Readable data stays on this device.
Local files, the clipboard, camera and microphone, local computation, and device storage can all be used without creating a readable external data path. Encrypted sync may move ciphertext, but its readable form stays local. Each local permission still applies.
Mark B
External exchange follows a controlled path.
Data may leave the device, but the app cannot bypass Croftry’s boundary. The destination and operation are declared for your approval. Croftry can inspect the exact content the app sends and receives at that boundary, and the exchange can leave an audit record.
Mark C
The data path cannot be fully verified.
A capability that Croftry cannot make transparent and auditable falls back to Mark C. It may still be useful; the yellow mark makes the limit clear.
The broadest boundary determines the mark. A local photo editor remains Mark A while its work stays on the device. Add an approved online service and it becomes Mark B. If Croftry cannot verify the resulting path, it becomes Mark C.
Local does not mean harmless.
A local app can still read a sensitive file, use a camera, consume substantial compute, or simply contain a bug. Croftry handles those concerns with specific permission prompts, resource limits, review, reporting, and removal. Keeping them separate lets the mark make one precise promise about where data can go.
Transparency is still being built out.
Today, Croftry records the capability or destination, operation, time, and outcome for supported external paths. A unified Console view of complete exchange content is still in development. Until that is ready, Croftry describes what the boundary can enforce without claiming more than users can inspect today.