Keep the hobby. Keep the keys private.

Do not solve a local problem with a public port

A local map or receiver administration page does not need to be reachable by everybody on the internet. Use the documented outbound feeding arrangement. For remote administration, use a properly configured trusted access method rather than casually forwarding the receiver's web or raw-data ports.

Keep the operating system and receiver software maintained. Change default credentials where the platform supplies them. Use the minimum exposure needed for your own network. A packet format carrying aircraft data is not an authentication system.

These are defensive operating recommendations. This guide does not assess the security of your router, appliance or installation.

Before running a copied command

Confirm who publishes it and what it changes. An installation command may add services, modify ports, change packages or enable sharing. Read the maintained instructions, save a recovery path and use a spare device for experiments that might disrupt a working station.

This guide intentionally avoids an all-purpose curl | sudo bash command. No single installer knows the state of every existing receiver. Links in the software directory go to the named maintainers' repositories, not mirrored installation snippets hosted by Skylark.

A repository being public does not prove that every linked binary or dependency has been audited. Decide what you trust and keep track of what you installed.

Private location and public attribution are separate choices

A network may need an accurate antenna location for receiver processing while offering a less precise or optional public marker. Read the actual controls. Do not assume that hiding your display name hides coordinates, or that joining a leaderboard is required for feeding.

Skylark's repository documentation describes private exact antenna coordinates and optional public station markers in one-degree cells. That description is not a promise about another network, and coarse display is not a guarantee of anonymity. [1]

Before sharing a screenshot, inspect the whole image for keys, location, router addresses, names and account identifiers. Crop or redact deliberately. Publicly visible antennas and repeated location clues can still reveal more than a marker alone.

Receiving, transmitting and publishing are different questions

Do not assume that an unencrypted transmission is legally unrestricted everywhere. Rules can differ for equipment, reception, disclosure and onward use. This guide is about passive reception; it does not authorise transmission, interference, airborne installation or receiving unrelated communications.

In Ireland, ComReg describes a licensing and exemption framework for wireless equipment. Its general licensing page is not a specific legal ruling for every ADS-B receiver or every use of received data. Check current local requirements and ask the regulator about your actual equipment and intended activity when needed. [2]

Air traffic control voice is a separate subject. Do not infer permission to receive or publish it from an ADS-B setup guide. Never use a hobby display as a navigation, collision-avoidance or operational aviation instrument.

Data rights deserve their own notebook entry

Record which destinations you feed, which datasets you consume, and the applicable terms. Check API access, attribution, redistribution, retention and commercial-use permissions separately from a feeder account benefit.

When you stop sharing, disable the relevant client and follow the service's key and account controls. Where a key may have leaked, rotate it rather than merely deleting the screenshot. Keep recovery material somewhere private and accessible to you.