A tablet on a shop counter is shared, public, and occasionally offline. Designing for it forced us to rethink what device trust means when the device is not personal.
Ask a security engineer to describe a device and you will usually get something like: a laptop, belonging to a person, in a home or an office, carried by that person, unlocked by that person. Nearly every device-trust model in the industry is built on that picture, and it is a reasonable picture for most software.
It is completely wrong for a shop counter.
The tablet running a register belongs to the business, not a person. Three people will use it today and a fourth will cover the evening shift. It sits on a counter that customers can reach across. It is powered on for fourteen hours and nobody logs out. Its network is a shop router that drops out when the neighbourhood power flickers. And unlike a laptop, if it disappears, nobody notices for hours.
Every one of those facts breaks an assumption that device-based security normally gets for free.
Most systems treat a trusted device as a strong hint about who is using it. On a shared register, that hint is worthless. The terminal can be entirely genuine while the person standing at it is anyone.
So on Enravo Core, those are two different questions with two different answers. The business always knows which terminal a sale came from and which person rang it up. Losing the terminal doesn't tell anyone who was standing at it, and knowing the cashier doesn't mean the terminal is still yours — so neither is allowed to stand in for the other.
Consider the actual scenario: the register is taken overnight. Whoever has it now holds a device the system used to trust, with a screen that is possibly still awake.
The right response has almost nothing to do with passwords. It has to be something a shop owner can do from a phone at eleven at night — not a support ticket. It has to take effect immediately for anything that touches money or customer records. And it must not take the business down with it.
This is where it gets genuinely hard, and where we spent the most time. A register that cannot reach the server still has customers in front of it. Refusing to sell is not a security posture a business will accept; they will simply write the sale on paper, and now you have neither security nor a record.
With Rakton on Enravo Core, a register that loses its connection keeps doing the everyday work of a shop — selling, printing, recording. What it can't do while offline is change who is trusted or what they're allowed to do. When the network returns, everything that happened lands in the books under the same rules it would have faced online.
The principle is that being offline should shrink what a device can do, never what it has to prove.
None of this was written as register code. Shared hardware, safe offline operation, revocation as an owner-facing action — these are properties of Enravo Core, and they exist because building Rakton POS put a real counter in front of an abstract model.
That is the argument for building products on your own platform, made concrete. A shop with one tablet and a busy afternoon asks better questions than a threat model does. If your business runs on shared devices in the field — registers, handhelds, kiosks — talk to us about what device trust looks like when it's built for them.
Platform, güvenlik ve mühendislik üzerine son makaleler.
A platform is a claim until something real runs on it. Rakton is the first product family built on Enravo Core — and building it changed Core more than we expected.
Devamını okuAssembling a stack from best-in-class services is the sensible default. Here is the specific reason we did the unreasonable thing instead — and what it cost.
Devamını okuComponent libraries scale poorly when every product has a different domain. We stopped hand-building admin screens — and started shipping admin panels in days instead of weeks.
Devamını oku