Privacy & Data Protection Policy
Authenticity Mark LLP (UEN T26LL0801L), 60 Paya Lebar Road, #06-28, Paya Lebar Square, Singapore 409051 — operator of tell.sg. In this document "we", "us" and "our" mean Authenticity Mark LLP.
Last updated: 19 August 2026.
This policy is written to be checked, not skimmed. Where it makes a technical claim, the same claim appears in our threat model, which is maintained against the platform's actual code.
1. The two kinds of people we deal with
Senders — people who write to a box. We are built not to know who you are. We do not collect your name, email address, phone number, IP address, device identifiers, or any account information, because none of these exist in the submission path. What we hold is what you typed, any file you attached (sanitised of hidden metadata), and a one-way cryptographic fingerprint of your passphrase that cannot be reversed into the passphrase itself.
Console users — people at organisations that rent boxes. For you we hold: your email address, display name, a hash of your password, your role on each box, records of which cases you first opened, and billing details for your organisation's plan.
2. What we collect, and why (PDPA purposes)
| Data | Whose | Purpose |
|---|---|---|
| Message content and attachments | Sender's submission | Delivering it to the organisation you addressed — the entire point of the service |
| Message content sent for AI follow-up questions | Sender's submission | Generating the optional follow-up questions on boxes where the organisation has enabled them — see §3 and threat model §7 |
| Passphrase fingerprint (one-way) | Sender | Letting you, and only you, return to your conversation |
| Console account details | Console user | Operating your account, authenticating you, sending service email |
| First-access and deletion records | Console user | The audit trail your organisation's governance relies on |
| Billing and verification records | Organisation | Charging for the plan; verifying the organisation's registered name via bank transfer |
| Subscription identifiers held by Stripe | Organisation | Recognising your subscription when the payment provider tells us it renewed or ended — no card details, see §3 |
We do not run analytics or advertising trackers, and make no third-party requests from sender-facing pages.
2a. Cookies
We set exactly two cookies. Both are strictly necessary to deliver a service
you asked for, both are HttpOnly and SameSite=Strict, both are sent only
over HTTPS, and neither is readable by JavaScript or by any other site. We
set no analytics, advertising or preference cookies, and no third party sets
any cookie through us.
| Cookie | Where | Lifetime | What it holds | What it is not |
|---|---|---|---|---|
tell_case |
tell.sg (senders) | 12 hours | A sealed copy of the one-way fingerprint of your passphrase | Not a case number, not an account, not an identifier for you — and it has no matching record on our servers |
tell_console |
box.tell.sg (console users) | 7 days | An opaque random token | Not your identity: the account is resolved server-side from a stored hash of the token, and signing out revokes it |
The sender cookie has no server-side counterpart by design. The ordinary way to keep someone signed in is a session row on the server, and for a sender that row would record which case was opened and when — the behavioural data §1 says we do not hold. Refusing the row is what leaves the cookie carrying the state instead, on the sender's own device, for a single visit. Deleting it changes nothing on our side, because there is nothing on our side; the passphrase remains the only route back to a case.
Because both cookies are strictly necessary to provide a service the person has requested, we do not present a cookie consent banner. There is nothing optional to consent to: refusing either cookie does not reduce tracking — we do none — it simply prevents you signing in or reading your replies.
3. Where your data lives
Everything is stored in AWS Singapore (ap-southeast-1), encrypted at rest and in transit. The key protecting sender passphrases is held in a hardware key-management service and decrypted only into memory.
Storage is Singapore. One kind of processing is not. Everything we store stays in ap-southeast-1. Where an organisation has enabled AI follow-up questions on a box (see the threat model, §7), the text of that report is sent to Amazon Bedrock in our own AWS account so the questions can be generated, and Bedrock may serve that request from another AWS region. Amazon states that Bedrock stores no model inputs or outputs, that no operator of the service can read them, and that the model's provider has no access to them — and we have not enabled Bedrock's optional prompt logging. So no copy is created in that region, or anywhere else. The transfer is made under our data processing agreement with AWS.
Card payments are handled by Stripe, and we never see a card. When an organisation subscribes to a paid plan, the payment page is Stripe's own — the card number is typed on Stripe's site, not ours, and it does not pass through our systems at any point. We store no card details of any kind: not the number, not the last four digits, not the brand, not the expiry. A saved card is saved at Stripe, and changing it happens on Stripe's own page. What we keep is the plan you are on, when it renews, and the identifiers Stripe gives us to recognise your subscription.
This applies to organisations that buy a plan. Senders never encounter Stripe at all: there is nothing to pay for, and no sender data is sent to any payment provider.
4. Message content: our role under the PDPA
For the content of messages, Authenticity Mark LLP processes on behalf of the organisation that rents the box — the organisation decides how a report is handled, answered, and when a case is deleted. For console-user account data and billing data, Authenticity Mark LLP is the collecting organisation. Questions about how a specific organisation handles reports should go to that organisation; questions about the platform come to us.
5. Retention — the actual numbers
- Unconfirmed signups: deleted after 7 days.
- Abandoned uploads (file attached, never submitted): removed after 1 hour.
- Duplicate-detection fingerprints (content-derived, not identity-derived): 30 days.
- Case content: held while the box exists. Box deletion runs through a notified safety window, then purges content, leaving only a tombstone so a returning sender is told the truth rather than shown an error.
- Backups: deleted reports, messages and attachments are removed from the live service immediately and are purged from encrypted backups within 7 days. Attachments are named here deliberately: the file itself is stored separately from the text it arrived with, and it keeps the same 7-day backup window.
6. Disclosure
We disclose personal data only where the law compels us. What we can be compelled to produce is bounded by what we hold, and for senders we hold no identity of our own asking: no account, no IP record, no device data, and no name unless a sender chose to write one. Our threat model describes this boundary in detail, including its limits. We do not sell or share data for marketing — ours or anyone's.
We do not monitor or review message content — the receiving organisation is the reader. Where content is brought to our attention, typically by that organisation or by legal process, indicating a serious threat to life or safety or material whose report Singapore law mandates, we may be legally required to report what we hold to the authorities. Even then, what we hold about the sender is what they chose to type.
7. Access and correction requests
Console users may request access to or correction of their personal data by writing to the contact below.
Senders: we cannot honour an access request for sender data, and this is a feature, not an evasion — we have no way to verify that any person wrote any message, because we hold nothing linking people to messages. Your passphrase is your access: it opens your case and everything we hold about it.
8. Data breach notification
We maintain a breach response process and will notify the Personal Data Protection Commission and affected persons as required by the PDPA where a notifiable breach occurs. For sender content, note that the identity a breach could expose is limited to what senders chose to write.
9. Data protection officer
dpo@tell.sg — the DPO responds to PDPA enquiries, access and correction requests, and complaints. If you are unsatisfied with our response, you may complain to the Personal Data Protection Commission of Singapore.
10. Changes
We will not weaken this policy quietly. Material changes are posted here with a new date, and changes that reduce sender protections would be announced on the platform itself before taking effect.