Privacy Policy

Last updated: October 21, 2026

This Privacy Policy explains what information SpeakMic ("the Service", "we", "us") processes when you create or join a room, and why. SpeakMic is designed to be a minimal, privacy-respecting tool: it does not use advertising trackers and does not record or store audio on our servers. We use a small amount of cookieless, privacy-friendly analytics to understand site usage and performance, as described below.

TL;DR

• By default, audio streams directly between devices (peer-to-peer, WebRTC) and is never recorded or stored on our servers. If the operator has enabled the optional intermediary server (SFU) mode and a room uses it, audio is routed through a self-hosted intermediary server in Germany instead — it is not stored or recorded there either.
• In Broadcast rooms, your device may be temporarily used as an audio relay node to help distribute audio to other listeners, using a portion of your upload bandwidth. No extra data is sent to our servers for this.
• We use cookieless, privacy-friendly analytics (Vercel Web Analytics & Speed Insights) to see aggregate visit and performance stats – no ads, no cross-site trackers, and no cookies.
• We additionally offer optional Google Analytics (Firebase) usage tracking (app launches, room creation/join, whether a chat message or reaction was sent, tab/help/update-button taps) — off by default, only runs after you explicitly agree, and never includes message content, the emoji picked, or room names/tokens. See Section 6.
• Rooms and chat messages are automatically deleted after a period of inactivity (3 months by default, 1 day for a temporary room - see Section 8).
• We only process the minimum needed to run a room (e.g. its name, access tokens/PIN hashes, and your IP address transiently via Cloudflare) – full details below.

1. Who is responsible for your data (data controller)

The Service is operated by:
Mateusz Barniak
Poland
Contact: [email protected]

2. How SpeakMic works (technical overview)

In a Broadcast room, audio is sent from the broadcaster's device to listeners using WebRTC, a peer-to-peer (P2P) technology built into web browsers. To support larger audiences, the Service uses a relay tree: some listeners' devices are automatically selected to act as relay nodes, each forwarding audio to up to three other listeners. This distributes the load that would otherwise fall entirely on the broadcaster's connection. When your device is selected as a relay node, it forms direct WebRTC connections to the listeners it serves, which means those listeners' browsers can see your public IP address (and vice versa) — exactly the same as in any other direct WebRTC connection on the Service. In a Walkie-Talkie room, the same P2P approach is used, but the "speaker" role rotates: whoever presses the talk button streams audio directly to every other participant for the duration of their turn. If two participants of such a room choose to talk privately (a "private call", which the other person must accept, and only if the room host allows them), their devices connect directly to each other in the same way, so each of them can see the other's public IP address while the call lasts (except in a room using the intermediary server, where the call goes through Cloudflare's TURN relay and neither sees the other's address); the audio is not stored. A separate feature, "relay rooms", lets a broadcaster set up their own room to rebroadcast another room's audio to a separate audience; from a data-processing perspective, that broadcaster is simply an ordinary listener of the source room. A small "signalling" server is used only to help devices find each other (exchanging connection details) and to relay short text chat messages. The signalling server never receives, processes, or stores the audio stream itself, and never records it. If the operator has enabled the optional SFU (intermediary server) mode and a room uses it, audio is instead routed through a self-hosted intermediary server in real time; that server does not record or store the audio either. In a Broadcast room, the broadcaster may optionally record their own microphone audio locally in the browser (a recording feature) — the recording file stays only on their device and is never sent to us or to any other participant.

The Service also provides a direct Video Connection feature, which connects exactly two devices in a one-to-one P2P call. The call owner generates a unique link or QR code; one other person joins via that link. Both audio and live video (camera feed) are transmitted directly between the two devices using WebRTC and are never routed through, recorded by, or stored on our servers. As with all WebRTC connections on the Service, both devices' public IP addresses are visible to each other for the duration of the call.

3. Information we process

We process the information listed below because it is necessary to perform the service you requested (Article 6(1)(b) GDPR — performance of a contract / provision of a service). We process connection metadata for our legitimate interest in preventing abuse and ensuring network security (Article 6(1)(f) GDPR).

The signalling server temporarily processes the following information while a room exists:

• Room name – the name you choose when creating a room, shown to listeners.
• Custom link – if you give a permanent room a custom link (e.g. speakmic.com/b/your-name), the name you chose is stored in plain text with the room and in a registry that maps it to the room. It is public: anyone who knows or guesses it can open the room, and anyone can check whether a name is in use. Please don't put personal data in it. When the room is deleted or the link is changed or removed, the registry keeps only the name, the previous room's token and the release date for 90 days (so the name can't be taken over while old links and QR codes may still be in circulation - our legitimate interest under Article 6(1)(f) GDPR), then deletes them.
• Room access tokens / PIN hashes – random tokens used to identify the room's broadcaster or admin and authorise actions such as deleting the room. If you set a PIN (for example an admin PIN, or a PIN required to join the room), only a cryptographic hash of the PIN is stored, never the PIN itself.
• Text chat messages – messages sent through the in-room chat are relayed to connected participants and kept only in the server's temporary in-memory storage for the current session. They are cleared as soon as all participants leave the room, are not written to a database or log file, and are permanently deleted when the room expires or is deleted.
• Walkie-Talkie nicknames – in a Walkie-Talkie room, the nickname you choose when joining is shared with other participants (shown in the participant list and alongside your chat messages) and is processed the same way as chat messages above. It is not linked to any account and is discarded when you leave or the room is deleted. If a room admin removes ("kicks") a participant, that participant's nickname is additionally stored (in lowercase) as part of the room's settings for as long as the room exists, so the same nickname cannot rejoin that room. The random per-room device identifier described in Section 5 is stored alongside it, so the same device cannot rejoin under a different nickname either.
• Connection metadata – your device's IP address and WebSocket connection information are processed transiently by our edge network (Cloudflare) to deliver the connection and to apply basic rate-limiting/abuse protection. When you create a room, your IP address is additionally used to enforce a short-term limit on how many rooms can be created from the same address; this is stored briefly (up to about an hour) in Cloudflare's key-value store and then automatically deleted. Similarly, login attempts to the admin panel, creator panel, or a landing page's moderator panel are rate-limited based on your IP address (a maximum of 5 failed attempts per 15 minutes), using the same Cloudflare Durable Object-based mechanism, and the attempt counter is automatically deleted once that period elapses. This data is handled by Cloudflare as our infrastructure provider and is not stored by us beyond what is needed for that purpose. When bot protection is switched on, creating a room also runs Cloudflare Turnstile in your browser: it checks signals about your browser and device to tell people from automated scripts, usually without you seeing anything, and we receive only a pass/fail result (Cloudflare acts as our processor for this; joining a room is never checked).
• Room registry (for administrative purposes) – when a room is created, its token, type (Broadcast / Walkie-Talkie), and creation timestamp are recorded in a lightweight internal registry in our key-value store. This registry is used only for: (a) the aggregate statistics shown in the admin panel (the number of currently existing rooms of each type, and the creation time of the most recently created one), and (b) an optional bulk-delete-all-rooms action (e.g. to clean up a test environment or respond to abuse), with an option to exclude rooms featured on landing pages. The admin panel does not provide a list of individual rooms based on this registry. The entry is removed from the registry when a room is deleted (individually or via bulk deletion by the Service's administrators), and in any case it expires automatically after at most 3 months from the room's creation (the same period as the permanent-room inactivity limit described in Section 8).
• Creator accounts, moderator passwords, and landing-page content – if you hold a creator account (provisioned by the Service's administrator) or administer a landing page as a moderator, we store: the creator's username and a cryptographic hash of their password (PBKDF2-SHA256), and, if the page has a moderator password set, an equivalent hash of that password (never the password itself). We also store the landing page's content and branding that you create or edit (e.g. logo, hero image, description, featured rooms). Logging into the admin, creator, or moderator panel sets a strictly necessary, cryptographically signed httpOnly session cookie in your browser, valid for 12 hours – see Section 5. This data is stored in our key-value store until the creator account, page, or moderator password is deleted.
• Frontend hosting logs and analytics – the SpeakMic web app itself (this website) is hosted on Vercel. Like any web host, Vercel's edge network processes your IP address and basic request metadata (e.g. browser user-agent) to serve the pages and for security and operational purposes (e.g. abuse prevention). We also use Vercel Web Analytics and Speed Insights to see aggregate, anonymised statistics about site usage (e.g. which pages are visited, referrers, country/region, device and browser type) and performance (Core Web Vitals such as load times). These tools are cookieless, do not use any persistent identifier, and do not track you across other websites.
• Relay node network usage – in Broadcast rooms, your device may be automatically selected as an audio relay node (see Section 2). When acting as a relay node, your device forwards audio it has already received to up to three other listeners via direct WebRTC connections. No additional personal data is collected or sent to our servers for this purpose; it is purely a device-to-device transfer. However, your device's upload bandwidth and CPU are used while you are in the relay role, and your public IP address is exposed to the listeners you serve (as with any WebRTC connection). The relay role ends automatically when you leave the room.

Audio is not stored or processed on our servers by default. Microphone audio is captured by your browser and streamed directly, peer-to-peer (or via relay nodes described above), to listeners' browsers. In cases where a direct connection cannot be established (see Section 4), audio may transit Cloudflare's TURN relay infrastructure, but is never stored or inspected beyond what is needed to deliver it. If the operator has enabled the optional intermediary server (SFU) mode and the room uses it, audio transits a self-hosted intermediary server in real time — it is not recorded or stored there.

4. STUN / TURN servers

To establish a direct P2P connection, WebRTC uses "STUN" servers to help devices discover how to reach each other across the internet. SpeakMic uses public STUN servers operated by Google (stun.l.google.com) and Cloudflare (stun.cloudflare.com). Establishing a connection via these servers can reveal your public IP address to those providers, which is normal and required for any WebRTC application.

When a direct P2P connection cannot be established (for example, because your network uses a restrictive or symmetric NAT), SpeakMic automatically falls back to a TURN relay server operated by Cloudflare (turn.cloudflare.com). In that case, your audio is relayed through Cloudflare's infrastructure for the duration of the session. The audio is never stored by Cloudflare or by us; it is only used to forward packets in real time. Your IP address will be visible to Cloudflare as the relay operator. This fallback affects only connections that cannot traverse the network directly (typically 5–15% of connections depending on network conditions). Cloudflare's privacy policy applies to data handled by their infrastructure: cloudflare.com/privacypolicy.

5. Cookies and local storage

As an ordinary room participant (broadcaster, listener, or Walkie-Talkie participant), you use the Service without any cookies unless you opt in to the analytics described in Section 6 – no advertising or cross-site tracking technologies are used. We use Vercel Web Analytics and Speed Insights for aggregate site-usage and performance statistics; these are cookieless and do not use any tracking identifier or track you across other websites - see Section 3 for details.

The exception is the login panels for the Service's administrator, creators, and landing-page moderators (see Section 3): logging in with a password on one of these panels sets one strictly necessary, cryptographically signed session cookie in your browser (httpOnly, inaccessible to JavaScript), valid for 12 hours, used only to keep you logged in. It is never used for tracking or advertising purposes, and is never set for ordinary room participants.

The app stores a small amount of data in your browser's local storage (not a cookie) for purely functional purposes:

• Broadcaster access token – if you create a room, a private token is saved on your device so you remain recognised as the broadcaster (e.g. after reloading the page). This is strictly necessary for the Service to function and is never sent anywhere except to our signalling server to authenticate your requests for that room.
• Walkie-Talkie admin token – if you create a Walkie-Talkie room, a separate admin token is stored locally so you remain recognised as the room admin (e.g. to kick participants or delete the room). It works the same way as the broadcaster access token above.
• "Install app" prompt dismissal – if you dismiss the prompt to install SpeakMic as an app, we remember that choice locally so it isn't shown again. This is a UI preference only.
• Recent rooms – a list of rooms you have created or joined on this device (room link/token, its custom link if it has one, name, and when you last joined) is kept in local storage so the "Recent rooms" list on the home screen can show them to you. This list is never sent to our servers and stays only on your device until you remove an entry or clear your browser's site data.
• Usage counters – how many rooms you have created on this device and how many times you have been in a Walkie-Talkie or broadcast room (plain numbers, no room details) are kept in local storage, so the app can pick which of our in-app announcements and banners to show you (e.g. a tip for people who haven't created a room yet). They are never sent to our servers and stay only on your device until you clear your browser's site data.
• Walkie-Talkie device identifier – when you join a Walkie-Talkie room, a random identifier (not linked to your name or any account) is generated and stored on your device for that room. It is sent to the signalling server only so that, if a room admin removes you, the same device can be recognised and prevented from rejoining that room under a different nickname. It is discarded when the room is deleted or when you clear your browser's site data.
• PIN recovery lock state – if you enter an incorrect broadcaster or admin PIN multiple times, a counter is stored locally to enforce a brief cooldown before further attempts. This data never leaves your device and is cleared automatically once the cooldown expires.
• Video connection token – when you use the Video Connection feature as the call owner, a unique connection token (your video link) is saved on your device so your link or QR code remains accessible after reloading the page. This token is sent to the signalling server only to identify your video room; it is not stored on our servers and is never shared with other call participants.
• Video owner secret – a random secret, unique to your device, is generated and stored locally the first time you use Video Connection as an owner. It is sent to the signalling server only when creating or regenerating your video link, to prove that you are the owner of that link. It is never visible to the other call participant and never used for any other purpose.
• Video ownership credential – when your video link is created or regenerated, the signalling server returns a short cryptographically signed token (derived from your owner secret and connection token) which is stored locally alongside them. It is sent to the signalling server each time you reconnect as the call owner, allowing the server to verify your ownership without any server-side lookup. It is never shared with the other call participant.
• Recent video connections – if you join a video call as a participant (not as the connection owner), the connection token and the date and time of your visit are stored in local storage to display a "Recent connections" list on your video connection screen. This data never leaves your device and stays there until you remove the entry or clear your browser's site data.

Because the local-storage data described above is strictly necessary for the Service to operate (or is a simple, non-tracking UI preference stored only on your own device), and the only cookie we use is a strictly necessary login session cookie (not used for tracking or advertising), none of this requires a cookie consent banner under the ePrivacy Directive / GDPR. The one exception is the optional Google Analytics (Firebase) usage tracking described in Section 6 below, which is off by default and only runs once you explicitly opt in - on the website it then stores Google Analytics cookies (such as _ga) in your browser, which is why we ask first. You can clear the local data at any time by clearing your browser's site data for this site; the session cookie expires automatically after 12 hours or when you log out.

6. Analytics consent (Google Analytics / Firebase)

We use Google's Firebase Analytics SDK (the same product as Google Analytics 4) to see aggregate feature usage — not tied to your name or account (see below for exactly how). It is optional and deliberately separate from accepting the Terms of Service: nothing is collected — the SDK itself isn't even loaded — until you agree, and you can change your answer anytime using the toggle below.

• On the website and the installed PWA, a banner asks once you've created or joined your first room.
• In the native Android app, the same choice is instead the last step of the one-time onboarding screen shown on first launch, after the permission requests.

Once you agree, we log a small number of events:

• app_open — the app/site was opened.
• room_created — room type, connection mode, whether it was made permanent, whether a PIN was set, and whether it got a custom link (never the link itself).
• room_joined — room type and connection mode, only when you're not the room's creator.
• message_sent / reaction_sent — room type only, never the message text or which emoji was picked.
• tab_clicked — which screen and tab you switched to.
• help_clicked — where you opened Help from.
• update_button_clicked — native app only, on the mandatory update screen.

None of these ever include a room name, room token/PIN, chat text, the emoji you reacted with, or your IP address as stored data. Like most analytics SDKs, Firebase Analytics attaches a random identifier (on the website kept in a Google Analytics cookie such as _ga; inside the native app scoped to that app installation) and basic technical data (app/browser version, OS, device model, coarse region from IP) to every event as part of its standard operation, processed by Google under Google's Privacy Policy — tied only to that random identifier, never to your name or account.

7. Browser notifications and native Android app

While you are broadcasting, SpeakMic can show a persistent browser/system notification ("Still broadcasting") so you know your microphone is live even if the app is in the background, with a tap-to-return action. This requires your explicit permission via your browser's notification prompt, which you can grant, deny, or revoke at any time in your browser settings. Notifications are shown locally by your device while you broadcast — we do not operate a push notification server and do not send marketing notifications.

If you use the native Android app, it uses an Android ForegroundService to keep audio connections alive while your screen is locked. While this service is running, Android requires displaying a persistent system notification in your notification panel (e.g. "SpeakMic is running"). This notification is shown locally by your device; no additional data is sent to our servers as a result of this. You can stop the service at any time by leaving the room.

In the native Android app the host of a room can tap "Send to everyone nearby". For 5 minutes (or until they stop it or leave the room) the phone then sends the room's type, code and name over Bluetooth, through Google Play services' Nearby Connections, to phones nearby; other SpeakMic app users who have the Join tab open see the room there and can open it, just as with its link. Nothing is sent before that tap, no connection is made between the phones, and none of this passes through our servers. It needs Android's "Nearby devices" permission (before Android 12, location - asked only when a host taps the button); the app does not use it to find out where you are.

With the SpeakMic Wear watch app (Wear OS), the watch is a remote for the room open in the phone app: while you are in a room, the phone sends the watch what the room's screen shows - its name, the nickname of whoever is talking or calling you, the number of people or listeners and the volume - and the watch sends back your taps (talk, mute, answer a call, leave). This goes between your own phone and watch through Google Play services' Wearable Data Layer; the watch never connects to the room, keeps only the last state for its tile and watch face, and none of this passes through our servers.

See Section 6 above for the native app's Firebase Analytics consent and event list — sent only when you've agreed, and only while an internet connection is available.

8. How long we keep data

Rooms (and any chat messages within them) are automatically deleted after a period of inactivity. Rooms created on the app's home page, both Broadcast and Walkie-Talkie, are "permanent" by default: a permanent room is automatically deleted once 3 months have passed without a broadcast (a Broadcast room) or without anyone connected (a Walkie-Talkie room), or earlier if its creator deletes it manually. When creating a room, its creator can make it "temporary" instead: a temporary room is deleted after 1 day with no active participants. A room set up in a landing-page editor is temporary unless made permanent there, which requires an admin PIN. Rooms that belong to a landing page (/p/…) are not deleted for inactivity while they belong to it; once released from the page, the 3-month limit applies.

Separately, the lightweight room-token registry described in Section 3 (a room's token, type, and creation date, used only for the admin panel's aggregate statistics and the optional bulk-deletion feature) is retained for at most 3 months from the room's creation and then automatically expires, regardless of the room's own lifecycle; it is removed earlier if the room itself is deleted.

A room's custom link is stored for as long as the room has it. After the room is deleted or the link is changed or removed, the link registry keeps the name, the previous room's token and the release date for 90 days, then deletes them automatically. Separately, a device that opened a room with a custom link but no admin PIN keeps a small local counter of those visits (to decide when to remind you about the PIN); it never leaves the device.

9. Your rights

Depending on your location, you may have rights under data protection laws such as the GDPR, including the right to: access the personal data we hold about you; request correction or erasure; restrict or object to processing; and data portability. Because SpeakMic processes almost no persistent personal data (rooms and chat are deleted automatically and audio is never stored), most of these requests can be satisfied immediately without contacting us: a room's broadcaster or admin can delete the room (and its chat history) at any time directly from the app, which removes this data from our systems straight away. For any other request, contact us using the details in Section 1. You also have the right to lodge a complaint with your local data protection supervisory authority.

10. Children's privacy

SpeakMic may be used from the age of 13; below the age of digital consent in your country (16 in Poland) with the permission of a parent or guardian (see our Terms of Service). The Service is not directed at children under 13 and we do not knowingly collect their personal data. The defaults protect everyone's privacy: analytics stays off until you agree, and we collect no location and do no profiling. Someone below the age of digital consent may agree to the analytics (Section 6) only together with a parent or guardian. If you believe a child has used the Service in a way that raises concerns, please contact us.

11. International data transfers

The Service runs on a global edge network (Cloudflare) and its frontend is hosted on Vercel. As a result, the transient connection data described above may be processed in data centres located in different countries, including outside the European Economic Area (EEA), in particular in the United States. If you opt in to the analytics described in Section 6, the same applies to the resulting data, processed by Google. Cloudflare, Inc., Vercel, Inc., and Google LLC all participate in the EU–U.S. Data Privacy Framework (DPF), which has been recognised by the European Commission as providing an adequate level of protection for personal data transferred from the EEA to the United States (adequacy decision of 10 July 2023). Where the DPF does not apply, transfers are governed by Standard Contractual Clauses (SCCs) adopted by the European Commission. For further details, see Cloudflare's, Vercel's, and Google's own privacy policies and DPF certifications.

The optional SFU intermediary server (the open-source LiveKit software, run by us) is hosted on servers we rent from Oracle (Oracle Cloud Infrastructure, Frankfurt region, Germany), so audio routed through it is processed in the EEA. Oracle acts as our data processor under its data processing agreement; it does not access the audio, which is passed through in real time and never stored.

12. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be reflected by updating the "Last updated" date at the top of this page.

13. Contact

If you have questions about this Privacy Policy or how your data is handled, contact us at [email protected].