Privacy Policy
This policy explains what personal data Capture Studio Ltd collects when you use Capture Ski and the other Capture Studio products, why we collect it, who we share it with, how long we keep it, and the rights you have over it. It covers the mobile app, the on-mountain camera network, and this website.
Where we are in our lifecycle
Capture Ski is in pilot. Some features described here are live only at participating resorts, and the platform's scale is small. We will update this policy as the product grows — see section 11 for how you will hear about changes.1.Who we are
Capture Studio Ltd (“Capture Studio”, “we”, “us”) is the data controller for the personal data described in this policy. We operate Capture Ski and the wider Capture Studio platform.
| Controller | Capture Studio Ltd |
| Company number | [COMPANY NUMBER] |
| Registered address | [REGISTERED ADDRESS] |
| Privacy contact | info@capture-studio.com |
We have not appointed a Data Protection Officer. We are not required to at our current size; privacy questions go to the address above and are handled by the founder.
Ski resorts that host our cameras are separate organisations. For the rider data described in this policy we are the controller. An administrator at a resort you have ridden at can see your rides at that resort in identifiable form — your display name, your session statistics, and the clips captured there — as well as aggregated analytics for the resort as a whole. They cannot see rides you took at a different resort. Section 4 sets out exactly what a resort receives. Where a resort processes personal data for its own purposes — its own ticketing, marketing or CCTV — that is the resort's responsibility under its own privacy notice, not ours.
2.What data we collect and why
The lawful basis is shown for each category. Where the basis is consent you can withdraw it at any time (section 7) without affecting processing that already happened.
| Data | Why we process it | Lawful basis | Retention |
|---|---|---|---|
| Identity — name, email address, phone number, rider handle, profile photo | Create and run your account, sign you in, contact you about your account. | Art. 6(1)(b) performance of a contract | While your account is active. If you ask us to delete your account, a 30-day grace period runs first; erasure starts when it ends (section 6) |
| Precise location — GPS position sampled once per second during an active ski session, stored as a time-series in one-minute blocks, plus the ski-trail polylines and per-run statistics derived from it | Trigger captures as you pass a camera zone, draw your run trace, calculate speed, distance and vertical drop, and show you on your crew’s map when you choose to share. | Art. 6(1)(a) consent — you grant location permission and start a session; Art. 6(1)(b) for the capture feature itself | Kept for as long as the ski session it belongs to, and deleted when you delete that session or your account. We do not yet run an automatic 12-month expiry on these samples — see section 6 |
| Health data — heart rate and active calories burned, read from Android Health Connect | Show heart-rate and effort overlays on your ride replay and session stats. | Art. 9(2)(a) explicit consent (special category data), with Art. 6(1)(a) consent | Stored as session averages on the ski session it belongs to, and deleted when you delete that session or your account. Revoking Health Connect access stops any further reading immediately; ask us and we will erase what we already hold |
| Motion data — accelerometer and gyroscope samples at 50 Hz, G-force at 10 Hz, and the body-mechanics derived from them (rotation degrees, air time, landing impact G, peak air height, pose skeleton tracks) | Detect and score tricks, measure air time and landing impact, and generate the wireframe overlay and coaching tips. | Art. 6(1)(b) performance of a contract | Raw samples are kept in ten-second blocks for as long as the ski session they belong to; the derived body-mechanics stay attached to the clip. Both are deleted when you delete the session, the clip, or your account. We do not yet run an automatic 12-month expiry on the raw samples — see section 6 |
| Video — clips of you recorded by fixed on-mountain cameras, thumbnails, and share-renders that include sponsor overlays | Deliver the product: the clip of your run is the thing you signed up for. | Art. 6(1)(b) performance of a contract | Until you delete the clip or your account. Section 6 explains the 12-month expiry we are putting in place for the video files, and what happens to the clip’s score and coaching tips |
| Gear-colour signature — a handful of dominant colour values for your jacket and your trousers, measured from the pixels inside your torso and legs in clips we have already recorded, and averaged across up to ten of your recent captures | Today this is only shown back to you, as the colour swatches on your profile in the app. We derive and keep it so that we can also use it to tell riders apart when several people trigger the same camera within seconds of each other — that matching step is built into the data but is not yet switched on. | Art. 6(1)(f) legitimate interests — attaching each clip to the correct rider | Recalculated nightly from your captures in the last 30 days (we need at least three), and held on your account for as long as the account exists |
| Contacts — SHA-256 hashes of the phone numbers in your address book, computed on your device (up to 500 per search). We do not hash or send email addresses, names, or any other contact field | Find which of your existing contacts already use Capture Ski, so you can add them as friends. | Art. 6(1)(a) consent — you must grant contacts permission and start the friend-finder | The hashes you send are used for the lookup and are not stored. Separately, a hash of your own phone number is stored on your account so other people can find you — only while you leave “discoverable by contacts” switched on |
| Bluetooth proximity — identifiers of the Capture Studio beacons your phone detects on the mountain | Work out which capture zone you are entering so the right camera fires. | Art. 6(1)(b) performance of a contract | 48 hours. A scheduled job deletes every beacon observation older than that, and a deletion request removes yours straight away |
| Device identifiers — push notification tokens (FCM / Expo) and the Firebase app instance ID | Send you a notification when your clip is ready, and keep your app session working. | Art. 6(1)(f) legitimate interests — delivering the notifications you enabled | Until you sign out, uninstall, or disable notifications |
| Server-side operational logs — records our own servers write when the app talks to them, such as which account called which function and when, and any error the server raised. We do not run an analytics or crash-reporting SDK inside the app, so we do not collect screen views, feature usage, session length, advertising identifiers or crash reports from your device | Keep the service running, investigate faults, and detect abuse of features such as the friend-finder. | Art. 6(1)(f) legitimate interests — operating and securing the service | Google Cloud operational logs: 30 days. Our own audit-log records: kept while your account is active, and kept after you delete your account in pseudonymised form — we remove your name and email address and leave an account identifier, the action and the time (section 6) |
| Anti-abuse counters — a count of how many times your account has used a rate-limited feature (friend-finder searches, rider searches, data export and deletion requests), stored against your account identifier and the name of the feature | Stop the friend-finder and other lookups being used to test large lists of numbers or accounts. | Art. 6(1)(f) legitimate interests — protecting the service and other people’s data | The count stops applying to you within an hour to a day. The counter row itself is currently kept until you delete your account, at which point it is deleted outright |
| Sponsor impressions — a count of how many times a sponsor overlay was shown | Report accurate impression counts to the resort and its sponsors. | Art. 6(1)(f) legitimate interests — running the resort’s sponsorship, reported in aggregate | Held as a running total on the sponsor’s own record. We do not keep a per-rider impression log, so there is nothing here that is linked to you |
| Safety and incident records | Respond to an incident on the mountain, run the end-of-day safety check-in, and pass a serious incident to resort staff. | Art. 6(1)(d) vital interests, and Art. 6(1)(f) legitimate interests in rider safety | While your account is active. An escalation you raised is kept afterwards with your name and contact details removed, for the same accountability reason as the audit log (section 6), then per the resort’s own incident-record obligations |
| Data export bundles — the zip file we build when you exercise your right of access, containing a copy of everything in this table that is linked to you | Answer your Article 15 request, and let us re-send the link if the first one expires before you download it. | Art. 6(1)(c) legal obligation — responding to a data subject access request | The download link in the email expires after 7 days. We intend to delete the bundle itself after 30 days; that automatic deletion is not switched on yet, so for now it is removed when you delete your account. See section 6 |
| Business enquiries — name, work email, resort, country, role and any message you send us through a demo-request or waitlist form on this website | Reply to your enquiry, and let you know when a product launches. | Art. 6(1)(f) legitimate interests — responding to a business enquiry you initiated; Art. 6(1)(a) consent for launch-notification emails | Until the enquiry is closed, or you ask us to remove you |
What we do not do
- We do not sell personal data. Not to sponsors, not to resorts, not to anyone.
- We do not use your data for behavioural advertising or build advertising profiles.
- We do not use your clips or data to train third-party AI models. Our AI provider is contractually barred from training on what we send them (section 4).
- We do not use facial recognition, and we do not measure faces, bodies or gait to identify riders.
- We do not track you across other websites.
A note on the gear-colour signature
We want to be clear about what this is, because “we recognise you from your clips” deserves an explanation. The signature is a handful of colour values — the dominant colours of your jacket and your trousers. It is a description of your clothing, not a measurement of your face or your body, and it cannot identify you on its own: plenty of riders own the same red jacket. Its intended use is narrow: a tie-break, when the system already knows a small set of riders were at a particular camera at a particular moment and has to decide which clip belongs to whom. We should be straight with you that this tie-break is not running yet — at the moment the signature is calculated and stored, and the only place it is used is the swatch display on your own profile. We are telling you about it now rather than after we switch it on.
Because it describes what you were wearing rather than a physical characteristic of your body, we treat it as ordinary personal data under Art. 6, not as biometric data under Art. 9. It stays inside our systems: it is never shown on your public profile, never shared with resorts or sponsors, and never sent to our AI provider. You can see your own swatches on your profile in the app, and they are deleted with the rest of your account.
3.How we collect it
In the mobile app
Most data reaches us because you enter it, or because you started a session. Location, motion, Bluetooth, contacts and health data all sit behind an operating-system permission prompt. If you decline a prompt the related feature is switched off; the rest of the app keeps working. You can withdraw any of these permissions at any time in your phone's settings.
From the on-mountain cameras
Cameras at participating resorts are fixed to a marked capture zone. They are not continuously recording to our servers: a camera records a short clip when a rider running an active session enters its zone, and that clip is associated with that rider. Resorts sign the capture zones so riders can see where cameras are and choose to avoid them.
From Health Connect
On Android we read heart rate and active calories from Health Connect, only after you explicitly grant those permissions, and only for the window of an active session. We do not read any other health record, and we never write to Health Connect.
From beacons
The app scans for Capture Studio Bluetooth beacons installed at the resort. It records the identifier of our beacon, not the devices of other people around you.
On this website
We collect what you type into a demo-request or waitlist form, plus the strictly necessary browser storage described in our Cookie Policy.
5.International transfers
Your account, clips, location samples and motion samples are stored in the European Union (Google Cloud, Frankfurt). Some of our processors are established in the United States, as listed in section 4. Where personal data is transferred outside the United Kingdom or the European Economic Area, we rely on the European Commission's Standard Contractual Clauses, together with the UK International Data Transfer Addendum where UK data is involved, and we carry out a transfer risk assessment before onboarding a processor.
You can request a copy of the safeguards we rely on by writing to info@capture-studio.com.
6.How long we keep it
The table below describes what our systems actually do today, not what we intend them to do. Where a period is automatically enforced we say so; where something is kept until you remove it, we say that instead. We would rather publish a modest promise we keep than a generous one we do not.
| What | How long | Enforced by |
|---|---|---|
| Capture video, thumbnails and share-renders (the media files) | Until you delete the clip or your account. We are putting a 12-month expiry in place on the video files themselves; until this row says otherwise, it is not yet running | Deleting a clip, or account deletion |
| The clip’s record — trick name, score, coaching tips, body-mechanics figures | Kept while your account is active, even where the video behind it has been removed. Deleting the clip removes both | Deleting a clip, or account deletion |
| Location samples (1 Hz) and motion samples (50 Hz) | Kept for as long as the ski session they belong to. There is no automatic expiry on them today, so in practice they are kept until you delete the session or your account | Deleting a session, or account deletion |
| Heart rate and calories read from Health Connect | Stored as session averages and kept for as long as the session. No automatic expiry today | Deleting a session, or account deletion |
| Session summary statistics (distance, vertical, top speed, personal bests) | While your account is active | Account deletion |
| Bluetooth beacon observations | 48 hours | A scheduled job that runs every 6 hours |
| Anti-abuse counters (rate limits) | The count stops applying within an hour to a day. The row itself is kept until you delete your account — each one already carries an expiry date, but we have not yet switched on the automatic sweep that acts on it | Account deletion |
| Live location broadcast to your crew while you are riding | 30 minutes after your last update | A scheduled job that runs every 5 minutes |
| One-shot “share my location now” pins | They stop being shown to anyone at the end of the window you chose. The pin itself is kept until you delete your account — the automatic sweep for expired pins is not switched on yet | Account deletion |
| Data export bundles | The download link expires after 7 days. We intend to delete the zip itself after 30 days; that automatic deletion is not switched on yet, so until it is, the bundle is removed when you delete your account or when we clear it by hand | Link expiry, and account deletion |
| Server-side operational logs (Google Cloud) | 30 days | Google Cloud log retention |
| Audit-log records of sensitive actions (for example friend-finder searches, administrative changes) | While your account is active, and afterwards in pseudonymised form — we remove your name and email address, leaving an account identifier, the action and the time. We have not yet set an end date on the pseudonymised records | Automatic redaction during account deletion |
| Escalations you raised to our on-call team | Same as the audit log: retained with your name and contact details removed | Automatic redaction during account deletion |
| The record that you asked us to delete your account | Retained, reduced to an account identifier, the status and the dates. Your email address and any reason you gave are removed | Automatic redaction at the end of the cascade |
| Account data (everything else linked to you) | When you ask us to delete your account a 30-day grace period starts, during which you can cancel. Erasure begins at the end of it and normally finishes within hours; a very large account can take a further day or two | The scheduled erasure job, which runs hourly and resumes where it left off |
| Records we must keep by law (for example accounting records, or an incident report) | For the period the relevant law requires | Manual review |
You can delete an individual clip at any time from the app or the web rider portal, and you can delete your whole account from Settings → Privacy. Either removes the data ahead of the schedule above.
Why we keep some records after you leave
Three things survive account deletion: our audit log, any escalation you raised, and the record of the deletion request itself. In each case we strip your name, email address and any free text you wrote, leaving an account identifier, what happened and when.
We do this because the audit log is our security record. If asking us to delete your account also deleted the log of what was done with it, deletion would become a way to destroy the evidence of misuse — of your account by someone else, or of someone else's account by whoever was using yours. We rely on Art. 17(3)(b) and (e) and on our legitimate interest in securing the service. If you think a specific entry should go as well, write to us at info@capture-studio.com and we will look at it individually.
Note for the Capture Studio team — do not publish over this
[RETENTION GAPS — code and console work still owed] The table above has been written down to what the infrastructure actually enforces. Each of these converts a row to a firmer promise once it ships; edit the row only after the enforcement exists and has been verified. Full detail indocs/runbooks/DATA_RETENTION.md. (1) Cloud Storage lifecycle rules are not applied yet — apply §2 of the runbook, then the video row can say “12 months from capture” and the export-bundle row's 30 days becomes real rather than intended. (2) imuBatches and locationBatches cannot take a Firestore TTL policy: the documents carry no timestamp field and the rules allowlist rejects one. Add expiresAt to the mobile writers and the allowlist, then apply TTL, then the location/motion rows can state 12 months. (3) Health data (heart rate, calories) sits on the session document and has the same problem — it is special-category data, so it should be the first one fixed, not the last. (4) Capture documents have no expiry, so a scored clip can outlive its video. Either stamp expiresAt on them in step with the media or leave the split wording above. (5) auditLogs and escalations have no end date. Stamp expiresAt = createdAt + 12 months in writeAuditLog(), apply TTL, then this page can state 12 months instead of “not yet set”. (6) Diagnostics: the audit brief said 90 days, this page says 30, and 30 is only the Google Cloud default. Confirm 30 is the commitment or change the log bucket. (7) Two Firestore TTL policies are ready to switch on and are not — rateLimits/expiresAt and locationShares/expiresAt. Both fields are already stamped by the writers, so this is console work, not code (DATA_RETENTION §3.2). Until they are on, both rows above have to say “kept until you delete your account”. (8) pruneBeaconObservationBatches deletes a maximum of 500 documents per 6-hour run. That is comfortably ahead of pilot volume, so the 48-hour row is true today — but it is a fixed throughput ceiling, and it will stop being true before the numbers get large. Make it loop until drained.7.Your rights
Under UK and EU data protection law you have the right to:
- Access — get a copy of the personal data we hold about you.
- Rectification — have inaccurate data corrected.
- Erasure — have your data deleted.
- Portability — receive your data in a structured, machine-readable format, or have it sent to another provider.
- Restriction — ask us to pause processing while a dispute is resolved.
- Object — object to processing we carry out on the basis of legitimate interests.
- Withdraw consent — at any time, for anything we do on the basis of consent (location, health data, contacts, marketing email).
- Complain — to a data protection supervisory authority (section 12).
How to exercise them
- In the app: Settings → Privacy. You can delete individual clips immediately. You can also ask for a copy of your data, which we build automatically and email to you as a zip — usually within the hour, and always inside the one-month deadline. The download link in that email lasts 7 days, and we keep the zip itself for 30 days so we can re-send the link if you miss it.
- Also in Settings → Privacy: account deletion. Requesting it starts a 30-day grace period during which you can cancel; after that we erase your data automatically (section 6 explains the few records we keep, and why).
- On the web: the rider portal, under Account Settings → Your data. Same routes as the app.
- By phone permission: revoke location, health, contacts or Bluetooth access in your device settings at any time.
- By email: info@capture-studio.com. We reply within one month, and will tell you if we need to extend that (we can extend by two further months for complex requests).
We do not charge for these requests and we do not require a specific form. We may ask you to confirm your identity before we act, so that we don't disclose your data to someone else.
8.Children
You must be 16 or over to hold a Capture Ski account. We do not knowingly create accounts for anyone younger. If we learn that an account belongs to someone under 16, we delete it.
Riders under 16 who appear in video
Ski resorts are public places and our cameras are fixed to marked capture zones on public pistes. A child skiing past a capture zone may appear in another rider's clip. This is unavoidable in the way a person appearing in the background of someone else's photograph is unavoidable, and we take it seriously:
- The resort is responsible for signing its capture zones so that everyone on the mountain — including parents and guardians — can see where cameras are and choose a different line.
- We do not attempt to identify, name, tag or build a profile for anyone who is not an account holder.
- We never create an account, a profile or a stats record for a bystander.
- Clips are private to the rider who triggered them unless that rider chooses to share them.
- A parent or guardian can ask us to remove any clip in which their child appears, by writing to info@capture-studio.com. Tell us the resort, the approximate date and time, and enough description to find the clip. We will remove it, and we will not ask for more information about the child than we need to do that.
9.Security
- All traffic between your device, our cameras and our servers is encrypted in transit with TLS.
- Data at rest in Firestore and Cloud Storage is encrypted by Google Cloud.
- Access is enforced per-document by Firebase Security Rules: a rider can read their own data, and a resort administrator can read only their own resort’s data.
- Administrative access is limited to named individuals, and administrative actions are written to an audit log.
- The friend-finder is rate-limited to five searches per account per hour, and every search is written to our audit log, so the feature cannot be used to test large lists of numbers.
- Push tokens, email addresses and phone numbers are excluded from public profile reads.
How the contacts friend-finder protects your address book
We want to be exact about this rather than reassuring. When you run the friend-finder, your phone converts each contact's number to a standard international format and puts it through SHA-256, a one-way hashing function. Only the resulting hashes leave your device. We never receive, and never store, the phone numbers themselves, your contacts' names, their email addresses, or anything else from your address book. The hashes we receive are compared against the stored hashes of riders who have switched on “discoverable by contacts”, and are then discarded.
What this does not do is make the hashes impossible to reverse. There is only a limited number of possible phone numbers, so anyone who obtained a list of these hashes could work out which numbers produced them by trying every candidate. The hashing means your contacts' numbers are not sitting in our database in readable form, and it limits what an accidental disclosure would expose — but it is not the same as anonymising them, and we do not claim that it is. We treat these hashes as personal data and protect them accordingly.
No system is perfectly secure. If we suffer a personal data breach that is likely to result in a risk to your rights and freedoms, we will notify the relevant supervisory authority within 72 hours and tell you directly where the law requires it.
11.Changes to this policy
This is version 2.1, published 7 September 2026. Every version carries a version number and a last-updated date at the top of this page.
If we make a change that materially affects how we use your data — a new category of data, a new purpose, a new processor handling special category data — we will tell you before it takes effect, by email to the address on your account and by an in-app notice. Minor changes (clarifications, corrections, a new address) are made by updating this page. Where a change requires your consent, we will ask for it rather than assume it.
12.Complaints
If you are unhappy with how we have handled your data, please tell us first at info@capture-studio.com — we would rather fix it.
You also have the right to complain to a supervisory authority. In the United Kingdom that is the Information Commissioner's Office (ICO), Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF — ico.org.uk. If you are in the European Economic Area you may complain to the data protection authority in the country where you live, where you work, or where the alleged infringement took place.
Complaining to a regulator does not affect your right to a legal remedy.