OwnpaceOwnpace is in its Alpha, by invitation. Nothing is charged during the Alpha. Request access
Privacy policy
Applies to: the Ownpace managed service at ownpace.eu, and this website.
Version: 1.0
Last updated: 2026-10-19
If you run Ownpace yourself, this policy does not apply to you and there is nothing for us to state: the software runs on your infrastructure, your data never reaches us, and we receive nothing — no telemetry, no usage counts, no error reports. The source is public and that claim is checkable rather than promised.
During the Alpha, the Alpha conditions apply as well. Where they say something different from this policy, they prevail.
1. Who we are
Archico B.V., trading as Ownpace, KvK 73922706, VAT NL8597.110.06.B01.
Contact for anything in this policy, including your rights under the GDPR: support@ownpace.eu. We correspond by email. A person reads what arrives there. We aim to answer within five working days and are bound by the GDPR's one-month limit for rights requests.
2. What Ownpace does, because it decides everything below
Ownpace moves your mail, contacts, calendars and files from one provider to another, and keeps the copy in step until you decide to switch over. It reads your source account, writes to your target account, and keeps a record of what it has moved so that running it again does not duplicate anything.
We are not a storage service. Your messages and files pass through Ownpace to be written to the target you chose. We do not store them: each one only passes through while it is being copied, and we keep no copy of it. What we do keep about each item is the record in §4.2.
3. Our role, which depends on who you are
For your account with us — sign-in, billing, support correspondence — we are the controller, whoever you are.
For the content of your migration — your mail, files, contacts and calendar entries — it depends on who is migrating:
- If you are an organisation, you are the controller and we are your processor. We act on your documented instructions, which are the migrations you configure. Our data-processing agreement forms part of your contract — available on request at support@ownpace.eu until it is published here.
- If you are a private individual moving your own or your family's accounts, the GDPR's household exemption (Art. 2(2)(c)) means you carry no controller obligations for what you move — and that exemption does not extend to us (recital 18). For your migration's content we therefore act as controller, on the contract between us (Art. 6(1)(b)), and this policy carries the commitments a business customer would get from a data-processing agreement: we process the content only to run the migration you configured (§5), the sub-processor list in §7 and the retention in §9 apply to you in full, and §2's promises hold.
During the Alpha, only households take part (Alpha conditions §1). So for your migration's content the second case applies to you, and no data-processing agreement is involved.
A mailbox also contains other people — the correspondents who wrote to you, and the people in your contacts and calendars — and a migration can involve a family member, or people you shared files with. They never contracted with us. What we hold that concerns them is what §4 describes (§4.6 lists it) and nothing more, it is protected by the same §7–§9, and the rights in §10 are theirs too, no account required.
4. What we actually hold
Stated at the level the software actually works at, because a vaguer answer would be less useful and no more honest.
4.1 Credentials for your accounts
Whatever is needed to read the source and write the target: an OAuth refresh token, or a username with an app password, or a service-account key. Encrypted at rest with AES-256-GCM under a key kept apart from the database: in the service's own configuration, and in the settings of the background tasks that run migrations, both on the same machine.
We ask for the narrowest access each provider offers. Where a provider offers nothing narrow — Google's IMAP endpoint accepts only a permission that amounts to full access to your mail — we say so rather than implying otherwise. The connectors that read your mail, contacts, calendars and files cannot write to the source at all.
You can revoke our access at your provider at any time, without asking us, and the migration stops.
4.2 The migration ledger — metadata, not content
For every item we move we keep a row recording: an identifier the source already assigned it (for mail, the Message-ID header; for a file, its path; for an event or a contact, its UID), a hash of that identifier, a hash of the content, the size in bytes, the folder, calendar or address book it is in, the identifiers the source and the target use for it, timestamps, and whether the copy succeeded. So that the app can show you which item it means, the row also keeps the name you know it by: a message's subject (once the message has been fetched), an event's or task's title, a contact's name, a file's name. If an item fails, the row keeps the reason as the provider worded it; that text can name a folder, a file or an address. This record is what lets a second pass skip what is already there, instead of duplicating your mailbox.
The ledger holds no message bodies, no attachments, no file contents. It does hold metadata that can be revealing on its own — subjects, names, folder and file names, the provider's error text, and hashes derived from content — and we would rather say that plainly than describe it as "technical data".
With each migration we also keep the folders it maps, how far each pass got, the decisions you made about items, the results of its checks, and the list of what was shared (§4.6). With your organisation we keep the distribution lists a migration found, with their members' addresses.
4.3 The count when you review your migration
When you review your migration, Ownpace reads your source to count what is there. That count is free. It stores counts, sizes and per-folder aggregates — not an inventory of individual items — and the provider's reason if something could not be counted. Item identifiers reach the ledger only when the migration actually starts. The counts belong to the migration they were counted for: kept with it, and gone when you delete it or your data is erased (§9).
4.4 Your request for access, and your account
Your request for access. During the Alpha, nobody is let into the service without asking us first, unless someone already in it invites them (§4.6). The request form keeps what you type: your email address, and if you give them, your name, an organisation, a note and the package you had in mind; and your language. Then it keeps our decision, who made it, and when. We use it to decide on your request and to answer you. We get an email about each new request, with your address and the organisation and package you named, but not your note. Asking creates no account.
Your sign-in account. Signing in runs on a sign-in service we operate ourselves, on the same machine as the service. Your sign-in account is kept there, not at another company; §7 says what your connection to it passes through. It holds your first and last name, your email address, a user name, a hash of your password (never the password itself), and your sessions: when you signed in, and the browser and the IP address you signed in from. That service also keeps a history of every change to your sign-in account (§9). Anyone can create a sign-in account at our sign-in page, but it opens nothing until we let that person in. The sign-in service's mail to you, such as a sign-in code or a link to reset your password, goes through our mail provider (§7).
Two-factor sign-in. Besides your password, our sign-in service offers you a second step when you sign in: an authenticator app or a security key. That second step is not required. You can also add a passkey; with it, you sign in without a password. If you add an authenticator app, the sign-in service keeps, encrypted, the secret key that app makes your codes with. If you add a security key or a passkey, it keeps its public key and the name you give it; we never receive the private key that belongs to it. The sign-in service records every failed attempt: a wrong password, a wrong code from your authenticator app, or a security key or passkey that is not recognised. It keeps the time, and for an attempt to sign in also the browser and the IP address. It never keeps the password or code that was tried. After 10 wrong passwords in a row, it locks your sign-in account until we unlock it at your request. All of this serves to protect your sign-in account. A second step or passkey is kept until you remove it or your sign-in account is removed; what the sign-in service's history keeps of it, and of every failed attempt, stays as long as §9 says.
Your account with us. Your email address, the identifier our sign-in service gives you, the organisation you belong to (in the app, your household's space is called an organisation), your role in it (during the Alpha, owner or admin), when you were invited and when you joined, and which versions of the Alpha conditions, the terms and this policy you accepted, in which language, and when.
During the Alpha, your Google address. If you want to connect a Google account, you give us its address, and we enter it in the list of test users that Google keeps for our app (§6).
Invoices and the usage figures behind them — how many migrations ran at once, and how much data was moved. During the Alpha nothing is charged: there are no invoices, and you register no payment method. Once there are payments, our payment provider handles them (§7); we do not ask for or keep your card number. If you fill in invoice details on the Billing page anyway — a name, an address, a VAT number, the email address your invoices are sent to — we keep them until your data is erased, and if you ask the app to check a VAT number, it is checked with the European Commission's VIES service.
4.5 Support and operational logs
Support mail. Anything you send to support@ownpace.eu. It arrives in a mailbox that our mail provider holds for us (§7). The same mailbox keeps a copy of the mail the service sends, such as sign-in codes, progress summaries and the notices you ask us to send.
Reporting a problem. During the Alpha, Report a problem in the app's menu sends your report as an email to support@ownpace.eu, through our mail provider (§7). The mail holds what you wrote and your sign-in address, so that we can answer you, and these facts, which the form lists before you send: the page you were on (without the secret part of a link), the reference and kind of an error if there was one, your organisation's identifier and status, your role, the version of the service, the state of the migration on that page and of each data type in it, whether access was given through a link, which providers its two accounts are with and whether their last test passed, whether the service is on hold or its scheduler has stopped, the name your browser gives itself, and what your browser tells the form: the language of the screen, your time zone, the width of the window, the version of the app in your browser when it is not the service's, the data type, side and migration of the error line you came from, and the reference of an error the app met in the five minutes before you opened the form. If you add a screenshot, it goes too. A screenshot shows whatever was on your screen, such as subjects, names and addresses, so look at it before you send it. Report this link, on a page reached through a grant link or a progress link, sends what the person wrote and the facts of that link the same way: the organisation and the migration, who made the link, the two accounts, and whether access was given; and an address only if they give one. A report contains the content of your mail, files or calendars, a subject, a folder name or a provider's error text only if you put it in what you write or in the screenshot.
Server logs record that requests happened, for the app and for this website: the time, your IP address, which NetBird passes on to us (§7), the page asked for (without the secret part of a link), the page you came from, what your browser says it is, and error codes. NetBird also keeps its own log of each request; §7 says what it holds. Logs are written so that credentials and message content do not appear in them. They are not free of names, though. When a step of a migration fails, the provider's own error text is written to the log of the process that met it, beside a reference, so that we can help you with it; that text can name a folder, a file or an address. And a request for access is logged with the email address it gives, as is our decision on it.
From these logs we also count visits to this website (pages, the site you came from, the kind of browser), as totals only, which identify nobody.
What the people who run the service can see. To run and support the service, the people on our side who operate it — during the Alpha, one person — can view service metadata about your account on our support screens: your organisation's name and status; its members' addresses and roles, and the identifier our sign-in service gives each of them; the names of your connections and migrations (a connection is named after the account's user name or address, unless you rename it); each migration's state and failure category; invoice summaries; how many items are waiting on a decision from you; and your organisation's log of who did what and when, without the details. They can also look up which organisation an address belongs to, and download the log of who did what, with its details, in which every address and file name is replaced by a pseudonym. The support screens cannot show your content. Message bodies and subjects, folder and file names, calendar entries, credentials and stored error text are not shown on any support screen — the screens are built without access to them, which you can verify in the source code rather than take on trust. Every such view is itself recorded — who looked, at whose account, at which screen, and when, and for a search, what was searched for — in a log the app cannot change. What it records about your account goes when your data is erased. A search by address and a download of the log are recorded without an organisation; they stay after that, and are deleted 12 months after they were recorded (§9). Ask us, and we send you what that log records about your account. Our data-processing agreement (§5 there) makes the same commitment to organisations.
Outside those screens. The person who runs the machine can technically reach the database, and the key that protects your credentials. That access is there to keep the service running and to repair it. When we look into a problem, it can show us what §4.2 keeps, such as a subject or a file name, and we look no further than the problem needs. Access this way is not recorded in the log above.
Nobody at Ownpace reads your mail, files, contacts or calendars. The exceptions are the ones §6 lists for Google data, and they hold for every provider: your own explicit request about specific items (a screenshot you add to a report is one), what security or the law makes necessary, and aggregated figures that identify nobody.
4.6 People who are not our customers
A migration touches people who never signed up with us. This is what we hold about them.
- The people you migrate for. To group a person's migrations you give them a name, and if you like an email address for their grant links. We keep both until you delete that person or your data is erased.
- A family member whose account you migrate. If you send them a grant link, they sign in at their own provider and give Ownpace access themselves, from a page that says who asked, from which account and to where. We keep that access (encrypted, §4.1), the address of their account, and when the link was made, used and ended. They can withdraw the access at any time. On their progress page, that deletes it here, and revokes it at their provider where the provider allows that. At their provider, it makes what we hold useless, and we delete it when you delete the migration or your data is erased. To connect a Google account, its address must also be on Google's list of test users (§6).
- People you shared files, folders or calendars with. When you ask the app to check your sharing, it keeps a list of who had access to what at your old provider: their address, the name of the file, folder or calendar, and their role. If you ask the app to tell them where their shared items went, each of them gets an email from support@ownpace.eu for each kind of item shared with them, such as calendars or files, once that kind has been switched over, with your note and the names of the items; and again only if you choose to send it again. A copy of each such email stays in our support mailbox for as long as §9 says (§4.5). The list goes when you delete the migration it belongs to, or when your data is erased.
- People you invite into your organisation: their address, their role, and whether they joined. Each gets an email from support@ownpace.eu that says who invited them to which organisation and where to sign in, and again only if you choose to send it again. A copy of each such email stays in our support mailbox for as long as §9 says (§4.5).
- People who report a link they were sent: see §4.5.
- Correspondents, and everyone else in your mail, contacts and calendars: only what §4.2 keeps about each item. Their name or address can appear there in a subject, as a contact's name or in an error text, and a distribution list keeps its members' addresses.
5. Why we hold it, in GDPR terms
| What | Purpose | Lawful basis |
|---|---|---|
| Credentials, ledger, the count when you review your migration | Performing the migration you asked for | Contract, including steps you request before one (Art. 6(1)(b)) — on your instructions as processor for an organisation; as controller for a household migration (§3) |
| Your request for access | Deciding whether to let you in, and telling you | Steps you ask for before a contract (Art. 6(1)(b)) |
| Your account and sign-in account, invoices, usage figures | Providing the service, letting you sign in safely, and billing for it | Contract (Art. 6(1)(b)); legal obligation for invoice retention (Art. 6(1)(c)). No invoices during the Alpha |
| The record of failed attempts, and the lock on your sign-in account after 10 wrong passwords in a row (§4.4) | Protecting your sign-in account from use by someone else | Legitimate interests (Art. 6(1)(f)) — yours as much as ours |
| Your Google address on Google's list of test users (Alpha) | Letting Google allow the connection you ask for | Contract (Art. 6(1)(b)) |
| Other people's data (§4.6): in what you migrate, a family member's access and address, the people you invite, and the mail to people you shared items with | Carrying out the migration you asked for, letting in the people you invite, and telling people, at your request, where their shared items went | Legitimate interests (Art. 6(1)(f)): yours, in moving your household's mail and files, and ours, in doing it; the limits in §4 and §9 protect theirs |
| The audit log of who did what in your organisation, and when | Showing you, and us, what was done in your organisation and by whom | Legitimate interests (Art. 6(1)(f)) |
| The copy made right before an update | Undoing a failed update, so that your data stays intact | Legitimate interests (Art. 6(1)(f)) |
| Server logs, for the app and this website | Keeping the service secure and working, and counting visits in totals | Legitimate interests (Art. 6(1)(f)) |
| Support mail and problem reports | Answering you, and fixing what went wrong | Contract / legitimate interests (Art. 6(1)(f)) |
| Support read-log (which of us viewed which account metadata, and when) | Accountability for our own access to your account | Legitimate interests (Art. 6(1)(f)) — yours as much as ours |
We do not use your data for advertising, we do not profile you, and we do not sell or rent your data to anyone. There is no analytics tracker on the application or on this website; we count visits to this website only from our server logs (§4.5). The app keeps your sign-in in your browser's own storage until you sign out, and remembers your language and a few choices there; it sets no cookie of its own, and neither does this website. Our sign-in page sets the cookies that signing in needs. This website loads nothing from other servers.
We make no decision about you by automated means alone: a person decides every request for access. Only the lock after 10 wrong passwords in a row (§4.4) happens by itself, and we lift it when you ask. To take part, you give us your email address; to connect a Google account during the Alpha, you also give us its address. Without them we cannot let you in, or connect that account.
6. Google user data — the specific commitments
Ownpace's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Concretely, and in our own words:
- We use Google user data only to provide the migration you configured — reading your source account and writing it to the target you chose — and to show you its progress.
- We do not transfer Google user data to anyone, except to the migration target you yourself selected; to people you yourself ask us to tell where a shared item went (§4.6); to NetBird GmbH, which carries your connections to us, and to the provider that carries the service's mail (§7), each only for that; and where the law requires it.
- We do not use Google user data for advertising of any kind.
- We do not allow humans to read Google user data. The exceptions are the ones the policy permits and no others: your own explicit request for specific items, what is necessary for security or to comply with the law, and aggregated figures that identify nobody.
- We do not use Google user data to train any machine-learning or AI model, general or otherwise.
Ownpace offers Google as a source only: there is no Google target to choose.
During the Alpha: Google's list of test users. While Ownpace's app at Google is in Google's test phase, Google lets an account connect only if its address is on that app's list of test users. So before you connect a Google account, you give us its address, and we enter it in that list at Google. The same goes for the Google account of a family member you send a grant link to. We take your address off the list when your data is erased. A family member's address comes off at the same time, or sooner if you or they ask (Alpha conditions §10). In the test phase, Google also ends a connection after about seven days; you then connect again (Alpha conditions §9).
You can revoke Ownpace's access to your Google account at any time at myaccount.google.com/permissions, or by deleting the app password you issued.
7. Who else touches it
During the Alpha, the service, its databases, our sign-in service and this website run on a machine we administer ourselves, in the Netherlands.
| Sub-processor | What for | Where |
|---|---|---|
| NetBird GmbH | Carrying your connections to app.ownpace.eu, id.ownpace.eu, status.ownpace.eu and www.ownpace.eu through to our machine. It ends the encryption (TLS) of those connections, so what passes through them, such as what you type when you sign in and what the app shows you, passes through it readable. It carries them on to our machine through an encrypted tunnel (WireGuard). It keeps its own log of each request for 7 days: the time, the IP address and a location derived from it, the page asked for, including the secret part of a link, how much was sent each way, and the answer's status and how long it took | Germany (EU) |
| Proton AG | Sending the service's mail, such as sign-in codes, our answer to your request for access, progress summaries, and the notices you ask us to send. Holding our support mailbox, support@ownpace.eu, where your mail to us and, during the Alpha, problem reports arrive, and where a copy of each mail the service sends is kept (§4.5) | Switzerland, outside the EU (§8) |
This table is the complete list of our sub-processors. If the service moves to a hosting provider after the Alpha, we name that provider here, and tell you, before any of your data goes there (Alpha conditions §11). Business customers are notified before a sub-processor is added, with the right to object as set out in the DPA; everyone else gets the same change notice through §13.
Mollie B.V. (Netherlands, EU) handles card and direct-debit payments. As a licensed payment institution it processes your payment data under its own responsibility and privacy policy — an independent controller, not our sub-processor. We do not ask for or keep your card number. During the Alpha nothing is charged, so Mollie receives nothing about you.
Inside your organisation, what the service holds is visible to its owner and its admins; the Alpha conditions ask you to invite nobody (§8 there). A progress link shows whoever holds it the counts and states of one migration, never its content.
Your migration's source and target providers are not our sub-processors — they are your own accounts, and your relationship with them is yours.
Beyond what this policy names, we give your data to others only where the law obliges us to.
8. Where it is, and where it is not
The service runs in the European Union. One party in the table above is outside it: our mail provider, Proton AG, is in Switzerland. The European Commission has decided that Switzerland protects personal data adequately (Art. 45 GDPR; Commission Decision 2000/518/EC), so the GDPR asks for no further safeguard for that transfer. During the Alpha there is one more step, which you ask for yourself: to let you connect a Google account, we enter its address in the list of test users that Google keeps for our app (§6). Apart from these, and a target you choose outside the EU (below), there is no transfer of your data to the United States or any other third country by us.
Two things you choose yourself can reach the United States. If you report a vulnerability through our form on GitHub (§11), GitHub keeps your report, in the US. And if your mailbox, or that of someone you ask us to write to, is at a US provider, our mail to it is delivered there.
That is not a formality but the core of the product: moving off a US-hosted provider makes little sense through a migration tool that is itself hosted in the US, so ours is not.
If your migration's target is outside the EU, your data goes there because you chose that target. We show you the target before anything is written.
9. How long we keep it
| What | Kept for |
|---|---|
| Credentials | Until you delete them. The access on a connection goes when you delete that connection; the app lets you once no migration uses it. Access a family member gave through a grant link goes when you delete that migration, or when they withdraw it on their progress page. A finished migration keeps the access you gave us, so that you can resume it. If you close your account, no new work starts with any of it from then on. Work that is already running finishes what it is doing at that moment, and then stops. A pass of a migration can carry on for about fifteen seconds after the close, and then finishes what it began. If you connected a whole Microsoft 365 organisation, a daily check that had already started can still read, once, the list of its mailboxes, and the list of its distribution lists and groups with their members' addresses (§11 of the terms). All of it is destroyed when your data is erased. Each time, we also revoke the access at the provider, where the provider allows that. |
| The migration ledger (§4.2), and what each migration keeps beside it, such as the list of what was shared (§4.6) | Until you delete the migration; then deleted with it. Otherwise until your data is erased. |
| The count when you review your migration (§4.3) | With the migration it was made for: until you delete that migration, or your data is erased. |
| What belongs to your organisation rather than to one migration: its members and invitations, the distribution lists a migration found, and the audit log of who did what, and when | Until your data is erased, also after you delete the migration that found them. |
| Which versions of the Alpha conditions, the terms and this policy each member accepted, in which language, and when (§4.4) | Until your data is erased, also after that member has left your organisation, so that it stays on record who agreed to what. |
| The people you migrate for: each one's name, and an email address if you gave one (§4.6) | Until you delete that person, or your data is erased. Deleting a migration does not delete the person. |
| The record of each pass: when it ran, and what it counted | During the Alpha: until your data is erased. |
| A pass's log lines | 60 days. |
| The app's own errors and warnings (a category and a reference, no text) | 30 days. |
| Your account, your organisation and your sign-in account | While your account exists. When you close it, you choose when your data is erased: at once, or after 7, 30 or 90 days. On that day we also remove your sign-in account from our sign-in service, and take your Google address, and any family member's, off Google's list of test users (§6); these are steps we take by hand. |
| A second step or passkey you added to your sign-in account: an authenticator app's secret key, encrypted, or a security key's or passkey's public key and name (§4.4) | Until you remove it, or your sign-in account is removed. What our sign-in service's history keeps of it stays as long as the row on that history says. |
| The lock on your sign-in account after 10 wrong passwords in a row (§4.4) | Until we unlock your sign-in account at your request, or it is removed. |
| The history our sign-in service keeps of your sign-in account: every change to it, such as your name and email address as they were and a second step or passkey you added, also after you removed it; your sign-ins; and every failed attempt, such as a wrong password (§4.4) | As long as we run this sign-in service, because it cannot remove them. Removing your sign-in account adds an entry to that history; it does not remove the earlier ones. |
| Your request for access (§4.4) | While it is open. Declined: deleted 30 days after our decision. Granted: kept with your account, and erased with it. |
| A sign-in account that someone created at our sign-in page but that we never let in, and that therefore opens nothing (§4.4) | 30 days after it was created, unless a request for access with that address is still open. |
| The sign-in account of someone who was removed from an organisation and is no longer a member of any (§4.4) | 7 days after they were removed, unless a request for access or an invitation with that address is still open. |
| Support mail and problem reports, and the copies of the service's own mail in the same mailbox (§4.5) | Until the question or problem is resolved, and then 6 months more. The same holds for the copies of the service's own mail. Then deleted from the mailbox. |
| The record of what we viewed on your account (§4.5) | Until your data is erased. What is recorded without an organisation stays after that: a search by address, and a download of the log of who did what. These are deleted 12 months after they were recorded. |
| The copy made right before an update | Until the update it was made for is shown to work, and never longer than 7 days. It holds the service's database and our sign-in service's database; before the system that runs the background tasks is upgraded, also its database. Such a copy is made only to undo a failed update, and it does not leave the hosting environment. Data erased from the service can remain in it for at most 7 days. |
| Records of the background tasks that run your migrations (identifiers, counts, and a category and a reference for an error; no names, addresses or content, apart from the reason one of us types when a switch-over is undone) | Until the end of the Alpha at the latest: then the background tasks start with an empty history. They are not deleted when your data is erased. |
| Server logs (§4.5) | Until the part of the service that wrote them is replaced: for the app and this website, at each update of the service; for our sign-in service, when its version or its settings change; for a background task, when its run ends. There is no fixed period. |
| The visit totals counted from this website's server logs (§4.5) | As long as we run this website. They are totals only, and identify nobody. |
| Invoices and the usage figures behind them | 7 years, because Dutch tax law requires it, in our bookkeeping system, which issues them. When your data is erased we delete our own copy of your invoices and keep only their numbers, so that each can still be found in the bookkeeping. During the Alpha nothing is charged: there are no invoices, and the usage figures go when your data is erased. |
During the Alpha we make no backups, apart from the copy made right before an update, in the table above (Alpha conditions §6). During the Alpha we close your account within 7 days of your request, and tell you the date on which your data will be erased (Alpha conditions §10). The erasure removes from the service's database everything this table keeps until your data is erased; your sign-in account and the Google addresses on Google's list follow on the same day, by hand. What the table says stays after erasure stays as it says. Apart from that, what remains is a record that an erasure took place, with dates and counts and no name or address. If we ever discontinue the service, §11 of the terms says what you get.
10. Your rights
Access, rectification, erasure, restriction, portability, objection, and withdrawal of consent where consent is the basis. Write to support@ownpace.eu; we will not charge you and we will not make you explain why. We may ask you to confirm that a request is yours, for example by writing from the address your account uses. These rights hold against us wherever §3 makes us controller — and the people in a migrated mailbox, and anyone else §4.6 names, who never held an account, can write to the same address.
Your right to object. Where we rely on legitimate interests (§5) — our logs, the record of failed attempts (§4.4), the audit log, the record of what we viewed on your account, the copy made before an update, and the data of other people in a migration — you may object at any time, on grounds relating to your situation. We then stop, unless we have compelling legitimate grounds that override your interests, rights and freedoms, or need the data for a legal claim.
Portability deserves a note. This whole product exists because moving your own data between providers is harder than it should be. If you want your data out of Ownpace, you already have it — it is in the target account we wrote it to. What we hold about you ourselves (§4), we send you in a common file format if you ask.
You may complain to a supervisory authority, in particular in the country where you live or work. In the Netherlands that is the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).
11. Security
Credentials encrypted with AES-256-GCM, under a key kept apart from the database that holds them: in the service's own configuration, and in the settings of the background tasks, both on the same machine. Connections to your providers are encrypted with TLS, and the provider's certificate is checked. An address you type yourself that starts with http:// is reached as typed, and that connection is not encrypted. Organisations are kept apart in the database itself through row-level security, for the app's requests and for the background tasks that run migrations. Our support screens read through views that pass it by design, and each of those views checks that the reader is one of the people who run the service (§4.5). The scheduled jobs that span organisations do not work under it yet; there, each query's own filter on your organisation keeps them apart. Logs written to keep credentials and message content out (§4.5 says what they can still name).
If a breach happens. If a breach of security affects your personal data, we report it to the Autoriteit Persoonsgegevens where the law requires that, and we tell you.
No system is perfect. If you find a vulnerability, report it privately through our form on GitHub or, if you have no GitHub account, write to support@ownpace.eu. We confirm that we received it within five working days. Please ask us before you test against the service itself: it holds other people's access to their accounts. We will not threaten you for telling us.
12. Children
The service is not directed at children under 16 and we do not knowingly create accounts for them. A household migration a parent sets up may of course move a child's account — that is the household case §3 describes, and the parent stays the one who sets it up. A grant link for a child under 16 is completed by the parent together with the child. The child's Google address goes on Google's list of test users (§6) at the parent's request.
13. Changes
Material changes are notified by email to account holders at least 30 days before they take effect, and every version of this policy stays available in its history on GitHub, so you can see what changed. That history also shows drafts that were never published; their version line says so. The version number and date at the top of this page show which version applies.
During the Alpha, the Alpha conditions (§11 there) set how you hear about what follows it, including a move to another hosting provider: at least 7 days ahead, by email. None of your data goes there unless you accept the new conditions.