Privacy policy
This page describes what Syncline actually does with information, as the software is written today. It is not a catalogue of advertising or analytics products we do not ship.
Who we are
Syncline is made by Noise Productions Ltd, a company in New Zealand. Questions about this policy, or about information that has passed through the product, go to millst@np.co.nz.
What Syncline is
Syncline measures lip-sync for live broadcast. It is a professional tool for gallery and control-room use, not a social network, not a consumer camera app, and not directed at children.
- Syncline (desktop) runs on a gallery PC. It looks at the broadcast chain and reports how far sound sits from picture.
- Syncline Beacon (this website) is the handset page at beacon.html. A phone in front of a camera plays a signed audio chirp and flashes a coded pattern so the desktop can time both.
- Syncline Beacon (native app) does the same job as the page, without a browser in the middle. The Android package is
nz.co.np.syncline.beacon. An iOS build is intended later and will follow this policy.
What happens on the phone
The beacon is an instrument. Almost all of the work stays on the device you are holding.
- Display. The screen shows a high-contrast pattern and, at times, a short code. That picture is meant for the gallery camera, not for us. Neither the web page nor the Android app opens the phone’s camera.
- Speaker. The phone plays a short chirp (and, if you leave spoken guidance on, a few sentences of instruction). That audio is generated on the device.
- Microphone. A self-check can listen to this phone’s own speaker, to measure the delay the handset adds to every later reading. On the web page that uses the browser microphone permission. On Android the app declares the microphone permission for the same check. Refusing is an ordinary outcome: the run continues and keeps the phone’s own delay. Samples are processed on the device to produce a few numbers (round-trip time, how loud the check was, whether the microphone opened). Those numbers may be sent to the paired desktop so the operator can see why a check failed. The waveform is not uploaded.
- Wake lock. During a run the screen is kept awake, because a sleeping phone is not a beacon.
- Talkback. The operator at the desktop can speak to whoever is holding the phone, and can type them a short message. The voice travels one way only, from the desktop to this phone, and is played out of the speaker as it arrives. Nothing is recorded, nothing is kept, and the phone does not send any audio back — the person holding it is already in front of a camera and a microphone, which is how they answer.
The native Android app also declares network state and internet access, which is how it pairs, and a wake lock. It does not declare a camera permission. There is no sign-in, no account, and no store of people on the phone.
What is sent to the Syncline server
Pairing uses a short four-character session code over HTTPS. The handset and the desktop then talk through our server at sync.np.nz, usually on a WebSocket, or on an ordinary HTTPS event stream if a WebSocket cannot be opened (typical on a studio LAN with a self-signed certificate).
The server is a relay. It issues or accepts the code, matches one desktop to one handset, and forwards small JSON messages between them — start and stop, chirp timing, “I drew this code”, “I read that code”, a status snapshot, the measured offset at the end. A status snapshot can include the truncated browser or device description, screen size, and the self-check figures above. Messages are capped at a few kilobytes. No chirp audio, no camera picture, and no microphone recording is sent to the server.
Talkback goes the same way, because it is the same connection. A typed message is a few words of text; a spoken one is short packets of compressed voice travelling from the desktop to the phone. The server passes both between the two ends without keeping them, exactly as it passes everything else. The phone never sends voice.
You can also run the beacon on its own, without a session. Then nothing is sent to the server at all; the phone chirps and flashes locally.
What we do not collect
- No accounts, email addresses, or sign-in.
- No advertising, no analytics SDK, no crash reporter, no third-party tracker.
- No cookies, local storage, or similar store on the beacon page.
- We do not sell information. We do not share it with advertisers. There are no ads in Syncline.
The hosting platform (Azure App Service) may keep ordinary web-server logs — time, address, path — for operating the site. We have not added a product on top of that to identify people or measure marketing.
How long anything lasts
Sessions live in the memory of the server process. They exist while a measurement is being paired, and they die when the desktop leaves or when the process restarts (a deployment restarts it). There is no long-term user database and nothing to export later. A handset that drops off can rejoin the same code while that session is still alive; once the session is gone, the code is gone with it.
The desktop may keep measurements, recordings, or settings on the gallery PC, under the operator’s control. That is the operator’s machine, not ours.
Children
Syncline is a professional broadcast tool. It is not directed at children, and we do not knowingly collect information from children.
Questions and deletion
There is no account to delete. A session ends when the measurement ends or the server restarts. If you want confirmation that a session is gone, or you have a question this page does not answer, write to millst@np.co.nz. We will help as far as the software actually stored anything — which, for the server, is only the short-lived pairing described above.
Changes
If the product starts collecting something this page does not describe, we will update this policy and the date at the top before that change ships.