HolyHub legal

Cookie Policy

Draft reviewed: 6 October 2026 · Effective date: [NEEDS EDITING]

Cookies, local storage, app storage and your choices when using HolyHub.

Draft status

Draft for review, not yet effective. Fields marked [NEEDS EDITING] must be completed and launch controls verified before these documents are published as effective policies.

1. What this policy covers

This policy explains cookies and other technologies that store information on, or access information from, your device. It covers the HolyHub website and relevant app storage. Personal information use is explained in our Privacy Policy.

The operator is OzGen AI LTD. Its contact details are in the Privacy Policy and remain marked [NEEDS EDITING]. This draft is based on a review of the local website and app source on 6 October 2026. Production hosting, response cookies and provider settings remain to be verified.

2. Cookies and similar technologies

A cookie is a small value stored by a browser. Local storage, device identifiers, pixels, scripts and app storage can also fall under the UK Privacy and Electronic Communications Regulations. The rules concern accessing information as well as storing it and apply even if the information is not personal data.

Normal downloads of local fonts and images and server-side request logging are not by themselves evidence of a tracking cookie. Processing a request’s IP address is still subject to applicable data protection requirements.

3. Website inventory

  • Custom HolyHub page code: no first-party cookie, persistent local-storage preference or analytics pixel is configured in the reviewed page script. Menu and modal state is held in memory and disappears on reload.
  • Legacy Webflow runtime: the website loads local Webflow files after page load. They contain a read of the WebflowEditor local-storage key and can activate editor-related external requests. They also contain code that reads an existing _mkto_trk cookie for Marketo form attribution. Presence of this code does not prove that a Marketo cookie is set or that a production attribution service is enabled.
  • Fonts and artwork: the website references locally hosted assets rather than an embedded third-party font service.
  • Waitlist: the static form currently points to the page itself. No production form provider or its cookies have been established by this repository review.
  • Hosting and security cookies: names, purposes, providers and expiry need to be checked on the actual deployed site. We do not invent cookie names or durations for a deployment we have not verified.

Production cookie names, purposes, providers, duration, security-cookie classification and consent controls: [NEEDS EDITING]. Audit a fresh browser visit and optional actions on the deployed site. Remove unused optional runtime paths or gate non-exempt access before it happens. The current implementation has no cookie preference control.

4. Storage in the mobile app

The app uses local storage and secure device facilities for authentication/session information, settings and feature data or caches. This can include cached study material and content, playback state and device notification registration information. The app and its providers also process security and connection identifiers.

The planned app providers include AdMob for ads, Amplitude for analytics and RevenueCat for subscriptions. Their SDKs can access or store identifiers and other device information depending on configuration. Approved identifiers, actual SDK versions, local storage keys, expiry, events and consent/objection control routes: [NEEDS EDITING]. Do not treat non-personalised ads as automatically free of device access.

Before publication, confirm lifetime, logout and deletion behaviour. Optional analytics, advertising identifiers or cross-service tracking must not be described as necessary simply because they support the business. A narrow statistical exception requires its own conditions; advertising is not covered by that exception.

5. Consent, exceptions and your choices

Storage or access essential to transmit a communication or provide a service you request can qualify for a PECR exception. We must assess the actual purpose. Optional advertising and cross-service tracking require prior valid consent.

Current UK law also provides narrow exceptions for statistical and appearance purposes with specific conditions, clear information and an easy, free way to object. We have not established that any optional HolyHub technology meets those conditions.

Where consent is required, optional access must stay off until you choose it. Rejecting must be as straightforward as accepting, with a way to change your choice later. Scrolling, continued browsing and a pre-ticked box are not consent. Preference control link or app path: [NEEDS EDITING]. Google’s applicable AdMob consent-platform requirements must also be met.

You can also clear or block storage through browser settings, change app permissions, or sign out. This can affect sign-in and requested features. Browser settings supplement the choices HolyHub must provide; they do not replace them.

6. Changes and questions

We will update this policy when technologies or purposes change. New consent-required uses need a fresh choice before access. Contact the controller identified in the Privacy Policy about device storage. This draft becomes effective only after the inventory and controls are confirmed.