Privacypolicy

LUMORA is a fictional studio and this site is a front-end demonstration. There is no server-side application behind it, no database, no customer record, no mailing list and no analytics account.

• The contact form validates what you type in the browser and then simulates a short delay. Nothing is transmitted. No request leaves the page.
• The booking flow produces a confirmation screen rendered entirely from the values you selected. No reservation exists, no chair is held and no one is notified.
• The Grooming Lab configurator computes its price estimate in the browser from a fixed local price table.
• There is no account system, so there is nothing to sign in to and no credentials to store.

In practical terms: if you close the tab, everything you typed is gone, and it never existed anywhere else.

A real studio running this site would need a modest amount of personal information to do its job. A complete deployment should expect to declare the following categories.

• Booking details — your name, email address, phone number, the service and artist you chose, the date and time you requested, and any notes you attached to the reservation.
• Contact form submissions — your name, email address, optional phone number, the subject you selected and the body of your message.
• Look configurations — the length, fade, texture, finish, sides and beard settings you saved in the Grooming Lab, if you chose to carry them into a booking.
• Technical and analytics data — pages viewed, approximate region derived from an IP address, referring site, device type and browser, collected in aggregate to understand which parts of the site are useful.
• Correspondence — anything you send us by email or telephone, kept as part of the conversation it belongs to.

A live deployment would rely on the performance of a contract as its lawful basis for booking data, legitimate interests for answering enquiries and keeping the site secure, and consent for anything optional — analytics and marketing email in particular.

This demonstration does use your own browser as scratch space. Nothing stored there is transmitted; it exists only on your device and only until you clear it.

• Grooming Lab configuration — your current look is written to localStorage under the key lumora:look so the configurator, the price estimate and the booking page stay in agreement as you move between them. Clearing your site data removes it. Nothing else reads that key.
• Optional reference photo — if you attach a photo in the Grooming Lab, it is read locally with the browser FileReader API so it can be shown back to you on the page. The file is never uploaded, never converted into a request and never written to disk by us. It disappears from memory when you leave the page.
• Interface preferences — small, non-identifying values such as whether you have dismissed a notice, kept in the same local storage and equally disposable.

You can inspect or delete all of it from your browser’s developer tools or site-settings panel at any time, without asking us and without any effect on the rest of the site.

This demonstration sets no cookies. There is no consent banner because there is nothing to consent to — no tracking pixel, no advertising identifier, no cross-site profiling, and no first-party session cookie, because there are no sessions.

A live deployment would likely need a small number: a strictly necessary cookie to protect forms against cross-site request forgery, and — only after explicit opt-in — an analytics cookie. Strictly necessary cookies do not require consent under the Privacy and Electronic Communications Regulations; everything else does, and should be off until you say otherwise.

Even a static site pulls resources from somewhere. These are the only external dependencies this demonstration has.

• Typefaces — Anton and Inter are loaded through next/font, which downloads and self-hosts the font files at build time. Your browser makes no request to Google Fonts and no font provider sees your IP address.
• Photography — images are served from the Unsplash and Pexels content delivery networks. Requesting an image necessarily reveals your IP address and user agent to those networks, in the same way as loading any image on the open web. Their own privacy policies apply to that exchange.
• Hosting — the site is served as static files from a commercial host, which keeps standard server access logs for security and operational purposes.

No data is sold, rented or shared with advertisers, brokers or partners, for the straightforward reason that none is collected. A live deployment would be expected to name every processor it uses — booking platform, email provider, analytics vendor — and to keep written processing agreements with each of them.

Nothing is retained by this demonstration, because nothing is received. The periods below describe what a live studio should commit to.

• Booking records — kept for the duration of the client relationship and for six years afterwards, which is the retention period ordinary UK accounting and tax obligations imply.
• Contact form submissions — kept for twelve months after the conversation closes, then deleted.
• Marketing consents — kept for as long as the consent stands, plus a record of its withdrawal so the withdrawal can be honoured.
• Aggregate analytics — retained for twenty-six months in a form that does not identify an individual.

The site is served over HTTPS. Because this demonstration holds no personal data, the practical attack surface is close to nil — there is no login to compromise, no database to exfiltrate and no session to hijack.

A live deployment would be expected to encrypt personal data in transit and at rest, restrict access to booking records to staff who need them, keep dependencies patched, and have a rehearsed procedure for notifying the Information Commissioner’s Office within seventy-two hours of becoming aware of a reportable breach.

If a real deployment held information about you, the UK General Data Protection Regulation and the Data Protection Act 2018 would give you the following rights, exercisable free of charge and normally answerable within one month.

• Access — to be told whether your data is being processed and to receive a copy of it.
• Rectification — to have inaccurate or incomplete information corrected.
• Erasure — to have your data deleted where there is no continuing lawful reason to keep it.
• Restriction — to have processing paused while a dispute about accuracy or legitimate interests is resolved.
• Portability — to receive the data you provided in a structured, machine-readable format, or to have it sent directly to another controller.
• Objection — to object to processing carried out on the basis of legitimate interests, and an absolute right to object to direct marketing.
• Withdrawal of consent — to withdraw consent at any time, without affecting the lawfulness of processing carried out before you withdrew it.
• Complaint — to complain to the Information Commissioner’s Office, the UK supervisory authority, at ico.org.uk.

Since this demonstration holds nothing, a request made against it can only be answered one way: there is no record to produce, correct or delete.

This policy may be revised as the template changes. The revision date at the top of the page is the authoritative one. Material changes to a live deployment — a new processor, a new purpose, a longer retention period — should be announced directly to affected clients rather than quietly published.

Questions about this policy, or about what a real deployment of this template would need to declare, can be sent to studio@lumora.example, or by post to Unit 04, The Ironworks, 118 Halden Street, London E2 7QP.

Both the address and the mailbox are fictional. A real studio would also name a data protection contact here, and register with the Information Commissioner’s Office if its processing required registration.