Layer400 Receiver Privacy Notice

1. Who is responsible

The controller for the personal data described in this receiver notice is Layer400 (Layer400, we, us or our).

Email: [email protected] (coming soon)

This notice explains personal-data handling for receiver registration, software acceptance, claims, device credentials, contributions, receiver reporting, updates, security and support. It applies to the personal-use receiver service. The separate general website Privacy Notice continues to cover unrelated website activity. This notice does not silently replace previously accepted agreements.

2. Scope and required information

The receiver service is offered to adult individuals operating supported fixed receivers in the United Kingdom for personal, non-business use. Account registration does not itself authorise contributions. Receiver access depends on account verification, the accepted release documents, station ownership, account limits and device security checks.

To provide the service we need your account email, account and receiver identifiers, the confirmed fixed antenna position, device public key, agreed document versions and the necessary operational data described below. If you do not provide required information, we cannot issue a receiver claim or provide the contributing receiver service. You can still use the public map without a receiver account.

Optional support submissions and optional browser permissions are not required to view the public map. Browser location is requested only when you choose Find location; you can select the antenna position on the map instead.

3. Personal data we receive

3.1 Registration and account data

We receive your registration email address, username or display name, email-verification state, internal account identifier, account status, security settings, sign-in and recovery events, and bounded security metadata needed to protect the account. Account email addresses are not included in receiver packages or ordinary public map responses.

Passwords and identity-provider secrets are handled by the identity service and are not available to the public map. We do not place passwords, session tokens, recovery codes or private account links in receiver logs or support bundles.

3.2 Software eligibility, acceptance and download data

We record the account's receiver eligibility, email-verification and enabled state; the release and document versions presented; each required affirmative acceptance or acknowledgement; UTC acceptance time; bounded request IP and user-agent audit metadata; and the release files requested.

The durable private acceptance record includes the minimum account identifier and email needed to show who accepted the documents. It does not contain a password, session token, claim code, signing private key, device private key or exact receiver coordinates.

3.3 Receiver and claim data

We receive the station’s private name, account relationship, claim status, internal station and device identifiers, declared receiver capabilities, confirmed antenna position, hardware inventory, software version, update state, clock and health information, credential identifiers, connection times, contribution statistics and diagnostic events.

The Pi generates its private device key locally. Layer400 receives the corresponding public-key identity or fingerprint and issued credential material needed to authenticate that device. The private device key must not be uploaded to Layer400 or placed in a support bundle.

3.4 Hardware and compatibility information

The receiver checks its model, architecture, operating system, software version, radio interfaces, stable adapter identifiers and relevant driver information to configure supported hardware safely. Detailed local diagnostics are not automatically a public upload. Layer400 receives declared capabilities, necessary health information and any diagnostic information you deliberately submit.

Separate hardware qualification may record model and revision, chipset, USB VID:PID, firmware, driver and actual passive reception results. A recorded identifier or an advertised monitor mode is not proof of successful Remote ID reception.

3.5 Station location

The precise fixed antenna position is used for receiver validation, distance and quality checks, coverage analysis, security, network operation and investigation of anomalous observations. Exact station coordinates are restricted operational data and are not intended for ordinary public display. Public presentation may use reduced precision, a broad area, aggregation, delay, a pseudonymous provider identifier or suppression.

Do not use a home address, a person’s name or another identifying label as the public station or provider name.

3.6 Remote ID observations

Time-stamped radio observations may contain a broadcast identifier, aircraft serial or session identifier, aircraft position, height, speed, direction, status and—where the applicable broadcast standard includes it—the position of the remote pilot or take-off point. We also record the reporting receiver, time, protocol, quality and confidence information.

Remote ID observations may be incomplete, duplicated, delayed, altered by reception conditions, unauthenticated or false. Layer400 does not describe them as complete or guaranteed air-traffic information. The receiver and map are not air traffic control, an air-traffic service, a navigation aid, an emergency service or proof that airspace is clear.

3.7 Website, network and security data

We receive IP address, request time, browser or app information, requested routes, session and correlation identifiers, response status, rate-limit events, authentication and authorisation outcomes, security alerts and records reasonably needed to diagnose failure, prevent abuse or investigate an incident.

Security logging must avoid request bodies or values that could contain passwords, sessions, claim codes, access tokens, signing keys, device private keys or precise station coordinates unless an exceptional, documented incident process lawfully requires a narrowly controlled record.

3.8 Support and test evidence

We receive information you deliberately include in an approved support or acceptance-test route, together with responses and the minimum technical evidence needed to resolve the issue. Receiver support bundles are generated locally, must be redacted, are not uploaded automatically and must be inspected before sharing.

4. Why we use personal data and our lawful bases

Depending on the activity, we rely on:

• contract to create and secure the requested account, present and record the separate agreements, supply the accepted digital content, issue the device identity and provide the requested receiver service;
• legitimate interests to enforce receiver ownership, authenticate contributions, prevent fraud and credential misuse, protect people and the service, validate and minimise received broadcasts, provide informational community coverage and history, measure network quality, investigate faults and maintain an auditable release;
• legal obligation where records or action are required by law; and
• consent only where a distinct activity legally requires it, such as optional marketing or a device permission.

Acknowledging this Privacy Notice is not consent to unrelated processing. Consent to immediate digital supply and acknowledgement of its possible cancellation-right effect are separate contract controls, not privacy consent. You may withdraw a consent where used, without affecting processing already carried out lawfully.

5. Public and restricted information

The public map-provider journey is designed to publish only an approved provider presentation and limited observation view. It is not an account directory, receiver-location registry or raw-data export.

Exact station coordinates, account email, account identifier, claim codes, device credentials, private keys, security metadata, detailed hardware inventory and private diagnostics remain restricted. A public provider presentation, broad area, availability indicator or contribution statistic may be shown only through the applicable authenticated and privacy-filtered publication path. Private receiver names and precise installation coordinates are not a directory for finding contributors.

A broadcast identifier is not necessarily a person’s name, but it may relate to an identifiable person when combined with other data. Do not use Layer400 to re-identify, target, confront or publish a person.

6. Retention

We keep each category only for the following period or until the following objective event. A paid or complimentary entitlement does not by itself decide retention.

• Account and profile: while the account is open, then deletion or irreversible anonymisation within 90 days after closure, except for the separate contract, security and legal records below.
• Sessions, sign-in and ordinary security logs: live sessions expire under the identity-service policy; bounded authentication, authorisation, request and rate-limit logs are kept for 90 days.
• Receiver eligibility and exceptional access restrictions: while needed for the account or active receiver, then removed within 30 days after the related eligibility ends, except for separately retained contract, security and legal records.
• Software Licence, document acceptance and immediate-digital-supply record: the minimum acceptance record is kept for six years after the receiver licence ends so that Layer400 and the consumer can establish the terms supplied and accepted and deal with legal claims.
• Receiver claim: the plaintext claim is displayed once and is not stored by Layer400. Its hash is valid for no more than 15 minutes. An unused or expired claim record is deleted within 30 days after expiry. A consumed replay binding is kept while its receiver credential is active and for 90 days after revocation or retirement.
• Station, device, public key and credential record: while the receiver is active and for 90 days after revocation or retirement. A revoked certificate identifier and revocation status may remain until the later of certificate expiry or 90 days after revocation where needed to reject the credential safely.
• Hardware qualification and release acceptance evidence: for 12 months after the relevant test or qualification closes. Evidence retained for a linked security incident follows the incident period below. Material that has been irreversibly stripped of personal data may be retained as non-personal release evidence.
• Receiver health and latest operational state: latest receiver state and privacy-safe fleet-health data are removed or cleared after 90 days without a qualifying receiver contact.
• Restricted raw receiver messages and decoded observations: no more than 30 days.
• Quarantine and dead-letter evidence: 30 days. Ingest idempotency and acceptance-conflict metadata is kept for 35 days. A committed receiver-acceptance delivery ledger is kept for 14 days.
• Public current-position state: one day as a maintenance horizon; ordinary live visibility is much shorter and governed by the current-state service rules.
• ADS-B track and reception history: 14 days.
• Remote ID derived and minimised track/reception history: no more than 1,095 days. Exact station coordinates, account data, claim data and device secrets are not part of the public history response.
• Contributor and network statistics: account- or station-linked statistics follow the account or station period above. Statistics that have been irreversibly aggregated or anonymised so that they are no longer personal data may be kept without a personal-data retention limit.
• Support: 90 days after the support case closes. A security-incident record is kept for 12 months after the incident closes, unless a longer legal hold is documented.
• Encrypted database backups: local encrypted recovery points are kept for no more than 14 days and no more than 14 copies, while preserving at least three valid copies. An encrypted off-site continuity copy is removed 30 days after creation once at least three newer verified recovery points exist; if they do not yet exist, the copy is kept only until those replacements have been verified. The recovery identity is held separately from the encrypted backup.

A documented legal hold may pause deletion only for the records and period reasonably required. When the hold ends, the ordinary period resumes and overdue records are deleted or irreversibly anonymised. The same retention rules apply when information is recovered from backup; restored records must be brought back within the applicable deletion schedule.

7. Sharing and processors

Layer400's application, identity, database, ingest and monitoring services are self-hosted. The following external providers are enabled; access is limited to the stated role:

• Cloudflare, Inc. — public DNS, content delivery, TLS termination and website security. It receives ordinary web-request information such as IP address, request time, route, browser/network headers, response and security metadata. Cloudflare operates a global network and may process this information in the United Kingdom, European Economic Area, United States and other network locations.
• Brevo (Sendinblue SAS) — transactional registration, verification, security and service email. It receives the destination email address, the message content or template fields and delivery/security metadata. Brevo states that its principal data storage for this service is in the European Union, including facilities in France, Germany and Belgium.
• OpenFreeMap — public map styles and tiles. A map visit sends ordinary network information and the map area and tiles requested by the browser. Tile delivery may use distributed infrastructure outside the United Kingdom; Layer400 does not send the receiver account email, claim, device credential or exact private station record as a map-tile parameter.
• Microsoft OneDrive — storage of client-side encrypted off-site database-backup archives. Microsoft receives ciphertext plus ordinary file metadata such as filename, size and timestamps; the separate Layer400 recovery identity is not uploaded. The storage geography follows the Microsoft account or tenant's assigned data location and may involve processing outside the United Kingdom.

If providers or purposes materially change, we will update the applicable notice or provider list and give the notice, and obtain any consent, required by law.

We may share narrowly necessary information with professional advisers, a purchaser or successor to the service, or a competent authority where required by law or reasonably necessary to protect people, security and legal rights. We do not sell personal data or provide an unrestricted public API containing raw observations or exact receiver locations.

8. International processing

Some enabled service providers may process personal data outside the United Kingdom. Where UK data-protection law requires it, we use an adequacy regulation, recognised contractual safeguards or another lawful transfer mechanism and assess additional protections where appropriate.

9. Security

Measures include verified account access, receiver ownership checks, separate short-lived claim codes, device-bound credentials, Ed25519 release signatures, encryption in transit, least-privilege access, restricted administration, bounded logging, backups, credential rotation and revocation, source-free public packages and redacted support bundles.

No online system is risk-free. Report a suspected vulnerability through the published security route. Never send a password, session token, claim code, private key or unredacted credential in ordinary email or chat.

10. Your rights

Depending on the circumstances, UK data-protection law gives you rights to access, correct, erase or restrict personal data; object to processing; receive certain data in a portable form; and withdraw consent. You may also complain to the UK Information Commissioner’s Office. We may need to verify identity and may lawfully retain or withhold some information.

Because Remote ID observations are received from radio broadcasts rather than collected from an account holder, we may need the time, location, identifier and supporting evidence to locate a record and assess a request safely.

You have the right to object to processing based on legitimate interests, including the use of broadcast observations that relate to you. Contact [email protected] (coming soon) and explain the relevant circumstances; we will assess the request and any lawful grounds for continuing. Do not include account or device secrets in a rights request.

Technical validation and abuse controls can reject a report or restrict a receiver automatically. You can contact support to challenge a restriction and request human review. Layer400 does not use reception of a broadcast to decide that a person or aircraft is acting unlawfully.

11. Children

The receiver service is offered to adults, not children. If we learn that a receiver account is operated by a child, we will restrict it and assess the data and any request with appropriate safeguards.

12. Changes, complaints and contact

We will identify the applicable version and date. A material change to the applicable receiver documents requires an appropriate notice and, where legally required, fresh affirmative acceptance before another download.

Privacy questions and rights requests: [email protected] (coming soon)
Controller: Layer400

You may complain to the UK Information Commissioner’s Office. This does not prevent you from using another remedy available under law.