Security

Tidenda keeps each organisation's content separate from every other organisation, lets each organisation decide who may do what, and signs what it publishes so that others can check it. This page is for administrators and security reviewers deciding how far to trust the platform, and where their own responsibility starts.

Organisation isolation

Every document, API key, webhook, workflow, AI operation, file and audit record belongs to exactly one organisation. Every read and write is limited to the organisation of the request, and no public interface or member action reaches across.

• Members sign in and work in one active organisation at a time. Everything they see is filtered to it.
• API keys belong to one organisation. The key decides the organisation; a payload naming another one is ignored.
• Storage is separate per organisation: each has its own storage bucket for files, and the database enforces the organisation boundary on every row.
• Webhooks fire only for events in the organisation that owns them.

A request for a document in another organisation is answered with 404 Not Found, so the platform does not reveal whether it exists.

Deleting an organisation

Only an owner can delete an organisation, after several confirmations; there is no undelete. Deletion removes its documents, files, settings, keys and webhooks, and everything its public sites serve. Open editing sessions are closed at once, and nothing more can be written from the moment deletion starts. People who belonged only to that organisation lose their account; people who also belong to another keep it there. A record of the deletion (when, by whom, and the outcome) is kept, as is the history of who was granted access.

Authentication

Members sign in through an OpenID Connect identity provider. The platform stores no passwords; the identity provider handles credentials, multi-factor authentication and federation. The browser holds only an HTTP-only session cookie. Signing out also ends the session at the identity provider, so the next sign-in asks for credentials again.

Integrations use API keys issued by an administrator. A key is a random 32-byte secret, shown once when it is created and stored only as a one-way hash, so a lost key must be replaced. Each key carries scopes that limit it to specific jobs: documents:create, phrases:read, phrases:write or publisher:read. A new scope is never added to existing keys automatically. See API overview.

Transport and browser. All traffic uses HTTPS, with certificates issued and renewed automatically. The application's Content Security Policy runs scripts only from the application's own address: no inline script runs except the application's own, allowed by its hash, and no script is loaded from another host.

Roles

What a member may do is decided by their roles in that organisation. A role belongs to a membership, the pairing of one person with one organisation, never to the person's account. The same person can be an owner in one organisation and an editor in another, and nothing carries over between them. The identity provider says who a person is, never what they may do.

Role	Intended for	May
owner	Whoever is accountable for the organisation	Everything an admin may, plus grant the owner role and delete the organisation
admin	Day-to-day administration	Manage members and roles, API keys, webhooks, workflows, AI, tags, spelling and organisation settings; switch the public site on or off and rebuild its content; permanently delete images and audio; erase removed members; everything a publisher may
publisher	Whoever controls the public site	Configure, publish and verify the domain of the public site, plus everything an editor may
editor	Editorial staff	Create and edit content

Each role includes the one below it. A member can hold several, and gets the combined permissions. New members are editors unless the inviter chooses otherwise.

Workflows add one more check. A workflow transition lists the roles allowed to take it, and the match is literal: listing only publisher excludes an admin who does not also hold publisher. See Workflows.

Guarantees

• No escalation. A member can only grant roles they hold themselves. An admin can make another admin but never an owner.
• There is always an owner. The last owner cannot be demoted, suspended or removed; the request is refused as a whole. To hand over, grant ownership to someone else first.
• Revocation is fast. Roles are checked on each request, not stored in the sign-in token, so a removed role stops working within seconds, without waiting for a session to expire.
• Suspension is complete. A suspended member keeps their record and history but has no permissions at all.
• The server decides. Hiding a control is never the only check. Every request that changes, publishes or verifies the public site is checked against the caller's roles on the server and refused with 403 without them, including edits to the site's settings made in the live editor.
• Switching the public site off takes it down. Its copies of articles and images are deleted from the site, every address on it answers 404, and nothing more is published to it until it is switched back on. See Public site.

Deletion and erasure

Journalism is archived, not deleted. Articles and planning items leave circulation by moving to cancelled, which can be reversed. Their history, and the signed snapshots of what was published, stay.

Wires are kept. Wires cannot be deleted from the app. They stay, with their earlier versions and signed snapshots, so every article keeps a source that is still there.

Media can be deleted for good. Members with the owner or admin role can permanently delete an image or an audio recording with its transcript, after a confirmation. Deletion removes the content everywhere the platform keeps it: the files, the document and every earlier version, the signed snapshots, cached and in-progress copies, and derived records such as usage records and the bodies of AI requests and responses. What remains is a record that the document existed, its type, and when and by whom it was deleted; its id stays reserved. An image or recording that a usable or withheld article uses cannot be deleted until it is removed from that article. See Media and Wires.

Erasing a member. Removing a member (archiving their profile) stops them signing in but keeps who they were. An owner or admin can then erase them:

• their profile keeps its place, so links to it still resolve, but their name, email, department and job title are replaced, and the profile's earlier versions are deleted;
• their sign-in account is disabled, signed out and deleted at the identity provider. A person who also belongs to another organisation keeps their account there; only this organisation's membership is removed;
• in this organisation's records of who did what (the access-change audit, document histories, the AI record, AI label changes, image-rights acknowledgements, video approvals, source check warnings set aside and video shares), their id and email are replaced by a pseudonym. The same pseudonym is used everywhere in the organisation, so the records stay complete and still read as one person's, but they no longer say who that person was. The pseudonym cannot be traced back without a secret held by the platform, and differs between organisations;
• their private documents, such as saved items and preferences, are permanently deleted.

Bylines and author links in articles are part of what was published and stay as published. Erasure cannot be undone. A member who is still active cannot be erased, and nobody can erase themselves.

Backups. The platform's database is backed up nightly and each backup is kept for 14 days. A deleted backup is kept for 14 more days before it expires for good. Content that is permanently deleted or erased therefore leaves the backups within about four weeks. A backup is restored only to recover from a failure, never to undo a deletion.

Audit

• Document history. Every status change is recorded in the document's own history: from which status to which, who made it (a member, or a named system process such as an AI operation), when, and, for published versions, the snapshot's signature.
• Access changes. Every role grant, change, suspension, removal and the creation of the organisation's first owner is recorded in the same step that applies it, with who did it, to whom, the roles before and after, and the time. Refused attempts are not recorded. This record survives the deletion of the organisation. Erasing a member is recorded here too, under the member's pseudonym.
• Permanent deletes are recorded: which document, of which type, by whom and when, with none of its content.
• Organisation deletion is recorded as described above.

API key and webhook changes and sign-ins are not part of the audit record.

Secrets and signing

Each secret is kept according to what it is for:

• API keys are stored only as one-way hashes.
• Webhook secrets are stored retrievably, because the platform needs them to sign every delivery. They are never shown after creation and cannot be rotated in place; replace a webhook to replace its secret.
• AI connector keys are stored retrievably, because the platform needs them to call the provider. They are never shown after they are entered, and can be replaced.
• Signing keys are held in the deployment's secret store, never in the database or in source control.

Signing. Every document version that reaches usable or withheld is captured as an immutable snapshot and signed with Ed25519. Uploaded images and audio are signed the same way, and so are transcript segments an editor verifies. Each kind of content has its own signing domain, so a signature for one can never pass for another. Signing keys rotate on the platform operator's schedule, and earlier public keys stay published so older signatures keep verifying.

Webhook deliveries carry two protections: an HMAC-SHA256 signature over the request, which proves the delivery came from the platform, and the snapshot's Ed25519 signature, which proves the content is unchanged wherever it travels. See Signatures and Webhook reference.

Plugins and AI providers

Plugins run in the member's browser with that member's own access, under the same organisation and role checks, and only versions an administrator has enabled are loaded. Plugin code comes only from approved publishers and is checked against its published digest before it runs. See Plugins.

AI operations send document content to the provider of the connector they use, under the organisation's own agreement with that provider. A document's history and internal notes are never sent. The models included with the platform run inside the deployment. See AI integrations.

Customer responsibilities

Some things only the organisation can do:

• Keep API keys secret. A leaked key allows whatever its scopes allow. Store keys in a secret manager, never in source control, and replace a key at the first suspicion.
• Harden webhook receivers. Verify the HMAC signature before reading the body, use HTTPS, and do not log rejected payloads. See Setting up webhooks.
• Verify downstream. When published content is passed on, its receivers should verify the Ed25519 signature. The platform publishes what they need; it cannot make them check.
• Choose plugins and AI providers. An enabled plugin can do anything the member using it can. A connector sends content to a third party. Enable only what the organisation needs.
• Review roles. Keep the owner and admin roles to the people who need them, and remove members who leave.

Reporting a security issue

Report suspected vulnerabilities privately to the operator of the deployment in use; for the Tidenda project itself, use the contact details on the project's home page. Do not disclose a vulnerability in public issues or chat channels before the operator has had a reasonable chance to respond.

Related pages

• Signatures
• Plugins
• Setting up webhooks