Privacy Policy

RotorLab.app: Privacy Policy

Effective date: October 9, 2026

This Privacy Policy explains how RotorLab, Inc., a Delaware corporation with its headquarters in Dubuque, Iowa ("RotorLab", "we", "us") collects, uses, and shares information when you use our websites, applications, and services (the "Service"). It is written for what the Service has become: a design tool, and a system of record for drone operators. If you use the Service as a member of an organization, that organization is the controller of the records it keeps in the Service, its administrators control the account, and this Policy describes what we do as its processor as well as what we do with the information we hold as controller (your account and our own logs).

1. Two roles. For your account details, sign-in and security logs, billing, the messages sent through our contact and quote forms, and our own analytics, we are the controller; our security log is our own record, kept apart from an organization's activity log. For the Records an organization keeps in the Service (aircraft, flights and flight logs, maintenance, pilots and their credentials and training, occurrences, authorizations, insurance, safety records, attached documents, and the organization's activity log), the organization is the controller and we are its processor under the Data Processing Addendum, which is available on request and incorporated by reference for every organization account.

2. Information we collect. a. Account information: name, email, organization, role, authentication credentials (passwords stored only as salted hashes; an authenticator's secret sealed at rest where the Service runs with its encryption key, as Section 7 says), and the sessions you open (the device as read from your browser, the address it came from, and when). b. Billing information you enter for invoicing (contact, address, tax identifier, and any tax exemption certificate) and what our payment processor returns (a confirmation, the card brand and last digits; never a full card number). c. Records an organization files: what its members enter, what its ground stations send, and what is read from the flight logs it uploads (which can include the aircraft's position, altitude, speed, battery and sensor readings, the airframe's serial, and the pilot on the flight). Records can name people who are not members, such as a requesting agency's contact, a supervising officer, or an applicator and their certification number on a service record. d. Log and device data: IP address, browser type, timestamps and pages requested; usage and diagnostic data about how the Service is used; and cookies used for authentication, security and preferences. Our own page counts use no cookie, and the key that counts a visitor once a day is replaced every day; an organization can switch usage analytics off for its members. Google Analytics is loaded only where we set it up and only after you accept analytics cookies (Section 4A). The Service also keeps information in your browser's own storage on your device: drafts not yet saved or filed (a mission, or a flight, defect or checklist run recorded while offline, which can include positions) and uploads that failed, until they are saved, filed or discarded; the choices you made on a form last, to fill in the next one; and, for use without a connection, your organization's aircraft list, their status and its checklist cards, until you sign out. e. Position data. An organization chooses what a flight keeps of where it flew: its exact position (the default); only a rounded area, in which case an exact position from a log, the flight form, a ground station or the API is reduced to the area before it is stored, while stored flight log files are kept as before; or no position, in which case no position is written to the flight and a flight log file is read for its hours, faults and health and then not kept. The choice applies from when it is made; positions already on the record follow the position window below. Where the Service runs with its encryption key, a flight's precise position is sealed with authenticated encryption before it reaches the database, and its take-off and landing points, the position in its stored analysis, a corrected position in its history and its copy in the void ledger are sealed the same way; so are stored flight log files, live recordings, saved missions, area outlines and frozen area dossiers, as they are written. A flight log waiting in File Flights to be filed is kept unsealed for up to 24 hours, until it is filed or removed, and items stored before the Service held its key stay unsealed unless they are written again or a pass we run seals them. Where the Service runs without its key, all of these are stored unsealed and protected by the other measures in Section 7. Either way, positions on a flight are reduced to a rounded area once the position window the organization sets has passed, unless the flight is on legal hold. A stored flight log file keeps the full track the aircraft recorded until the stored-log window the organization sets deletes it. The exact point never appears on a public page.

3. How we use information. As controller: to operate, secure, and improve the Service; to sign you in and keep your account safe (including the sign-in throttle and session policy); to bill and to answer you; to send the notices the Service and the law require; and, with your consent, the newsletter. When you use the free log analyzer without an account, your first reading needs nothing from you; after that we ask for an email address, which we keep with that browser's access for up to a year so the analyzer stays open there. If you ask us to email you a reading, we send it to the address you give and note that address. Joining the newsletter is a separate choice. As processor: only to provide the Service to the organization, on its instructions, as the Addendum describes. Model annotations in the Service score an organization's own records for its own use; no record is used to train a model that serves another organization unless that organization opts in to training inclusion, which is off by default and can be withdrawn.

4. How we share information. We do not sell personal information and we do not share Records with anyone but the organization that keeps them, except: with the subprocessors listed in the Addendum (hosting, offsite backup, payment processing, email delivery, and, where the organization enables it, the flight-record decryption service of the aircraft's manufacturer), each bound to protect it; with a third party the organization itself directs us to (a webhook endpoint, a linked manufacturer, an auditor it hands a package to, a public transparency page it publishes); with the outside services in Section 4A, only what that section says each receives; when the law requires it, in which case we tell the organization unless the law forbids it; and in a merger or sale, where the successor takes on this Policy. A manufacturer an organization linked keeps, after the link ends, the organization's name, the day the link ended and the standing the link last reported, and nothing read after it.

4A. Outside services. These are every outside party the Service can call, and what each receives: a. Independent timestamps: RFC 3161 timestamping authorities and OpenTimestamps calendars receive one hash a day over the day's records, never a record. b. Map imagery and terrain: Esri, USGS The National Map, OpenStreetMap and the AWS elevation tiles are fetched by your browser when a map is drawn; each request says which square of the map is wanted. A copy of the Service can instead draw its maps from a tile server its operator runs. c. DJI log reading: reading a current, encrypted DJI flight record sends its key identifiers to DJI's keychain service (DJI is a company based in China), only for an organization whose administrator switches it on, and never for a signed-out visitor. d. Airspace, airport and advisory data: the FAA, the airspace publishers we read and uasvs.org are asked for their published files; the request carries nothing about an organization. e. Weather: MET Norway, aviationweather.gov and api.weather.gov receive the coordinates of a planned point or of a flight's place. f. Place and elevation lookups: OpenStreetMap Nominatim receives an address typed to place a map, and the USGS elevation service receives a point's coordinates. g. Google Analytics: only where we set it up, and only after you accept analytics cookies; it receives the page visited and the browser's usual request details. h. Address autocomplete: Google Maps Places receives an address as it is typed into a billing or sign-up form, where we have it switched on. i. Email: the mail relay the Service is set to use carries the messages it sends: invitations, password resets and notices. j. Card payments: Stripe receives what checkout needs, the plan and the organization's billing details; card numbers go to Stripe and never to us. k. Single sign-on: the identity provider an organization sets takes part in the sign-in exchange OpenID Connect defines. l. Webhooks, traffic sources and alert hooks: the addresses an organization or we enter receive the events and requests each one is set up for, and nothing else. An organization can switch off, for its own members, map imagery and terrain from outside services, weather, place and elevation lookups, and address autocomplete, and can switch off usage analytics. A copy of the Service run in offline mode calls none of these, except single sign-on, email and webhooks to hosts inside its own network that its operator lists.

5. What a public page shows. An organization that publishes a transparency page chooses what it shows; only rounded areas, counts and periods it approved appear, never an exact position, a name, or an unpublished record, and each published period is frozen and hashed.

6. Retention. Account information is kept while the account is active and, when an organization's plan ends, for the periods in Section 15 of the Terms: ninety days read-only with export, then twelve months retained with no access, then deletion with everything the organization kept, counted and recorded, after an alert thirty days and a final notice seven days before. Buying or restoring a plan before the deletion restores full access. Within the Service, an organization sets its own retention for stored flight logs and precise positions, including "keep for life", and a legal hold keeps a record past every window; a filed record is voided rather than destroyed, and a person on a record is deactivated rather than deleted, because the records of flying and of maintenance are records of record for as long as the organization keeps them. An organization can also set a window after which a person who has left is minimized (their name and handle stay on the records they are on; their email, sign-in, phone, medical date and the notes on their pilot profile are removed, and a medical certificate kept as a credential is blanked), and a window after which a photo or document removed from a record, kept hidden until then, is deleted; neither has a default. The organization's activity log is its own record, kept for as long as the organization keeps its records. Our own security logs are kept for twelve months, the page views we count for thirteen months, and the messages sent through our contact and quote forms for twenty-four months. An address given to the free log analyzer is kept with that browser's access for up to a year, and the count of messages sent to an address, which limits how often we write to it, for one day. When an organization is deleted, we keep its billing records (the amounts, tax, dates, and invoice and payment references of what it paid, and our decisions on its billing requests) as our own financial record for our accounting period, seven years unless our accountant sets another, with their notes, subscription references and the reasons given removed. Backups are kept in a second location and expire on the schedule stated on the trust page.

7. Security. Sessions are server-side and hashed; passwords are salted hashes; where the Service runs with its encryption key, authenticator secrets, precise positions, the credentials an organization stores, and the flight log files, live recordings, saved missions and area outlines Section 2(e) names are sealed at rest with authenticated encryption as they are written; traffic is encrypted in transit; the activity log is a hash chain; roles gate every read and write; and the trust page states the rest, including what we do not claim.

8. Your choices and rights. You may see and correct your account information in the Service, end your own sessions, turn two-factor on, and download your own data from My Account (what the Service holds about you, scoped to you and never to a colleague's records). An organization's administrators can export everything the organization holds about a person, and minimize a person who has left, as Section 6 describes. Depending on where you live, you may have rights to access, correct, delete, port, or restrict information about you, and to object to certain processing. For information you hold as a member of an organization, the organization is the controller and will answer the request, with our help; a request to delete a record of flying or maintenance is answered by deactivation and voiding as Section 6 describes, because the record itself must stay. Contact us through the support channel in the Service; we answer within thirty days.

9. International users. We process and store information in the United States. If you use the Service from elsewhere, you agree to that transfer, and the Addendum carries the standard contractual clauses where they apply. Where an organization switches DJI log reading on, the key identifiers of its encrypted DJI flight records go to DJI's keychain service, as Section 4A(c) says.

10. Children. The Service is not directed to children under 16 and we do not knowingly collect their personal information.

11. Changes. We may update this Policy. If a change is material we give notice in the Service or by email at least thirty days before it takes effect, and ask you to accept it in the Service.

12. Contact. For privacy questions or requests, contact us through the support channel shown in the Service, or write to security@rotorlab.app for a security concern. RotorLab, Inc. is the controller named in Section 1; its address for written requests is RotorLab, Inc., Dubuque, Iowa, and its email for legal notices is legal@rotorlab.app.

These documents have changed since you last accepted them. Read the ones that matter to you from the list, then confirm to continue to RotorLab.