PROIEX Cookie and Similar Technologies Notice
Document key: cookie_notice Document version: 1.0 Effective date: [PUBLICATION DATE]
This notice explains how [PROIEX EU LEGAL NAME] uses cookies, browser storage, scripts and similar technologies on proiex.com and the PROIEX application. It should be read with the Privacy Notice.
1. Your choices
Strictly necessary technologies operate because they are needed to provide a service you request, protect the Platform or remember your privacy choices. They cannot be disabled through Cookie Settings, although your browser may block them and the service may then stop working.
All non-essential technologies are disabled until you choose the relevant purpose. The consent interface offers Accept all, Reject all and granular choices with equal prominence and no pre-ticked optional categories. You may change or withdraw a choice at any time through Cookie Settings in the footer. Withdrawal is effective for future use and does not affect processing already performed lawfully.
Signup terms, identity-verification acceptance and marketing choices are separate from cookie choices.
2. Current first-party cookies
| Name | Provider | Purpose | Category | Normal duration |
|---|---|---|---|---|
ACCESS_TOKEN | PROIEX | Authenticates a signed-in request | Strictly necessary | 15 minutes under the current configuration |
REFRESH_TOKEN | PROIEX | Renews an authenticated session securely | Strictly necessary | 7 days, or 30 days when “remember me” is selected, under the current configuration |
XSRF-TOKEN | PROIEX | Prevents cross-site request-forgery attacks | Strictly necessary | Matches the refresh-session period |
CookieConsent and consent-service records shown in Cookie Settings | Cookiebot by Usercentrics | Stores and proves privacy choices | Strictly necessary | [CONFIRM LIVE COOKIEBOT CONFIGURATION; NORMALLY UP TO 12 MONTHS] |
AUTH_TOKEN is a retired legacy name that the application attempts to clear. It must not be treated as an active authentication design. Cookie lifetimes can end earlier on logout, revocation, security action or browser deletion.
3. Browser storage used by the application
These records are not all HTTP cookies, but transparency and storage-access rules can still apply.
| Storage | Examples | Purpose | Normal duration |
|---|---|---|---|
| Local storage | USER, role-specific notice-dismissal flags, payment callback state | Maintains limited interface/session context and remembers a local interface choice | Until removed by logout, completion, user action or browser deletion |
| Session storage | onboarding token and registration flags, verification email, seller/notary onboarding drafts, verification flash messages | Allows a multi-page signup or verification flow to continue | Until the browser tab/session ends or the flow clears it |
| Session storage | property-nearby, walk-score, pollen and air-quality caches | Avoids repeated requests and improves performance | Current feature cache, normally no longer than 24 hours and no later than the browser session |
Sensitive identity-document contents should not be stored in browser storage. An onboarding token is a credential: do not use a shared device, and close the session after completing signup.
4. Third-party technologies
The exact cookies and storage created by a vendor can change. Cookie Settings and the automatically generated cookie declaration at [COOKIE DECLARATION URL] contain the live names, purposes, recipients and durations after a production-domain scan.
Cookiebot by Usercentrics
Cookiebot displays preferences, controls optional categories and stores consent evidence. Its preference storage is necessary. Before launch, PROIEX must verify that the configured domain group, categories, languages, consent mode and records cover every production subdomain and embedded service.
Simple Analytics
The site loads the Simple Analytics page-measurement script. The provider states that its standard service uses no cookies or persistent visitor identifiers and discards IP addresses. PROIEX uses only aggregated website statistics under [LEGITIMATE INTEREST ASSESSMENT / OTHER CONFIRMED BASIS]. If the implementation or provider settings change to collect personal or device-level data, PROIEX will update this notice and obtain consent where required.
Tawk live support
The Tawk chat widget can process IP/device data and set provider cookies or storage when loaded. It must remain blocked until the user chooses the support/functional category, except when the user expressly requests the chat and the applicable law permits loading it for that request. Chat messages are also governed by the Privacy Notice.
Google Maps and environmental/location features
Property-address entry and map-related features can load Google Maps or call Google services. Google may receive IP/device data, requested coordinates or an address. Optional map embeds must follow the configured functional-consent rule. Server-side requests and strictly requested address functions must be assessed and described separately; a public API key does not remove privacy obligations.
Workflow providers
Persona or Didit verification, DocuSign signing, notarial technology and payment/banking flows may use cookies or storage on their own domains or embedded interfaces. These technologies are activated when you request the relevant verification, signature, appointment or payment service. The interface identifies the provider and links its notice before hand-off. Optional analytics or marketing by those providers is governed by their own choices where they act independently.
5. Categories used in Cookie Settings
- Necessary: authentication, session refresh, CSRF protection, load/security controls, consent storage and a feature explicitly requested by the user where no optional tracking is involved.
- Preferences / functional: optional maps, live support and remembered feature choices that are not essential to the core site.
- Statistics: any analytics technology that accesses or stores device information beyond an exempt, privacy-preserving aggregate implementation.
- Marketing: advertising, cross-site measurement, remarketing or profiling. PROIEX does not enable this category unless the live declaration specifically lists a vendor and the user opts in.
Changing a vendor's category requires a documented e-privacy assessment; it must not be done solely for product convenience.
6. Browser controls and signals
Browsers can delete or block storage, but blocking necessary records may prevent login or workflow completion. Where technically supported and legally required, PROIEX honours recognised consent-withdrawal or privacy signals for optional processing. Browser “do not track” signals have no uniform legal or technical definition; use Cookie Settings for a reliable choice.
7. Keeping the declaration accurate
PROIEX scans the production website and application after every material frontend/provider release and at regular intervals. Unknown technologies are investigated and blocked or classified before use. The owner of this notice records the scan date, affected domains, vendor configuration and approval.
Production scan date: [DATE] Domains scanned: [DOMAINS AND SUBDOMAINS] Cookie Settings: [URL] Contact: privacy@proiex.com
Last updated: [LAST UPDATED DATE]
