# Privacy notice

This describes what the service stores, in what form and for how long. It is
written from the code, not from intentions: every retention period below is
enforced by a scheduled job, and the jobs are named where it matters.

## In one minute

- Forwarded messages are **not stored**. They pass through and are gone.
- Your alias addresses are stored in plain text, because the relay has to read
  an address to route mail to it.
- The address your mail is forwarded to is **encrypted under a separate key**.
- Nothing is sold, shared, profiled or advertised against. There are no
  third-party scripts, fonts or analytics anywhere on this site.
- We identify you by an account, not by a name. We never asked for one.
- Most operational records live for **7 days**. Records about abuse and about
  legal orders live for **24 months**, because they document a decision that
  somebody may later contest.

The rest of this page is the same thing, said precisely.

## 1. Who is responsible

The controller is the operator of Skudo, in Italy.

_(Operator name and postal address: shown as an image on the notice page.)_

If you cannot read the image, or prefer it in another form, write to
privacy@skudo.org and we will send the same details as text.

Contact for anything in this notice, and to exercise your rights:
privacy@skudo.org.

## 2. What is stored

### The service itself

| What | Form | How long |
| --- | --- | --- |
| Your alias addresses | Plain text, because the relay has to read an address to route mail to it | Until you delete the alias |
| The address an alias forwards to | Encrypted under a key held separately from the one protecting the rest of the database, with a keyed index used to find the row | Until you remove it |
| Alias notes and display names | Encrypted | Until you delete the alias |
| Per-alias counters and last-used times | Plain numbers and timestamps | Until you delete the alias |
| Account credentials | Password hash. The recovery secret is split into two random halves stored on separate systems, neither useful alone | Life of the account |
| Records of messages sent through an alias | Account, alias and recipient references, type, whether it bounced. **No content** | 7 days |
| Delivery failures | Sender and destination encrypted; remote server, error code and time in plain text | 7 days |

A deleted alias is marked at once and **permanently erased within 24 hours**.
The 7 day records are removed every six hours.

### Support and enforcement

| What | Form | How long |
| --- | --- | --- |
| Support tickets and the messages in them | The address you wrote from and what you wrote | **7 days after the ticket is closed** |
| Files attached to a ticket | Encrypted on disk, with the file name encrypted too. Scanned before storage; metadata is stripped from images, because a screenshot carries the device and often the place it was taken | Deleted with the ticket |
| Tickets about abuse, and records of legal orders | As above | **24 months**, because they document a decision that can be contested |
| Abuse reports made about an alias | The reported address, category, what the reporter said | 24 months |
| Administrative actions | Which action, on which account, when, and the administrator's own address | 24 months |

Writing to support is the one part of this service where you hand us an address
we did not have. If you write from an address you would rather we did not keep,
use one of your own aliases.

### Running the service

| What | Form | How long |
| --- | --- | --- |
| Aggregate counters | Whole numbers only: how many messages were forwarded in an hour, how many sign-ins failed. **No account, alias, address or IP is attached, and there is no column for one** | 30 days by the hour, 400 days by the day |
| Fault reports | The error, the file and the line. Request parameters and arguments are deliberately not captured | 90 days after the fault is closed |

The counters deserve a sentence, because they are the part people assume is
worse than it is. They are not a log of events. Nothing in them can be traced
to a person, not because the identifiers are obscured but because they were
never collected: the table has four columns and none of them is about you.

### The browser extension

It has no access to any site at install time. Reading a page to draw the
in-field icon is a separate, opt-in permission, requested only after you turn
that feature on, and even then it only looks for signup and login fields, not
the rest of the page.

Your access token is stored in the browser's own extension storage, on your
device: it does not add a row to our database, and the content script running
inside a page never sees it. Your forwarding address is never requested by, or
exposed to, the extension in any form.

## 3. Message content

Forwarded messages are **not stored**. A message goes from the incoming
connection to the outgoing one and no copy is kept. If the destination is
temporarily unreachable the message waits in the mail queue, on disk, like every
mail server's queue, until it is delivered or expires.

The mail server's own log, which every mail server keeps and which records who
sent what to whom, is **read and then emptied every five minutes**. It is not
archived and there is no copy.

If you turn on the **optional mailbox**, messages are also stored so you can read
them over IMAP. It is off by default, and nothing is ever written to our disk in
readable form: a message is stored only if it can be encrypted to your OpenPGP
key, which we do not hold the private half of, or if it arrived already
encrypted end to end, in which case it is stored exactly as it came. Without a
key, mail that is not already encrypted is not stored at all. Sender and
recipient headers stay readable on the stored file, and so does the subject line
unless you enable protected headers in your settings.

## 4. Why, and on what basis

| Purpose | Basis |
| --- | --- |
| Providing the service you asked for | Performance of a contract, Article 6(1)(b) GDPR |
| Preventing abuse and keeping the service deliverable | Legitimate interests, Article 6(1)(f) |
| Answering lawful orders | Legal obligation, Article 6(1)(c) |

We do not rely on consent. Consent would require verifying parental consent for
younger users, and verifying means collecting identity, which is the opposite of
what this service is for.

On legitimate interests: the interest is keeping the service deliverable for
everybody. A handful of accounts opened to send spam can get our domains blocked,
which breaks every alias for every user at once. The processing is limited to
counters and signals attached to an account, never to the content of anyone's
mail, and you can object to it.

## 5. What we do not do

No selling or sharing of your data. No advertising. No profiling and no
automated decisions with legal effects. No third-party scripts, fonts, trackers
or analytics on the site, and the build is checked for third-party requests
before every release.

## 6. Who else is involved

Servers are run at a hosting provider inside the European Union.

If you choose to support the project, a card payment happens on **Ko-fi**, which
is a separate service with its own privacy policy: your donation and any details
you give them are handled by them, not by us. Bitcoin and Lightning go through a
BTCPay server we run ourselves, with no payment processor in between, and other
currencies are sent directly to an address.

What we record about a donation is the amount, the currency, how it arrived and
when. There is no column tying it to an account, on any of those paths, so
"which user donated" is a question this database cannot answer rather than one we
decline to answer. The donation wall is separate and opt in: a name and a line
of text somebody typed in on purpose. You never have to donate to use the
service, and donating changes nothing about your account.

No personal data is transferred outside the European Economic Area.

## 7. Your rights

You can ask for access, correction, erasure, restriction, portability, and you
can object to processing based on legitimate interests. Export in JSON, CSV and
ZIP is available inside the application at any time without asking us.

One consequence of the design: we identify you by your account, not by your
name, and we cannot link an alias to a person without the account it belongs to.
If you write to us about an alias from an address we cannot connect to an
account, we may not be able to answer, and Article 11 GDPR lets us say so rather
than collect more information about you in order to be able to.

We answer within one month. If a request is complex we may extend that by two
further months, and we will tell you within the first month if we do.

You can complain to the Garante per la protezione dei dati personali in Italy,
or to the authority where you live.

## 8. Security incidents

If a breach is likely to create a risk to your rights we notify the supervisory
authority within **72 hours** and you without undue delay. An incident report is
published within **14 days**, including what was still unknown at the time.

## 9. Age

You must be at least **14**, which is the age Italy sets for using an online
service on your own account. We cannot verify age without asking for identity,
which we will not do, so we rely on what you tell us. If you believe a younger
child has an account, write to privacy@skudo.org and it will be closed.

## 10. Changes

Material changes are announced at least 30 days in advance and previous versions
stay available.