Privacy Policy
Nexa Beep (the “Software”) is a local-network messenger for Windows, macOS, and Linux distributed by SosomLab (the “Company”). This Privacy Policy explains what data the Software handles, where it is stored, what leaves your device over the network, what the relay server operated by the Company can and cannot see, and what the Company receives when you apply for a commercial license.
Notice of revision (posted 2026-10-12 · effective 2026-10-19) This Policy has been revised to reflect changes in Software versions v0.3.0–v0.5.0. Main changes: (1) when multi-device identity is enabled, copies of messages you send, recent conversation history, and read state are delivered to your own other devices over encrypted sessions (Sections 2 and 3-4); (2) the conversation-history mapping files and the license file are stored in plain text (Section 2); (3) the information the Company receives when you apply for a commercial license and how it is handled (new Section 7); (4) your rights (Section 9). The scope of information handled by the relay server has not changed. The revision history is at the end of this page.
1. Summary
- By default the Software communicates directly between devices on the same local network (LAN). No Company server is involved in this mode, and the Company does not automatically receive any data from the Software.
- The Software contains no analytics, telemetry, advertising, or tracking. There is no account sign-up, and the Software never connects anywhere to check a license.
- Every message and file is end-to-end encrypted (Noise_XX) between devices. Whatever path the data takes, only the participating endpoints can read it (including the multiple devices a peer has grouped together and your own other devices — Section 3-4).
- The Software contacts the Company-operated server
beepd.sosomlab.comonly if you explicitly enable the relay feature (Section 4). That server cannot read your conversations and stores nothing to disk. - Message contents, received files, and contact details kept on your device are stored encrypted and can be deleted by you at any time. Some files — settings, the identity key, the conversation-history mapping files (peer public keys), and the license file — are plain text (Section 2).
- If you enable multi-device identity (optional, off by default), parts of your conversation history are delivered, encrypted, to your own other devices (Section 3-4). Nothing is stored on a Company server.
- The Company receives personal information from you only when you apply for a commercial license by emailing a request code, or when you contact us (Section 7).
2. Data Stored on Your Device
The Software creates files in a single data folder only. It uses the data/ folder next to the executable if that is writable (portable build, Windows installer); if the install location is replaced wholesale on upgrade (macOS app bundle, Homebrew, Linux packages) or is not writable, it uses your operating system’s user configuration folder. If neither is writable it falls back to .nexa-beep in your home folder. You can check the actual location with nexa-beep --whoami.
| Item | Contents | Storage |
|---|---|---|
| Settings | Options you choose: theme, language, sorting, filters, window size, notifications, transfer limits, server address | Plain text (settings.cfg — contains nothing sensitive) |
| Identity key | The device’s X25519 key pair. The fingerprint of its public key is the only identifier the Software uses for you | Plain text (identity.key — it is the root that encrypts the other files and cannot wrap itself; Unix mode 0600) |
| User key · pairing passphrase (only if multi-device identity is enabled) | The Ed25519 user key that groups your own PCs as one user, and the pairing passphrase known only to your own devices | Encrypted (user.key · Unix mode 0600) |
| Trust pins | Public keys of peers you have met and their trust state (pinned, fingerprint-verified, blocked) | Encrypted (trust.seg) |
| Conversation history | Messages and completed-transfer records for 1:1 and group chats (including lines received from your other devices if multi-device identity is enabled) | Encrypted (history/*.seg segment files · Unix mode 0600) |
| Conversation-history mapping (v0.5.0+) | The full public key (32 bytes) of each peer device that a history file belongs to (file names contain only the leading part of the fingerprint) — one per peer with history | Plain text (history/{fingerprint prefix}.id · Unix mode 0600). A public key is not secret, but anyone who can read these files can tell which peers this device has conversation history with. No message content is included |
| Quarantined received files | Received files awaiting your approval (.beepq sealed envelopes) | Encrypted |
| Profile contact details | Email address and phone number you enter in your profile | Encrypted (profile.sec) |
| Profile image cache | Your avatar and avatars sent to you by peers | Encrypted |
| Offline queue | Outgoing messages held while the recipient is offline | Encrypted |
| Status log (optional, off by default) | Status-bar text written to a daily file | Plain text (only if enabled; contains status text only) |
| License file (only if a commercial license is installed) | The file signed and issued by the Company: license ID, licensee name, tier, issue date and term, device code (hash) | Plain text (license/nexa-beep.license · Unix mode 0600 · tampering is detected by its signature). An administrator may instead place it in a machine-wide location (e.g. %ProgramData%\nexa\nexa-beep on Windows) |
Encryption uses ChaCha20-Poly1305 sealed envelopes (NBSE) with keys derived from the device identity key. Consequently, if identity.key is compromised, the encrypted files on the same device can be opened as well — safeguarding and backing up the key file is your responsibility, and the Software says so in its settings screen.
These files themselves are never copied off your device and are never uploaded to the relay server. However, if you enable multi-device identity, parts of your conversation history (copies of messages you send, recent history for a device that was offline, and read state) are delivered to your own other devices over encrypted sessions, and the receiving device re-encrypts them with its own key before storing them (Section 3-4). File contents, key files, and trust pins are not delivered this way.
Deleting the data folder removes all of that device’s data permanently. Deleting a single conversation discards that conversation’s data key (crypto-shredding), so its remaining bytes can no longer be decrypted. Deletion applies only to that device and is not propagated to other devices. If the same conversation remains on another of your devices grouped by multi-device identity, you must delete it there as well; history that remains may be delivered back through catch-up. Old data may also survive in SSD wear-levelling areas or in backups you have made; the Software does not guarantee physical erasure.
To start at login, the Software adds a user-level autostart entry (Windows HKCU\…\Run, macOS LaunchAgent, Linux XDG autostart). This is on by default and can be turned off in settings. The Software writes nothing else to the registry or system areas.
3. Data Sent on the Local Network (LAN)
3-1. Discovery packets
To find other users on the same network, the Software periodically sends discovery packets by UDP multicast/broadcast (default port 47100). These packets are not encrypted and contain only:
- the device public key (fingerprint);
- a display name — by default your hostname with anything that looks like a real name removed, or
beep-{fingerprint}if that cannot be determined; you can change it at any time; - the session listening port;
- a flag and revision number indicating whether a profile is available (the profile contents are not included);
- if multi-device identity is enabled, a 16-byte hash tag derived from your handle and pairing passphrase (a hint for finding your own devices — the handle and passphrase themselves are never sent, and the tag cannot be reversed).
Email addresses, phone numbers, real names, bios, and messages are never placed in discovery packets. Because anyone on the same network can observe these packets, the fact that you are running the Software and your display name are not hidden within the LAN. Since a fixed public key is broadcast periodically, an observer on the same LAN could also re-identify the device over time.
3-2. Sessions
When you connect to a peer, the Software performs a Noise_XX handshake over TCP (default port 47200); every message, file, profile, and delivery/read receipt then travels only through that encrypted session. A network observer can see packet sizes and timing but not contents.
If a peer has grouped several devices with multi-device identity (v0.4.0+), the messages you send are delivered to all of that peer’s online devices, each over its own encrypted session, and may also reach the peer’s other devices through the peer’s own synchronization (Section 3-4). You cannot control which devices a peer has grouped together.
3-3. Profile disclosure (opt-in)
Your profile name, email, phone number, bio, and photo are each disclosed only if you switch them on individually (all off by default). Only the items you make public are sent, through the encrypted session, to peers you are connected to; for peers on the same LAN a quiet profile-exchange session is established automatically right after discovery. Turning an item off removes it from peers’ caches at the next announcement, but cannot erase what someone has already seen.
A profile received from a peer is merely “what that key claims”; the Software does not vouch for its accuracy.
3-4. Multi-device identity (optional · v0.2.15+)
When you enable multi-device identity in Settings › User, your own devices that share the handle (a short public name) and pairing passphrase you chose recognise each other as “my device” without approval or fingerprint comparison. The feature is off by default. When enabled:
- The pairing passphrase is never sent to the server or to any peer. A PSK derived from it is used for a separate handshake (Noise XXpsk3) with your sibling devices, and membership is proven inside that session.
- Your devices exchange the user key and a signed device list (which devices belong to the same user) inside the encrypted session only. When two devices meet for the first time, their user IDs merge towards the older one.
- The handle is shown to connected peers on the user line of your profile card. It is only a label, not an identity; if a different user key uses the same handle, peers see a conflict marker.
- If you lose a device and replace the user key, a succession certificate is sent to peers so that the old ID carries over to the new one. It contains no profile or message data.
- Conversation sync (v0.4.0–v0.5.0) — devices of the same user exchange the following inside the encrypted session between sibling devices (Noise XXpsk3):
- Sender copies: a copy of a message you send to a peer from one device (with that peer’s public key and a display-name hint) is handed to your other devices so it also appears in their conversation.
- Catch-up: when one of your devices comes back online, it receives the conversation it missed from a sibling device. Text lines only (file contents are excluded), up to the most recent 200 lines per conversation (thread) and 1 MiB per session. Each line carries its text, time, originating device, and sender display name.
- Read state: a “read up to here” marker for a conversation read on one device is sent to your other devices so their unread badges clear too.
- This data travels only between your own devices; sync data arriving over anything other than a sibling session is discarded. If your devices are on different networks it may pass through the relay server, which only forwards end-to-end ciphertext and stores nothing (Section 4-2). The receiving device stores what it receives re-encrypted with its own key; history files themselves are never transferred.
- Turning multi-device identity off, or revoking a device in the My Devices list, stops synchronization with that device, but content already delivered remains on each device (delete it on each device as described in Section 2).
4. Relay Server (Optional Feature)
Communicating with someone who is not on your LAN requires a relay server. This feature is enabled only when you set Settings › Server to Managed and press [Test] successfully. Until then the Software makes no Internet connections at all.
4-1. The official default server
The default server address in the app is beepd.sosomlab.com:47300 (TCP+UDP), operated by the Company. The server program, nexa-beepd, is open source in the same repository as the Software, and you may point the app at a server you host yourself or at any other server. The official server runs on a virtual machine provided by a cloud provider (Oracle Cloud Infrastructure).
4-2. What the server receives
When connected, the Software establishes a Noise-encrypted channel with the server and sends the following:
| Information | Contents | How the server treats it |
|---|---|---|
| Rotating rendezvous IDs | A 16-byte hash of your device public key and the UTC date (yesterday, today, tomorrow). The public key itself is never sent, and the hash cannot be reversed | Held in memory only while you are connected; gone when the connection closes |
| Pairing rendezvous IDs (only if multi-device identity is enabled) | Three 16-byte values (yesterday, today, tomorrow) derived from your handle and pairing passphrase, used only as a meeting point for your own devices on other networks. The handle and passphrase themselves are never sent | Held in memory only while connected |
| Public IP address and port | As observed by the server on your connection; forwarded to the peer so that a direct connection (hole punching) can be attempted | Held in memory only while connected |
| Channel open/close events and byte counts | Which two rendezvous IDs were connected, when, and how much they exchanged | Handled in memory during relaying only |
| Ciphertext fragments | Only when hole punching fails and the server must carry the data itself. This is end-to-end ciphertext between the two devices; the server cannot open it | Forwarded immediately; never stored |
The server stores nothing to disk. It is a pipe, not a buffer: data flows only while both parties are connected, and even when operational logging is turned on, only connection numbers, the first 4 bytes of rendezvous IDs, channel numbers, and byte counts are recorded. Message bodies, files, file names, profiles, and peers’ names or affiliations never reach the server.
Using the relay does mean, however, that the server learns the metadata “which rendezvous ID connected with which, and when”, along with your public IP address. It cannot see the contents, but this fact cannot be concealed, and the Software documents it openly.
4-3. Server user list and public card (opt-in)
While the relay is enabled, the setting “Show me to server users” (on by default once the relay is enabled; can be turned off) makes you and other users who have the same setting appear in each other’s lists simply by being connected to the server. For this the server receives, and relays only to other users who have the setting on:
- your device public key (fingerprint);
- a public card containing only the profile items you have made public (name, email, bio; at most 1 KiB). If nothing is public the card is empty.
The server does not interpret the card — it only checks its size — keeps it in memory only, and discards it when you disconnect. Turning the setting off stops your information from being relayed and also stops you from receiving other users’ lists (a mutual rule). Please be aware that via the public card, your name, email, and bio become visible to other users connected to the same server. You can change which items are public in your profile settings at any time.
4-4. Server identity verification
On first connection the Software pins the server’s public key; if that key ever changes, the Software refuses to connect and warns you. The official server’s pin is published in the project wiki so that you can compare it.
5. Handling of Received Files
Files sent to you are kept encrypted in quarantine until you approve them. The Software never executes a received file, never opens links automatically, and never extracts archives automatically. On Windows, quarantined files are scanned through the antivirus interface (AMSI) of whatever security product is installed on your PC; this scan takes place entirely on your machine. Only files you approve are materialized into your download folder, and they carry the operating system’s quarantine marker (Mark-of-the-Web / quarantine attribute).
6. Third-Party Services
The Software uses no third-party analytics, advertising, or crash-reporting services. It uses the operating system’s notification, tray, and autostart facilities, which are governed by each OS’s own policies. If you use a relay server hosted by someone else, that operator can see the information described in Section 4-2; the Company is not a party to that relationship. If you email a license request or an inquiry, that email passes through the email services used by you and by the Company, and those providers’ policies apply.
7. Information Processed When You Apply for a Commercial License (v0.3.0+)
Non-commercial use requires no license file; this section applies only to users who apply for a commercial license. The Software never connects anywhere to check a license and never sends a request code to the Company automatically. When you yourself email the request code created under Help › License… (or with nexa-beep --license request) to [email protected], the Company receives the following:
| Item | Contents |
|---|---|
| Information in the request code | Device code (a 20-byte SHA-256 hash of the operating system’s machine identifier — the identifier itself is not included) · operating system type · app version · request date · the name and email address you entered (only if you entered them) |
| The email itself | The sender’s email address and whatever you write in the message |
- Purpose: issuing the license file (your licensee name and device code are signed into the file), keeping issuance records, reissuing and handling device changes, and answering license inquiries. It is not used for any other purpose, such as marketing.
- Retention: the Company keeps the issued license file and an issuance record (license ID, licensee name, email, part of the device code, product, issuance terms such as tier and term, notes) on systems it manages. They are kept for as long as needed to issue and manage the license, and are deleted without delay if you ask. Where applicable law requires records such as transaction records to be kept, they are kept for the period required.
- Disclosure to third parties: the Company does not sell or provide this information to third parties (except where required by law).
- If you do not send a request code, the Company receives none of this. You may also leave the name and email blank when creating the request code (the Company may then confirm the details needed for issuance by email).
8. Children
The Software is a general-purpose messenger and is not directed at children. The Company does not knowingly collect personal information from children.
9. Your Rights
- Data on your devices: the data described in Sections 2–3 stays on your device under your control and can be removed as described in Section 2. The Company does not hold this data, so there is nothing on the Company’s side to access, correct, or delete. Content delivered to your other devices through multi-device identity is deleted on each device.
- Official relay server: information held in memory while you are connected (Section 4) disappears as soon as you disconnect or turn the relay off.
- License application information (Section 7): you may request access to, correction or deletion of, or suspension of processing of the information the Company holds about you. Contact us at the address below; we will act on your request without delay after verifying your identity. Once the issuance record is deleted, license support such as reissuing or device changes may no longer be possible (an already installed license file keeps working).
10. Contact
- Email: [email protected]
11. Changes to This Policy
If this Privacy Policy changes, the revised text and its effective date will be posted on this page. Material changes — in particular any broadening of what the relay server handles or any additional personal information processed by the Company — will be announced at least 7 days before they take effect.
Revision History
| Posted | Effective | Changes |
|---|---|---|
| 2026-10-12 | 2026-10-19 | Reflects Software v0.3.0–v0.5.0 — disclosure of conversation sync under multi-device identity (sender copies, catch-up, read state) · delivery to a peer’s multiple devices · conversation-history mapping files and license file (plain text) added to the storage table · data folder location corrected · new Section 7 on information processed for commercial license applications · expanded user rights. No change to how the relay server handles information |
개인정보처리방침
Nexa Beep(이하 “소프트웨어”)는 SosomLab(이하 “회사”)가 배포하는 Windows·macOS·Linux용 로컬 네트워크 메신저입니다. 이 개인정보처리방침은 소프트웨어가 어떤 데이터를 다루고, 어디에 저장하며, 네트워크로 무엇이 나가고, 회사가 운영하는 릴레이 서버가 무엇을 보는지, 그리고 상업 라이선스를 신청할 때 회사가 무엇을 받는지를 설명합니다.
개정 안내 (2026-10-12 게시 · 2026-10-19 시행) 이 방침은 소프트웨어 v0.3.0~v0.5.0의 변경에 맞춰 개정되었습니다. 주요 변경: ① 다중 기기 신원을 켠 경우 내가 보낸 메시지의 사본·최근 대화 기록·읽음 상태가 이용자 본인의 다른 기기로 암호화 세션을 통해 전달된다는 점(제2항·제3-4항) ② 대화 기록 매핑 파일과 라이선스 파일이 평문으로 저장된다는 점(제2항) ③ 상업 라이선스 신청 시 회사가 받는 정보와 그 처리(제7항 신설) ④ 이용자의 권리(제9항). 릴레이 서버가 다루는 정보의 범위는 바뀌지 않았습니다. 개정 이력은 맨 아래에 있습니다.
1. 요약
- 소프트웨어의 기본 동작은 같은 로컬 네트워크(LAN) 안의 기기끼리 직접 통신하는 것입니다. 이 동작에는 회사의 서버가 관여하지 않으며, 회사는 소프트웨어로부터 어떤 데이터도 자동으로 수신하지 않습니다.
- 소프트웨어에는 분석·텔레메트리·광고·추적 기능이 일절 없습니다. 계정 가입도 없으며, 라이선스 확인을 위해 어디에도 접속하지 않습니다.
- 모든 대화와 파일은 기기 사이에서 종단 간 암호화(Noise_XX) 되어 전달됩니다. 어떤 경로를 거치든 내용을 읽을 수 있는 것은 대화에 참여한 단말(상대가 묶어 둔 여러 기기와 이용자 본인의 다른 기기 포함 — 제3-4항)뿐입니다.
- 이용자가 릴레이 서버 기능을 직접 켠 경우에만(제4항) 회사가 운영하는 서버
beepd.sosomlab.com과 통신합니다. 이 서버는 대화 내용을 읽을 수 없고, 어떤 데이터도 디스크에 저장하지 않습니다. - 기기에 저장되는 대화 내용·수신 파일·연락처 정보는 암호화되어 저장되며, 이용자가 직접 삭제할 수 있습니다. 다만 설정·신원 키·대화 기록 매핑 파일(상대 공개키)·라이선스 파일 등 일부 파일은 평문입니다(제2항).
- 다중 기기 신원(선택 · 기본 꺼짐)을 켜면 대화 기록의 일부가 이용자 본인의 다른 기기로 암호화 전달됩니다(제3-4항). 회사 서버에는 저장되지 않습니다.
- 회사가 이용자의 개인정보를 받는 경우는 이용자가 상업 라이선스를 신청하며 요청 코드를 이메일로 보낼 때와 이용자가 회사에 문의할 때뿐입니다(제7항).
2. 기기에 저장되는 데이터
소프트웨어는 데이터 폴더 한 곳에만 파일을 만듭니다. 실행 파일 옆 data/ 폴더에 쓸 수 있으면 그곳(포터블 · Windows 설치본)을, 업그레이드 때 통째로 교체되는 설치 위치(macOS 앱 번들 · Homebrew · Linux 패키지)이거나 쓸 수 없으면 운영체제의 사용자 설정 폴더를 씁니다. 어느 쪽도 쓸 수 없으면 홈 폴더의 .nexa-beep를 씁니다. 실제 위치는 nexa-beep --whoami로 확인할 수 있습니다.
| 항목 | 내용 | 저장 방식 |
|---|---|---|
| 설정 | 테마·언어·정렬·필터·창 크기·알림·전송·서버 주소 등 이용자가 고른 옵션 | 평문 (settings.cfg — 민감한 값 없음) |
| 신원 키 | 기기의 X25519 키 쌍. 이 키의 공개키 지문이 소프트웨어에서 이용자를 가리키는 유일한 식별자입니다 | 평문 (identity.key — 다른 파일을 암호화하는 원료이므로 자신을 감쌀 수 없음 · Unix 0600) |
| 사용자 키 · 페어링 암호 (다중 기기 신원을 켠 경우) | 내 PC들을 한 사용자로 묶는 Ed25519 사용자 키와, 형제 기기끼리만 아는 페어링 암호 | 암호화 (user.key · Unix 0600) |
| 신뢰 핀 | 이용자가 만난 상대의 공개키와 신뢰 상태(핀 고정·지문 대조됨·차단) | 암호화 (trust.seg) |
| 대화 기록 | 1:1·그룹 대화의 메시지와 전송 완료 기록(다중 기기 신원을 켠 경우 내 다른 기기에서 받아 온 줄 포함) | 암호화 (history/*.seg 세그먼트 파일 · Unix 0600) |
| 대화 기록 매핑 표 (v0.5.0~) | 기록 파일 이름(지문 앞자리)에 대응하는 상대 기기의 전체 공개키(32바이트) — 기록이 있는 상대마다 하나 | 평문 (history/{지문 앞자리}.id · Unix 0600). 공개키는 비밀 정보는 아니지만, 이 파일을 열람할 수 있는 사람은 이 기기가 어떤 상대와 대화 기록을 갖고 있는지 알 수 있습니다. 메시지 내용은 담기지 않습니다 |
| 격리된 수신 파일 | 승인 전 상태의 수신 파일(.beepq 봉인) | 암호화 |
| 프로필 연락처 | 이용자가 프로필에 입력한 이메일·전화번호 | 암호화 (profile.sec) |
| 프로필 이미지 캐시 | 내 아바타와 상대가 보내 준 아바타 | 암호화 |
| 오프라인 큐 | 상대가 꺼져 있을 때 보관해 둔 발신 메시지 | 암호화 |
| 상태 로그 (선택 · 기본 꺼짐) | 상태바에 표시된 문구를 날짜별 파일로 | 평문 (켠 경우에만 · 내용은 상태 문구뿐) |
| 라이선스 파일 (상업 라이선스를 설치한 경우만) | 회사가 서명해 발급한 파일: 라이선스 ID·라이선시 이름·등급·발급일과 기한·기기 코드(해시) | 평문 (license/nexa-beep.license · Unix 0600 · 서명으로 위·변조를 검증). 관리자가 기기 공용 위치(Windows %ProgramData%\nexa\nexa-beep 등)에 둘 수도 있습니다 |
암호화는 ChaCha20-Poly1305 봉투(NBSE)로 이뤄지며, 키는 이용자 기기의 신원 키에서 파생됩니다. 따라서 identity.key가 유출되면 같은 기기의 암호화 파일도 열릴 수 있습니다 — 키 파일의 보관과 백업은 이용자의 책임이며, 소프트웨어는 이를 설정 화면에 고지합니다.
이 파일들 자체는 기기 밖으로 복사되지 않으며, 릴레이 서버를 켜더라도 서버에 올라가지 않습니다. 다만 다중 기기 신원을 켠 경우에는 대화 기록의 일부 내용(내가 보낸 메시지의 사본, 꺼져 있던 기기를 위한 최근 대화 기록, 읽음 상태)이 이용자 본인의 다른 기기로 암호화 세션을 통해 전달되며, 받은 기기는 그 내용을 자기 키로 다시 암호화해 저장합니다(제3-4항). 파일 본문·키 파일·신뢰 핀은 이 방식으로 전달되지 않습니다.
데이터 폴더를 삭제하면 그 기기의 데이터는 전부 영구히 제거됩니다. 대화 하나를 삭제하면 그 대화의 데이터 키를 폐기하므로(크립토 셰레딩) 남은 바이트는 복호화할 수 없게 됩니다. 삭제는 그 기기에만 적용되며 다른 기기로 전파되지 않습니다. 다중 기기 신원으로 묶인 다른 내 기기에 같은 대화가 남아 있으면 그 기기에서 따로 삭제해야 하고, 남아 있는 기록은 따라잡기를 통해 다시 전달될 수 있습니다. 또한 SSD 웨어 레벨링이나 이용자가 만든 백업 사본에 옛 데이터가 남을 수 있으며, 소프트웨어는 물리적 삭제를 보장하지 않습니다.
소프트웨어는 시스템 시작 시 자동 실행을 위해 운영체제의 사용자 수준 등록(Windows HKCU\…\Run · macOS LaunchAgent · Linux XDG autostart)을 추가합니다. 이는 기본 켜짐이며 설정에서 끌 수 있습니다. 그 외에 레지스트리나 시스템 영역에 기록하지 않습니다.
3. 로컬 네트워크(LAN)로 나가는 데이터
3-1. 발견 패킷
소프트웨어는 같은 네트워크의 다른 이용자를 찾기 위해 UDP 멀티캐스트·브로드캐스트(기본 포트 47100)로 발견 패킷을 주기적으로 보냅니다. 이 패킷은 암호화되지 않으며 다음만 담습니다.
- 기기 공개키(지문)
- 표시 이름 — 기본값은 실명으로 추정되는 부분을 제거한 호스트명이며, 판별할 수 없으면
beep-{지문}형식입니다. 이용자가 직접 바꿀 수 있습니다. - 세션 수신 포트
- 프로필 공개 여부 플래그와 버전 번호 (프로필 내용은 들어가지 않습니다)
- 다중 기기 신원을 켠 경우, 핸들·페어링 암호에서 파생한 16바이트 해시 태그 (같은 사용자의 기기를 찾기 위한 힌트 — 핸들·암호 원문은 실리지 않으며 역산할 수 없습니다)
이메일·전화번호·실명·소개글·메시지는 발견 패킷에 절대 실리지 않습니다. 같은 네트워크의 누구나 이 패킷을 볼 수 있으므로, 소프트웨어를 실행하고 있다는 사실과 표시 이름은 같은 LAN 안에서 숨겨지지 않습니다. 고정 공개키가 주기적으로 방송되므로 같은 LAN의 관찰자가 기기를 장기간 재식별할 수 있다는 한계도 있습니다.
3-2. 세션
상대와 연결되면 TCP(기본 포트 47200)로 Noise_XX 핸드셰이크를 하고, 이후 모든 메시지·파일·프로필·전달/읽음 확인은 이 암호화 세션으로만 오갑니다. 네트워크 관찰자는 패킷의 크기와 시각은 볼 수 있지만 내용은 볼 수 없습니다.
상대가 다중 기기 신원으로 여러 기기를 묶어 둔 경우(v0.4.0~), 이용자가 보낸 메시지는 상대의 접속 중인 기기 전부에 각각의 암호화 세션으로 전달되며, 상대의 다른 기기로도 상대 쪽 동기화(제3-4항)를 통해 전해질 수 있습니다. 상대가 어느 기기들을 묶어 두었는지는 이용자가 통제할 수 없습니다.
3-3. 프로필 노출 (옵트인)
프로필의 이름·이메일·전화번호·소개글·사진은 항목별로 공개 여부를 이용자가 직접 켭니다(기본 전부 비공개). 공개로 둔 항목만 암호화 세션을 통해 연결된 상대에게 전달되며, 같은 LAN의 상대에게는 발견 직후 자동으로 프로필 교환용 세션이 세워져 전달됩니다. 공개를 끄면 다음 공지 때 상대의 캐시에서 해당 항목이 지워지지만, 이미 본 사람의 기억까지 지울 수는 없습니다.
상대가 보내 준 프로필은 “그 키의 주장”일 뿐이며 소프트웨어는 그 진위를 보증하지 않습니다.
3-4. 다중 기기 신원 (선택 · v0.2.15~)
설정 › 사용자에서 다중 기기 신원을 켜면 이용자가 정한 핸들(짧은 공개 이름)과 페어링 암호가 같은 이용자 자신의 기기들이 승인·지문 대조 없이 서로를 “내 기기”로 인식합니다. 이 기능은 기본 꺼짐입니다. 켜면 다음이 달라집니다.
- 페어링 암호는 서버로도 상대 기기로도 보내지 않습니다. 암호에서 파생한 PSK로 형제 기기와 별도 핸드셰이크(Noise XXpsk3)를 맺고 그 세션 안에서 소속을 증명합니다.
- 같은 사용자의 기기끼리는 사용자 키와 서명된 기기 목록(어느 기기가 같은 사용자에 속하는지)을 암호화 세션 안에서 교환합니다. 처음 만난 두 기기의 사용자 ID는 먼저 만든 쪽으로 합쳐집니다.
- 핸들은 연결된 상대에게 프로필 카드의 사용자 줄로 보입니다. 핸들은 라벨일 뿐 신원이 아니며, 같은 핸들을 다른 사용자 키가 쓰면 상대 화면에 충돌 표식이 붙습니다.
- 기기를 잃어버렸을 때 사용자 키를 교체하면 후계 증명서가 상대에게 전달되어 옛 ID가 새 ID로 이어집니다. 이 증명서에도 프로필·메시지는 들어가지 않습니다.
- 대화 동기화 (v0.4.0~v0.5.0) — 같은 사용자의 기기끼리는 형제 기기 사이의 암호화 세션(Noise XXpsk3) 안에서 다음을 주고받습니다.
- 발신 사본: 이용자가 한 기기에서 상대에게 보낸 메시지의 사본(대화 상대의 공개키와 표시 이름 힌트 포함)을 다른 내 기기에 건네, 그 기기의 대화에도 보이게 합니다.
- 따라잡기: 꺼져 있던 내 기기가 다시 켜지면 형제 기기에게서 놓친 대화를 받아 옵니다. 텍스트 줄만 대상이며(파일 본문은 제외), 대화(스레드)당 최근 200줄, 세션당 1MiB까지입니다. 각 줄에는 본문·시각·발신 기기·발신자 표시 이름이 담깁니다.
- 읽음 상태: 한 기기에서 읽은 대화의 “어디까지 읽었는지” 표시를 다른 내 기기에 알려 안읽음 배지를 함께 걷습니다.
- 이 데이터는 이용자 본인의 기기 사이에서만 오가며, 형제 세션이 아닌 연결로 들어온 동기화 데이터는 버려집니다. 내 기기들이 서로 다른 네트워크에 있으면 릴레이 서버를 경유할 수 있으나, 서버는 종단 암호문만 중계하고 저장하지 않습니다(제4-2항). 받은 기기는 받은 내용을 자기 키로 암호화해 저장하며, 기록 파일 자체를 옮기지는 않습니다.
- 다중 기기 신원을 끄거나 기기를 내 기기 목록에서 폐기하면 그 기기와의 동기화는 멈추지만, 이미 전달된 내용은 각 기기에 남습니다(제2항의 방법으로 각각 삭제).
4. 릴레이 서버 (선택 기능)
같은 LAN이 아닌 상대와 통신하려면 릴레이 서버를 거쳐야 합니다. 이 기능은 이용자가 설정 › Server에서 모드를 Managed로 바꾸고 [Test]를 눌러 성공해야만 켜집니다. 켜지 않으면 소프트웨어는 인터넷으로 어떤 통신도 하지 않습니다.
4-1. 공식 기본 서버
앱의 서버 주소 기본값은 회사가 운영하는 beepd.sosomlab.com:47300(TCP+UDP)입니다. 서버 프로그램 nexa-beepd의 소스는 소프트웨어와 같은 저장소에 공개되어 있으며, 이용자는 자신이 직접 세운 서버나 다른 서버 주소로 바꿀 수 있습니다. 공식 서버는 클라우드 사업자(Oracle Cloud Infrastructure)의 가상 머신에서 운영됩니다.
4-2. 서버가 받는 정보
서버에 접속하면 소프트웨어는 서버와도 Noise 암호화 채널을 맺고 다음을 보냅니다.
| 정보 | 내용 | 서버의 취급 |
|---|---|---|
| 회전 랑데부 ID | 기기 공개키와 UTC 날짜를 해시한 16바이트 값(어제·오늘·내일 세 개). 공개키 원본은 보내지 않으며 해시를 역산할 수 없습니다 | 접속 중에만 메모리에 보관. 연결이 끊기면 사라짐 |
| 페어링 랑데부 ID (다중 기기 신원을 켠 경우) | 핸들·페어링 암호에서 파생한 16바이트 값 세 개(어제·오늘·내일). 같은 사용자의 기기가 다른 네트워크에 있을 때 만남 지점으로만 쓰이며, 핸들·암호 원문은 보내지 않습니다 | 접속 중에만 메모리에 보관 |
| 공인 IP 주소와 포트 | 서버가 연결에서 관측하는 값. 상대와 직접 연결(홀펀칭)을 시도하도록 상대에게 전달됩니다 | 접속 중에만 메모리에 보관 |
| 채널 개설·종료와 바이트 수 | 어느 두 랑데부 ID가 언제 연결되어 얼마나 주고받았는지 | 중계 중에만 메모리에서 다룸 |
| 암호문 조각 | 홀펀칭이 실패했을 때만 서버가 대신 나르는 데이터. 두 단말 사이의 종단 암호문이라 서버는 열 수 없습니다 | 즉시 상대에게 전달 · 저장하지 않음 |
서버는 아무것도 디스크에 저장하지 않습니다. 양쪽이 동시에 접속해 있을 때만 데이터가 흐르는 파이프이며, 운영 로그를 켜더라도 연결 번호·랑데부 ID 앞 4바이트·채널 번호·바이트 수만 남깁니다. 대화 본문·파일·파일명·프로필·상대의 이름이나 소속은 서버에 닿지 않습니다.
다만 릴레이를 쓰면 “어떤 랑데부 ID가 어떤 ID와 언제 연결했는가”라는 메타데이터와 공인 IP 주소는 서버가 알게 됩니다. 내용은 몰라도 이 사실은 감출 수 없으며, 소프트웨어는 이를 문서에 명시합니다.
4-3. 서버 사용자 목록과 공개 카드 (옵트인)
릴레이 서버를 켠 상태에서 “서버 사용자에게 나를 표시” 설정(릴레이를 켠 경우 기본 켜짐 · 끌 수 있음)을 두면, 같은 설정을 켠 다른 이용자와 서버 접속만으로 서로의 목록에 나타납니다. 이때 서버는 다음을 받아 같은 설정을 켠 접속자에게만 중계합니다.
- 기기 공개키(지문)
- 공개 카드 — 프로필에서 공개로 둔 항목만(이름·이메일·소개글 · 최대 1KiB). 공개 항목이 없으면 빈 카드입니다.
서버는 카드 내용을 해석하지 않고 크기만 확인하며, 메모리에만 두었다가 연결이 끊기면 지웁니다. 이 설정을 끄면 내 정보도 중계되지 않고 다른 사람의 목록도 받지 않습니다(상호 규칙). 공개 카드를 통해 이용자의 이름·이메일·소개글이 같은 서버에 접속한 다른 이용자에게 보인다는 점을 유의하시기 바랍니다. 공개 항목은 프로필 설정에서 언제든 바꿀 수 있습니다.
4-4. 서버 신원 확인
소프트웨어는 첫 접속 때 서버의 공개키를 고정(핀)하고, 이후 키가 바뀌면 접속을 중단하고 경고합니다. 공식 서버의 핀 값은 저장소 위키에 공개되어 있어 이용자가 대조할 수 있습니다.
5. 수신 파일의 취급
상대가 보낸 파일은 승인 전까지 암호화된 격리 상태로 보관되며, 소프트웨어는 어떤 경우에도 수신 파일을 실행하거나 링크를 자동으로 열거나 아카이브를 자동으로 풀지 않습니다. Windows에서는 이용자의 PC에 설치된 백신 프로그램의 검사 인터페이스(AMSI)로 격리 파일을 검사하며, 이 검사는 이용자 PC 안에서만 이뤄집니다. 이용자가 승인한 파일만 다운로드 폴더에 실체화되고, 운영체제의 격리 표식(MotW·quarantine)이 함께 남습니다.
6. 제3자 서비스
소프트웨어는 제3자 분석·광고·크래시 보고 서비스를 사용하지 않습니다. 운영체제의 알림·트레이·자동 실행 기능을 사용하며, 이들은 각 운영체제의 정책을 따릅니다. 이용자가 직접 세운 릴레이 서버를 쓰는 경우 그 서버의 운영자는 제4-2항에 적은 범위의 정보를 보게 되며, 회사는 그 관계의 당사자가 아닙니다. 라이선스 요청이나 문의를 이메일로 보내는 경우 그 메일은 이용자와 회사가 각자 이용하는 이메일 서비스를 거치며, 해당 서비스 제공자의 정책이 적용됩니다.
7. 상업 라이선스 신청 시 처리하는 정보 (v0.3.0~)
비상업적 사용에는 라이선스 파일이 필요 없으며, 이 항은 상업 라이선스를 신청하는 이용자에게만 해당합니다. 소프트웨어는 라이선스 확인을 위해 어디에도 접속하지 않고, 요청 코드를 회사로 자동 전송하지도 않습니다. 이용자가 도움말 › 라이선스…(또는 nexa-beep --license request)에서 만든 요청 코드를 직접 이메일로 [email protected]에 보낼 때 회사는 다음 정보를 받습니다.
| 항목 | 내용 |
|---|---|
| 요청 코드에 담기는 정보 | 기기 코드(운영체제의 기기 식별자를 SHA-256으로 해시한 20바이트 값 — 식별자 원문은 담기지 않음) · 운영체제 종류 · 앱 버전 · 요청 날짜 · 이용자가 입력한 이름과 이메일 주소(둘 다 입력한 경우에만) |
| 이메일 자체 | 보낸 사람의 이메일 주소와 이용자가 메일에 적은 내용 |
- 이용 목적: 라이선스 파일 발급(파일에 라이선시 이름과 기기 코드가 서명되어 들어감), 발급 이력 관리·재발급·기기 변경 처리, 라이선스 관련 문의 응대. 이 밖의 목적(마케팅 등)으로는 이용하지 않습니다.
- 보관: 회사는 발급한 라이선스 파일과 발급 기록(라이선스 ID · 라이선시 이름 · 이메일 · 기기 코드의 일부 · 제품 · 등급·기한 등 발급 조건 · 비고)을 회사가 관리하는 시스템에 보관합니다. 보관 기간은 라이선스 발급·관리에 필요한 기간 동안이며, 이용자가 삭제를 요청하면 지체 없이 삭제합니다. 다만 관계 법령이 거래 기록 등의 보존을 요구하는 경우에는 그 기간 동안 보관합니다.
- 제3자 제공: 회사는 이 정보를 제3자에게 판매하거나 제공하지 않습니다(법령에 따른 요구가 있는 경우 제외).
- 요청 코드를 보내지 않으면 회사는 이 정보를 받지 않으며, 이름·이메일을 비워 두고 요청 코드를 만들 수도 있습니다(이 경우 발급에 필요한 정보를 이메일로 따로 확인할 수 있습니다).
8. 아동에 관한 사항
소프트웨어는 범용 메신저로서 아동을 대상으로 하지 않습니다. 회사는 아동의 개인정보를 알면서 수집하지 않습니다.
9. 이용자의 권리
- 기기 안의 데이터: 이 방침의 제2항~제3항에서 설명한 데이터는 이용자 기기 안에서 이용자가 직접 통제하며, 제2항의 방법으로 삭제할 수 있습니다. 회사는 이 데이터를 보유하지 않으므로 회사 측에 열람·정정·삭제를 요구할 대상이 없습니다. 다중 기기 신원으로 내 다른 기기에 전달된 내용은 각 기기에서 삭제합니다.
- 공식 릴레이 서버: 접속 중 메모리에 두는 정보(제4항)는 연결을 끊거나 릴레이 설정을 끄는 즉시 사라집니다.
- 라이선스 신청 정보(제7항): 이용자는 회사가 보관하는 자신의 정보에 대해 열람·정정·삭제·처리정지를 요구할 수 있습니다. 아래 연락처로 요청하면 본인 확인 후 지체 없이 처리합니다. 발급 기록을 삭제하면 이후 재발급·기기 변경 등 라이선스 관리 지원이 어려울 수 있습니다(이미 설치된 라이선스 파일의 동작에는 영향이 없습니다).
10. 문의처
- 이메일: [email protected]
11. 방침의 변경
이 개인정보처리방침이 변경되는 경우 개정된 내용과 시행일을 이 페이지에 게시합니다. 중요한 변경 — 특히 릴레이 서버가 다루는 정보의 범위가 넓어지거나 회사가 처리하는 개인정보가 추가되는 경우 — 은 시행일로부터 최소 7일 전에 공지합니다.
개정 이력
| 게시일 | 시행일 | 내용 |
|---|---|---|
| 2026-10-12 | 2026-10-19 | 소프트웨어 v0.3.0~v0.5.0 반영 — 다중 기기 신원의 대화 동기화(발신 사본·따라잡기·읽음 상태) 고지 · 상대의 여러 기기로의 전달 · 대화 기록 매핑 파일·라이선스 파일(평문) 저장 표 추가 · 데이터 폴더 위치 보정 · 상업 라이선스 신청 시 처리하는 정보(제7항) 신설 · 이용자의 권리 보완. 릴레이 서버의 정보 취급은 변경 없음 |