Privacy Policy

Quick summary

Tasks4Access is a family app-restriction and task-approval product: a parent chooses tasks and which apps stay restricted on a child’s paired device, and restrictions lift once the parent reviews and approves completed work. We collect the account, family, task, device and billing information needed to run that service, we never sell personal data, we don’t read messages or private on-device content, and a parent can delete the account and associated data at any time. The rest of this page explains exactly what we collect, why, and for how long — including the specific technical detail Android and iOS require us to be precise about.

Who we are and how to contact us

Tasks4Access (“we”, “us”, “our”) operates the Tasks4Access mobile app and website (together, the “Service”) and is the data controller for the personal data described in this policy. For any question about this policy, to exercise a data protection right, or to raise a concern, contact us at hello@tasks4access.com or via our Contact page — this is our primary and fastest channel for privacy requests. We have not yet published a separate registered company name, company number, registered postal address, or dedicated Data Protection Officer on this page; if and when that formal registration information is finalised, it will be added here.

Scope of this policy and roles within a family account

A parent creates and controls the Tasks4Access family account using their own name, email address and password. A child does not have an independent login, email address or password of their own — their device is connected to the family account through a secure device-pairing process that only a parent can initiate, and the app treats the parent as responsible for the child’s profile and settings within that family account. Where this policy refers to “you”, it means whichever of these roles applies to the reader; where the distinction matters, we say “parent” or “child” specifically.

Information we collect, and where it comes from

• Account information you provide when a parent registers: name and email address. Passwords are stored as a salted hash, never in a reversible or plaintext form.
• Child profile information a parent enters when adding a child to the family account, such as the child’s display name. A child does not enter this themselves.
• Family, task and approval data created within the product: task descriptions, which apps a task restricts, approval/rejection status, and reward or access periods. If a parent marks a submitted task “Needs More Work”, the short written explanation they give is stored temporarily — see “Temporary task feedback” below.
• Device and app-restriction data needed to enforce restrictions, which differs by platform — see “Android-specific data” and “iOS-specific data” below for the exact technical detail.
• An app-generated device identifier (a random identifier created by the app itself, not your device’s IMEI, Android ID, hardware serial number, or advertising ID) used to recognise a paired device to our servers.
• A push-notification device token for each parent and child device that has notifications enabled, used only to deliver notifications to that device — see “Push notifications” below.
• Subscription and billing information, handled by our payment processor Stripe — see “Payment and subscription data (Stripe)” below. We do not collect or store your full card details ourselves.
• Waitlist information if you join our waitlist — see “Waitlist and marketing emails” below for exactly how this is collected and by whom.
• Partner-programme information if you apply to, or enquire about, our Partner Referral / Fundraising Programme — see that dedicated section below.
• Rate-limiting data used transiently for security: to slow down abuse of sign-in, pairing and account-deletion endpoints, we briefly track attempt counts keyed by IP address and/or device identifier in a rolling, short-lived counter. This is not stored as a persistent per-person profile and is not used for any other purpose.

What we do not do

Tasks4Access does not read the content of messages, browsing history, or other private in-app content on a connected device. We do not request or use location access anywhere in the app. We use only the device permissions required to enforce app restrictions and report device/app status, and we describe the exact scope of those permissions below rather than asking you to take our word for it.

Android-specific data: installed apps and foreground-app detection

On Android, app restrictions are enforced using an Accessibility Service, which Google requires us to disclose precisely because the underlying Android API is broad. Here is exactly what our implementation does and does not do with it:

• Installed-app inventory. We read the list of launchable apps installed on a paired Android device (each app’s name, its package identifier, and a small icon thumbnail from the operating system, not a personal photo) so a parent can choose which apps to restrict. This is scoped to apps that expose a normal home-screen launcher entry point — not an unrestricted enumeration of every package on the device.
• Foreground-app detection. While the Accessibility Service is enabled, it detects which app is currently in the foreground on the device so the app can decide, on the device itself, whether to show a lock screen for a restricted app. Only the foreground app’s package name is read — never on-screen text, images, keystrokes, or any other window content — and this decision happens locally on the device; we do not keep a server-side history of which apps a child opened or when.
• The Accessibility Service is declared as an enforcement tool, not an assistive technology, and does not claim the broader access-for-disability purpose Android’s Accessibility API is designed for. Even though the underlying Android permission technically allows reading on-screen window content, our code never does so beyond the app’s own package name.
• Before this permission is requested, the app shows an in-the-moment, plain-language explanation of exactly this scope and requires you to actively acknowledge it before you are taken to Android’s own settings screen to enable the service.

iOS-specific data: Screen Time / Family Controls opaque tokens

On iOS, app restrictions are enforced using Apple’s own Screen Time (Family Controls / Managed Settings) system, which is deliberately designed by Apple so that a third-party app like ours cannot see which real apps a person has chosen to restrict. Specifically:

• When choosing apps to restrict, you use Apple’s own system picker. It returns Apple’s opaque, non-reversible “application token” or “category token” values for whatever you selected — Apple provides no API for us to turn these back into a real app name, bundle identifier, or icon.
• These opaque tokens are stored and used only on the device itself, to apply the restriction directly through Apple’s on-device Managed Settings system. They are never sent to, or stored on, our servers.
• Because we cannot see the real app identity, the app asks you to type a short label for each restricted slot (for example, “Games app”) purely so you can recognise your own choice later. Only that label and a random identifier generated on the device — not any Apple-issued token or real app identity — is sent to our servers, so a parent’s dashboard can show the restriction exists.
• iOS authorisation is requested as an individual, on-device authorisation on the child’s own device (this app does not use Apple’s separate Family Sharing “child account” system), and there is no background monitoring extension installed beyond what Apple’s Screen Time framework itself provides.

Families using a mix of Android and iOS devices

Our servers store restriction and inventory data the same way regardless of platform (a display label plus a platform-scoped identifier), so a parent and child on different platforms, or on the same platform, are handled by the same underlying data model. We have not published a dedicated technical walkthrough or exhaustive end-to-end test report of every specific parent/child platform combination, so while we have no reason to expect different data-handling behaviour between combinations, we note this as an area we have not separately documented beyond what is described above.

How we use information, and our legal bases (UK GDPR)

We only use your information for the purposes below, and we rely on one of these UK GDPR lawful bases for each:

• To provide the Service — account creation, the task/approval workflow, device pairing, and app-restriction enforcement. Necessary to perform our contract with you (Article 6(1)(b)).
• To process payments and manage subscriptions — necessary to perform our contract with you (Article 6(1)(b)).
• To keep the Service secure and reliable — rate-limiting abusive requests, investigating suspected fraud or misuse, and maintaining service integrity. Based on our legitimate interest in operating a secure service (Article 6(1)(f)), balanced against your interests in not being over-monitored — which is why this data is minimal and short-lived, as described above.
• To send account and transactional communications (verification, password reset, billing and product notices related to your account) — necessary to perform our contract with you (Article 6(1)(b)).
• To send waitlist/marketing product updates, and to enable optional push notifications — based on your consent (Article 6(1)(a)), which you can withdraw at any time as described below.
• Partner-programme processing — see the dedicated legal-basis note in that section below.

Parental authority and children’s data

A child’s profile, task data, and device-restriction data are created and controlled by their parent as part of the parent’s own contract with us — a child does not separately sign up or separately consent to using the Service. Because the parent is the family account holder, requests to access, correct, or delete a child’s data (or the whole family account) should come from a parent on that family account, in the same way described in “Deleting your account” below. If you are a young person and believe your data is being processed inappropriately by your family’s account, our Contact page is the right place to reach us.

Authentication and email

Signing in uses your email address and password (or, on a paired child device, a device-scoped session set up by a parent during pairing — not a separate email/password login for the child). Account, verification, password-reset, and partner-programme transactional emails are sent through our hosting provider’s own outbound mail service, not a separate third-party marketing email platform. Session, pairing, and password-reset tokens are stored in hashed form, not as reusable plaintext secrets, and are revoked on sign-out or account deletion.

Push notifications

Tasks4Access delivers push notifications through Firebase Cloud Messaging (FCM), a service provided by Google; on iOS devices, Firebase in turn relies on Apple’s Push Notification service (APNs) to reach the device, which is how Firebase delivery works on iOS generally. When a parent or child signs in on a device, that device registers a push token with our servers, linked to that person and that device within your family account. We use this token only to deliver notifications relevant to that person — for example: a task has been assigned to a child, a child has submitted completed work for a parent to review, a parent has approved a task, a parent has marked a task “Needs More Work”, or a device’s protection has been disabled and needs re-enabling. Every notification is a short, generic preview — it never contains task-feedback text or other private task content, which is only ever visible after opening the app. Google/Firebase (and, for iOS delivery, Apple) process the token only to route the notification to the correct device and do not receive the notification’s private content from us beyond what is in the generic preview. A device’s push token is removed when that device is unpaired or removed, when the account signs out, or when the account is deleted. Push notifications are optional — declining them never blocks any task, approval, or pairing functionality.

Payment and subscription data (Stripe)

Subscription payments are handled by Stripe, our payment processor. When you subscribe, Stripe creates a customer record and we store a reference to it (a Stripe customer ID) together with your subscription and billing status (for example, which plan you’re on, whether your subscription is active, past-due, or cancelled, and your current billing period) so the app can reflect your account correctly and so support can help if something goes wrong. Tasks4Access does not collect or store your full card number or other full card details — these are entered directly into Stripe’s own secure checkout and billing-portal pages and are never seen by our servers. Stripe retains payment and billing records as required for its own regulatory, fraud-prevention and accounting obligations, independent of Tasks4Access; we retain the customer ID and subscription/billing-status reference for as long as your account is active and for a reasonable period afterwards for our own financial record-keeping, as described in “Deleting your account” below. Stripe is a US-headquartered company, so this necessarily involves an international transfer of your billing information to Stripe — see “International data transfers” below.

Waitlist and marketing emails

Our public waitlist form (on the homepage and the /waitlist/ page) submits your email address directly to Brevo, our email marketing platform, rather than through our own servers. Brevo uses a double opt-in process, meaning you’ll receive a confirmation email before you’re actually added to the list. If you complete that process, your email address is stored with Brevo so we can send you product updates you have opted in to receive. You can unsubscribe at any time using the link in any email we send, and Brevo is a processor acting on our instructions for this purpose only — your waitlist email address is not used for anything beyond the updates you opted into.

Partner Referral / Fundraising Programme

This section covers information specific to the Partner Referral / Fundraising Programme. It applies in addition to the rest of this policy.

• Partner applications. When you apply to become a partner, we collect the information you submit on the application form: your name, partner type, contact email, contact phone (optional), approximate audience size (optional), and a preferred referral code (optional). Which other fields are required depends on your partner type. If you apply as an individual creator, your website or social profile URL and how you intend to promote your referral link are both required, so we can review your public presence. If you apply on behalf of a school/PTA, club, charity, or other organisation, your organisation name, your role (for example “Treasurer”), and how you intend to promote your referral link are all required; your website is optional unless you are applying as a Charity, in which case it is also required. A charity registration number is required only if you apply as a Charity, and is used to verify your charity before your referral link goes live. We never collect bank or payment details as part of an application.
• Charity partnership enquiries. If you send a “discuss a charity partnership” enquiry before formally applying, we collect only what you submit on that shorter form: organisation name, charity registration number (optional at this stage), your name, your role (optional), contact email, approximate audience size (optional), and your message (optional). An enquiry does not create a partner application and is not automatically turned into one — it is used only to reply to your question by email.
• Referral tracking. Your referral link and code are not secret and are designed to be shared. When someone visits your referral link, we resolve the code and issue a single-use, non-guessable visit token so a resulting sign-up can be attributed to you; this token is stored only in hashed form, and we deliberately do not record the visitor’s IP address, browser/device details, or any other click-level tracking against it.
• Report/dashboard authentication. Partner reporting access (/partner/report) is passwordless: you request a one-time sign-in link by email, which is single-use and expires after 15 minutes. Once used, it sets a secure, HTTP-only session cookie (scoped only to the reporting page) valid for 30 minutes; the underlying token is never exposed in the address bar, stored in the page itself, or accessible to page scripts.
• Commission and payout records. We keep a record of each commission calculated for you (the qualifying payment, the rate applied, and the resulting amount) and, once a payout is made, an external bank-transfer reference and date. We do not store your bank account details in Tasks4Access — payout details are verified and arranged with you directly, outside this system, before a transfer is made.
• Separation from family/user data. Partner reporting shows only your own aggregate totals (visit counts, sign-ups, paying referrals, and earnings). A partner never sees a referred family’s name, email address, or payment details, and a parent/family account never sees who referred them beyond having entered a referral code themselves.

Legal basis for processing. We process partner application and programme data because it is necessary to consider your application and, if approved, to perform our Partner Agreement with you (tracking referrals, calculating and paying commission, and giving you reporting access). Fraud and abuse prevention around referral codes (for example, rate-limiting) is based on our legitimate interest in keeping the Programme working correctly for genuine partners.

Retention. We retain partner application and commission/payout records for as long as your partner status is active and for a reasonable period afterwards, as needed for our own financial record-keeping and legitimate business or legal purposes (for example, audit trail of commission calculations and payments already made). A rejected or withdrawn application is retained only long enough to prevent duplicate pending applications and for our own records.

Partner data-subject rights. If you are a partner, you have the same rights described in “Your rights” below over your own partner application and account data. Note that a completed commission or payout record forming part of our financial history cannot always be deleted on request while still needed for legitimate accounting purposes, but you can always ask us to stop future referral tracking by asking us to suspend your partner status.

Cookies and website analytics

We do not run Google Analytics, Meta/Facebook Pixel, or any other visitor-tracking or advertising analytics script on tasks4access.com. The only cookie our own website code sets is the secure, HTTP-only partner-report sign-in session cookie described above, scoped only to the partner reporting page. Our website is built on WordPress hosting, which may set its own strictly necessary technical cookies (for example, to keep the site working correctly); we do not use these for tracking or advertising purposes.

Automated decision-making and profiling

We do not use automated decision-making or profiling that produces legal or similarly significant effects about you. Our rate-limiting described above is a simple, mechanical throttle (a maximum number of attempts in a time window) rather than individualised scoring, and it never automatically suspends or closes an account by itself.

Data sharing

We do not sell your personal data. We share information only with service providers who help us operate Tasks4Access, and only as needed to provide the Service:

• Stripe — payment processing (see “Payment and subscription data” above).
• Google / Firebase Cloud Messaging, and by extension Apple’s Push Notification service for iOS delivery — push notification delivery (see “Push notifications” above).
• Brevo — waitlist/marketing email delivery, for waitlist subscribers only (see “Waitlist and marketing emails” above).
• Our hosting provider’s own outbound mail service — account/transactional and partner-programme email delivery (see “Authentication and email” above); this is not a separate third-party marketing platform.

No data is shared for advertising or cross-app/cross-site tracking purposes with anyone.

International data transfers

Some of the service providers above are based outside the UK — notably Stripe and Google/Firebase, both US-headquartered. Where we transfer personal data to a provider outside the UK, we rely on that provider’s own standard contractual safeguards (such as the UK’s International Data Transfer Addendum or equivalent Standard Contractual Clauses) as part of our agreement with them. We have not independently verified the exact physical server region used by every provider for every data type, so we describe this transfer as arising from the use of these named providers rather than asserting a specific data-residency guarantee beyond what each provider itself publishes.

Security

All traffic between the app and our servers is encrypted in transit (HTTPS/TLS). Passwords are stored as salted hashes, never in plaintext or a reversible form. Session, pairing, and password-reset tokens are stored hashed, not as reusable plaintext secrets, and are revoked on sign-out or account deletion. We have not independently verified or published a specific statement about at-rest database encryption at the hosting-layer level, so we do not claim that here beyond the transit-encryption practices described above. No method of transmission or storage is 100% secure, and we cannot guarantee absolute security.

Data retention

We retain account and family data for as long as your account is active, and for a reasonable period afterwards as needed for legitimate business or legal purposes (for example, financial record-keeping) — see “Deleting your account” below for what is deleted immediately versus retained. Routine database backups are taken as part of normal operations; a backup taken before data is deleted or before a retention period (such as the 7-day limit described below) expires can still contain a copy of that data as of the backup’s date. We have not yet finalised or published a specific backup retention length or access-control policy, so we cannot currently guarantee erasure from every historical backup within a specific time frame — only that data stops being live and visible in the product once its stated retention period ends or it is deleted from the live database.

Temporary task feedback (“Needs More Work”)

When a parent marks a submitted task “Needs More Work” instead of approving it, they must write a short explanation (up to 300 characters) of what still needs fixing. This explanation is stored only so the child who owns the task can see why it was sent back and correct it — it is never used for any other purpose, and only the child and the authorised parent(s) on that child’s family account can ever see it. It stays visible and current through resubmission and review — resubmitting the task does not clear it — and is kept live for a maximum of 7 days, deleted sooner if the task is approved or cancelled (or the task itself is deleted), or replaced the next time the task is sent back with a new explanation. The child is notified of a “Needs More Work” decision by a generic push notification that never contains the explanation text itself; the explanation is only visible after opening the app, is not stored permanently on your device, and is fetched fresh from our servers each time. This 7-day limit applies to our live, in-use database. A routine full database backup taken before an explanation is deleted can still contain a copy of it as of that backup’s date, and we have not yet finalised how long such backups themselves are retained — so we cannot yet guarantee this text is erased from every historical backup within 7 days, only that it stops being live/visible in the product within that time.

Deleting your account, and cancelling a subscription

You can delete your Tasks4Access account and associated data at any time, directly from the app (Account → Danger zone → Delete account) without needing to reinstall it, or by request if you no longer have the app — see our Account deletion page for exactly how, and exactly what is deleted versus retained. In short: your login, profile, and (if you are your family’s only parent) your children’s tasks, devices and app restrictions are deleted; billing/payment history and any referral or partner-commission records are kept, anonymised, for financial record-keeping. If you are one of multiple parents on a shared family account, deleting your own account removes your own login and access but does not delete the shared family, children, or their data, since another parent still relies on it. Cancelling a paid subscription is a separate action from deleting your account — it stops future billing through Stripe’s billing portal but does not, by itself, delete your account or family data.

Your rights

Subject to applicable exceptions, you have the right to: request access to the personal data we hold about you; request correction of inaccurate data; request erasure of your data; request that we restrict certain processing; object to processing based on our legitimate interests; and request a portable copy of data you provided to us. You can exercise any of these by contacting us at hello@tasks4access.com or via our Contact page. Some data — such as completed financial/commission records described above — cannot always be erased on request while we still need it for legitimate accounting or legal purposes. If you are unhappy with how we have handled your personal data, you also have the right to complain to the UK’s data protection regulator, the Information Commissioner’s Office (ICO), at ico.org.uk.

Withdrawing consent

Where we rely on your consent (for example, waitlist/marketing emails, or push notifications), you can withdraw it at any time — using the unsubscribe link in any marketing email, or by disabling notifications for your device in the app or your device’s system settings. Withdrawing consent does not affect the lawfulness of anything we did with your data before you withdrew it, and does not affect the separate, contract-based processing needed to run your account (for example, transactional account emails, which are not marketing).

Changes to this policy

We may update this policy from time to time, for example as the product changes or to improve clarity. The “Effective and last updated” date at the top of this page reflects the current version. Where a change is material, we will take reasonable steps to make it noticeable, such as an in-app notice or an email to account holders.

Contact us

If you have questions about this policy, contact us at hello@tasks4access.com or via our Contact page.