Security

BriefDuty has two halves, and they have deliberately different security postures.

The dashboard and studio are behind authentication. Everything there — briefs, documents, team, reader records, billing — belongs to a tenant and is reachable only by members of that tenant.

A published safety brief is the opposite: it is meant to be opened by a guest or a crew member on their own phone, with no account and no password. Understanding that split is the key to using BriefDuty safely.

Accounts are authenticated through Firebase Authentication. Passwords are handled by Google's identity platform; we never see or store them.

Every request to the API is checked against the signed-in user's membership of the tenant being addressed. A user who is not a member of a tenant cannot read or write anything inside it.

Within a tenant, roles decide what a person can do. Owners and administrators can publish briefs, manage the team and change billing; other members cannot.

Briefs, chapters, documents, uploaded media and reader records are all stored against the tenant that owns them, and every read and write is scoped by tenant.

Ticket verification is scoped the same way. If a guide scans a passenger ticket that belongs to a different organisation, the scan is rejected rather than silently accepted.

A published brief lives on a long, unguessable URL. It is served with noindex, nofollow so it does not appear in search engines, and the site's robots file asks crawlers to stay away.

But anyone holding the link can open it, and links get forwarded, printed on QR codes and pinned to noticeboards. Treat a published brief as public.

Do not put confidential information, personal details of staff, or anything you would not pin to a noticeboard into a published brief.

When a guest finishes a brief they enter a name, and optionally an email address. That record is stored against the brief, with the time they finished and the language they read it in.

If the brief requires verification, the guest is issued a ticket QR that a guide scans at the gate. Scanning marks the reader verified with a timestamp. Scanning the same ticket twice reports that it has already been verified rather than creating a second record.

Reader records belong to the operator. We show them to you and we do not use them for anything else — they are excluded from the sample reviews we use to improve the AI assistant.

BriefDuty runs on Google Cloud. Customer data is stored in Australia.

• Hosting — Firebase App Hosting on Cloud Run.
• Database — Cloud Firestore.
• File storage — Firebase Storage, for the images and video in your briefs.
• Sign-in — Firebase Authentication.
• Payments — Stripe. Card details go directly to Stripe; we store a customer reference and subscription status, never a card number.
• Email — Resend, for invitations and password resets.
• AI — Google Gemini, through Google's paid API, for drafting and translation.

Brief content is sent to Google Gemini to be drafted or translated. It is not used to train Google's models or ours.

Translations are cached against your brief, so the same content is not sent repeatedly.

Our staff may review samples of brief content to improve the assistant's output quality. Reader records are never included.

You can delete a brief, a document or an entire tenant from within the product. Deletion is immediate.

We do not keep backup copies. That means deletion is genuinely permanent — there is no shadow copy of your content sitting in a backup system waiting to expire, and a request to erase data can be answered honestly.

It also means we cannot undo an accidental deletion.

Keep your own copy of anything you rely on for compliance. If a record matters to you six months from now, export it — we cannot recover it for you.

If we become aware of a data breach we will investigate, contain it, and notify affected parties and the Office of the Australian Information Commissioner where the law requires it.

We do not currently commit to a fixed notification window beyond what the law sets.

We would rather tell you this than let you assume it. As of the effective date of this page, BriefDuty does not have:

• A SOC 2, ISO 27001 or equivalent third-party audit.
• An independent penetration test.
• A published uptime commitment or service credits.
• Backups, as described above.
• An EU representative under Article 27, a data protection officer, or Standard Contractual Clauses.

If your procurement process requires any of these, talk to us at [email protected] before you commit — we would rather know early than fail an assessment later.

If you believe you have found a security problem in BriefDuty, email [email protected] with enough detail for us to reproduce it. We will acknowledge your report and keep you updated while we investigate.

Please do not test against other customers' tenants, publish the issue before we have had a chance to fix it, or access data that is not yours.