Privacy Policy

1.Who We Are

White Rabbit Foundry Limited ("WRF", "we", "us", "our") operates the Emily virtual assistant service. We are registered in England and Wales. We act as a data controller under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. For privacy enquiries or to exercise your rights, contact us at: help@emily-wrf.com.

2.Data We Collect

We collect and process the following categories of personal data:

• Account data: name, email address, organisation name (optional), password hash (stored by Firebase Authentication).
• Email content: the content of emails you send to Emily's address, including any attachments, for the purpose of processing your instructions.
• Chat messages: messages you send via the in-app chat interface.
• Email from other people to your Emily address: when someone else emails your Emily address, Emily passes their message to you and acts on your reply. If the message asks to meet or talk, we keep a short record - their name, email address and the subject line, never the message body - for up to 14 days, so that a one-word "yes" from you is enough for Emily to arrange the meeting.
• Third-party contact data: names, email addresses and any details you record (phone, organisation, role, notes) for individuals you ask Emily to contact. Emily also auto-saves a contact (email and a name) for people you email, so it recognises them next time; you can turn auto-save off, edit, or delete any contact from your Contacts page.
• Usage and activity data: actions taken, timestamps, job logs, and usage counts for billing and service improvement. When you ask Emily for something she can't do yet, we keep a note of that request (its subject and wording) so we know what people want built next; it is held with your account and deleted with it.
• Repeating meetings Emily sets up: the meeting's title, its guests' email addresses, its times and repeat pattern, and a reference to the calendar event or invitation, so Emily can move or update the series later when you ask. If you have not connected a calendar, invitations are sent as calendar files (.ics) from Emily's own address, and the online meeting link for a virtual meeting is created on WRF's Microsoft 365 account.
• Billing data: processed entirely via Stripe. WRF does not store card numbers. We store Stripe customer and subscription IDs.
• Memories: facts and preferences you ask Emily to remember, stored to personalise future interactions.
• Connected calendar data (optional): if you choose to connect a Microsoft, Google or Apple calendar, we access your calendar free/busy information and event details (times, titles, attendees, locations, meeting links) to show your availability and manage meetings, and we create, update or cancel events at your request. We only access calendars; we do not access your email or mailbox through these connections. See section 13.
• Connected Zoom account (optional): if you choose to connect a Zoom account, we create a Zoom meeting on your account when you ask Emily to arrange a meeting, so the join link can be added to the invitation, and we read your Zoom account email address once at connection to show which account is linked. We do not read, list or modify your existing Zoom meetings. See section 13.
• Connected AI assistant access (optional): if you connect Emily to ChatGPT, Claude or another compatible assistant, we process connection permissions, short-lived authorisation records and hashed access credentials so that assistant can use the Emily tools you approve. See section 14.
• Mobile number and text messages (optional): if you link a mobile number to text Emily, we store that number on your account once you have confirmed a code texted to it, together with the content of the texts you send her and her replies, which are handled exactly as an emailed or in-app request would be. We may also use a linked number to tell you about a problem you need to know about and cannot see by email - for example, that your inbox is rejecting Emily's emails. See sections 5 and 7.
• Files and documents you store: files you upload through the dashboard, or ask Emily to keep from an email attachment, together with text extracted from them so Emily can use their contents; for organisations, documents uploaded to the organisation's shared library.
• Push notification subscriptions (optional): if you allow browser notifications, we store the subscription your browser issues - an address at your browser vendor's push service, the keys needed to encrypt a message to it, and the browser's user-agent string - so we can alert you when Emily needs you. Notification contents are encrypted so that the push service cannot read them. We only send notifications through the Google, Mozilla, Apple and Microsoft push services.
• Technical data: authentication tokens, IP addresses (for security), and error logs.
• Sender authentication results: for email sent to Emily's addresses, we record the sender-authentication checks reported by our email provider (SPF and DKIM results, the sending domains, and any spam classification) so we can tell genuine messages from attempts to impersonate you. See section 9.

3.How We Use Your Data

We process your personal data for the following purposes and on the following lawful bases:

• Providing the Service (contract): processing your emails and instructions, scheduling meetings, setting reminders, sending replies.
• Billing and account management (contract): creating and managing your subscription, invoicing, and billing communications.
• Service communications (legitimate interest): sending operational emails such as confirmations, updates, and security alerts.
• Telling you when an email didn't arrive (contract and legitimate interest): our email provider tells us when a message Emily sent was delivered or bounced. To match that report to you, each email Emily sends carries an internal reference to your account and request - an identifier with no meaning outside our systems, which a recipient can see if they inspect the message headers. If an email Emily sent to someone on your behalf bounces, she tells you which address failed and why (for example, that it doesn't exist), stops chasing that address, and asks for the right one. If your own inbox is rejecting her emails - for example because it is full - we show a notice on your dashboard, send a push notification to devices where you have allowed them, and text your linked mobile if you have one. The notice clears itself once an email to that address is delivered again.
• Tips, check-ins and Emily product updates (legitimate interest): Emily may send you getting-started tips and nudges, occasional check-ins and questions to personalise her, and news about Emily features. We tell you about these when you sign up. We do not send any of these to sign-ups that look automated (see section 9).
• News, our other products, partner offers and marketing texts (consent): we send news from White Rabbit Foundry, information about our other products and services, offers from companies we work with, and updates by text only if you agree. We ask on the sign-up form, with the box left unticked, and record your answer; accounts created before 6 October 2026 keep the setting they already had. Partner offers are sent by us - we never give your details to partners. Texts of this kind go only to a mobile you have linked.
• Your choices: you choose which of these you get, one by one, in Settings › Preferences › Emails & texts from us, and you can change your mind at any time. You can also reply "unsubscribe" to any of these emails (or "no more tips" or "no more check-ins" to switch off just those), or email help@emily-wrf.com. None of this affects emails about your account, billing or security, reminders and updates you set up, or Emily's replies to your requests.
• Service improvement (legitimate interest): analysing usage patterns in aggregate to improve performance and features, and reviewing the notes of requests Emily could not do yet (see section 2) to decide what to build.
• Account security and anti-impersonation (legitimate interest): confirming that you control the email addresses registered to your account, checking sender authentication on inbound email, holding messages that appear to impersonate an account holder so they are not acted on, and checking new sign-ups for signs of automated abuse - so that our sign-up emails cannot be used to flood an address belonging to someone who never asked for them. See section 9.
• Replying to people who email Emily without an account (legitimate interest): if someone who is not a customer emails one of Emily's addresses, we may reply once introducing the Service - but only where their email passes sender authentication (SPF/DKIM) and does not look like spam, automated mail or phishing, so we never confirm a live address to a scammer. We keep a record of that address solely so that we never send it twice, and for no other purpose - it is not added to a mailing list, not used for any other campaign, and not shared. If you would rather not receive that reply, or want your address removed, email help@emily-wrf.com and we will action it.
• Legal compliance (legal obligation): retaining records required by law.
• Beta feedback (consent / contract): if you are a beta participant, we may contact you to request feedback as agreed at registration.

We do not sell your personal data to third parties, and we do not use your content for advertising.

4.AI Processing

Email content, chat messages, and attachments you provide to the Service are processed by AI language models (currently Google Gemini, accessed via the Gemini Developer API) to generate responses and take actions. By using the Service, you consent to this AI processing. AI-generated outputs may not always be accurate; you remain responsible for monitoring actions taken on your behalf via the Activity log.

We do not use your content to develop, improve or train AI or machine-learning models, and we do not transfer your content to any third party that would use it to train their models. This applies unconditionally to data obtained from Google Workspace APIs (including Google Calendar): such data is never used for model development or training, and is used solely to provide the user-facing features you have asked for.

Ellis, the help chat on our website. What you type to Ellis is sent to Google Gemini so it can answer from our help centre. If you are signed in, Ellis also uses a short, read-only summary of your account - your first name, plan status, actions used this period, Emily address, time zone, which calendar accounts are connected, whether a mobile is linked, and the names of your rules and automations. It never sees your emails, messages, calendar events, contacts or memory notes, and it cannot make changes. To improve the help centre, we keep a record of each question and Ellis's answer for 180 days: email addresses, phone numbers and long numbers are removed first, and the record holds no IP address, no name and no account or user identifier - only whether the person was signed in and which page they were on. We rely on our legitimate interest in answering questions better; please don't type personal details you don't want kept. The conversation itself stays in your browser tab and is cleared when you close it. With your consent, analytics records how Ellis is used (for example, that it was opened or a question was asked, and the help topic it matched), never the words you typed.

Google Workspace APIs - Limited Use. Emily's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

5.Third-Party Data Sharing

We share data with the following categories of third parties, solely to provide the Service:

• Google Cloud Platform / Firebase: infrastructure (compute, database, authentication). Data is stored in europe-west2 (London).
• Google Gemini (Gemini Developer API): AI processing of your email content and instructions, and of the questions you ask Ellis, our help chat.
• Mailgun (Sinch, EU region): our email transport provider for sending and receiving Emily's emails on the emily-wrf.com domain (including inbound mail routed to your Emily address). Message content, headers, attachments and sender/recipient addresses are processed by Mailgun in the EU to deliver the Service.
• Twilio (SMS): if you link a mobile number to text Emily, your texts to her and her replies are carried by Twilio, which processes your mobile number and message content to deliver them. Twilio is a US company; transfers are covered by its data processing addendum and standard contractual clauses.
• Microsoft 365 (Graph API): Emily's own mailbox is hosted on WRF's Microsoft 365 tenant, so the content, headers and attachments of mail sent to and from her addresses are processed by Microsoft alongside calendar events and Teams meeting links. If you connect a Microsoft calendar, the same API reads and writes your own calendar (see section 13). Connecting a calendar does not give Emily access to your mailbox.
• Google Calendar API: if you connect a Google calendar, to read your availability and create/manage events and Google Meet links on your behalf (see section 13).
• Apple iCloud (CalDAV): if you connect an Apple calendar with an app-specific password, to read your availability and create/manage events (see section 13).
• Zoom (API): if you connect a Zoom account, to create Zoom meetings on your behalf and read your Zoom account email at connection (see section 13).
• OpenAI (ChatGPT), Anthropic (Claude) and other assistant platforms: if you choose to connect Emily, the platform receives the Emily tool results you request and sends your instructions to Emily under the permissions you approve. The platform processes that information under its own terms and privacy policy. See section 14.
• Open-Meteo (weather forecasts): when a scheduled weather update runs, Emily asks Open-Meteo for the forecast. It receives the place name you asked about (and the coordinates it returns for it) and nothing else - no account details, no email content and nothing that identifies you. Open-Meteo is based in Germany and its servers are in the EU.
• MET Norway (backup weather forecasts): if Open-Meteo remains unavailable after a retry, Emily can request a backup forecast from the Norwegian Meteorological Institute. Only the requested city's coordinates are sent from Emily's server, without your identity or account details. MET Norway processes these requests in Norway.
• Stripe: payment processing. Stripe is a data controller for card data under their own privacy policy.
• Browser push services (Google, Mozilla, Apple, Microsoft): if you allow browser notifications, the notification is delivered through the push service your browser chooses. The contents are encrypted end to end, so the service sees only that a message was sent to your subscription, not what it said.
• Google Fonts: our pages load a typeface from Google's font service, which receives your IP address and browser user-agent in order to serve it. This happens on every page, including before any cookie choice, because it is part of rendering the page rather than measurement.

Each third-party provider processes data under their own data processing agreements and privacy policies. We may also share data with third-party individuals (e.g., the person you ask Emily to email), but only in order to carry out your instructions.

Finding and contacting a local service. If you ask Emily to find a provider such as a cleaner or plumber, she runs a web search (through the AI provider's search grounding) using the type of service and the area you give her, and returns publicly listed businesses and their published contact details. The area you supply may be saved as a note so she does not have to ask again; you can remove it at any time on the Files and memory page. If you then ask her to contact one of them, she emails that business on your behalf, sharing your name and whatever details you asked her to pass on. Emily never contacts a business without your explicit instruction.

6.International Transfers

Your account, your content and everything Emily does with them are stored and processed in the United Kingdom (europe-west2, London). That is where the database, the file store and the service itself live.

Providing the Service also means handing certain data to the providers in section 5, and not all of them are in the UK:

• European Union: Mailgun, which carries Emily's email - message content, headers, attachments and addresses; and Open-Meteo, which receives only the place name for a weather update.
• Norway: MET Norway receives city coordinates only when a backup weather forecast is needed.
• United States: Twilio (your mobile number and the text messages themselves), Zoom (if you connect it), Stripe (payments), Google's Gemini API infrastructure (AI processing), and, if you connect an assistant, that platform.
• Microsoft 365 hosts Emily's mailbox on WRF's tenant; Microsoft processes that mail under its own regional infrastructure.

We ensure appropriate safeguards are in place for these transfers, including standard contractual clauses, the UK International Data Transfer Addendum, or adequacy decisions as applicable.

7.Data Retention

We retain personal data for as long as your account is active. Data that is regularly used continues to be retained while you use the Service; data is automatically deleted on the following schedules:

• Short-lived processing records (such as inbound-message deduplication and pending confirmations) are purged within days, and the options Emily last offered you are kept for 7 days.
• Ellis, the help chat: questions and answers are kept for 180 days, with email addresses, phone numbers and long numbers removed and no IP address, name or account identifier, then deleted automatically. To stop misuse we also keep a short-lived counter of how many questions were asked, keyed to your IP address (and your account, if you are signed in), deleted automatically, normally within a day.
• Connected-assistant authorisation codes and access tokens expire within minutes. Refresh access normally expires after 30 days unless renewed through use, disconnected or revoked sooner.
• Address-confirmation links expire within hours of being issued: 24 hours for the link in your welcome email and reminders, and 60 minutes for a link you ask for or one confirming an additional sending address. Links to approve requests you sent before confirming work for 48 hours.
• Held-message records (sender address, subject line and authentication result for messages held as possible impersonation - never the message body) are kept on the same 6-year schedule as the rest of your account history, because they are the evidence of an attempt to impersonate you and are worth having if one is ever disputed.
• Email delivery records (recipient address, subject line, and whether the message was delivered, bounced, or was reported as spam - never the message body) are kept for 90 days, so that we can tell you whether something we sent actually arrived. Our email provider keeps its own copy for only a few days. A note that we have already told you about a bounced address (so you are not told twice in a day) is deleted after 30 days, and the notice about your own inbox is removed as soon as an email to it is delivered again.
• Meeting requests to your Emily address (the sender's name, address and subject line) are deleted automatically after 14 days.
• Email to help@ or enterprise@emily-wrf.com is passed on to our team's mailbox, shown as from the sender "via Emily", and our replies go back to the sender. We do not keep the message. We keep a delivery log for 30 days - the sender's domain, the message size, the number of attachments and whether it was delivered - never the content. Messages our mail provider flags as spam are not passed on; only that log entry is kept.
• Text Emily (SMS) data: a mobile number is stored on your account only once you have confirmed a code texted to it, and is removed when you unlink it or text STOP to Emily. Verification codes expire within ten minutes. Texts to and from Emily are kept with your chat history and handled by Emily exactly as an email or chat request would be. A text from a number that is not linked to any account is answered once with a link to our guide and is not read or stored; we keep only a hashed form of that number for 24 hours to avoid replying repeatedly. Delivery status per text is recorded like email delivery records.
• Aggregate statistics - daily counts with no name, address or content in them, such as how many people visited a page or how many messages were delivered on a given day - are kept for three years so we can compare one year with the next. They say nothing about any individual and are not linked back to an account.
• Account data, content, activity history, logs and automations are retained for up to 6 years from their last use, then automatically deleted. Records that you keep current (for example saved files, memories, contacts and active automations) are retained for as long as you continue to use them.

Upon account closure:

• Account deletion or cancellation: when you delete your account (or it is closed), your account data is retained for 12 months for accounting, legal and dispute-resolution purposes, and is then permanently deleted - your content, activity, contacts, memories, files, calendar connections and mirrors, repeating meetings, booking links, held messages, notifications, push subscriptions and any linked mobile number. You can reactivate at any time before then.
• What outlives a deleted account: a few records are not filed under your account and so are not caught by that erasure - delivery receipts for individual messages (keyed by the message, holding a recipient address and subject), and the record that we have already sent a one-time reply to a given address. These are deleted on their own schedules above (90 days and 6 years respectively). Billing records held by Stripe are retained as set out below.

Billing records are retained for the period required by UK tax law. You may submit a deletion request at any time by emailing help@emily-wrf.com; we will action it in line with the periods above and your statutory rights.

8.Your Rights Under UK GDPR

Subject to applicable law, you have the right to:

• Access: request a copy of the personal data we hold about you.
• Rectification: request correction of inaccurate or incomplete data.
• Erasure: request deletion of your personal data where there is no compelling reason for continued processing.
• Restriction: request that we restrict processing of your data in certain circumstances.
• Portability: receive your data in a structured, machine-readable format.
• Object: object to processing based on legitimate interests.
• Withdraw consent: where processing is based on your consent, withdraw it at any time.

To exercise any of these rights, email help@emily-wrf.com. We will respond within one month. You also have the right to lodge a complaint with the Information Commissioner's Office (ICO) at ico.org.uk.

9.Security

We implement appropriate technical and organisational measures to protect your data, including encryption of data in transit (TLS) and at rest, OAuth token encryption using Google Cloud KMS for calendar and meeting-provider connections, hashed credentials for connected-assistant access, role-based access controls, and audit logging. No method of transmission over the internet is entirely secure; we cannot guarantee absolute security.

Confirming your email addresses. Because Emily acts on instructions emailed from your registered addresses, and sends email on your behalf, we ask you to confirm each address you register - your sign-in address and any additional addresses you add. Until an address is confirmed, Emily will not act on instructions sent from it, route mail to it, or treat it as you on a thread. Additional addresses that stay unconfirmed are removed after 7 days. This prevents someone registering an address they do not control and having your mail treated as theirs.

Screening for impersonation. Our email provider checks the sender authentication (SPF and DKIM) of messages sent to Emily's addresses, and reports the result to us. Where a message claims to come from an account holder but fails those checks, Emily holds it instead of acting on it, and limited details may be reviewed by our team to decide whether it is genuine. That review is limited to the sender address, the subject line, the authentication result and the account concerned - never the message body or any attachments. Messages that pass authentication, and messages from third parties that are not claiming to be an account holder, are not held and are not reviewed. Held-message records are kept in line with section 7.

Screening sign-ups. Anyone can type someone else's address into a sign-up form, and a sign-up email sent to an address that never asked for it is unwanted email however legitimate the sender. When an account is created we therefore check a small number of signals - the shape of the name and address given, the source of the request, and whether a password reset is asked for within minutes of signing up - and where a sign-up looks automated we send only a single message asking the address holder to confirm it. Nothing else is sent until they do, and confirming the address releases everything normally. We record the outcome of that check on the account, and short-lived counts of sign-ups per source address, which expire within days.

Keeping our own figures accurate. We use the outcome of that check, together with whether the address has been confirmed, whether the account has been signed in to again or used, and whether a payment card has been added, to leave sign-ups that look automated out of our internal business reporting (for example, counts of sign-ups and trials). This is for our own records only: it does not change the Service for the account or what Emily sends, it clears itself as soon as a real person confirms the address and signs in, uses Emily or adds a card, and a member of our team can correct it.

This screening applies only to email received at Emily's own addresses. It does not apply to, and never involves, data from your connected calendar, meeting or assistant accounts (see sections 13 and 14).

10.Cookies and Analytics

We use cookies and similar technologies for the following purposes:

• Strictly necessary: authentication tokens and session management cookies, required for the Service to function. These cannot be disabled.
• Ellis, the help chat (your browser only): the conversation is kept in your browser tab's session storage so it survives moving between pages, and is cleared when you close the tab. Two small flags in the same storage remember, for this visit only, that Ellis has already offered help and whether you chose "Not now". None of this browser storage is sent to us or used for advertising; with your consent, optional analytics records how Ellis is used but never what you typed.
• Your appearance choice: if you pick Light or Dark rather than following your device, we store that one word in a cookie named emily-theme so the page is already the right colour when it loads. It holds nothing else - no identifier, nothing that could single you out - it is set only when you ask for it, and choosing "System" deletes it. It is not used for measurement and is not shared.
• Optional analytics: with your consent, we use Google Analytics 4 across our website and the signed-in dashboard to understand which pages are visited, what is clicked, and what is typed into our search boxes, so we can improve the product. It stays off entirely unless you accept. We send only the shape of a page address, never the address itself: identifiers, tokens and email addresses in a path are replaced before anything is sent. The one exception is the campaign label on a link - the utm_source, utm_campaign and similar tags we add to our own advertising and referral links, and the click identifiers advertising platforms append to them. We keep those so we can tell which advert, email or website brought you here. They describe the link, not you. Everything else in a web address is discarded before anything is sent, including invitation tokens and confirmation codes, and we never send form entries, the content of your messages, your calendar or meeting data, or anything Emily has processed on your behalf. If you decline, we ask again on your next visit rather than treating one refusal as permanent; if you accept, we remember that until you change it or clear your browser. You can change your mind at any time using Cookie settings in the footer of any page.
• Optional advertising measurement: with the same consent, the OpenAI Ads measurement pixel records visits to our public pages (using the same page shapes described above, never the full address) and the moment a free trial becomes a paid subscription, so we can understand the effectiveness of our advertising. Apart from that one subscription signal, it is not used in the signed-in dashboard, and it is not given your Emily content, invite token, dashboard activity or connected-calendar data. To match a subscription to the advert that led to it, the pixel may include a one-way hash (SHA-256) of an email address shown on the page - never the address itself.

The optional cookies by name. None of these is set until you select "Accept optional cookies":

• _ga and _ga_1Y8DQ40ZL0 (Google Analytics, on whiterabbitfoundry.com) tell one visit from another. They last up to two years, though most browsers cap them at about 13 months.
• __obref (OpenAI Ads pixel, on whiterabbitfoundry.com) links a visit to the advert that led to it, for up to a year.
• When the pixel loads, OpenAI's own servers (bzr.openai.com and bzrcdn.openai.com) may set Cloudflare security cookies (__cf_bm, _cfuvid) on their own domains to protect those servers from automated traffic.
• If you withdraw consent after giving it, the pixel sets __oaiq_consent to record that it must stay off. It holds only that choice.

Server-side conversion measurement. When a new account is created, we also report that a registration took place directly from our own servers to the OpenAI advertising measurement service, so that we can tell which advertising leads to sign-ups. This report uses no cookies and no access to your device. It contains a one-way cryptographic hash (SHA-256) of your email address and of your account identifier, never the address itself, together with your IP address, your browser user agent and the page you registered on. If our automated checks suggest a sign-up may not be genuine, we hold the report back and send it only once the email address has been confirmed and the account used; a report sent that way contains only the hashes, the page you registered on and your cookie choice, never your IP address or user agent. We rely on our legitimate interest in measuring the effectiveness of our own advertising, and you may object at any time by contacting us. If you have not accepted optional cookies, we do not include the browser identifier set by the pixel, and we mark the report so that it is used only to count the registration and never for personalised advertising.

Changing or withdrawing your choice. Optional measurement stays off unless you select "Accept optional cookies" in our cookie control. Withdrawing is as easy as consenting: select Cookie settings in the footer of any page, choose "Reject optional cookies", and we stop the optional measurement and delete the analytics cookies already set in your browser. You can also install the Google Analytics Opt-out Browser Add-on.

11.Children

The Service is not directed at individuals under the age of 18. We do not knowingly collect personal data from children. If you believe we have inadvertently collected such data, please contact us immediately.

12.Organisations and Enterprise Accounts

Where Emily is used by an organisation, member accounts are grouped under that organisation's admin, billing and policy layer. If your account belongs to an organisation (including where you join automatically by signing up with a verified organisation email domain, or by accepting an invitation):

• Your organisation's admins can see your usage and activity at the organisation level, manage your display name and Emily address, set organisation-wide rules and memory that apply to your assistant, and set the communication policy (including restricting Emily to internal recipients).
• Organisation-wide memory and rules created by your admins are shared with, and applied to, all members' assistants.
• Booking links. When Emily arranges a meeting with someone on your behalf, her email may include a private link where they can book one of your free times (if your calendar is connected) or tap the times that suit them (if it is not). The page shows only the times you are free, your first name, your organisation name, and the meeting length and type - never why you are busy or any event detail. Links for a single meeting expire after 14 days; a reusable link you make stays open for the period you choose (30 or 90 days, or until you turn it off in Settings; all your links close if your account is deleted). Links are looked up only by a scrambled (hashed) form; a copy of a link you made yourself is kept encrypted so you can copy it again from Settings. The page loads no analytics or advertising trackers. The times the other person chooses are used only to arrange that meeting. If you ask Emily for a booking link to share yourself, the person who books through it gives their name and email address so Emily can send the invite; these are used only to arrange that meeting and are saved to your contacts, as they would be for any meeting. For a meeting with several people, everyone on the email sees which offered times each of the others can make, by first name only - never their email addresses or anything else. When a booking link is shared in a messaging app or on social media, that service may fetch a preview of it; the preview shows only your first name, your organisation name and the meeting length and type, never any times or calendar details.
• Emails you copy Emily into. When you copy Emily on an email to other people, she reads that message, including who it is addressed and copied to, to work out whether you are asking her to do something. If you are not, she does not reply or act. If you ask her for something in the thread - for example a booking link for the people on it - she replies to those people in the same thread, with you copied. After she has sent a booking link into a thread, she reads replies from the people in it only to tell whether they are about the meeting, and responds only when they are.
• Team scheduling. When a colleague in your organisation asks their Emily to arrange a meeting with you, Emily may check your availability - the free/busy times from your connected calendars together with your stated working hours - to propose times you are both free, instead of emailing you to ask. Only whether you are free is used: your colleague is never shown why you are busy, and never any event detail - no titles, attendees, locations or anything else from your calendar. This applies only while you have a calendar connected, and your organisation's admins can turn it off for the whole organisation.
• Billing is handled at the organisation level. We share organisation billing and usage information with the organisation's admins and process it to issue invoices.
• For your organisation's members, WRF acts as processor on behalf of the organisation for the content processed under the organisation's instructions, and as controller for account, security and billing data. The organisation is responsible for having a lawful basis to add members and to process the data it directs Emily to handle.

If you have questions about your organisation's use of Emily or wish to exercise your rights, contact your organisation admin or email us at help@emily-wrf.com.

13.Connected Calendars and Meeting Providers (Microsoft, Google, Apple, Zoom)

You may optionally connect one or more calendars so Emily can read your real availability and manage meetings for you, and optionally a Zoom account so Emily can add a Zoom link to the meetings she arranges. Connecting is entirely optional; the Service works without it.

• How you connect. Microsoft and Google calendars are connected using OAuth 2.0 - you sign in with the provider and grant consent in your browser; we never see your password. Apple iCloud calendars are connected using an app-specific password you generate at appleid.apple.com and enter in Settings.
• What we access. Only your calendar data: your free/busy times and event details (times, titles, attendees, locations and meeting links) across the calendars you connect, and the ability to create, update and cancel events and generate online meeting links (Microsoft Teams or Google Meet). We request the minimum scopes needed for this - for Microsoft, Calendars.ReadWrite and, on a work or school account only, OnlineMeetings.ReadWrite (Microsoft offers Teams meeting creation on work and school accounts only, so on a personal Microsoft account we do not request it and access is limited to your calendar); for Google, the Calendar read-only scope (calendar.readonly, which covers reading your event details, your free/busy availability and your calendar list) and the Calendar events scope (calendar.events, to create, update and cancel events). We do not request or access your email, mailbox, contacts or files through these calendar connections.
• Sign-in scopes. Alongside the calendar scopes we also request the standard sign-in scopes - openid, email and profile, plus offline_access for Microsoft - which return the name and email address of the account you connected. We use them to show you which account is linked and to keep the connection alive without asking you to sign in again.
• How we use it. Solely to provide the scheduling features you ask for: showing your availability, summarising your schedule, proposing meeting times, and creating or changing calendar events on your behalf. We do not use connected-calendar data for advertising, we do not sell it, and we do not use it to train or fine-tune AI models.
• How we store it. OAuth access and refresh tokens (and the Apple app-specific password) are envelope-encrypted with Google Cloud KMS and stored in the United Kingdom; they are never exposed to your browser or shared with third parties. Calendar contents are processed transiently to answer your requests and are not retained beyond what is needed to provide the Service. The one exception is calendar mirroring: if you ask Emily to block time on one calendar to match another, she keeps a record of which events she has mirrored - the event identifiers and their start and end times, never titles, attendees or notes - for as long as that mirror is running, so she can keep the two in step and tidy up when an event moves or is cancelled. It is deleted with your account. We also keep which calendars you've unticked for availability checks and, if one can't be read, when the failures began, how many there have been, the calendar's name and the provider's error message. These failure details are cleared once it reads again or you untick it. We also note when it last read successfully and when we last told you about a failure. All of this is deleted with your account.
• Connecting Zoom. Zoom is connected using OAuth 2.0; you sign in with Zoom and grant consent in your browser, and we never see your password. We request only the minimum scopes needed - meeting:write:meeting to create a meeting on your account, and user:read:user to read your account email once so we can show which Zoom account is linked. When you ask Emily to arrange a meeting, she creates a Zoom meeting on your account and places the join link in the calendar invitation. We do not read, list or modify your existing Zoom meetings, and we do not access recordings, participants, chat or account settings. Your Zoom OAuth tokens are envelope-encrypted with Google Cloud KMS and stored in the United Kingdom, and the join links of meetings Emily creates are retained only to reuse in related messages. We do not use Zoom data for advertising, we do not sell it, and we do not use it to train or fine-tune AI models.
• Disconnecting. You can disconnect any calendar or your Zoom account at any time from Settings → Calendars & scheduling (or by asking Emily). Disconnecting revokes our access with the provider and deletes the stored tokens. You can also revoke access directly in your Microsoft, Google, Apple or Zoom account security settings. If a connection stops working - for example because access was removed at the provider or a password changed - we email you once (and send a push notification where you allow them) with a link to reconnect it. A short outage doesn't end a connection. We ask you to reconnect only when the provider says access has been removed. If one calendar keeps failing to read, we leave it out of your availability and tell you once by email (and push where allowed).

Google API Services Limited Use. Emily's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. We use Google Calendar data only to provide and improve the scheduling features you request, do not transfer it except as necessary to provide the Service or as required by law, do not use it for advertising, and do not allow humans to read it except with your consent, for security, to comply with the law, or where the data is aggregated and anonymised.

14.Connected AI Assistants (ChatGPT, Claude and Compatible Platforms)

You may optionally connect your Emily account to ChatGPT, Claude or another compatible assistant through Emily's connector (sometimes called a plugin). On ChatGPT, Emily is listed in the plugin directory as Emily by White Rabbit Foundry. On platforms where Emily is not listed in a directory, such as Claude, you add the connector yourself using Emily's published address. Connecting is optional and Emily continues to work by email and through the dashboard without it.

• How you connect. You sign in to your existing Emily account on Emily's own consent page and approve the listed permissions. The connected platform never receives your Emily password.
• What the platform can access. Where a platform requests it (ChatGPT does; Claude currently does not), identity permission returns your stable Emily user identifier, verified sign-in email and the fact that it is verified so the platform can retain the correct account connection and apply workspace-domain protections. Read permission can return your Emily rules, automations, recent activity, stored-file metadata, contacts, memories and usage. Chat permission can pass an instruction to Emily, which may use credits or, after the platform shows you a prepared plan and you confirm it, cause external actions such as sending email, changing calendar events or managing supported Emily data. Purchases, billing and subscription changes, paid-address changes and account deletion are not available through the connection. The consent page shows the permissions requested before you approve them.
• How credentials are stored. Emily issues random access and refresh credentials and stores only cryptographic hashes of them. Access credentials are short-lived, refresh credentials rotate after use, and detected reuse revokes the whole connection.
• How data is shared. The connected platform receives only the tool result needed for the request you make. Its handling of your prompt and the returned result is governed by that platform's own settings, terms and privacy policy.
• Disconnecting. You can revoke each authorisation from Account settings → Connected assistants, or remove it from the connected platform. Revocation stops refresh access and immediately invalidates the connection credentials. Some platforms may share one authorisation across desktop and mobile.

15.Changes to This Policy

We may update this Privacy Policy periodically. We will notify you of material changes by email or via the Service at least 14 days before the changes take effect.

16.Complaints

If you have a concern about how we handle your personal data, please contact us first at help@emily-wrf.com. If you are not satisfied with our response, you have the right to lodge a complaint with the Information Commissioner's Office (ICO), the UK supervisory authority for data protection. Details at ico.org.uk/make-a-complaint. ICO helpline: 0303 123 1113.