Security

Last updated 12 August 2026

This page describes how DiaryRobo actually protects data, and — in equal detail — what it does not yet do. A security page that only lists strengths tells you nothing, because every service has gaps and the useful question is which ones.

What is in place

Tokens are never stored

When you register a robot, its access token is generated from 32 bytes of cryptographically secure randomness, shown to you once, and then discarded. Only a SHA-256 hash is written to the database. If our database were copied, the tokens in it could not be used — there are none in it.

A leaked token does not cost you the diary

Rotation issues a new token and invalidates the old one immediately, keeping all existing entries. This matters more than it sounds: when the only remedy for a leak is to start over and lose your data, people quietly keep using the compromised token instead.

curl -X POST -H "Authorization: Bearer $TOKEN" \
  https://diaryrobo.onrender.com/robots/$ROBOT_ID/rotate-token

One robot's token opens only that robot

Every endpoint checks the token against the specific robot in the URL. A token for robot A returns 401 on robot B — for reading, exporting, deleting and rotating alike. This is covered by tests that specifically try to cross the boundary.

Deletion actually deletes

Removing a robot cascades at the database level to its diary entries, their raw telemetry payloads and its access records. There is no orphaned data left behind. We verified this against the live database rather than assuming the foreign keys were right.

Row-level security, with helpers out of reach

Access rules are enforced in the database itself, not only in application code. The helper functions those rules use were originally in the public schema, which made them callable directly through the REST API — a signed-in user could have probed which robots they had access to. They now live in a schema that is not exposed.

Encryption

All traffic is over TLS. Data at rest is encrypted by Supabase, and backups are encrypted. Note what this does and does not mean — see the gaps below.

Secrets are not in the repository

Service keys and tokens live in environment variables on the hosting platform. .env is git-ignored. The public code contains no credentials.

What is not in place

• The token is the only identity There are no user accounts, no passwords, no two-factor authentication. Whoever holds a robot's token is that robot, as far as the system is concerned. Role-based access — family, caregiver, doctor — exists in the database design but is not reachable through the API yet.
• We can read your data Running the service requires a key that bypasses the database's own access rules. Encryption at rest protects against someone stealing the disks; it does not make the data opaque to us. There is no end-to-end encryption, and with the diary needing to be searchable and summarisable, adding it would be a significant redesign rather than a setting.
• Registration is open to anyone No captcha, no rate limit, no email verification. Someone could create large numbers of empty robots. Nothing is exposed by this, but the service could be disrupted.
• No rate limiting on the API A valid token can be used as fast as the network allows. There is no protection against a compromised token being used to bulk-export data quickly.
• Retention is not enforced automatically Our hosting plan has no scheduled jobs. Entries past their retention period are deleted when the expiry endpoint is called — by you. Until you call it, the data is still there.
• No independent audit No penetration test, no SOC 2, no ISO 27001, no HIPAA assessment. This code has been reviewed by the person who wrote it, and by nobody else.
• Data is in the United States Including health data from EU and UK users, with no transfer mechanism in place. See the privacy policy.
• Single operator, free hosting One person maintains this. There is no on-call rotation, no incident response team, and no formal recovery plan beyond what the hosting providers offer.

How to protect yourself

• Keep the retention period as short as you can live with. Data that has been deleted cannot leak.
• Run the expiry endpoint on a schedule — a daily cron line is enough.
• Rotate the token if it has been anywhere it should not, including screenshots and chat messages.
• Do not connect a robot belonging to a real patient in a regulated care setting until the gaps above are closed.
• Export periodically. Do not treat this as your only copy.

Reporting a vulnerability

Write to hello@diaryrobo.com with enough detail to reproduce the issue. We will confirm receipt within 72 hours and tell you what we intend to do.

We have no bug bounty — there is no budget for one. What we can offer is that reports are welcome, will be taken seriously, and that we will not respond to good-faith research with legal threats. Please do not access data belonging to robots that are not yours; if you need a robot to test against, register one, it takes a minute.

Changes to this page

12 August 2026 — First version. At the same time: added deletion, token rotation, retention limits and data export; moved row-level-security helper functions out of the publicly exposed schema.