Secure Relay / development service
Secure Relay is a security-first development service beginning with one fixed pair in one direct-message lane, without copying the conversation into email. We define the threat model, build a controlled prototype, test the boundaries, and require review before any real-world pilot.
Prototype status: this is a proposed development service, not a live public messenger, security certification, or guarantee. The ambition is world-class protection; the public promise is only what testing can prove.
Proposed message route
The designed route gives the recipient a generic Gmail notice after an approved delivery transport is enabled. The notice carries no conversation-sender name, message body, conversation subject, preview, attachment, or reply content. The recipient returns through the authenticated relay to view and acknowledge the message.
Start with invited participants, known devices, and a documented reason for access.
Encrypt the approved message before storage or relay, using keys the design can rotate and revoke.
Keep policy and change history in Git. Keep plaintext messages and secrets out of repositories, logs, and email.
After the delivery transport passes review, send one generic Gmail notification with no conversation content or sender identity.
Return through the verified relay, decrypt on the approved path, and record a minimal receipt.
Sign in to Ten Thirty Two Secure Relay to view it.
What Gmail still sees: the alert-sending account or service, alert recipient, delivery time, generic notification subject, and normal routing headers. Gmail processes the notification, so the design does not claim that email metadata disappears.
Honest security boundaries
No messaging system can honestly guarantee absolute security. Secure Relay work begins with the people, devices, data, recovery paths, and failures that apply to the specific use case.
Versioned code, policies, configuration templates, reviews, and non-sensitive audit references may live in a private repository. Plaintext messages, live credentials, recovery secrets, and private attachments do not.
Encryption can protect content while delivery services, devices, and network operators still observe some metadata. We document what remains, reduce it where practical, and never call it invisible.
Lost devices, copied screens, account recovery, phishing, and shared access can defeat good cryptography. Device revocation, key rotation, training, and a tested incident path are part of the build.
Early-test limit: prototypes use synthetic or explicitly approved low-risk data. Regulated, highly sensitive, or safety-critical information stays out until legal, operational, and independent security reviews support the specific use.
Measurable roadmap
Each stage has a pass condition. A failed test stops the release instead of being hidden behind a security slogan.
Map 100% of approved data flows, roles, devices, retention rules, and recovery paths; obtain written owner approval before code handles pilot data.
Automated checks find zero plaintext message bodies or live secrets in Git, email fixtures, application logs, and analytics. Every alert fixture remains content-free.
Pass key rotation, device revocation, backup restore, expiration, duplicate-delivery, and acknowledgement tests with documented results.
Commission an external security assessment, remediate every critical and high-severity finding, and repeat the affected tests before a pilot.
Invite a small named group, begin with synthetic data, measure delivery and acknowledgement, verify deletion against the retention rule, and publish the stop conditions.
Start with the risk, not the feature list
Tell us who needs to communicate, what could go wrong, what must never enter Gmail or Git, and how the recipient should acknowledge the message. Scoping is a conversation; production use requires documented controls and testing.