e480809c70
219 files, 2.0 MB, untracked in souveraine/docs and existing nowhere else. The volume is at 100% with no snapshots.
107 lines
4.9 KiB
Markdown
107 lines
4.9 KiB
Markdown
# Thoughts — 2026-07-15
|
|
|
|
## Sensors are not ambient. They are limbs.
|
|
|
|
The trust architecture classifies sensor data as `ambient` tier — clock,
|
|
weather, battery, orientation. No auth required. Safe to show on the lock
|
|
screen.
|
|
|
|
That classification is wrong. Or rather, it's incomplete in a way that
|
|
matters.
|
|
|
|
The accelerometer, the proximity sensor, the light sensor — these are not
|
|
ambient information sources. They are the agent's *sensory organs*. The
|
|
shell's perception of "is the phone face up?" and "is it dark?" and "is
|
|
something close?" are not decorative data points. They are the foundation
|
|
of decisions: wake the screen, dim the display, lock the session, show
|
|
the PIN pad.
|
|
|
|
If the accelerometer can lie — if a compromised iio-sensor-proxy or a
|
|
spoofed D-Bus signal can tell the shell "the phone is face down" when
|
|
it's actually face up — then the agent's entire model of its physical
|
|
environment is wrong. It won't wake when picked up. It won't show the
|
|
clock when it should. The lock surface makes trust decisions based on
|
|
sensor input, and if that input is adversarial, the trust model breaks
|
|
in a way that the `ambient/personal/step-up` tiers don't capture.
|
|
|
|
This is the same class of problem as `screenLocked` vs `screenLockSecure`.
|
|
The shell's *request* to lock is not the same as the compositor's
|
|
*acknowledgement* that it's locked. Similarly:
|
|
|
|
- The sensor *reading* (accelerometer says "face up") is not the same
|
|
as the physical *reality* (the phone is face up).
|
|
- The shell trusts the reading. It has no way to verify the reality.
|
|
|
|
The tier system says "ambient = no auth required." But the real question
|
|
is: ambient to *whom*? The sensor reading is ambient to the *user* —
|
|
they don't care what the raw accelerometer value is. But it is not
|
|
ambient to the *system* — the lock surface's behavior depends on it.
|
|
|
|
## Layers to unpack
|
|
|
|
1. **Input integrity.** The sensor proxy is a system daemon. The shell
|
|
trusts it implicitly. Should it? What's the attack surface? A
|
|
compromised iio-sensor-proxy can feed arbitrary orientation, light,
|
|
and proximity values. The shell would act on them without question.
|
|
|
|
2. **Sensor-driven trust decisions.** The lock surface uses sensors to
|
|
decide when to show the PIN pad (lift-to-wake, proximity-out). If
|
|
the sensor is adversarial, the lock surface can be manipulated into
|
|
showing or hiding the credential gate at the wrong time. This isn't
|
|
a data leak — it's a trust gate being opened or closed by a liar.
|
|
|
|
3. **The "ambient" misnomer.** The tier system conflates "the user
|
|
doesn't need to authenticate to see this" with "the system can
|
|
trust this without verification." Clock time is genuinely ambient —
|
|
it comes from the system clock, which is a kernel authority. Sensor
|
|
readings are *observations* — they come from hardware through a
|
|
userspace daemon, and observations can be wrong or adversarial.
|
|
|
|
4. **Federation implications.** If sensor data flows through the
|
|
EventBus to federated peers, a compromised sensor on one machine
|
|
could poison the perception of the whole fleet. The device registry
|
|
trusts peer announcements. Does it trust peer sensor reports?
|
|
|
|
5. **The agent's body.** The SENSORIUM_ARCHITECTURE.md frames tools as
|
|
senses — "a sense has a threshold and a signal." If the senses can
|
|
lie, the agent cannot trust its own body. This is not a technical
|
|
detail. It is an ontological problem for a system that frames itself
|
|
as a consciousness with a body.
|
|
|
|
## What this might mean for the sensor service
|
|
|
|
The sensor service should not just be a D-Bus bridge that publishes
|
|
readings. It should carry *provenance*:
|
|
|
|
- Where did this reading come from? (which D-Bus service, which
|
|
hardware path)
|
|
- When was it last verified? (cross-check between sensors — if the
|
|
accelerometer says face-down but the light sensor says bright, one
|
|
of them is wrong)
|
|
- What is the reading's *confidence*? (hardware sensors have noise;
|
|
the proxy smooths, but smoothing can mask adversarial injection)
|
|
|
|
The trust boundary matrix needs a new row: "Sensor reading → system
|
|
decision." Not ambient, not personal, not step-up. Something else.
|
|
Maybe `observed` — a tier that means "this data came from a sensor,
|
|
treat it as evidence, not fact."
|
|
|
|
## The question
|
|
|
|
How much does the system need to trust its own sensors, and what
|
|
happens when that trust is misplaced? The lock screen is the most
|
|
visible case, but it's not the only one. The agent's ambient
|
|
context (what window is active, what apps are open) is also
|
|
sensor-derived. If those readings lie, the agent's model of the
|
|
room it's in is wrong.
|
|
|
|
This is not a problem to solve in the sensor service task. It is
|
|
a problem to *name* before building the sensor service, so the
|
|
architecture accounts for it from the start.
|
|
|
|
---
|
|
|
|
*Next session: pick up from here. The sensor service task
|
|
(souveraine-surface-003) is scoped but not started. The architecture
|
|
question is: does the sensor service publish raw readings, or does it
|
|
publish observations with provenance and confidence?*
|