Privacy Policy

Future Engine Limited, a company registered in England and Wales under company number 16640272, whose registered office is at 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom, operates this application and is the controller of the personal data described in this policy. The application is provided as a business-to-business service: Future Engine is engaged directly by the client whose project it presents, on a project-by-project basis, and acts as the application’s super administrator: it creates and manages every user account and provides the related account management and support to that client and its project team, within the scope agreed by contract. The client may determine who on its team is given access; day-to-day processing within the application is carried out by Future Engine Limited.

Future Engine Limited is registered with the Information Commissioner’s Office, the UK data protection regulator, under registration reference ZC044931.

The people whose data this policy covers (account holders and those connecting to the application) use it in a business capacity, as the client’s own team or as professionals engaged on the client’s project. The application is not offered to consumers and does not process consumer data.

This policy covers personal data processed by this presentation application only. It does not cover other dealings you may have with Future Engine Limited or with the client outside the application.

• Account details: the username, role and a securely hashed password for each managed account and, where the administrator adds it, the account holder’s work email address. Usernames are short three-character identifiers (two letters and a number) rather than full names, and we never store passwords in readable form. The shared access-code account carries no email address.
• Connection data: the network (IP) address each sign-in came from. It is a record, not a gate: it is kept with the sign-in history, it is what a pause after repeated failed attempts is counted against, and it may appear in technical logs. It never decides who is allowed in.
• Device data: for each device approved for a person, a description of it as the browser reports it (for example “Safari on iPad”), any name the administrator gives it (for example “Suite iPad 1”), when it was approved, when it was last used, the address it was last seen at, and which of the application’s two screens it is set to be (the presenter’s controller or the room’s big screen), as set on the device or by the administrator. For each approved device, and for each request still waiting to be approved, we derive an approximate location label from that address (city / region level) using a third-party IP geolocation service, which receives that address for the lookup; see “Who we share it with” below.
• Session data: two essential cookies. A signed session cookie keeps you signed in and records your access role, and a device-marker cookie holds a random value identifying this browser so an approved device is recognised at your next sign-in. Neither contains tracking identifiers; see “Cookies” below.
• Presentation activity: for each presentation given through the application, whether it was launched as a tenant presentation or a rehearsal, the sections, drawer trays and floor plans it showed, the order they were shown in, and how long each was on screen. It is kept with the session that gave the presentation, so it is associated with the account signed in at the time; a session started with the shared access code identifies the device rather than a named person. Time during which nothing is touched anywhere in the session is capped, and both the capped and the plain elapsed figures are kept. It is visible only to the super administrator, session by session and in the application’s presentation statistics, which summarise it by presentation and by presenter: for each account, how many presentations and rehearsals it gave, how long they ran, the sections it spent most time on, the days and times of day they were given, and how these change week by week.
• Technical logs: routine server logs (times, addresses, requested pages, errors) kept for security and troubleshooting.
• Take-away packs: each time a presenter saves a take-away pack to their device or emails it to themselves, a record of it: when it was made, the account signed in (a session started with the shared access code identifies the device rather than a named person), the device’s name, the presentation, whether it was saved or emailed, the email address it was sent to and what the email provider reports became of the email (delivered, delayed, bounced or marked as spam), together with a copy of the pack itself. An emailed pack goes to the address the presenter confirms, normally their own (filled in from their account where it has one, and theirs to change), and they forward it to the prospect from their own mailbox; who it is forwarded to is outside the application. When a device cannot make a pack, it reports that to the record instead: when it failed, the account signed in, the device’s name where it has one, its browser and version (and the browser’s full description of itself), the size of its window, the presentation, the step the pack stopped at, the message the presenter was shown and the device’s own technical account of what went wrong. When several packs cannot be made close together, the application alerts the super administrator on its menu and by email to the address set for its alerts, naming the devices, the presentations and the accounts concerned. The record is visible only to the super administrator.

The application does not track your browsing, does not profile you, does not use advertising or tracking technologies, and does not knowingly collect data about children. A small number of on-device preferences (such as how the media library is laid out) are stored locally on the device itself and never sent to us. A device also keeps its own copy of which screen it is set to be, alongside the one held with its record.

• To provide access: authenticating sign-ins and maintaining your session, and filling in your work email address when you email yourself a take-away pack (performance of a contract, and our legitimate interest in operating the service).
• To keep the service secure: checking that a sign-in is on a device approved for that person, pausing sign-in from a connection after repeated failed attempts (and alerting the administrator to sustained ones), preventing unauthorised access and investigating misuse (our and our clients’ legitimate interests in protecting confidential material).
• To understand how the presented material performs: recording which parts of a presentation were shown and for how long, so the material can be judged and improved (our and our clients’ legitimate interests in the quality of the material they commission). A presentation given on the shared access-code account is not attributable to a named person.
• To see how the material is being presented: summarising that record by presenter, so that we and the relevant client can see how the material is used across the presenting team and plan the briefings, rehearsal and support presenters receive (our and our clients’ legitimate interests in presenting their projects well). The summaries count attended time, with idle time capped as described above, and a presentation given on the shared access-code account is counted against the device rather than a named person.
• To account for the material handed out: recording each take-away pack, who made it, on which device and for which presentation, keeping a copy of it, following each emailed pack’s delivery so the presenter learns at once when one did not arrive, and recording each pack a device could not make, alerting the administrator when they keep failing, so the fault can be found and fixed (our and our clients’ legitimate interests in controlling confidential material, in delivering what a presenter sends and in a service that works).
• To establish, exercise or defend legal claims: keeping the record of who accepted the Terms of Use and when, together with the record of sign-ins, devices, sessions, presentations given and take-away packs made, so that we and the relevant client can evidence and pursue a breach of those terms, including a presentation shown without the client’s permission (our and our clients’ legitimate interests in enforcing their rights).
• To meet legal obligations: where we are required to retain or disclose information by law.

The application sets two strictly necessary cookies, both http-only and neither used for tracking, analytics or advertising. The session cookie keeps you signed in securely and is removed when you sign out or when it expires. The device-marker cookie holds a random value that identifies this browser so a device approved for you is recognised the next time you sign in; it deliberately outlasts the session (up to 400 days, the longest a browser allows) and therefore remains after you sign out, and it carries nothing about you, only that value. Clearing it, or using a different browser or a private window, simply makes this look like a new device, which means a fresh approval request at the next sign-in. Because both cookies are essential to providing the service you asked for, no consent banner is required and no optional cookies exist to configure.

We do not sell or rent personal data, ever. Data is shared only with:

• our hosting and infrastructure providers, who store and process it on our behalf under contract;
• the email delivery provider the application is connected to (such as Resend, or a mail service such as Amazon SES), which sends the application’s emails on our behalf under contract: it handles each email, the address it is sent to and, for an emailed take-away pack, the pack attached to it, and where it reports deliveries back, whether each email arrived;
• Google, whose Google Drive holds the application’s encrypted backups and the copies of the take-away packs, in a shared drive belonging to us or to the client, under Google’s terms for business customers;
• a third-party IP geolocation service (currently ipwho.is), which receives the network address a trusted device was last seen at, or the address a request waiting for approval came from, solely to estimate its approximate location so the administrator can recognise it. Only the address is sent (never a name, account or any other data), and only for those devices and requests, not for routine visits;
• the relevant client, where necessary to manage who has access to their presentation, to report on how the presented material performed and how it is being presented (which may include the summaries by presenter described above), or to investigate a suspected breach of the Terms of Use; and
• professional advisers and authorities, where required by law or to protect our or our clients’ legal rights.

Data is stored with reputable hosting providers. Where any processing takes place outside the United Kingdom, we ensure an adequate level of protection through recognised safeguards (such as adequacy regulations or standard contractual clauses).

Account details, including any work email address, are kept for as long as the account is needed for the engagement and are deleted when the account is removed; the administrator can also remove an email address from an account at any time. Session cookies expire automatically. Technical logs are retained on a short rolling basis for security and troubleshooting, and longer only where needed to investigate an incident or meet a legal obligation. Records of past sign-ins (when a session ran, from which connection address, on which device, and the terms version accepted) are kept for the life of the deployment as evidence of terms acceptance and access control, until the administrator deletes them, either one session at a time or all of one person’s records at once. The presentation activity described above is kept with the session that produced it, for the same period, and is deleted with it; the statistics are worked out from that record each time they are opened, so deleting the activity removes it from them too. Each take-away pack’s record and its copy are kept until the administrator deletes them; deleting one removes the record and moves the copy to the Google Drive bin, which Google empties after 30 days. The record of a pack a device could not make is kept for 90 days, or until the administrator deletes it sooner. A device stops being approved when the administrator revokes it or when it goes unused for longer than its set period.

Access to the application is controlled by authentication and role-based permissions; passwords are stored only as strong one-way hashes; sessions are cryptographically signed; and administrative functions are restricted to designated administrators.

Under UK data protection law you have rights over your personal data, including the rights to access it, to have it corrected or deleted, to restrict or object to its processing, and to data portability where applicable. To exercise any of these rights, contact Future Engine Limited via the contact details provided with your engagement, or in writing to its registered office at 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom. You also have the right to complain to the Information Commissioner’s Office (ico.org.uk) if you are unhappy with how your data has been handled.

We may update this policy from time to time; the version and effective date at the top of this page identify the current one. Material changes will be brought to your attention at your next sign-in, on either sign-in screen.