Privacy · Mobile app

Privacy Policy for TRLLN Collect

Last updated: August 27, 2026

Platform-specific collection

iOS and iPadOS: TRLLN Collect uses Bluetooth Low Energy (BLE) and NFC only while the app is in the foreground. Precise location is optional and, when enabled, is used only while the app is in the foreground. TRLLN Collect does not scan for or collect nearby Wi-Fi data, use BLE in the background, or collect location in the background on iOS or iPadOS.

Android: depending on the enabled and approved app workflow, TRLLN Collect may use BLE, NFC, precise location, nearby Wi-Fi data, and Supernode Mode. Supernode Mode supports the approved Android background BLE, Wi-Fi, and location behavior and runs with the required Android permissions and foreground-service notification.

Introduction

TRLLN Collect (“we”, “our”, or “us”) is a mobile field application that detects nearby Bluetooth Low Energy (BLE) nodes and supports physical asset validation using NFC. This Privacy Policy explains how the app handles information when you use it.

Information we collect

Bluetooth Low Energy (BLE)

  • Purpose: we request Bluetooth access to detect nearby BLE nodes matching configured manufacturer IDs and to validate the operational status of associated assets.
  • What: observations may include the hardware MAC address of a matching BLE node on Android, or the platform-provided device UUID on iOS, together with signal and timing information used for operational telemetry.
  • When: on iOS and iPadOS, BLE scanning occurs only while the app is in the foreground. On Android, BLE scanning may continue in the background only when the approved Supernode workflow is enabled, the required permissions are granted, and the required foreground service is running.
  • Transmission: matching BLE observations may be included in telemetry payloads sent to https://api.trlln.io/*.

NFC asset validation

  • Purpose: NFC is used to identify a physical asset and validate whether its associated BLE node is emitting.
  • What: the app reads only the NDEF payload from the NFC tag. The NDEF payload contains the MAC address of the associated BLE node.
  • When: NFC validation is performed as part of an in-app asset-validation flow while the app is active.
  • Validation: after reading the NDEF payload, the app checks for the associated BLE node and may record the validation result as operational telemetry.

Location (GPS)

  • What: when permission is granted and a location fix is available, the app may collect precise GPS coordinates, including latitude and longitude.
  • iOS and iPadOS: precise location is optional and is collected only while the app is in the foreground.
  • Android: precise location may enrich telemetry during active use. When the approved Supernode workflow is enabled and the required permissions are granted, location may also be collected in the background through the Android foreground service.
  • Purpose: location helps associate BLE observations and validation events with the field location where the work occurred.
  • Transmission: available coordinates may be included in telemetry payloads sent to https://api.trlln.io/*.

Nearby Wi-Fi access points — Android only

  • What: on Android, the app may collect the hardware MAC address (BSSID) and signal strength (RSSI) of nearby Wi-Fi access points when the relevant workflow and permissions are enabled.
  • What is not collected: Wi-Fi network names (SSIDs) are not collected.
  • iOS and iPadOS: the app does not scan for or collect nearby Wi-Fi access-point data.
  • Purpose: available BSSID and RSSI information provides ambient location context to complement GPS coordinates in telemetry.

Device identifier

  • What: a stable, hardware-derived identifier (device_id) is generated on the device and included in every scan payload sent to api.trlln.io.
  • Format: a truncated SHA-256 hash derived from hardware properties (Android ID / iOS Vendor ID, device model, board), truncated to 12 uppercase hexadecimal characters and prefixed with the platform name — for example, android_XXXXXXXXXXXX or ios_XXXXXXXXXXXX. This identifier is deterministic and persists across app restarts; it is not a randomly generated UUID.
  • Storage: stored in secure storage on your device.
  • Purpose: server-side device attribution and observability — allows the server to associate scan events with a specific device across sessions. It cannot be used to identify you personally.

Authentication

  • The app authenticates users via Auth0 (auth0.com), a third-party authentication service.
  • User credentials (email/password or social login) are handled exclusively by Auth0’s hosted login page. The app does not process your credentials directly.
  • Auth0 issues a JWT access token that is stored in secure storage on your device and included as a Bearer token in all API requests to api.trlln.io.
  • For details on how Auth0 handles your data, see Auth0’s privacy policy: https://auth0.com/privacy.

How data is submitted

  • Operational submission: BLE observations, NFC validation results, available location, and Android Wi-Fi context may be submitted to TRLLN services as part of the app’s operational workflows.
  • Connectivity recovery: pending scan and telemetry data may be submitted automatically when network connectivity is restored.
  • Periodic retry: pending data may be retried according to the app’s retry and retention rules. The app does not guarantee that every attempted submission will be delivered.

Local storage and offline operation

  • BLE observations, NFC validation records, Android Wi-Fi context, telemetry payloads, sync status, and retry state may be stored locally in a database on your device.
  • When connectivity is unavailable, pending data may remain queued locally and the app attempts to transmit it when connectivity resumes.
  • The queue uses retry and retention rules, including retry backoff where applicable, for temporary network failures.
  • Local storage and transmission depend on the app workflow, device state, granted permissions, available connectivity, and applicable retention rules.

Data storage

  • Operational data may be stored locally on your device before submission and may be transmitted to api.trlln.io when the relevant workflow submits it.
  • Data transmitted to TRLLN services is associated with the relevant operational records and device identifier for device attribution, troubleshooting, and telemetry correlation.

Third-party services

  • https://api.trlln.io/* — primary data endpoint for operational and telemetry data.
  • Auth0 (auth0.com) — authentication provider.

The app does not include advertising or analytics SDKs.

Your rights

  • To request access to, correction of, or deletion of any data held on our servers, contact us at the address below.

Changes to this policy

We may update this Privacy Policy from time to time. We will notify you of any changes by updating the “Last updated” date at the top of this page.

Contact us

If you have questions about this Privacy Policy, please contact us at info@trlln.io.