OpalSpan: privacy and device-storage information
Version: privacy-en-2026-10-08-v8. Language: English.
Identity and purposes
Ready IT ApS, CVR 38769383, c/o Matt Luccas Phaure Jensen, Viften 18, 1. 1, 2670 Greve, Denmark; contact@readyit.dk; telephone +45 22 76 54 06.
Ready IT is controller for its own account administration, service security, billing and required business records. Where it processes customer technical-work data on a customer's behalf, that customer determines the processing instructions and the applicable processing agreement governs Ready IT's role. Where the customer is itself a processor, Ready IT acts within that authorised processing chain. Not every flow has the same controller.
| Controller purpose | Information and legal basis |
|---|---|
| Sign-in, workspace administration and delivery of your subscription | Identity-provider identifier, name/email, membership, role, workspace and order details. GDPR Article 6(1)(b) for a contract with the individual or requested pre-contract steps; Article 6(1)(f) for managing business-customer users and contacts, in the legitimate interests of delivering and administering the authorised service. |
| Protecting access and investigating misuse or service incidents | Authentication and access metadata, device/session identifiers, times, access outcomes and relevant incident reports. Article 6(1)(f), in the legitimate interests of protecting systems, customer data and service reliability and establishing what occurred. |
| Usage administration, payment reconciliation and support | Usage quantities, model/rate references, order/payment references, contact details and correspondence. Article 6(1)(b) where needed for the individual's contract; Article 6(1)(f) for business-account administration, support, reconciliation and resolving disputes. |
| Device telemetry where Ready IT actually determines the purpose/means | Scoped readings and technical identifiers below, only for the expressly requested service within a documented lawful basis. Article 6(1)(b) applies only where objectively necessary for that individual's requested service; any required consent is obtained separately and may be withdrawn. Customer-controlled processing follows its applicable DPA/instructions. A household/business purchase does not determine the role or give device-user consent. |
| Required accounting, tax and consumer-contract records | Invoice/buyer details, tax information where applicable, payment/refund records, agreement copies, acceptance and rights-request records. Article 6(1)(c) where retention or processing is required by law. Necessary records for legal claims may also be retained under Article 6(1)(f). |
Sign-in identity and access information are needed to provide authenticated service. The information necessary for the order, receipt and payment is needed to complete a purchase and provide its records. Without it Ready IT cannot complete those functions. Optional case content, device evidence and AI context depend on the work you choose to perform; omitting them can limit that work. Do not supply information unrelated to the requested task.
Information comes from you, your authorised workspace users and administrators, Auth0 sign-in, Stripe payment events, and the devices, files and technical evidence selected for authorised work. Customer contacts and people mentioned in case material may therefore be recorded indirectly by a customer or technician, rather than supplying the information themselves. These technical-work sources are customer-supplied or authorised device/workspace material, not a general public-record collection service.
OpalSpan Mech assists technical work; it is not offered as a system for making legally significant decisions about people. Automated access and credit checks enforce the selected service permissions and allowance. They are not an assessment of a person's creditworthiness.
Data and recipients
Depending on the features used, OpalSpan processes account and membership details, customer/contact/company records, case notes and drafts, device links and selected diagnostic/technical-work information. Hosted AI processes supplied context, conversation history and tool evidence through OpenAI.
Conversation history may span cases and devices; authorised workspace use is not confined to one chat folder. Material in another chat is not thereby private from other authorised workspace use. Access audit is metadata, not a recording of every command or transferred file. Conversation and case records can separately contain technical content.
| Recipient | Function and relevant information |
|---|---|
| AWS | Bridge hosting/operations in Lightsail eu-north-1, Stockholm, and the CloudFront front door; hosted service data, authorised device-telemetry metadata and request metadata relevant to those functions. No new telemetry or service-email provider is introduced by this package. |
| Auth0 | Authentication and identity services; sign-in identifiers, identity/contact attributes and authentication metadata. OpalSpan separately controls workspace membership and access. |
| Stripe | Hosted Checkout, payment processing, invoices/history and customer details; buyer/payment information and subscription/payment references. Stripe also processes information for its own payment, fraud-prevention and legal obligations. |
| OpenAI | API model processing for hosted OpalSpan Mech; selected conversation/context and tool evidence, usage and request metadata. |
| Microsoft 365 / Microsoft Graph | The existing contact mailbox and delivery of contract/rights confirmations: recipient address, message content, fixed document attachments and delivery metadata. Messages may also remain in the mailbox's Sent Items. The recipient's own mail provider receives mail addressed to that recipient. |
Suppliers' roles depend on the processing concerned; inclusion here does not make every supplier a subprocessor for every data item. Disclosure to authorities or professional advisers may also be required for an applicable legal obligation or necessary legal claim.
Stripe supplies invoices and payment receipts separately from OpalSpan's contract and rights confirmations.
Scheduled Mech and minimised device telemetry
An enrolled device sends only its lawfully selected Telemetry tier. Disabled
performs no optional telemetry collection; existing authenticated presence and
service-security traffic keep their independent purposes. Light
(telemetry-light-v1) contains fourteen
closed signal IDs: presence.online, volume.free_pct, volume.free_bytes, volume.fill_trend, crash.new_record, power.unexpected_reboot, disk.health_warning, thermal.pressure, system.uptime, memory.commit_pct, memory.available_pct, memory.stall_pct, memory.pressure and cpu.utilization_pct.
Full (telemetry-full-v1) contains all Light IDs plus eighteen IDs:
resource.exhaustion, volume.inodes_free_pct, filesystem.read_only, update.reboot_pending, update.last_success_age_days, update.failure_events, protection.antivirus_health, protection.gatekeeper, service.failure_events, service.failed_count, battery.capacity_pct, system.error_events, hardware.corrected_errors, hardware.uncorrected_errors, thermal.temperature_c, gpu.memory_used_bytes, gpu.memory_total_bytes and gpu.memory_used_pct. Full is cumulative coverage, not faster sampling. Resource usage
and other telemetry are one feature, not independent monitoring subscriptions.
Not every signal is supported on every platform; unsupported, inapplicable,
initial-baseline, source-failed and stale evidence remains explicit and is never
reported as zero or a healthy result.
The original health-first-slice-v1, health-catalogue-v1 and
health-resources-v1 identities retain their historical meanings for older
clients and observations. No old binding or device-user grant authorises the
new combined tier merely because some signals overlap. Device-linked readings
can be personal data. Hashes are pseudonymous, not anonymous or guaranteed
unlinkable.
| Information | Exact local source and handling |
|---|---|
| Envelope/authority | Authenticated workspace/device linkage, random batch ID, boot ID, UTC sample time, keyframe/clean-stop flags and closed signal-profile ID; fixed signal/instance/state, optional numeric value/unit/event ID, source observation time and allowlisted unavailable/error reason. Native opt-out/revision is not consent. Attributable instruction/consent evidence records exact profile, notice/binding, subject/evidence hashes, confirmation, revision, time/expiry separately; no username enters the feed. |
| Light and Full presence/volumes | presence.online, volume.free_pct, volume.free_bytes, volume.fill_trend: existing presence; native fixed-drive/local-filesystem free space for at most eight volumes and system trend; Mac APFS Data free space excluding purgeable capacity. Locally hashed Windows/Linux volume instances, no raw labels/paths. |
| Light and Full crash/reboot/warning | crash.new_record, power.unexpected_reboot, disk.health_warning: bounded fixed Windows System provider/event metadata, boot change without a local clean marker; at most16recent Linux coredump-journal metadata rows; at most128Mac system DiagnosticReports file-metadata entries. Only fixed codes/counts/opaque event keys leave the device, not messages, EventData, report body, raw filename or app name. Optional Linux kernel-exported NVMe warning; no exhaustive SMART/drive-health pass. |
| Light and Full thermal | thermal.pressure: supported Linux critical-trip-point projection or bounded at-most-hourly Mac thermal status. Windows remains unavailable. No private SMC/GPU/CPU sensor or invented manufacturer temperature. |
| Light and Full memory/uptime | system.uptime: native boot/tick/uptime source, at most hourly. memory.commit_pct, memory.available_pct: Windows GetPerformanceInfo/GlobalMemoryStatusEx ratios; Linux MemAvailable ratio only. memory.stall_pct: Linux PSI memory full avg60. memory.pressure: supported Mac pressure sysctl, normal/warning/critical projected to0/1/2. Whole-percent ratios/stalls and fixed levels only; unavailable equivalents remain unavailable. No processes, software or working-set inventory. |
| Full resource/storage | resource.exhaustion: fixed Windows Resource-Exhaustion-Detector event count or boot-scoped Linux OOM-counter delta; initial counters establish a baseline, not invented historical events. volume.inodes_free_pct: local Linux statfs ratio. filesystem.read_only: Linux root/Mac system-data mount flag. Windows equivalents and APFS inode budgeting are unavailable. No file enumeration. |
| Full updates | update.reboot_pending: presence of two supported Windows Update/CBS reboot keys or Linux reboot-required marker, at most hourly; no PendingFileRenameOperations paths. update.failure_events: fixed Windows Update provider IDs20/31 count. update.last_success_age_days: age of a success actually observed from Windows Update ID19, or the scalar Mac system LastSuccessfulDate preference, at most daily. No network update search, package/update inventory or patch-compliance conclusion. Other OS equivalents are unavailable. |
| Full protection | protection.antivirus_health: Windows Security Center's aggregate registered-antivirus health, good/poor/snoozed projected to0/1/2; not-monitored/unsupported is unavailable. It does not prove RTP state or absence of threats. protection.gatekeeper: Mac assessment-control enabled0/1 from one bounded daily system utility. No product, signature, detection or threat-name inventory. Linux equivalents are unavailable. |
| Full services | service.failure_events: fixed Windows SCM failure/crash IDs7000/7023/7031/7034 counts. service.failed_count: systemd manager's scalar NFailedUnits at most hourly. No service/unit names, commands or application inventory. Mac service-failure aggregate is unavailable. |
| Full battery | battery.capacity_pct: lowest valid installed battery full/design capacity ratio, at most daily and eight sources. Typed Windows battery-class IOCTL, consistent Linux energy/charge sysfs pair, or typed Mac IOKit capacity properties. No serial, registry dump or private SMC API. No battery, relative/invalid capacities or failed reads are unavailable/error, not100%. |
| Full event counts | system.error_events: at most128new Windows System error/critical metadata records or Linux journal priority0–3 metadata records per covered query. hardware.corrected_errors, hardware.uncorrected_errors: fixed Windows WHEA IDs17/19/47 or18/20/46 counts. No rendered message, account, executable, service/unit/app name, address or EventData. Unsupported Mac/Linux hardware equivalents are unavailable. |
| Always excluded | Raw logs, diagnostic/report/file bodies, threat names, usernames/sign-in addresses, application/software inventories, serials, network names, paths, commands, environment variables, arbitrary event matchers and broad monitoring of logons/account/admin changes. Other expressly authorised support work retains its separate explicit scope. |
Sampling uses the existing encrypted device channel and protected bounded state: five-minute cheap observations, fifteen-minute night cadence, six-hour keyframes; hourly/daily slow sources as stated, never PowerShell, continuous broad WMI, system_profiler, network softwareupdate search or a routine DiagnosticSnapshot. On initial activation/restart, fixed event queries may cover at most the previous hour; later queries use bounded local cursors. Cursor loss, truncation, permission and read failures invalidate coverage, not a success-shaped zero. A cached slow reading retains its original source timestamp and is not refreshed by presence. Native reads that cannot be cancelled may finish after a stop, but a superseded result is not queued and at most one battery-reader worker remains in flight.
Maximum64signals/16KiB per batch,256KiB/day,64queued batches/256KiB. These bounds can suppress or drop excess history; no exhaustive or instant detection is promised. Temporary Rescue is excluded. Collection, deterministic rule evaluation and case references create no AI-credit/device-work usage and send no default model feed. Only necessary bounded alert/context enters an actually authorised Mech run using the unchanged disclosed OpenAI arrangements.
Additional collection needs independently published exact copies/hash, an attributable original-holder/controller or authorised-processor instruction for the named current targets/profile, separate profile-specific informed device-user consent or evidence of objective necessity for expressly requested monitoring, native capability and explicit target profile selection. Required employment/ organisation notices and upstream-controller authority remain the responsible party's obligations; a notice is not terminal-access consent. First-slice consent, an old contract, enrolment, role, silence and removal of an opt-out supply no new authority. The current signed-in user consent path cannot invent another user's consent. Unavailable paths stay pending/off.
Resource readings within Telemetry
CPU utilization belongs to Light and Full. Temperature and dedicated GPU-memory readings belong to Full. These are the existing bounded native sources described below; choosing a combined tier does not start a diagnostic report, enumerate applications, identify network interfaces or introduce another provider.
A future-enrolment default records the workspace controller's prospective tier preference. Setting Full as the default does not widen existing device-user consent, override a local opt-out or supply missing access/processing authority. New devices collect only when their actual supported native capability, current instruction and applicable device-user authority cover the selected tier. Existing devices require an explicit version-bound change; historical rows keep their original profile and source time.
CPU is aggregate interval utilization between native OS tick samples, not process/application activity. Windows uses GetSystemTimes on systems with up to64logical processors; larger processor-group layouts remain unsupported. Linux uses the aggregate /proc/stat counters, excluding double-counted guest ticks. macOS uses the public Mach host CPU counters. Initial counters, resets and invalid intervals do not produce an invented zero.
Memory retains its exact existing platform meaning: Windows commit/limit and available physical memory; Linux MemAvailable and PSI full avg60 reclaim stalls; macOS native memory-pressure level. Memory utilization is not reclaim pressure. Uptime is at most hourly.
Up to three locally pseudonymised OS-exported temperature readings are reported in degrees Celsius, rounded to a tenth. Windows uses thermal-zone performance counters; Linux uses exported hwmon readings or thermal zones. Native Windows counter enumeration is bounded to64instances/32KiB for selection; no sensor name/path leaves the device. A reading is not necessarily CPU die temperature. macOS temperature remains unsupported without a reliable public source. No manufacturer threshold, inferred health score or vendor driver/SDK is added.
Dedicated GPU-memory usage, physical capacity and whole-percent utilization describe the selected largest dedicated-memory adapter among up to eight enumerated adapters. Windows uses public DXGI adapter capacity and bounded adapter-level performance counters, never process counters; Linux uses exported DRM VRAM scalars. Shared memory and process names are excluded. Dedicated VRAM is inapplicable on Apple-silicon unified-memory systems; other unsupported macOS sources remain unavailable. Physical utilization is not a reclaim-pressure measurement or a guaranteed allocation budget. Unsupported, absent, inapplicable, initial-sample and source-failed states remain distinct and nonnumeric.
Both Telemetry tiers keep five-minute cheap/fifteen-minute night sampling, six-hour keyframes,64signals/16KiB per batch,256KiB/day,64queued batches/256KiB and seven-day readings/thirty-day events and alerts. Bounded native readers cannot accumulate; superseded or cancelled results cannot be queued. Collection and deterministic evaluation consume no AI credits or device-work units and send no default model feed. Existing supplier, retention, original orders/prices/rights and separately authorised deeper-work boundaries are unchanged. Temporary Rescue remains excluded.
Installing support or publishing these copies does not select a Telemetry tier or widen an existing device grant. Native 0.23-or-newer software and its actual advertised Light/Full capability, the independent exact v12/v8 publication, current target revisions and local controls are checked by the service. Older software remains readable with its original scope and an honest upgrade-required state. A tier-aware future default is a preference; collection still requires the current instruction and applicable attributed device-user authority.
Authenticated requested telemetry
An explicit telemetry request from the signed-in authorised technician is the service action and its attributed request evidence. Within the actual permitted workspace/device scope, the service fills the required purpose/capacity, published profile/document binding and current revisions and records the prospective instruction and requested-service necessity. Mech trusts that technician request and attempts the permitted command; it does not ask the person to prove their general authority, complete a personal questionnaire, find a separate consent package or approve the same requested telemetry again.
This service-owned evidence is not a fabricated assertion that an unrelated person gave consent. The responsible customer/technician remains responsible for applicable organisation/employee notices and upstream-controller instructions. Existing attributed personal-consent/withdrawal routes remain available where used. Actual server-enforced permission, target, publication, native-capability and local-opt-out refusals remain boundaries. Removal of a local veto never supplies a telemetry request or new grant. Explicit Light/Full tier selection is required; older grants are not silently migrated. Genuine unattended-work, financial and native-access decisions retain their separate unchanged controls.
International processing
The Stockholm Bridge region does not establish EU-only processing. CloudFront has an international edge network; identity, payments, AI and email involve separate supplier processing and access arrangements.
AWS supplies the Stockholm hosting and international edge services under Ready IT's ordinary AWS account terms. The applicable AWS data-processing terms and standard contractual clauses are incorporated through those terms for the transfers they cover.
Hosted Mech uses OpenAI Ireland Ltd. under the ordinary OpenAI Services Agreement, updated 1 December 2025 and effective 1 January 2026. Section 5.3 incorporates OpenAI's DPA. Ready IT's API project uses Global residency and the Standard service tier, not an EU-only route. DPA section 4.1 provides for onward transfers from the EEA under agreements containing standard contractual clauses or an applicable GDPR Article 45 adequacy decision. See https://openai.com/policies/services-agreement/ and https://openai.com/policies/data-processing-addendum/.
Microsoft 365 Exchange Online and Graph are governed by the ordinary Microsoft agreement and incorporated Products and Services DPA. Microsoft's May 2026 DPA provides for processing in the United States and other countries where Microsoft or its subprocessors operate, subject to its stated location commitments. Its Data Transfers section applies the 2021 standard contractual clauses to transfers out of the EEA; the described transfer arrangement includes Microsoft Ireland Operations Limited and Microsoft Corporation. The DPA also records Microsoft's Data Privacy Framework commitments. This is not a claim that all mail processing stays in the EU. The DPA is available through https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA.
Auth0, supplied by Okta, processes sign-in identity and authentication data from an EU tenant. OpalSpan separately controls workspace membership and access. Supplier support and onward processing may occur outside the EEA. Okta's published processing and transfer information is available at https://www.okta.com/legal/trustandcompliance/.
Contact contact@readyit.dk to request information about the applicable transfer safeguards or a copy of the relevant safeguards.
Hosted AI retention
OpalSpan keeps conversation history for the authorised workspace. Hosted Mech sends relevant context and tool evidence to OpenAI's API to answer and carry out requested work. Stored Responses output is disabled, and Ready IT has not opted API inputs or outputs into model training, feedback or evaluation sharing. When you request hosted Python analysis, OpalSpan sends the selected conversation file and analysis question to an isolated OpenAI Code Interpreter container. OpalSpan returns the finding and any generated files to the same private conversation and requests deletion of the container after the run. Failed deletion is retried; OpenAI expires a container after 20 minutes without activity. OpenAI's separate API retention described below still applies. OpenAI may retain data for abuse monitoring for up to 30 days by default, or longer where its published terms permit, and encrypted prompt-cache state for up to 24 hours. These provider periods are separate from OpalSpan's own records; the service does not claim zero retention or EU-only processing. See https://developers.openai.com/api/docs/guides/your-data.
Retention
| Information | Retention period or criteria |
|---|---|
| Account and workspace administration | Kept while needed for the active account, memberships and service, then subject to applicable erasure, legal-record and dispute requirements. Cancelling a paid plan and returning to Free does not close the workspace or delete its records. |
| Customer directory, cases and conversation history | Kept for continuing authorised workspace work and case history. Directory/case records have no general automatic expiry timer. Closing a case or stopping payment is not an erasure instruction. For on-behalf processing, return/deletion follows the customer's instructions and the processing agreement. |
| Access-session/audit metadata | Ended access periods and ordinary audit metadata are removed according to the workspace's audit-retention setting, which defaults to 90 days. Cleanup runs in batches, so removal may occur after the configured period. Active periods and separately retained release, acceptance or other required evidence have different lifetimes. |
| Mistake History | An append-only accountability record without automatic expiry. Continued retention depends on the accountability/incident or legal-record purpose; applicable correction, erasure and restriction rights remain. |
| Mech files | Temporary scratch files expire after seven days of inactivity by default, with cleanup at startup and daily. Active runs can protect files from expiry; retained files follow their own policy. File removal does not remove a conversation or required financial record. |
| Telemetry readings/deltas | Historical numeric/state readings expire seven days after original measurement, not upload; row bounds may prune earlier. Latest non-event state and bounded native comparison/dedup metadata are separate while enrolled and can be stale, not historical feed. |
| Telemetry events/alerts and ingestion receipts | Event/alert records expire thirty days after recorded occurrence; count-bounded ingestion receipts expire thirty days after receipt. Older measurements do not become fresh alerts; a case/run reference does not preserve the entire expired feed. |
| Native unsent telemetry | Maximum64batches/256KiB; seven-day original-sample-age expiry during operation or next startup and clearing on acknowledgment/off. A stopped computer cannot be remotely wiped. Latest baseline/authority/cursors are separate protected enrollment metadata, not a historical report archive. |
| Automation configuration/authority/run history | Retained for the configured service and evidence of exact prospective authority; each run stays in the one conversation with its separate history policy. Immutable authorisation and necessary contract/financial/case evidence have separate purposes; cancelling a schedule is not promised erasure. |
| Usage, contract and financial records | Kept for reconciliation, required accounting/tax and contract evidence, and necessary dispute or legal-hold periods. Quantities and payment references may outlive conversation payloads; they do not require keeping every prompt. |
| Contact and confirmation email | Kept while needed to handle the enquiry, establish the contract or rights request, and meet associated legal-record/dispute requirements. Copies can remain with the recipient's mail provider. |
| Provider logs/application state | Subject to the relevant supplier flow; the OpenAI limits above are separate from OpalSpan's own records. |
| Recovery copies | Automatic service snapshots retain the latest seven daily generations. Separate manual recovery copies have no automatic expiry and are reviewed individually. During ongoing service, a copy may remain after live data is removed. A return or deletion request includes relevant recovery copies; any legally required retention exception is explained. Before restored data is returned to use, completed deletion and restriction instructions are reconciled. |
For access, correction, return, deletion or restriction requests, Ready IT verifies the requester's authority and the affected workspace and records. Live service data, recovery copies and records held for legal obligations may need different treatment. Ready IT records the action and explains any remaining copies or exceptions for the specific request. Cancelling renewal or removing access does not itself delete records. Contact contact@readyit.dk; requests about customer-controlled data are handled with the relevant controller.
Rights and complaints
Where applicable, you may request access, correction, erasure, restriction or portability and object to processing. Where consent is the basis, you may withdraw it without affecting the lawfulness of earlier processing. The relevant conditions and exceptions apply. Contact contact@readyit.dk; a request concerning customer-controlled data is handled with the relevant controller.
You may complain to the Danish Data Protection Agency, Datatilsynet, https://www.datatilsynet.dk/, or another competent supervisory authority.
Cookies and similar technologies
OpalSpan uses an authentication cookie to provide signed-in access. The protected authentication ticket has a fourteen-day lifetime with sliding renewal enabled; continued use can renew it. This is not a promise that every session ends after fourteen days. OpalSpan does not request a persistent browser-cookie expiry for this sign-in path. Browser handling, including session restoration, is separate from the ticket's validity.
Short-lived nonce and correlation cookies protect the sign-in exchange and expire after approximately fifteen minutes. Those are OpalSpan's sign-in cookies, not a description of Auth0's separate SSO cookies. These authentication and challenge operations enable the requested sign-in and its security.
The workspace-selection cookie __Host-ForgeWorkspace remembers your selected
workspace for up to 30 days; the invitation-handoff cookie
__Host-ForgeInvitation lasts up to 20 minutes. These cookies are operated by
Ready IT, protected, Secure and HttpOnly; they do not themselves grant access.
Their technical names remain unchanged during the OpalSpan transition.
The workspace interface also uses local storage to remember your explicitly chosen Simple/Advanced view. This preference has no automatic browser-storage expiry; you can change the view or clear site storage. Enrollment uses session storage to recover the requested enrollment journey, with a progress record identifier rather than a raw enrollment code; it is removed explicitly or with the browser tab/session. Refusing that storage prevents this recovery function. These operations support the requested view or enrollment journey, not advertising. A requested preference does not make unrelated tracking necessary.
Auth0's sign-in journey and Stripe's hosted payment journey operate their own device-storage technologies. Auth0 describes its session, sign-in security, device/attack-protection and, where used, multi-factor cookies at https://auth0.com/docs/manage-users/cookies/authentication-api-cookies. The Auth0 tenant's default session policy is persistent. Persistent sessions have a three-day idle timeout and a seven-day maximum; nonpersistent sessions have a one-day idle timeout and a three-day maximum. These are server-side session limits, not a promise that browser storage is physically erased on the same timetable. They are distinct from OpalSpan's own authentication ticket.
Stripe describes its payment/security and other storage categories at https://stripe.com/legal/cookies-policy, with individual cookie purposes, durations and available consent choices at https://stripe.com/cookie-settings. Stripe's wider website policy is not a claim that every listed analytics or advertising cookie operates in Checkout.
The OpalSpan Agent CLI stores a protected sign-in credential on the technician's device so the authorised user can return without signing in for every command. The current user's Windows Credential Manager protects it on Windows; Linux uses the configured Secret Service or protected-key store. Logging out removes the local profile credential and cache, but does not itself delete server records or revoke every token held by another process.
The browser product uses opalspan.com; installed Agent CLI and device clients
continue to use forge.readyit.dk as a compatible service endpoint.
Native clients also keep configuration and authorised-device state separately.
Clearing browser state does not clear that native state or delete server
records.