MED Diary Security · Shared Access

Records you share are sealed before they leave your phone

Shared Access lets someone you trust — a son, a daughter, a caregiver — follow the vitals, current medications and dose activity, and individual lab results you choose from their own phone. This page explains, honestly and in detail, what our server can and cannot see while making that possible.

The short version: every record you choose to share is encrypted on your phone with a key carried in the full invite. The MED Diary server never receives that key, so it can store and forward the encrypted record without reading the health content inside it.

Prefer to watch? A short narrated and captioned version of this page.

Read the video transcript

Sharing your health with family shouldn't mean sharing it with anyone else. MED Diary seals Shared Access records on your phone before upload, so our server can relay them without reading their contents.

You choose among vitals, current medications and dose activity, and individual lab results. Your caregiver gets a read-only view in MED Diary Care. Updates occur during the apps' sharing and refresh passes, so they can be delayed and Shared Access is not an emergency monitoring service.

Before upload, each shared record is encrypted on your iPhone with AES-256-GCM. The encrypted envelope travels over TLS, while readable health content stays out of the relay.

Your phone creates a separate random 256-bit key for each caregiver. The full invite contains the code and key. You hand it over by copying or sharing the full invite, or by entering the displayed code and key through a channel you choose. Anyone who sees the full invite could see the key. The redemption body sends the code, not the key, while the request still carries account, session, and ordinary network metadata. Acceptance also requires Sign in with Apple using the email you invited.

Our server stores encrypted envelopes plus delivery metadata such as the two account identities, selected categories, record identifiers and counts, and activity timing. Some routing identifiers expose limited timing information, including the scheduled slot for a dose event. The server can route updates, but it cannot decrypt health values, medication names, lab results, notes, or clinical timestamp fields inside the envelope.

The caregiver app stores the key in that phone's Keychain and keeps cached envelopes encrypted at rest. It decrypts them for display. A missing or wrong key fails closed instead of showing partial data.

Tap Stop Sharing and the server immediately blocks new access and deletes the encrypted record payloads. The caregiver app clears local encrypted data when it detects revocation, but detection can be delayed. A device that has not detected it may retain its last encrypted cache and key, and revocation cannot erase screenshots or exports the recipient already made.

Revoked share metadata is scheduled for deletion after 30 days by daily cleanup. If you share again, MED Diary creates a fresh share and a fresh key. If a device loses its key, stopping and re-inviting is the recovery path, and creating that replacement invite requires Premium.

Three participants, one locked box

When you share, three things are involved: your phone, our server, and your caregiver's phone. The key is created on your phone and copied to the caregiver's phone through the full invite; the MED Diary server does not receive it. The server in the middle is a courier carrying sealed envelopes — it knows an envelope went from you to your caregiver, but it cannot open it.

Records are encrypted on your phone before upload, relayed as ciphertext, and decrypted for display on your caregiver's phone. The MED Diary server does not receive the key needed to reverse the middle step.

The key travels with your invite — not through our server

When you invite a caregiver, your phone generates a fresh, random 256-bit encryption key just for that share. The full invite contains both a short redeemable code and that key. You can copy or share the full invite, or hand over the displayed code and typeable key through a channel you choose. Your caregiver's app saves the key into that phone's secure Keychain when they accept.

The invite-redemption body sends only the invite code, which identifies the share; the Shared Access API has no key field. Like any authenticated request, it still carries account, session, and ordinary network metadata. The handoff matters: a messaging provider, another person, or anyone else who can see the full invite could also see its key. Acceptance therefore also requires the caregiver to sign in with the exact Apple Account email address you invited.

The gold path is how the key reaches the caregiver: through the full invite you hand over. The grey dashed paths show what the MED Diary server receives during redemption — a short code, not the key. Protect the full invite as you would other sensitive information.

What a record actually looks like to us

Here is the same glucose reading twice: first as readable content on your phone, then as a simplified view of what our service stores. The record content is sealed with AES-256-GCM authenticated encryption using your share's key, which the MED Diary server does not receive.

On your phone (before upload)

{
  "kind": "glucose",
  "glucoseMgPerDl": 112,
  "mealContext": "beforeBreakfast",
  "note": "before walk",
  "recordedAt": "2026-07-01T08:05:00Z"
}

On our server (simplified record row)

{
  "category": "vitals",
  "clientRecordId": "reading-7f3a…",
  "schemaVersion": 1,
  "updatedAt": "2026-07-01T08:06:12Z",
  "payload": {
    "envelopeVersion": 1,
    "nonce": "AAECAwQFBgcICQoL",
    "ciphertext": "PCCxd7CGrWjoDPDb1Js8AaHstgXCV30XUQmBpydLZ950c
                   8GPyuM+uhnBHoHL6EZMiyEUr2D0wb9Z+Fh8WpGQj5ta
                   pwmn8wpDcjveC821LIpd7KYQE0MkCZGWvOBagtzu…",
    "tag": "XuYpaKoO/vAhDRbtJWTWcA=="
  }
}

The envelope values come from a fixed fixture shared by the app, caregiver app, and server test suites. ciphertext is the protected reading; nonce represents the per-encryption nonce, which production generates afresh at random; and tag detects changes to the envelope's encrypted fields. The category, stable record identifier, schema version, and server update time remain visible and are not covered by that tag.

Honest accounting: what we can and cannot see

Encryption hides the content of your records. To deliver envelopes reliably, a courier still needs address labels — so some operational facts remain visible to us. We think you deserve the full list, not just the reassuring half.

Not readable by our server

Inside the encrypted envelope; our server receives no key.

✕Glucose, blood pressure, weight, and lab valuesevery number, in every record
✕Medication names, doses, and schedulesand whether a dose was taken or skipped
✕Lab results, reference ranges, and flagsincluding which analytes were tested
✕Your personal notes"before walk", "felt dizzy" — all sealed
✕Clinical timestamp fields inside each payloadlimited dose-slot timing still appears in a routing identifier, listed at right

Visible to us

The courier's address labels — needed to deliver.

✓The two Shared Access identitiesincluding caregiver email and the display name used for the invite
✓That a share exists, and its statusinvite code, invited person, active or revoked, and lifecycle dates
✓Which categories you sharee.g. "vitals" and "medications" — names only
✓How many records exist per categorystable IDs and schema versions; dose-event IDs include medication ID, day index, and scheduled minutes
✓When your app uploads and theirs checks inactivity timing plus ordinary request and network metadata, not record content

In short: our server is blind to content, not to identity or activity. Someone with access to relay data could infer that a user updates a category frequently or shares it with a particular account. The encrypted envelope does not reveal the health value, medication name, lab result, note, or clinical timestamp inside it. See the Privacy Policy for the complete data flow.

Stopping a share blocks new access and deletes relay payloads

Each caregiver gets their own share with its own independent key, so ending one person's access never affects another's. When you tap Stop Sharing:

Stopping is final, not a pause. Revocation deletes encrypted relay records immediately; revoked share metadata is scheduled for deletion after 30 days by daily cleanup. A caregiver device or app that has not detected revocation may retain its last encrypted cache and key, and no app can recall screenshots, exports, or other copies a recipient already made.

What this means in the worst cases

If MED Diary's server were breached, what would an attacker get?

The encrypted envelopes and the metadata listed above — account identities, invite and share records, category names, record IDs and counts, limited dose-slot timing, request activity, and ordinary network metadata. The health content inside official-app envelopes would be AES-256-GCM ciphertext with no key on the MED Diary server to unlock it. Brute-forcing a random 256-bit key is beyond any realistic computing capability.

Can MED Diary employees look at my shared readings?

The Shared Access service does not receive the key, so an employee, administrator, or database backup cannot use the relay data to decrypt your record content. Your chosen caregiver can read the content after their device decrypts it, and anyone who sees the full invite or a copy the caregiver makes may also gain access. This statement applies to Shared Access records, not to separate features such as a lab report or meal you explicitly submit for live AI processing.

Someone intercepts my invite — can they read my data?

The full invite contains the key, which is why you should copy, share, or read out its displayed code and key only through a channel you trust. A person who obtains the full invite would still need to sign in with the exact Apple Account email address you invited to accept it. If you are unsure the invite stayed private, stop sharing and create a new invite; that creates a new share and key.

What if my caregiver's phone is lost or they shouldn't see my data anymore?

Use Stop Sharing as soon as you can. The server immediately blocks further fetches and deletes the encrypted relay payloads. The caregiver app purges local encrypted data when it detects revocation, but that detection can be delayed; an offline device or an app that has not opened the affected share may retain its last encrypted cache and key. Revocation cannot remove screenshots, exports, or other copies already made by the recipient. If a device itself is lost, also use Apple's device protections such as Lost Mode where available.

What if I get a new phone and my key is gone?

Keys stored by the apps are device-only Keychain items and do not sync through iCloud Keychain or restore onto a new device. If a key is missing, the app fails safe: it publishes or displays nothing rather than falling back to something weaker. Stop the affected share and create a fresh invite from a device that can manage it; creating that replacement invite requires Premium.

What happens if I remove one sharing category?

The server stops accepting or serving that category and deletes its encrypted relay records. Once MED Diary Care receives the narrower scope, it no longer fetches or displays that category. Local encrypted cache cleanup can lag, and narrowing cannot recall content the recipient already saw, screenshotted, exported, or otherwise copied.

Why not keep a backup of my key "just in case"?

Because a server-side spare key would make the relay capable of decrypting your data. MED Diary does not escrow Shared Access keys. Recovery therefore means stopping the old share and creating a new invite with a fresh key.

Is Shared Access a monitoring or emergency service?

No. It is a read-only way to keep someone informed. A caregiver may not open the app, may be offline, and may see an update late. MED Diary does not alert emergency services or create a duty for the recipient to respond. Contact local emergency services for urgent help.

What happens if my Premium subscription ends?

An active share remains eligible for the apps' normal sharing and refresh passes; it is not a real-time feed. Premium is required to create a new share, add a category, or restart a stopped share. You can narrow a share or stop it without Premium, so privacy-reducing controls remain available.

For the technically curious

The envelope, precisely

cipher: AES-256-GCM (authenticated encryption) via Apple CryptoKit
key: 256 random bits per share, generated on-device, stored in the iOS Keychain (device-only, never in any backup or cloud sync)
nonce: 96 random bits generated afresh whenever a record is sealed in production
tag: 128-bit GCM authentication tag; changes to the nonce, ciphertext, or tag make envelope decryption fail closed (clear routing metadata is outside this authentication boundary)
envelopeVersion: lets us upgrade the format in the future without breaking older apps
key transport: invite string MEDIARY1:<code>:<key>; MED Diary displays it as a QR and as a typeable base32 key, while MED Diary Care currently accepts the full invite pasted or the code and key typed separately

The four-field encrypted envelope format is pinned by a byte-exact golden fixture across the MED Diary app, caregiver app, and server. The surrounding relay record deliberately leaves routing metadata — including category, stable record identifier, schema version, and update timing — in cleartext. Cross-repository fixtures verify the envelope produced and consumed by the official apps; the relay treats payload JSON as opaque rather than decrypting or interpreting it.

This document describes the Shared Access architecture as implemented. Transport between the apps and our server is additionally protected by TLS, independent of the end-to-end layer described here. Read the Privacy Policy, Shared Access terms, or contact support. We'd rather over-explain than have you wonder.