Security and threat model

What is never collected

A contributor is not asked to identify themselves. This is the default; where the organisation can change something, it is named.

• Name, phone number and e-mail are not asked. The organisation can switch on an optional name field; it can always be left empty.
• The forms for coming back from another phone (SMS code or e-mail link) are off by default. If the organisation switches them on and a contributor uses them, the number or address only brings the files back; the organisation's team sees it only if the contributor ticks "The organisation may contact me".
• No IP address is kept in Tanikio's database: not with files, contributors, devices or sessions. Rate limits use the address only as a short-lived cache key.
• No account, app or installation: the contributor only opens the link.
• Tanikio's pages carry no advertising or tracking scripts and load their scripts, styles and fonts only from Tanikio's own address.

The device token and "forget me"

Tanikio recognises a phone, never a person.

• On the first visit the phone receives a random token, kept by the browser (cookie, localStorage, IndexedDB). The server keeps only its sha256 digest. The token belongs to one incident: on another incident the same phone is a new contributor.
• The token does one job: it lets the contributor see under "What I sent" what they sent, and delete it if the organisation allows that.
• "Forget me" revokes every device token of the contributor; empties the name, phone, e-mail and profile picture fields; deletes sign-in links and SMS codes; switches off the location and contact permissions; and clears the cookie and the token stored in the browser. The next visit from that browser is a new contributor.
• What it keeps: the files stay with the organisation as evidence, with their original, sha256, receive time and verification history. They stay attached to an anonymous contributor record (shown with a label such as "Contributor-12") that no longer leads to any phone or person.
• Deleting a file is separate: when the organisation allows it (on by default) a contributor can delete their own files one by one. A deleted file stops being served at once; the organisation can restore it for 7 days, then it is removed for good.

Consent and location

Nothing is uploaded before the contributor has read what happens to it.

• Before the first file, once per device, a consent screen says what is kept, who sees it and how to remove the link to it. The time of acceptance and the version of the text shown are recorded; if the organisation changes the text, it is asked again.
• The "Share my location" box is optional and starts unticked. If it is ticked, the GPS position in a photo is stored separately in the evidence record, for the organisation's team only. If it is not, the GPS tags are discarded as soon as the file is read, before they are converted, and never recorded.
• Location never appears in the thumbnail, preview or publication version of a file.
• The original file is kept untouched, so whatever the phone wrote into it stays inside it — see "Limits".
• The consent form runs a bot check that uses no third-party service.

The evidence chain

Each file is recorded the moment it arrives, and that record is not rewritten.

• When a file completes, the server computes its sha256 digest itself. If the phone sent a digest too, the two are compared and a mismatch rejects the file.
• The receive time comes from the server clock and is stored in UTC. Capture time and camera model are read from the file when present; when the capture time comes only from the phone's file date, the panel marks it as weak evidence.
• The original is stored byte for byte. No later process writes to it.
• Thumbnails, previews and the publication version are re-encoded and carry no EXIF, GPS or XMP data; an automated test checks this byte by byte.
• If the same file reaches the incident twice, both are kept and the later one is marked as a duplicate. A capture time more than two days before the incident date is flagged.
• Verification steps (raw, in review, verified, published, rejected) go through one service that logs every step: who, when, from which state to which, the note and the rejection reason. The contributor sees at most the state, never the note or the reason.

Who can see what

The files are kept for the organisation running the incident.

• The organisation's team, the owners and editors added to the incident, see every file, its evidence fields and its verification history in the panel. An account that is not a member gets "not found" and cannot even tell that the incident exists.
• Talivio's platform administrators can open any incident's panel to run and support the service.
• A contributor sees only their own files. If the organisation switches on the incident gallery (off by default), everyone who opens the incident link sees the files sent to it.
• Files never sit at a public address. They are served only through short-lived signed links, issued after an access check.
• The organisation running the incident is the data controller; Tanikio (Talivio) processes the data on its behalf.

Packs

Two packs leave the panel; the organisation's team builds both.

• Evidence pack, for the legal team: the original files, each hashed again while packing. manifest.json lists per file the stored and the packed sha256 and whether they match, the original file name, receive and capture time, the evidence fields and the verification state with its log. manifest.sha256 lets anyone check the whole pack with "shasum -a 256 -c". Phone numbers and e-mail addresses never enter it.
• In the evidence pack a contributor appears under the name they gave, otherwise under a label such as "Contributor-12"; the verification log names the team members who took each step.
• Press pack, for newsrooms: published photos only, as JPEG without metadata, with neutral numbered file names; credits.txt gives the incident, its date and a suggested credit line. No contributor name appears anywhere. Videos do not go into the press pack yet.
• The organisation downloads the pack from the panel and hands it to the newsroom itself. Tanikio does not contact newsrooms or send them anything.
• Prepared pack files stay on the server for 7 days, then they are deleted.

Retention

How long an incident's files are kept.

• By default an incident is kept for 24 months from its date. The organisation can change this date in the incident settings.
• When the date passes, the incident's contributor pages close and its address answers "not found".
• Automatic deletion of the files when the period ends, and a reminder before it, are not in place yet.
• An upload left unfinished is discarded after 24 hours.

Limits: what Tanikio cannot protect against

Tanikio protects what it keeps on its servers. The following are outside its reach.

• Your phone

  Photos stay in the phone's gallery and the incident link in the browser history; the device token stays in the browser until "forget me". Whoever holds the unlocked phone can see all of that, and "forget me" clears neither the gallery nor the history.

• What the phone writes into the file

  If the camera writes the location or device details into a photo or video, they stay inside the original, which is never modified. The organisation's team can see them when it opens the original or the evidence pack, even if "Share my location" was not ticked. To avoid this, switch off location tagging in the camera settings before you shoot.

• The network and the operator

  The connection is encrypted (HTTPS), so the files cannot be read on the way. Your mobile operator, the Wi-Fi provider or anyone watching the network can still see that you connected to this address, when, and how much data you sent. Traffic passes through the hosting and content delivery providers (Cloudflare). The web server's access log and the application's security log (failed bot checks on the consent form) can record the connecting address; they sit outside the database and are kept as the hosting is configured.

• The organisation's team

  The organisation sees the files and downloads the packs. Tanikio cannot control what happens to downloaded files or packs, or with whom they are shared; "forget me" and deleting a file do not reach copies made earlier. If a team account is taken over, everything that account can see is exposed.

• What the picture shows

  Faces, voices, clothing, number plates and reflections can identify you or others. Tanikio does not blur faces.

• Legal orders

  If Talivio or a hosting provider receives a binding order from a competent authority, data kept on the platform may have to be disclosed. Asking for no names, phone numbers or e-mails and keeping no IP addresses in the database limits what exists to disclose; it cannot shield the files and records that are kept.