Cookie Policy

Effective date: 6 November 2026

1. Scope LH Infra Mesh Private Limited uses or permits cookies and similar technologies only for identified Lighthouse features. This policy covers browser cookies, local storage, pixels and relevant mobile SDK/device identifiers. The Privacy Policy explains associated personal-data processing. A cookie is a small item stored by a browser; local storage may persist differently. An SDK is software included in an app and can collect information without using a browser cookie. Disabling browser cookies does not necessarily disable an app SDK.

2. Necessary and optional technologies Strictly necessary technologies may support authentication, session integrity, security, consent preferences and a requested transaction. We limit this category to what is necessary for the service requested; advertising or general product analytics must not be relabelled necessary merely because useful to Lighthouse. Optional functionality may remember preferences or personalise a feature. Optional analytics may measure usage and errors beyond strictly necessary operational monitoring. Advertising technologies may measure campaigns or personalise advertising. Each actual technology must be listed in the inventory below. AI or recommendation processing is not automatically a cookie category. If recommendations use account or RFQ data, the Privacy Policy and AI Processing Notice govern that use as well as any relevant device storage.

3. Your controls Before optional technologies requiring consent run, the interface must offer clear Accept optional, Reject optional and Manage preferences controls. Choices must be equally easy to use, without pre-ticked options, misleading colours or blocking unrelated services. Necessary technologies are explained separately. You can reopen Cookie preferences from the legal/footer menu and change your choice. Withdrawal stops future optional activation; information already collected is handled under the Privacy Policy and relevant deletion rights. Keep a consent record that identifies the choice, version and time without retaining unnecessary browsing history. Browser controls can block or delete cookies and local storage, but may sign you out or reset preferences. Device controls can limit advertising identifiers. If cross-app or cross-site tracking is used on iOS, the required operating-system permission must also be obtained; a website consent banner does not replace it.

4. Third parties, embeds and email pixels Enable third-party embeds, advertising tags and optional SDKs only for the purposes disclosed and with required permission. An embedded map, video or social post may disclose data to its provider; offer a consent-aware loading choice when needed. Email tracking pixels must be treated as a separate measurement choice where required. Marketing unsubscribe and cookie withdrawal are different controls, both of which must work. No third party is entitled to use information for an unrelated purpose merely because it provides an SDK. Provider contracts and configurations must match the user-facing notice.

5. Inventory to complete before publication No actual cookies or SDKs were independently audited for this draft. Product/engineering must enter one record per deployed item: Technology name and exact cookie/key/SDK identifier; provider and legal entity; first or third party; service/domain; data collected; specific purpose; necessary or optional category; activation trigger; storage duration; receiving countries; withdrawal behaviour; and provider privacy link. Authentication/session item: [CONFIRM actual name, provider and expiry]. Consent-preference item: [CONFIRM actual name and expiry]. Analytics item, if deployed: [CONFIRM or mark NOT USED]. Advertising/attribution item, if deployed: [CONFIRM or mark NOT USED]. Maps/video/chat or other embedded service, if deployed: [CONFIRM or mark NOT USED]. Mobile SDKs and crash reporting: [CONFIRM exact SDKs and configuration]. Do not publish this inventory as though the examples are actual technologies. Remove unused categories and replace entries with verified records.

6. Retention, signals and updates Session items expire with their defined session; persistent items have their stated expiry. Do not describe them all as lasting for the browser session. Review expiry against purpose and avoid indefinite identifiers. Honour legally required opt-out signals where applicable and accurately explain tested support. Do not claim that Global Privacy Control or Do Not Track is honoured unless implemented; do not claim every signal is legally irrelevant. Update the inventory before enabling a materially new technology and obtain new consent when required. Questions and complaints go to the confirmed privacy contact in the Contact, Grievance & Dispute Resolution Policy.

Implementation acceptance Test a fresh browser, Reject optional, withdrawal, embedded content, logged-out access and mobile SDK behaviour. Optional tags must not activate before the relevant choice, and changing preferences must persist as disclosed.

7. Technology-by-technology disclosure Before publication, the inventory must cover browser cookies, local storage, pixels, SDK identifiers, server-side event transfers, embedded media and similar tracking. For each item state the actual provider, name or identifier, purpose, duration, first/third-party status, data categories and category of choice. An “essential” label must be justified by the function the user requests. Optional advertising or broad behavioural analytics must not be classified as essential merely because they fund or improve the business. Where a local exception permits a limited measurement use without consent, verify its exact conditions and the required information or opt-out.

8. Consent interface and proof Where consent is required, do not load optional technology before the affirmative choice. Provide clear accept, reject and granular settings without misleading prominence, preselected optional categories or a penalty for refusal. Explain each purpose in understandable language. Keep evidence of the notice version, purposes, vendors, choice and time, with a proportionate identifier. Withdrawal must be as easy as giving consent. A changed provider or materially changed purpose may require a fresh choice; an old consent record is not permission for unrelated processing. A dismissal, continued scrolling or ordinary use must not be treated as optional consent where that would be invalid. Store the minimum needed to remember a refusal so users are not repeatedly pressured to agree.

9. Mobile applications and external platforms Operating-system permissions for location, camera, photos and notifications are separate from cookie choices and privacy-law consent. Request a permission when needed for the relevant feature and explain the effect of declining it. App tracking authorisation, where required by Apple, must be implemented for the actual tracking practice; a cookie banner does not replace that flow. Android data disclosures and consent controls must accurately reflect the SDKs shipped in the app. Removing a visible analytics screen does not disable an embedded SDK. Embedded maps, videos, social widgets and externally hosted content can disclose data before interaction. Use appropriate controls or a clear activation step where needed. A link to a third-party policy does not replace Lighthouse’s own duty to explain the disclosure.

10. European, UK and US choices For EU/EEA users, assess the applicable national ePrivacy rules alongside GDPR. For UK users, assess PECR and current amendments and exceptions. These regimes should not be treated as an identical universal rule for every cookie, but required consent must be obtained before optional access or storage. For a covered California activity, some advertising disclosures can constitute “sale” or “sharing” even without cash payment. Provide the legally required opt-out and honour recognised opt-out preference signals where applicable, including Global Privacy Control. A generic “we do not sell data” statement must not conceal advertising sharing. Other US state privacy rules may require targeted-advertising opt-outs and signal handling. Determine applicability and implement the correct controls. The setting must affect actual provider events, not only the text shown to the user.

11. Testing and change management Test on a fresh browser, after rejection, after acceptance, after withdrawal and across app versions. Verify that optional events stop and that server-side transfers follow the same choice. Keep a record of approved vendors and remove unused tags. Publish the actual durations and providers before launch. Do not invent an inventory or leave a promise that every session identifier expires on logout when the technology persists longer. Contact and rights requests follow the Privacy Policy.

12. Consent categories and meaningful choices Where consent is required, optional technologies must remain disabled until a valid choice is recorded. Choices should distinguish relevant purposes such as analytics, personalisation and advertising; consent to one purpose must not automatically activate unrelated tracking. A user must be able to decline optional categories through a reasonably accessible control. The interface must not use misleading button labels, preselected optional choices or repeated obstruction to obtain consent. Closing a banner or continuing to browse must not be treated as affirmative consent where that is legally insufficient. Necessary technologies must be limited to their actual necessary purpose.

13. Preference storage and changes Lighthouse may store the minimum information needed to remember and demonstrate a choice, including the choice, applicable notice version and relevant event record. That record must not become an advertising identifier merely because it is exempt from optional analytics consent. A user can revisit preferences through the disclosed control. Withdrawal applies to future consent-based collection and use, subject to lawful handling of earlier data. Where identifiers already exist, the implementation should delete or disable them as appropriate and instruct relevant providers. The screen must accurately describe what the control changes.

14. Server-side events and third-party embeds A technology does not fall outside the applicable privacy rules merely because an event is sent by a server rather than browser JavaScript. The same purpose and consent or opt-out restrictions must reach server-side advertising and analytics flows where applicable. An embedded video, map, social feed or chat widget may contact its provider before the user interacts with it. Where required, block that contact until the relevant choice or provide a privacy-preserving alternative. A placeholder should explain the effect of loading the external content.

15. Mobile identifiers, permissions and app settings Mobile SDKs, advertising identifiers and similar device storage must be included in the inventory. Operating-system permission for photos, location or notifications does not automatically authorise unrelated analytics or advertising use. App-store tracking permissions and platform requirements must be implemented where applicable. Device-level settings may limit some processing but do not replace Lighthouse's own required controls. Explain any material difference between web and app choices, including whether an account-level preference applies across signed-in devices. Do not claim cross-device synchronisation unless implemented.

16. Inventory fields and provider accountability For each active technology, identify its name or meaningful identifier, provider, purpose, data involved, first- or third-party status, lifespan, relevant destination or transfer information and control category. Session and persistent technologies must be distinguished. A broad category name alone is insufficient where specific disclosure is required. Provider changes must be reviewed before activation. A vendor's own cookie policy does not establish Lighthouse's lawful basis or guarantee that the configured product honours the user's choice. Remove unused tags and prevent old app versions from silently reactivating disallowed processing where within Lighthouse's control.

17. Verification and complaints Check behaviour before a choice, after rejection, after category-specific consent and after withdrawal. Verification should include network requests, SDK events and server-side transfers relevant to the stated purpose. A visual banner test alone is insufficient. If a preference appears not to work, users may report the device or browser, approximate event and affected control without supplying passwords or unnecessary browsing history. Lighthouse will assess the discrepancy and correct inaccurate disclosures or configuration. Applicable privacy rights and complaint routes remain available.

18. Mobile tracking choices Where Apple’s definition of tracking applies, obtain the required App Tracking Transparency authorisation before tracking. A cookie banner or contractual clause does not replace that authorisation. Do not fingerprint the device or use another identifier to bypass refusal.

Validate SDK behaviour before consent and after withdrawal, including data transmitted through webviews. If the released app does not track, do not add a misleading tracking prompt simply because this policy mentions tracking.