Security

The letter is encrypted on the device

A letter leaves the device you write it on encrypted. On the server and with us it sits as an unreadable block. It stays that way for the recipient too, until the condition comes true.

The app seals the letter's text and name on the phone with the recipient's public key. Only the encrypted block reaches the server. The server stores the block and cannot open it.

The password never reaches the server

The app derives two separate secrets from the password on the device. One goes to the server for sign-in. The other encrypts the key backup and never leaves the device. If someone forgets their password, we cannot open their backup either.

Keys are pinned on first sight

The app pins the key of everyone you write to on your device the first time it sees it. On later letters it compares the key the server returns with that one. If the key changed, the app does not send the letter and warns you. Most often the reason is that the other person changed device or password. The decision is yours.

Addresses and phone numbers are stored as digests

The server does not keep other people's email addresses and phone numbers in plain text. It stores a keyed digest (HMAC-SHA256), which cannot be turned back into the address. The phone number is an abuse measure. The app asks for it before you write a condition-bound letter to someone you have not corresponded with, and keeps only its digest. For an account that reached the report threshold the digest stays for twelve months. That way the same number cannot open a new account and do the same thing.

Writing to an address without an account

If the recipient has no account yet, the letter waits under the digest of the address. The address itself is not stored on the server. The letter's key waits on your device and in your encrypted backup. When they sign up, your device seals it to them and delivers it.

A confirmation link does not work on its own

For account deletion, a link is sent to your address. The link brings you to a page on this site. The confirmation happens only when you press the button there. Email servers and security scanners open incoming links before you do. The button keeps such an opening from counting as your consent.

When you write to someone for the first time, the app locks the letter with an extra code. The code never passes through our server. It travels to the recipient with the link, by the route you choose. The server cannot open the first letter because it does not know the code. If the recipient has an account, the app takes their key from two separate sources and does not send the letter if the two disagree. After the second letter the key stays saved on your device, no code is needed, and every change is shown to you.

A letter you write to yourself is opened by a key that is already on your device, so what keeps it closed until the condition is not the encryption but the server, which does not hand it to you before then either.

What it sees

The server knows who writes to whom. It also knows the condition's type and settings. These are a date, a chosen point and radius, or a city. It keeps the letter's status and when it opened. It needs these to watch the condition.

What it does not see

• The letter's text and name.
• Your password and the inside of your key backup.
• The recipient's location. For a place-bound letter the recipient's device confirms the arrival and only "arrived" reaches the server.
• The birth date and the number of days. For the "when they turn an age" and "a number of days later" conditions, the device sends only the day it opens. They are not written on the proof seal either, because the seal writes what the server knows.
• Address search results. The only thing saved is the point you tapped. The name of the place stays on your device and never enters the letter.

What the recipient does

The sender cannot see whether the letter was read or when the recipient opened the app. Those fields are closed to the sender at the database level. When a letter opens, the notice to the sender arrives after a random delay of 6 to 24 hours. That way the notice does not say where the recipient was at that minute. The chosen point and radius are never shown to the recipient. The recipient only knows the letter opens "when you get somewhere".

Blocking and rejecting

A blocked sender gets the same answer as a sender writing to someone without an account. So they cannot tell they were blocked. An unopened first letter from someone you have not corresponded with can be rejected. It is dropped and the sender is not told. If you close the lock, that person cannot send you locked letters.

The database and server functions are in Frankfurt (Germany). Error records are kept in the European Union. The names and locations of the other services are in the privacy notice.

Sky conditions are computed for the city the sender chose. For weather conditions the server watches the airport observation station nearest that city. Neither asks for the recipient's location. For the weather on the today screen, the city you picked goes to the weather service through our server. Neither your location nor your device goes there.

In the closed test build, the app sends a technical error report to a service called Sentry when it does not recognise the cause of an error. This can happen in three places. If the app closes unexpectedly. If it shows an error sentence on screen with a short code at the end. Or if a job running in the background, such as delivering a letter, meets an error it does not recognise; nothing appears on screen in that last case. No report is produced in any of these when there is no network connection, or for the server's known answers such as a rate limit or a wrong password.

What is sent

The error's stack trace, meaning which class and which line it stopped at. And the device's technical state: model and maker, Android version, app version, screen size, language and time zone, battery level, free memory and the app's permissions. A short code saying which path the error happened on goes too.

What is not sent

The letter text, the letter code, keys and location are never sent. Your user ID, email address, names of people, device ID, screenshots and the list of screens you visited are not sent either. Before sending a report, the app removes the user, navigation trail, request details, extra fields, device ID and the text of the error message. It removes the tags too, with one exception: the error code shown on screen. That one is kept only if it is the letter H followed by two digits, and removed in any other form. The app does not put your IP address into the report. What remains is the stack trace, the device's technical state and that code. This removal happens in the code and two tests check it on every build.

Where it is kept, and for how long

Sending personal data is turned off. Reports are kept in Sentry's European Union region and deleted after at most 30 days.

How to turn it off

There is no switch inside the app today and it stays on for the duration of the closed test. If you would rather not have it, write to beta@untillo.com and we will send you a build without it. Whether the store version carries this service will be decided before release.

The person who opens a treasure hunt link does not need the app. The hunt is played in the browser at av.untillo.com. Location permission is asked only to show that you reached a stop. The page works out the distance to the stop inside the browser and the location never leaves the page. Only "arrived" reaches the server. The key that opens the letters sits in the last part of the link, after "#". The browser never sends that part to the server.

If you found a security issue in Untillo, write to info@untillo.com. We will read your report and get back to you. We ask you not to share it with others until it is fixed.