Privacy

What we store

Your custody pattern as a repeating shape, the hours you said you could go out, any dates you blocked, your time zone, and your first name. If a date gets agreed, the time of that date. If you gave us an email address, that too.

Your first name is the only thing your match sees about you. We never ask for a surname, a phone number, a photo, a location, or anything at all about your children, and there is nowhere to enter any of it. There is still no account and nothing to log into.

About the email address

It is optional. Without it the product works exactly the same, and the only way back to a link is the address bar or the device you made it on.

If you give it, we use it for these things: sending you your own link, telling you when your link has an answer, telling you when a time is suggested, telling you when one is agreed, and sending you your list of links if you ask. Your match never sees the address, and we never send it to them.

It is stored encrypted inside the same sealed record as everything else, so a copy of our database still reads as nothing.

No subject line contains a name, a date or a schedule, and neither does the first line of any message, so a notification on a locked phone shows nothing about who or when. Open the message and it does tell you: who answered, roughly how much time you share, and what the suggested time is. That is what the message is for. We never put your full pattern in one.

The honest cost: an email in an inbox is a durable copy of a link, and inboxes get breached and read by other people far more often than databases do. Our mail also passes through Gmail, which keeps its own copy of what we sent, under its own retention rather than our fourteen days. If any of that is a risk for you, do not give us an address.

“Email me my links”

So that you can get back to a link from a device that never had it, we keep an index of which pairings belong to which address. This is the one part of the system that is weaker than the rest, and it is worth being precise about why.

Everything else here is locked with a key that exists only in your link, so we could not read it if we wanted to. That trick cannot work for a list you look up by your address. Instead the index is filed under a scrambled form of your address, mixed with a secret held on our side. Our database alone opens nothing, and the secret alone opens nothing, but somebody holding both could open the index.

Be clear about what opening it would be worth, because it is more than it sounds. The index holds links, and a link is the key to its pairing — so somebody who opened your index could then read those schedules. It is not a lesser copy of the same data. It is the one door in this design that a copy of our database plus a secret we hold could open, and we would rather say that than let “links, not schedules” do quiet work.

Two things bound it. The index disappears along with the last link in it, so it is never a growing store of old keys. And the only thing we ever do with it is send mail to the address it belongs to, so someone typing your address into that box sends the list to you and learns nothing themselves.

If that trade is not one you want, do not use this feature. Leave the address box empty and nothing about you is ever filed under your address at all.

How it is stored

Encrypted, with a key derived from the secret part of your link — the part after the #, which your browser does not send as part of the address it requests. The key is never stored, and the secret is never written to our logs.

Be precise about what that is and is not. It is protection against a stolen database. It is not end-to-end encryption, and it does not mean we cannot see your schedule. To show you an overlap our server has to receive the secret from your link, which the page sends in a request header, and derive the key for that one request. We do not keep it. But a sentence saying we could never read your schedule would be false, and an earlier version of this product made claims in that direction that we have had to withdraw.

The practical effect: if our database were copied, stolen, or demanded in full by a court, the pairings in it would come out unreadable. Someone holding your actual link can read that one record. Nobody holding only the database can read any of them.

The exception is the index described above, and it is a real one. If you gave us an address, somebody holding the database and our secret and your address could open your index, and from there your pairings. That is one party holding three things rather than one, and it is strictly weaker than the rest of this page. It applies only to people who used the address feature.

Everything deletes itself after fourteen days — the pairing, and the index entry that points at it. Either of you can delete it instantly, at any time, from the link itself, and that removes both schedules and both index entries at once.

The link itself

Anyone holding your link can answer it. Once someone has, it closes, and only the two of you can see anything. Send it to one person rather than posting it anywhere.

What we measure

Counts, and only counts. How many links were made, opened, answered, and turned into a date. The numbers carry no identifiers, no addresses, no device fingerprints, and go to no advertising or analytics company. Nothing in them records who did any of it, or when.

The honest split: that is our analytics. Serving a website is a separate thing. Our hosting provider handles your IP address to deliver pages to you and to stop one person hammering the service, the same as any website, and we use a short-lived scrambled form of it to count requests for rate limiting. We do not store it beside anything you entered and we never see a list of who visited.

We do not respond to Do Not Track or Global Privacy Control signals, because there is no tracking here for them to switch off. No third party collects anything about you across this site or any other.

Who else touches it

Three companies are involved in running this, and it is fair that you know what each one can see.

• Netlify hosts the site and stores the encrypted records. It sees requests and IP addresses as any host does. What it stores for us is ciphertext.
• Google carries our outgoing mail, so if you gave an address, Google handles the messages we send you and keeps its own copy of them under its own retention rather than our fourteen days.
• Namecheap holds the domain name. It sees nothing you enter.

Nobody else. No advertising network, no analytics company, no data broker, and nothing is given or sold to anyone for any purpose.

What you can actually do about your data

We are not going to publish a list of rights we cannot deliver. Here is what exists.

Everything you enter is scheduled to be deleted within fourteen days. Either party can delete a pairing immediately from their own link, and that ends it for both of you. Holding the link is what authorises that, because it is the only proof of ownership this system has.

Deleting removes the record from the service. It does not recall a screenshot, a forwarded link, a browser history entry, a calendar file someone already downloaded, an email already sitting in a mailbox, or copies held by our hosting and email providers under their own retention.

There is no account, so there is nothing to log into, nothing to export, and nothing for us to look up for you. If you write and ask what we hold for a given email address, we will not answer. That is deliberate: we cannot confirm the person asking owns that address, and the answer would tell anyone who guesses an address whether that person has used OffWeekend. That is precisely the answer this system is built not to give.

If you gave us an email address and want it out of the list we use to send you your own links, write from that address and we will remove it. We will not tell you whether it was there. Please do not email us your link — whoever reads that message can open the pairing.

Where this is available

Not in the UK, the EU, the EEA or Switzerland. Handling this kind of information properly under those laws takes more than we have built. We block those regions rather than process data we cannot yet defend processing.