Immutable document version: owner-canary-privacy-2026-08-25
Applies to: private, personal/consumer-only Receiver Owner-Canary acceptance test
Approved: 27 August 2026
1. Who is responsible
The controller for the personal data described in this Owner-Canary notice is Jacques Henry Ireland Steventon trading as Layer400 (Layer400, we, us or our).
Email: [email protected]
Geographic/postal address: Jacques Steventon trading as Layer400, 11 Wyvern Way, Blandford, Dorset, England, DT11 7XQ
This notice explains personal-data handling for the restricted Owner-Canary registration, software acceptance, Raspberry Pi 5 receiver claim, device credentials, contributed observations, map-provider publication, security and support journey. It supplements, and does not silently amend, the currently deployed general Privacy Notice. The approved final notices must state clearly which version governs each activity.
2. Owner-Canary scope
The Owner-Canary is restricted to one exact verified and enabled account and one expressly approved Raspberry Pi 5 receiver. General public receiver enrolment is disabled. Creating or verifying another ordinary Layer400 account does not make it eligible for receiver download, claim issuance, device credentials, production ingest or map-provider publication.
The Owner-Canary is personal/consumer-only. Business or commercial use is not permitted under this release.
3. Personal data we receive
3.1 Registration and account data
We receive the email address submitted for the clean registration test, a 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. The private Owner-Canary email is deployment configuration: it must not be committed to source code, packaged in receiver artifacts, exposed through the website or retained in general build evidence.
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 whether the exact account is allowlisted; its 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 Pi 5 and radio-hardware qualification data
For the acceptance test we record the Raspberry Pi model and revision, operating-system and kernel versions, architecture, package version, network-adapter inventory and the exact Cudy product label, hardware revision, chipset, USB VID:PID, firmware and driver. Genuine monitor-mode capture results and relevant failure diagnostics are recorded. We do not claim generic Cudy support from an untested or unidentified device.
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 the single-account and single-device boundary, authenticate the receiver, protect the service, prevent fraud and credential misuse, validate observations, measure coverage, investigate faults and maintain an auditable Owner-Canary 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 name, broad area, availability indicator or contribution statistic may be shown only after the exact device is authenticated and the publication gate is enabled for the Owner-Canary.
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.
- Owner-Canary allowlist: for the authorised private test, then removed within 30 days after the test is closed or superseded by a separately approved programme.
- Software Licence, document acceptance and immediate-digital-supply record: the minimum acceptance record is kept for six years after the Owner-Canary 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 Owner-Canary acceptance evidence: for 12 months after the private test closes. Evidence retained for a linked security incident follows the incident period below.
- 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. Production publication remains blocked until the configured jobs and archive lifecycle enforce this schedule.
7. Sharing and processors
Layer400's application, identity, database, ingest and monitoring services are self-hosted for this test. 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 Owner-Canary 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.
No other external provider is approved for Owner-Canary personal-data processing without an updated notice or current subprocessor list and, where legally required, a fresh notice or acceptance step.
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 exact account and device allowlists, 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.
Contact [email protected]. Do not include account or device secrets in a rights request.
11. Children
The Owner-Canary is not offered to a child. It is a personal test for the expressly allowlisted adult account holder. General public receiver enrolment remains disabled.
12. Changes, complaints and contact
We will identify the applicable version and date. A material change to the accepted Owner-Canary documents requires an appropriate notice and, where legally required, fresh affirmative acceptance before another download.
Privacy questions and rights requests: [email protected]
Controller: Jacques Henry Ireland Steventon trading as Layer400
Geographic/postal address: Jacques Steventon trading as Layer400, 11 Wyvern Way, Blandford, Dorset, England, DT11 7XQ
You may complain to the UK Information Commissioner’s Office. This does not prevent you from using another remedy available under law.