Privacy notice

Last updated 31 October 2026.

This notice explains what personal data Availashare collects, why, who receives it, where it is kept, for how long, and how you can use your rights. It is written to be read in full, but the summary below is accurate on its own.

Availashare is provided by:

88mph Tech
United Kingdom

At a glance

We are the data controller for everything described here, including the copies of your calendars.
Availashare reads your calendars. It cannot create, change or delete an event.
We keep a copy of the events from the calendars you include, from 30 days in the past to 180 days in the future, and replace it every 15 minutes.
Anyone who holds a share link can read the feed behind it, open it as a web page, or ask it for busy and free times, without signing in. You decide who receives a link and you can revoke it at any time.
The application and the database run in Amsterdam, in the Netherlands, on infrastructure operated by Railway Corporation, a United States company. Railway keeps its logs and runs its platform in the United States.
We set one cookie, the one that keeps you signed in. There are no analytics, advertising or tracking technologies on this site.
We do not sell personal data, do not use it for advertising and do not use it to train models.

1. Who we are and our role

88mph Tech, based in the United Kingdom, is the data controller for your account, the Google accounts you connect, the calendar addresses you add, the copies of your events, your settings, your share links and the messages you send us.
Availashare is built for individuals. We do not act as a processor on your behalf. If you use Availashare for an organisation and need a data processing agreement, write to us before you rely on the service.
Google, Apple, Microsoft and any other publisher of a calendar you connect or add remain separate controllers of the original calendar. Their notices govern what they do with it.
The people who hold a share link receive the feed because you gave them the link. What they do with it afterwards is between you and them.

2. The personal data we hold

Your account

Your email address and name, taken from the first Google account you signed in with, and the date you joined.

Connected Google accounts

For each Google account you connect: the Google user identifier, email address, name and profile picture address that Google sends us; the access token and refresh token that let Availashare read the account's calendars; the time the access token expires; the time we last refreshed the account's calendar list; and the last error Google returned, if any. The tokens are stored encrypted.

Your calendar list

For each calendar of a connected account: its name, description, Google calendar identifier, time zone, your access role, colour, whether it is the account's primary calendar, when it was last copied and the last error, if any. We keep the list so that you can choose which calendars to include.

Calendars added by address

The address you pasted, stored encrypted and shown in full only once, on the preview screen; afterwards the dashboard shows only its host name and last four characters. We also keep the name you gave the calendar, its time zone, the validators the publisher sends with the file (ETag and Last-Modified) so that we can ask only for changes, and the time since which a fetch has been failing, if it is.

Copies of events

For each calendar you include in at least one virtual calendar, we keep the events that start between 30 days before and 180 days after the moment of each copy. For each event we keep: the event identifier and iCalendar UID, title, description, location, start and end, whether it is an all-day event, its status (confirmed or tentative; cancelled events are skipped), whether it marks you busy or free, its visibility, your own response to it (Google calendars only), a link back to the event, the identifier of the recurring series it belongs to, and when the source last changed it.

We do not keep attendee lists, organiser addresses, attachments, reminders or conferencing entries. An event marked private or confidential in Google, or marked CLASS:PRIVATE in a calendar added by address, is always shown as busy, whatever level of detail you chose. Titles, descriptions and locations are kept exactly as the source holds them, so they may contain names, email addresses or other details of people other than you. Section 4 explains how we treat those.

Virtual calendars and settings

The name, description and time zone of each virtual calendar; the availability rules you type for it (working hours, weekly busy blocks, busy dates, a minimum notice period, a rounding of times and the label used for busy blocks), which are settings rather than events read from a calendar; and for each source inside it: whether it shows full details, titles only or busy only, the title prefix, the busy label, the include and exclude keywords, whether all-day, declined or free events are skipped, and its order.

Share links

For each link: a random token of 32 characters, the optional label you wrote to describe what the link shows, the most it reveals (what the sources show, titles only, or busy only), how far ahead it reaches if you limited that, whether its web page is switched on, when it was revoked if it was, how many times its feed or its availability answer was fetched and when that last happened, and how many times its web page was opened and when that last happened. We do not record who fetched or opened a link, or from where.

Technical data

Our hosting provider records each request to the service: the requesting IP address, the path requested, the method and status, the browser or calendar application that made it, and the time. For a request to a feed or a share page the path contains the link's token. Our own application log on the same platform holds the same information without request bodies and cuts every link token to its first six characters. These logs are kept for up to 90 days. Availashare sets one cookie, _availashare_session, which holds your signed-in session; it is described in section 9.

Correspondence

The emails you send us and our replies.

Payment data

None at present, because paid plans are not open. Before billing starts we will update this notice with the payment provider's name and the data it processes. Availashare will never hold your full card number.

3. Why we use personal data and on what legal basis

Purpose	Data	Lawful basis
Signing you in and keeping you signed in	Account, session cookie	Performance of our contract with you
Reading and copying the calendars you include	Tokens, calendar list, calendar addresses, copies of events	Performance of our contract with you
Building your virtual calendars and serving their feeds to whoever holds a link	Copies of events, settings, share links	Performance of our contract with you
Showing other people's details that appear inside your events	Titles, descriptions and locations of events	Legitimate interests, yours and ours, as explained in section 4
Keeping the service secure and working	Request logs, error messages, fetch counters	Legitimate interests in running a reliable and secure service
Answering your requests and complaints	Correspondence, account	Legitimate interests, and legal obligation where a right is exercised
Keeping tax and accounting records once billing opens	Billing records	Legal obligation

We do not rely on consent. The screen on which you grant Availashare access to a Google account is Google's authorisation mechanism, not consent under data protection law, and you can withdraw that access at any time as described in section 6.

4. Other people in your calendars

Event titles, descriptions and locations often mention other people: the colleague you meet, the address of a friend, the name of a doctor. Availashare does not analyse, classify or extract any of that. It stores the text as the source holds it and shows it to whoever holds a link, exactly as the source would, unless the source or the link is set to titles only or busy only, a filter drops the event, or the event is marked private at the source.
We process these details because you chose to include the calendar and to share its feed. Our legal basis is legitimate interests: yours, in sharing your schedule with people who plan around you, and ours, in providing the service you configured. We have balanced that against the interests of the people mentioned. The data already sits in your calendar, it is kept for a short rolling window, it goes only to the people you gave a link to, and you have three controls: busy-only mode hides every detail, keyword filters drop events, and a link can be revoked at once.
We do not contact the people mentioned in your events, because we have no way to know who they are and writing to them would be more intrusive than the processing itself. This notice is public for them to read, and section 10 explains what they can ask of us.
A title such as the name of a clinic or a place of worship can reveal sensitive information. Think about that before you share full details, and use a busy-only link wherever the details are not needed.

5. Who receives personal data

Recipient	What they receive	Where	Why, and the safeguard
Whoever holds a share link	The feed behind the link and its web page, showing full events, titles only or busy blocks as you set it; and the availability answer, which carries busy and free times only, never titles, and can be read by software on any website	Wherever they are	Your instruction, given by sharing the link
Railway Corporation	Everything in section 2, because it hosts the application and the database	Application and database in Amsterdam, the Netherlands; logs, monitoring and platform operations in the United States	Hosting under Railway's data processing agreement, which includes the EU standard contractual clauses and the UK international data transfer addendum. Railway states that it is certified under the EU-US Data Privacy Framework and its UK extension.
Google LLC	Our requests to read your calendars, carrying the token of the connected account	United States	Your grant of access on Google's consent screen; Google's own privacy policy applies to your Google account
The publisher of a calendar you add by address (Apple, Microsoft, Google or another)	Our fetch requests: the address, our server's IP address and the identifier "Availashare calendar fetcher", every 15 minutes	Wherever the publisher's servers are	Your instruction, given by adding the address
Cloudflare, Inc.	Only the queries that resolve our domain name, made by DNS resolvers and not by you	Global network	Cloudflare does not receive any of the data in section 2

Nobody else receives personal data from Availashare. We use no analytics, advertising, email delivery or support tools that see your data. If we add a provider, this notice is updated before it starts.
We will disclose personal data where the law requires it, and will tell you unless the law forbids that.
If Availashare is sold or transferred to another operator, your data passes with the service under this notice, and you will be told before it happens.

6. Google API Services and Limited Use

Availashare asks Google for four permissions: openid, email and profile, which identify the account, and calendar.readonly, which allows reading the account's calendars and events. None of them allows Availashare to create, change or delete anything in your Google account.
Availashare's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
In practice this means that calendar data obtained from Google is used only to build the virtual calendars, views, feeds, share pages and availability answers you configured. It is not used for advertising, not sold, and not transferred to anyone except the people you give a link to, or where needed for security or to comply with the law. No person at 88mph Tech reads it, except with your permission to fix a problem you reported, to investigate abuse or a security incident, or where the law requires. It is not used to build or train any model.
We apply the same rules to calendars added by address, although Google's policy does not cover them.
You can withdraw Availashare's access at any time by disconnecting the account on your dashboard, which revokes the tokens at Google and deletes them together with the account's calendar list and events, or from your Google account permissions, after which the next copy fails and the dashboard asks you to reconnect or disconnect.
If we ever want to use Google data for a new purpose, we will ask for your permission before starting.

7. Where data is kept and international transfers

The application and the database run in Railway's Amsterdam region, inside the European Economic Area. Railway's request logs, application logs, monitoring and control plane are in the United States, and its staff in the United States can access the platform. Using Railway therefore involves a transfer of personal data from the United Kingdom to the United States.
That transfer rests on Railway's data processing agreement, which incorporates the EU standard contractual clauses and the UK international data transfer addendum, on Railway's stated certification under the EU-US Data Privacy Framework and its UK extension, and on our own assessment of the risk.
Feeds are served to the people you give a link to, wherever they are. Calendars added by address are fetched from wherever their publisher's servers are. Both follow from your instructions.

8. How long we keep personal data

Data	Kept until
Copies of events	Replaced at every copy, every 15 minutes. Events that leave the 30-day to 180-day window, or that were deleted at the source, disappear at the next copy. All events of a calendar are deleted at once when you remove the calendar from Availashare, disconnect the account it belongs to, or delete your account. If a source stops answering, the last copy stays in place until you reconnect, replace the address or remove the calendar.
Google tokens and calendar lists	Deleted at once when you disconnect the account, and the tokens are revoked at Google at the same moment. Deleted with your account.
Calendar addresses	Deleted at once when you remove the calendar; overwritten when you replace the address.
Virtual calendars, settings and share links	Until you delete the virtual calendar or your account. A revoked link stops answering immediately and stays listed as revoked on the calendar's page until then.
Your account	Deleted at once when you delete it from the dashboard, together with everything above. The tokens of every connected account are revoked at Google first.
Hosting and application logs	Up to 90 days, kept by Railway.
Database backups	Kept by Railway in the same region for a short period. Data you deleted leaves them as they expire.
Correspondence	Two years after the last message, or longer while a dispute is open.
Billing records	None at present. Once billing opens, invoices are kept for six years as UK tax law requires.

9. Cookies

Availashare sets one cookie and no other storage in your browser.

Cookie	Set by	Lasts	Purpose
`_availashare_session`	Availashare	Until you sign out or close the browser	Identifies your signed-in session and protects forms against forgery

The cookie is strictly necessary to provide the service, so it needs no consent and there is no banner. There are no analytics, advertising or third-party cookies, and no scripts from other companies on this site.

10. Security

Every connection to Availashare uses TLS, and browsers are told to use it for all future visits. There are no passwords to store, because you sign in with Google.
Google tokens and calendar addresses are encrypted in the database with keys that are kept outside it. The database accepts connections only from the application over a private network.
A share link's token is 32 random characters, which cannot be guessed. A revoked or unknown token answers with nothing, lookups are limited to 60 a minute from one address, and every answer behind a link tells browsers not to pass the address on and search engines not to index it. Feeds and share pages are also excluded in robots.txt. A share page carries no navigation, no account details and no script from anyone but us.
Events you marked private or confidential at the source are always shown as busy, whatever the link or the source is set to show, and the availability answer never carries titles.
When fetching a calendar by address, Availashare refuses private and internal network addresses, follows at most three redirects, stops after 15 seconds or 5 megabytes, and connects only to the address it checked.
Access to the production systems is limited to the operator.
If a personal data breach is likely to put you at high risk, we will tell you without undue delay, and we will report it to the Information Commissioner's Office within 72 hours where the law requires.
Your part: treat a share link as a key, prefer busy-only links where details are not needed, revoke a link that has reached the wrong hands, and keep your Google accounts secure. If an address you added leaks, reset it where the calendar is published and paste the new one.

11. Your rights and how to use them

Under the UK GDPR and, if you live in the European Economic Area, the EU GDPR, you have the right to access the personal data we hold about you, to have it corrected or erased, to restrict or object to its processing, to receive it in a portable format, and to complain to a supervisory authority.
Most of this you can do yourself. The dashboard shows every connected account, calendar, virtual calendar and link we hold. You can disconnect an account, remove a calendar, revoke a link or delete your whole account there, and each takes effect at once. Your feeds are standard iCalendar files that any calendar application can import, which is your portable copy.
For anything else, write to the contact address shown at the bottom of every page, from the email address of your account. We answer within one month. If a request is complex we may take up to two further months and will tell you why. We do not charge for this.
If you are not an Availashare user and you appear in someone's feed, you can object to that or ask for the data to be erased. Write to us with what you saw and, if you have it, the link. Because the copy is refreshed from the source calendar every 15 minutes, the lasting fix lies with the account holder: we will put your request to them, they can remove or restrict the event, switch the calendar to busy only or revoke the link, and we will tell you the outcome within one month. Where the law requires more from us, we will do it.

12. Complaints

If you are unhappy with how we handle your data, write to the contact address shown at the bottom of every page. We acknowledge a complaint within seven days and answer it within one month.
You can also complain to the Information Commissioner's Office at any time: ico.org.uk/make-a-complaint, telephone 0303 123 1113, or Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.
If you live in the European Economic Area, you can complain to the data protection authority of your country instead.

13. Children

Availashare is for adults. You must be at least 18 years old to use it, and we do not knowingly hold an account for anyone younger. If you believe we do, tell us and we will delete it.

14. Changes to this notice

Any change is published on this page with a new date at the top.
If a change matters to you, for example a new recipient, a new purpose or a longer retention period, we show a notice on the dashboard at least 14 days before it takes effect.
A new use of data obtained from Google starts only after you have agreed to it.

15. Contact

88mph Tech, United Kingdom. See also the terms of service.