Privacy Policy
This policy explains how personal data is processed when you visit this website, when you hold a Pelyr account, and when you use the Stream API (together, the “Service”). It is provided under the EU General Data Protection Regulation (Regulation (EU) 2016/679, “GDPR”), the Austrian Data Protection Act (Datenschutzgesetz, “DSG”) and the Austrian Telecommunications Act 2021 (Telekommunikationsgesetz 2021, “TKG 2021”).
The Service is built to be data-minimal. There is no advertising, no cross-site tracking, no third-party tracking cookies and no profiling. We do not store your full IP address in the Stream API’s logs, because it is truncated before it is written.
1. Controller
The controller within the meaning of Art. 4(7) GDPR is:
Gerichtsstraße 13, 9300 St. Veit an der Glan, Austria
Email: hello@pelyr.com
Use these details for any data protection question or to exercise your rights.
2. Data Protection Officer
A statutory Data Protection Officer (Datenschutzbeauftragter) has not been appointed, as the conditions of Art. 37 GDPR and the corresponding provisions of the DSG are not met. The controller named in section 1 is your point of contact for all data protection matters.
3. Overview of processing
| Activity | Data | Legal basis |
|---|---|---|
| Website and server logs (§5) | IP address, timestamp, requested URL, referrer, user agent | Art. 6(1)(f) — legitimate interest in a secure, functioning website |
| Reach measurement (§7) | Page, referrer, device/browser type; IP transiently as a daily hash, not stored | Art. 6(1)(f) — legitimate interest in reach measurement |
| Account and GitHub sign-in (§8) | GitHub user ID and login name, account creation date, display name, sign-in timestamps, recovery code hash | Art. 6(1)(b) — performance of the user relationship; Art. 6(1)(f) for account security |
| Stream API keys (§9) | Key hash, key prefix, label, scope, creation/revocation/last-use timestamps | Art. 6(1)(b); Art. 6(1)(f) for security |
| Usage accounting (§9) | Per key and calendar month: connections, rejections, message count, bytes transferred | Art. 6(1)(b) — enforcing the connection limits; Art. 6(1)(f) — capacity planning and security for the message and byte counts, which enforce nothing |
| Abuse protection (§10) | Truncated IP address, key prefix, failure reason | Art. 6(1)(f) — legitimate interest in IT security |
| AIS vessel data (§11) | Vessel identifiers, positions, voyage data; personal only where attributable to a natural person. Individual messages are also archived, each with the identifier of its source | Art. 6(1)(f) — legitimate interest in providing publicly broadcast maritime data |
| Contributor stations (§12) | Contact details, station location and coverage, uptime and operating statistics; in individual cases of suspected manipulation, that station’s complete raw uploads for a limited period | Art. 6(1)(b) — operating and rewarding the station; Art. 6(1)(f) — detecting manipulation |
| Contact by email (§14) | Email address, message content | Art. 6(1)(b) / (f) |
Where we rely on legitimate interests (Art. 6(1)(f) GDPR), you have a right to object — see section 18.
4. Processors and infrastructure
The following providers process personal data on our behalf as processors under Art. 28 GDPR:
| Provider | Role | Processing location |
|---|---|---|
| Cloudflare, Inc. — Privacy · DPA | Delivery, CDN and edge security for pelyr.com and for the Stream API; processes visitor IP addresses at the edge. Also object storage (R2): the archive of received AIS messages (§11) and, where a contributor station is under investigation, that station’s raw uploads (§12) | Global edge and storage network / USA — see §15 |
| GitHub, Inc. (Microsoft) — Privacy | Identity provider for account sign-in. GitHub is an independent controller for the data it processes on its own platform — see §8 | USA — see §15 |
| netcup GmbH, Karlsruhe, Germany — Privacy · DPA | Hosting of the application servers: the Stream API, the backend and the reverse proxy run in containers on this server | Germany (EU) |
| DigitalOcean, LLC — Privacy · DPA | Managed PostgreSQL and Valkey — accounts, API key hashes, usage counters and live stream state | Frankfurt, Germany (EU); the company is US-based — see §15 |
| STRATO GmbH, Berlin, Germany — Privacy · DPA | Server for our self-hosted Plausible instance (reach measurement — §7) and for our SigNoz instance, which collects the services’ operational telemetry (§5) | Germany (EU) |
We do not sell personal data and do not pass it to third parties for their own purposes. Disclosure to public authorities occurs only where we are legally obliged to do so.
5. Website and server logs
When you access the Service, technical connection data is processed so the site can be delivered and operated securely: the IP address of the requesting device, date and time, the requested resource and HTTP status, the referrer where transmitted, and the user agent.
Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in the secure, stable provision of the Service.
Storage period: only as long as necessary for those purposes, in particular to investigate technical faults and security incidents, after which the data is deleted or anonymised. Server logs are not used to build user profiles.
Operational telemetry (SigNoz)
The services send their own operational telemetry — log entries, error reports, timing measurements — to a SigNoz instance we run ourselves on a server operated by STRATO GmbH, Berlin (see section 4). This is how a fault is found without having to log into each machine.
These records describe the service, not the visitor. Where they touch a request at all, the Stream API writes a truncated IP address and the non-secret prefix of an API key, never the full address and never the key itself (see section 10). No telemetry leaves the EU.
Legal basis: Art. 6(1)(f) GDPR — legitimate interest in an operable, diagnosable service.
6. Cookies and local storage
Storing information on, or reading it from, your device is governed by § 165(3) TKG 2021. We use only what is strictly necessary to provide the functions you request — in particular a session token once you are signed in. There are no analytics, advertising or cross-site tracking cookies.
Because nothing requiring consent is stored on your device, no cookie consent banner is used.
7. Reach measurement with Plausible
To see which pages are used, we run Plausible Community Edition on our own server. Plausible is designed to work without cookies and without following anyone across sites.
We measure reach on both of the surfaces we operate: this website (pelyr.com) and the contributor dashboard (dashboard.pelyr.com). They are kept as two separate sites in Plausible. Nothing links a visit to one with a visit to the other.
On each of them, the measurement script and the endpoint that receives the events are served from that same site — from pelyr.com on this website, and from dashboard.pelyr.com on the dashboard — and not from an analytics domain. Your browser never contacts a third-party host for this.
Each page view records the page, the referrer, and a coarse device and browser type. Your IP address is not stored. It is used transiently to derive a hash that changes daily, which is what lets Plausible tell a returning visitor from a new one within one day, and nothing beyond it. There is no identifier that survives to the next day, and no way to recognise you across websites.
The dashboard is used while you are signed in. Three safeguards apply to it, so that being signed in does not make the measurement more revealing than it is on the public website:
- No identifier of you is sent. A measurement event carries no account, user or station identifier, and no custom properties.
- Your session cookie is removed before the event is passed on to the Plausible instance. The instance therefore cannot attribute the measurement to your account, even in principle.
- The address is shortened before it leaves your device. An address that would identify a single station is reduced to a placeholder, so we can see how often the station pages are used but not which station was opened. Everything after the “?” in an address is discarded as well, which includes the destination carried along through a sign-in.
Processor: the instance runs on a server operated by STRATO GmbH, Berlin, Germany (see section 4). No data leaves the EU for this purpose.
Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in understanding whether the website and the dashboard are useful, measured with the least data that answers the question. You may object at any time (see section 18).
8. Accounts and GitHub sign-in
An account is required to obtain a Stream API key. Accounts are created exclusively through GitHub: you authenticate at GitHub, and GitHub confirms your identity to us.
We store:
- your GitHub user ID and login name, and the date your GitHub account was created;
- a display name;
- the scope and limits assigned to your account (permitted data sources, maximum number of keys and concurrent connections);
- timestamps: account creation, last sign-in, and when your GitHub login name was last seen;
- a hash of a one-time recovery code, where one has been issued.
We never receive and never store your GitHub password, and we do not store an email address for Stream API accounts.
The GitHub account creation date is used as one signal against automated mass registration. Signing in transmits data to GitHub under GitHub’s own privacy statement, for which GitHub is the controller.
Legal basis: Art. 6(1)(b) GDPR for providing the account; Art. 6(1)(f) for its security and against abuse.
9. Stream API keys and usage accounting
For each API key we store a cryptographic hash of the key, a short non-secret prefix used to identify it in logs and in the interface, an optional label you choose, its scope, and the timestamps of creation, revocation and last use.
The key itself is never stored. It is shown to you once, at creation. If you lose it, it cannot be recovered — only replaced.
The time of last use is recorded at most once per key and minute, so that you can identify unused or compromised keys.
Per key and calendar month we count connections, rejected connection attempts, messages delivered and bytes transferred. Connection counts serve to enforce the limits in the Pelyr API Terms. Message and byte counts enforce nothing — there is no volume limit; they exist so that we can plan capacity and notice a key being abused. The counters are not linked to individual queries: which vessels or areas you subscribe to is not stored.
Legal basis: Art. 6(1)(b) GDPR for the connection counts — enforcement of the agreed limits; Art. 6(1)(f) GDPR for the message and byte counts — capacity planning and security.
10. Abuse protection and how IP addresses are handled
Failed authentication attempts are logged so that systematic key-guessing can be detected. In these logs the IP address is truncated before it is written:
- IPv4 keeps only the first two octets —
203.0.x.x - IPv6 keeps only the leading network portion
This is enough to see whether attempts come repeatedly from the same network, and not enough to identify an individual connection. The full address is processed transiently to establish the connection and by the edge and reverse proxy layers, but the Service does not write it to its own logs.
Rate limits at the edge use the IP address transiently for counting; no profile is created.
Legal basis: Art. 6(1)(f) GDPR — legitimate interest in the security of the Service and of its users’ keys.
11. AIS and vessel data
AIS is a radio system that vessels use to broadcast their identity, position and voyage data publicly and unencrypted for safety of navigation. We receive these transmissions from third-party feeds and from community stations and pass them on.
For commercial vessels this data relates to the ship, not to a person. It can nevertheless become personal data where a vessel is attributable to a natural person — a small private craft, for example — since the position of the vessel may then permit conclusions about the position of a person.
Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest lies in providing publicly broadcast maritime data for situational awareness, research and safety-related purposes. Weighing this against the interests of those affected, we take into account that the data is broadcast openly and without encryption by law, is intended by design to be received by anyone, and is widely available from other sources.
If you are affected and object to processing (Art. 21 GDPR), contact us using the details in section 1. We will examine every objection individually. Note that we can only act on our own presentation of the data — the vessel’s own transmission continues regardless, and the same signal remains receivable by anyone.
Use of this data for the surveillance or tracking of individuals is prohibited by the Pelyr API Terms.
Archiving. Received AIS messages are not only delivered live but also written to an archive we keep in Cloudflare’s object storage (R2). The archive holds individual messages, not merely aggregated figures, and each record carries the identifier of the feed or station it came from. We use it to compute coverage, to produce statistics and for research. Data received from community stations and data received from third-party feeds are held in the same archive, distinguished by a source marker.
12. Contributor stations
If you operate an AIS receiving station for the network, we additionally process the data required to run and reward it: contact details, the station’s approximate location and coverage area, and its operating and uptime statistics. Details are governed by the separate contributor agreement.
Raw recording in individual cases. There is deliberately no blanket raw archive of station uploads. Where there is a concrete suspicion that contributions are being manipulated, or where a delivery fault cannot be diagnosed from the metadata alone, we can switch on a recording for the individual station concerned for a limited period. While it is active, that station’s complete uploads are stored in Cloudflare’s object storage (R2) under a key containing the station identifier, and are deleted after 90 days. They serve only to check the plausibility of contributions and to diagnose faults in a station’s delivery. They are not used for anything else.
Legal basis: Art. 6(1)(b) GDPR for operating and rewarding the station; Art. 6(1)(f) GDPR for the raw recording — our legitimate interest in detecting manipulation of a reward system paid out from shared funds, and in diagnosing delivery faults that cannot be traced from metadata alone.
13. Storage periods
| Data | Period |
|---|---|
| Account data | Until the account is deleted — see below |
| API keys (hash and metadata) | Until the account is deleted; a revoked key is kept as proof of revocation for as long as that proof may be needed |
| Monthly usage counters | Deleted together with the account |
| Contributor station: master data, uptime and coverage records | For as long as the station takes part, and afterwards for as long as needed to settle the reward period — then handled as set out below |
| Records of suspected manipulation | 3 years, then deleted |
| Reward runs and reward lines | 7 years (statutory retention for accounting records) |
| Server and abuse logs | As long as required for security purposes, then deleted or anonymised |
| AIS data | Live delivery; individual messages are archived for coverage calculation, statistics and research and kept for as long as required for those purposes — see §11 |
| Raw recording of a station under investigation | 90 days, then deleted — see §12 |
| Email correspondence | As long as required to handle your enquiry and any statutory retention period |
Deleting your account deletes the associated keys and their usage counters.
If you ask us to delete your data
An account that has no contributor station attached can be deleted by you directly, and that deletion is immediate. If you operate a station, deletion is not a single step: parts of the data are needed to settle the reward period you took part in, and parts we are required by law to keep. You can request deletion at any time using the details in section 1, and we then handle it as follows.
| Data | What happens on a deletion request |
|---|---|
| Account, display name, contact details | Deleted |
| Stream API keys and usage counters | Deleted |
| Station master data, uptime records, coverage records | Anonymised: the link to you and to your station is removed. What remains are coverage figures that can no longer be attributed to a person |
| Records of suspected manipulation | Restricted (Art. 18 GDPR) for 3 years, then deleted. They are no longer used, only kept — Art. 17(3)(e) GDPR, for the establishment and defence of legal claims |
| Reward runs and reward lines | Restricted for 7 years, then deleted. Accounting records are subject to a statutory retention period (§ 132 BAO, § 212 UGB) — Art. 17(3)(b) GDPR |
“Restricted” means blocked, not kept in use: the data is retained solely to meet the obligation named beside it and is not otherwise processed. Once the period ends, it is deleted.
Until the automated path for this is in place, we carry it out manually on request within the period stated in section 18.
14. Contact by email
If you contact us at hello@pelyr.com, we process your address and the content of your message in order to answer it.
Legal basis: Art. 6(1)(b) GDPR where the enquiry concerns a contractual relationship, otherwise Art. 6(1)(f).
15. International transfers
Three of the providers in section 4 are companies based in the United States: Cloudflare, GitHub and DigitalOcean. Transfers to them take place on the basis of the European Commission’s Standard Contractual Clauses (Art. 46(2)(c) GDPR) in conjunction with the relevant provider’s data processing addendum, and where applicable on the provider’s certification under the EU–US Data Privacy Framework (adequacy decision of 10 July 2023, Art. 45 GDPR).
In the case of Cloudflare this concerns not only delivery at the edge but also the object storage described in sections 11 and 12. It is used without a jurisdictional restriction, so we cannot guarantee that the objects are stored within the Union.
In the case of DigitalOcean the databases themselves are operated in the Frankfurt region (Germany), so the data is stored within the Union. The company is nevertheless subject to US law, which is why the safeguards above apply to it as well.
The servers running the application (netcup) are located in Germany and are operated by a German company; no transfer to a third country takes place there.
Notwithstanding these safeguards, a residual risk cannot be excluded that US authorities gain access to data under US surveillance law without you having a remedy equivalent to that under EU law.
16. Data security
All connections are encrypted in transit (TLS). API keys are stored only as hashes. Access to production systems is restricted to the controller. The services run in separated containers with resource limits, and the Stream API logs neither full IP addresses nor the content of your subscriptions.
17. No automated decision-making
No automated decision-making within the meaning of Art. 22 GDPR, including profiling, takes place. Automated limits — the connection and subscription limits of section 6 of the Pelyr API Terms, rate limiting at the edge, the revocation of an abused key — are technical protective measures and produce no legal effect concerning you within the meaning of Art. 22.
18. Your rights
You have the right to:
- access (Art. 15 GDPR) — what we process about you;
- rectification (Art. 16);
- erasure (Art. 17);
- restriction of processing (Art. 18);
- data portability (Art. 20);
- object (Art. 21) — to any processing based on legitimate interests, including the presentation of AIS data relating to you;
- withdraw consent at any time with effect for the future, where processing is based on consent.
Requests go to the address in section 1. We respond within one month; where a request is complex, that period may be extended, and we will tell you.
Where you ask for erasure, section 13 sets out what is deleted straight away, what is anonymised, and what we are obliged to keep — with the period and the ground for each.
19. Right to lodge a complaint
You have the right to complain to a supervisory authority, in particular in the Member State of your residence, place of work or the alleged infringement. The competent authority for us is:
www.dsb.gv.at
20. Obligation to provide data
You are under no statutory or contractual obligation to provide personal data. Without a GitHub sign-in, however, no account and therefore no API key can be created. Browsing this website requires no account.
21. Changes to this policy
We may update this policy to reflect changes to the Service or the legal position. The current version, with its date, is always published here.