What the server sees, and for how long
Version 2.1 · Last updated 25 September 2026
This notice is short because there is little to describe, and specific because a vague privacy notice is worth nothing. Everything below can be checked against the source and against your own browser’s network tab.
The short version. There is no account, no database and no analytics. The signalling server sees a room code, a random connection id, and — unavoidably, because that is how the internet works — your IP address while your socket is open. It never sees your files, messages, drawings, voice, screen, nickname, room password or invite-link secret. The server writes nothing about you to disk; the only thing it keeps is a daily count of how busy it was. Everything about a room ceases to exist when the room does. Your own browser writes nothing either, unless you tick “resume this if the tab closes” on a transfer — see section 6.5.
A summary is not the notice. The detail below is what governs.
1. Who is responsible
The controller for the processing described here is [OPERATOR LEGAL NAME], [REGISTERED ADDRESS], contactable at [PRIVACY CONTACT EMAIL]. [DATA PROTECTION OFFICER]. [EU UK REPRESENTATIVE].
Under Quebec’s Act respecting the protection of personal information in the private sector, the person in charge of the protection of personal information is [PRIVACY OFFICER NAME AND TITLE], reachable at the same address. Where that person is not designated in writing, the role falls by law to the person with the highest authority in the enterprise.
This notice covers the signalling service at [SERVICE URL]. It does not cover what other participants do with what you send them, which is between you and them.
2. Why there is so little to describe
The server’s only job is to introduce two browsers and then step aside. It passes opaque connection blobs between sockets in the same room; once the browsers have a direct encrypted channel, everything travels between them and never through it. There is no database, no object storage and no message queue: all state lives in the memory of one process and is lost when that process restarts.
This is the reason the lists below are short. It is a property of the design rather than a promise about our intentions, and you do not have to take our word for either — the source is available and the network traffic is inspectable in your own browser’s developer tools.
3. What the server processes
| Data | Why | How long |
|---|---|---|
| IP address | Inherent to any TCP connection. Used to deliver the WebSocket and for nothing else. Not logged, not stored, not used to identify or count you. | In memory for the life of the socket |
| Room code | To put the right browsers in the same room. | Life of the room, which ends the moment the last person leaves. A room nobody has entered yet is kept two minutes |
| Connection id | A random string identifying a socket within a room, so signalling can be routed. It is not derived from anything about you and changes every session. | Life of the socket |
| Signalling blobs | Session descriptions and network candidates, passed between two sockets unread. They contain the network addresses the browsers will use. | Not retained — relayed and discarded |
| Room settings | Which entry mode, whether strict, whether it burns, when it expires, how many people it holds, and which of files, screen sharing, voice and the board it allows. Needed to enforce them — or, for those four, to give every member the same rules, which each browser then enforces. | Life of the room |
| Password salt and verifier | For password rooms. The password itself never reaches the server; only a PBKDF2-SHA256 derivation of it, computed in your browser, is compared. | Life of the room |
| Proof-of-work challenge | A puzzle issued per join attempt, so joining can be rate-limited without knowing who is joining. It is signed rather than remembered: the server keeps only puzzles already solved, so that none can be spent twice. | Not kept when issued; once solved, until its two minutes are up |
| Rejoin token | A random string letting you reclaim your seat after a network blip without knocking or retyping a password. Using it hands you a new one, and it stops working once the new one is used. One room only. | Until its replacement is used, or until your seat is given up: you leave, the room closes, or your connection stays down past the short grace period |
| Knock ticket | For approval rooms: a random id for a pending request. The label shown to the host is encrypted with the room secret, which the server does not have. | Ninety seconds |
| Daily activity counters | How busy the server was, per UTC day: connections open at the busiest minute, connection-minutes, rooms opened, seats taken, and the worst delay of its event loop. Numbers only — no address, no room code, no identifier, and no time finer than the day. A day is published only once it is over, so its numbers cannot say when anything in it happened. Shown on the status page as a calendar, and their running total on the front page. Where the operator sets it up, they are kept in a Cloudflare KV store so a restart does not reset them. | Up to 371 days |
Nothing in this table is written to disk except the daily counters in its last row, which say how busy the machine was and never who made it busy. There is no analytics, no telemetry, no error-reporting service, no advertising and no fingerprinting. [ACCESS LOGGING]
4. What the server never receives
- File bytes, file names, folder structures and file sizes;
- chat messages;
- whiteboard strokes and screen annotations;
- voice audio and shared screen video;
- nicknames — they travel inside the encrypted channel between browsers;
- room passwords;
- invite-link secrets;
- the safety words two people compare to verify each other.
5. The invite link
An invite link looks like https://example/#12345-SECRET. Everything after the # is a URL fragment, and fragments are resolved entirely inside the browser: they do not appear in the request line, and the Referrer-Policy is set so they do not appear in a Referer header either. The secret carried there is what lets two participants verify each other automatically, and it is something the server has never seen.
The application removes the fragment from the address bar as soon as you are in the room, so it is not sitting in view during a screen share, and keeps the secret in memory instead. Anywhere you paste that link, of course, the secret goes too.
6. What is stored in your browser
6.1 Cookies: none. The application sets no cookies, and the signalling library is configured not to. There is no consent banner because there is nothing to consent to.
6.2 Session storage. One key, gd-agreed, holding the version of the Terms you accepted. It dies with the tab. It is never sent to the server.
6.3 Local storage: none. Deliberately. Your theme choice is kept in memory only, because a remembered preference is itself a record that this browser opened Obleevo.
6.4 Service worker cache. The application’s own static files — HTML, stylesheet, scripts, fonts — are cached so it works offline. No user content is ever cached. Burning a room clears this cache and unregisters the worker.
6.5 Resuming a transfer, if you ask for it. A large download normally survives a network blip but not the tab closing, because the record of which blocks arrived lives in memory. If you tick resume this if the tab closes when you accept a file, that record is written to an IndexedDB database named ghostdrop-resume in your browser. It holds the file’s name and size, which blocks were verified, the hashes needed to verify the rest, and the handle your browser gave the application when you chose where to save. It does not hold the file’s contents — those are already in the file you picked. It is never sent to the server or to any other participant. It is deleted when the transfer finishes, when you cancel it, when you leave or burn the room, and in any case after seven days. Leaving the room deletes the whole database rather than emptying it, so the name stops appearing in your browser’s own storage listing. This is the only thing Obleevo ever writes to your disk, and it is off unless you ask for it, per transfer.
6.6 Files you save. A received file is written where you told the browser to put it. It is yours from that moment and nothing in the application can reach it again.
7. What is handed to your operating system
Notifications are off until you switch them on, and permission is asked for only when you do. What they say comes from a fixed list of six sentences chosen by which event occurred — a file is waiting, someone wants in, and so on. They never contain a file name, a nickname, a message, a room code or any other content, because the application selects a list entry rather than composing text. This matters: a notification is written to a notification centre by software this application does not control, so anything a notification said would have left the room. They are raised only while the tab is in the background, and you can switch them off again at any time.
The screen is kept awake while a transfer, call or screen share is running, and released as soon as nothing is happening. This sends no data anywhere; it asks your browser not to let the device sleep.
The share button hands the invite link to your operating system’s share sheet, and then to whichever application you pick from it. That link contains the secret that admits someone to the room, so treat sharing it exactly as you would treat sending it any other way: whoever receives it can join, and the application you share through will have a copy. Nothing else is passed to the share sheet — no files, no messages, no contacts are read.
Dictation is off unless you allow it. Turning speech into text is done by your browser’s own speech service, not by Obleevo. Where the browser can do it on the device, it does, and nothing leaves. Where it cannot, the sound of your voice is sent to the browser’s maker — Google for Chrome, Microsoft for Edge, Apple for Safari — under their terms, and the application tells you so and asks before the first time. Voice messages are different: they are recorded in your browser and sent to the room over the same encrypted peer-to-peer channel as a chat message, and never pass through the server or anyone else.
The browser tab’s title shows a count of messages you have not seen and, during a transfer, a percentage. It never shows a name or any content, and it is cleared when you return to the tab.
8. Legal bases and consent
Where the UK or EU General Data Protection Regulation applies, we rely on:
- Article 6(1)(b), performance of a contract — for the connection data needed to put you in a room you asked to join;
- Article 6(1)(f), legitimate interests — for the proof-of-work challenges and rate limits that keep the service usable and resistant to abuse. Our assessment is that this is minimally intrusive: the whole point of the design is to rate-limit without identifying anyone, which is less intrusive than the IP-based throttling it replaces;
- Article 6(1)(c), legal obligation — where we are required to retain or disclose something, which given what we hold would be very little.
Quebec. Under the Act respecting the protection of personal information in the private sector, we collect only the information necessary to provide the service you asked for, and we collect it from you directly. The purposes are those set out in section 3 and no others. No identification, localisation or profiling technology is used; had one been, section 8.1 of the Act would require us to tell you and to give you the means to switch it off, and there is nothing here to switch off. Privacy settings are at their highest by default because there are no settings to lower.
9. Retention
Retention periods are in the table in section 3. The general rule is that a room’s state is destroyed when the room is destroyed — when the host burns it, when it reaches its time limit, the moment the last participant leaves, or when the process restarts. There is no backup, because there is nothing to back up.
Burning a room additionally instructs every participant’s browser to clear the origin’s storage, caches and service worker, so the application leaves nothing behind on their machine either. Files already saved to their disk are theirs and are untouched.
On your own device. A resume note you opted into (section 6.5) is kept until the transfer finishes, until you cancel it, until you leave or burn the room, or for seven days, whichever comes first. Nothing else is kept anywhere.
10. Recipients and processors
9.1 Hosting. [HOSTING PROVIDER, LOCATION] operates the machine the signalling process runs on and can therefore observe connection metadata at the network level. They act as a processor under [DATA PROCESSING AGREEMENT].
9.2 STUN. Browsers contact a STUN server to learn their own public address. [STUN PROVIDER] therefore sees your IP address. If that matters to you, run your own — it is a one-line configuration change.
9.3 TURN relay. [TURN OPERATOR]. When Hide my IP is on, your encrypted media passes through this relay, which sees your IP address and your peers’ but cannot decrypt anything. Relay credentials identify this service to the relay, not you. They are not made per person: everyone asking at the same moment receives the same one, and with Cloudflare’s relay a single credential, valid for 12 hours by default, is handed to every visitor until it is renewed, for less time as the relay’s monthly allowance runs low. The relay’s long-term secret or API token never leaves the server. The relay has a monthly allowance: the server reads, from Cloudflare, only the total number of bytes the relay carried per day - nothing about who - and when the allowance is used up, or cannot be read, it stops handing out credentials for it and cancels the ones already out. Where a backup relay is set up - run by The House of Brendrof on a server rented from OVHcloud in Beauharnois, Quebec - it takes over at that moment; it sees the same things, your IP address and your peers’ but never the content, and its software is set to keep no logs. Without a backup, or with it unavailable too, connections are direct until the allowance frees up; Hide my IP then says it is paused rather than connecting you without it.
9.4 Nobody else. No analytics provider, no advertising network, no CDN, no font service, no error tracker. The application’s Content-Security-Policy forbids loading anything from a foreign origin, which is a technical guarantee of this rather than an assurance.
9.5 Law enforcement. We will respond to a valid legal order. What could be produced is limited to what exists at that moment: whether a given room code is live, and the sockets currently attached to it. We cannot produce content, history, or anything about a room that has closed, because none of it exists.
11. International transfers
The signalling service is hosted in [COUNTRY/REGION]. Where connection data leaves the UK or EEA, the transfer relies on [TRANSFER MECHANISM]. Your content does not transit our infrastructure at all; it goes wherever the two browsers are, which is a matter between the participants.
Where personal information is communicated outside Quebec, section 17 of the Quebec Act requires a privacy impact assessment first. One has been conducted for the hosting arrangement described in section 9.1, and its conclusion is that the information at stake — an IP address held for the life of a socket, and a room code — is adequately protected in the destination jurisdiction. It is available on request.
12. Your microphone, and your speakers
Your microphone is opened only when you press the call button, and never in response to anything another participant sends. Leaving the call stops the microphone tracks, which is what turns your browser’s recording indicator off. Muting stops the audio being sent but keeps the call open; leaving is what releases the device.
Audio from other participants is not played until you join the call. Anyone connected to you can start sending audio at any time — that is a property of the peer-to-peer connection, not a choice this application makes — so unsolicited audio is held rather than played, and the call view tells you how many people are talking. It begins playing when you join, and stops when you leave.
Files are never written without your acceptance. A file you have not accepted has no save location, no partial file and no record; data sent for it is discarded unread.
Your camera is used for one thing: reading a room’s QR code, and only after you press the scan button on the join screen. It is opened without the microphone, the picture is read by your browser on your device to find the link, and nothing it sees is recorded or sent anywhere. It is released the moment a code is found, the scanner is closed, or you leave the page.
A picture or a video you received can be shown in the page. It is read back from your own copy — the file you saved, or the one held in memory — never fetched from the network, and never from a file your browser’s check flagged as dangerous. Nothing about it is kept once you leave the room.
13. What other participants can see
11.1 A direct peer-to-peer connection reveals your IP address to the other participants. That is how WebRTC works. Hide my IP, where a relay is configured, replaces your address with the relay’s — moving who sees it rather than removing it.
11.2 Participants see your chosen nickname, anything you send, and — if you share a screen — whatever is on it, including notifications that arrive while you are sharing.
11.3 Anything a participant receives, they can keep. Our erasure guarantees are about our systems and about the browser’s own memory. They are not, and cannot be, a guarantee about other people.
14. Security
No system is perfectly secure, and this one is no exception. What we can say is specific: the operator is not in a position to read your content, and that is structural rather than a matter of trust.
- Content is end-to-end encrypted between browsers by WebRTC’s mandatory DTLS-SRTP. The server holds no key and could not decrypt anything if it did hold the ciphertext, which it does not.
- On top of that, content is encrypted a second time with post-quantum keys - a hybrid of X25519 and ML-KEM-768, mixed with the room’s secret where there is one, rotated at least every minute and renewed every half hour - so traffic recorded today cannot be opened later by a quantum computer. Messages and files always carry this layer; calls and screen sharing carry it where both browsers can seal media frames. Once two people are connected, their connection’s later negotiation also travels inside this encrypted channel rather than through the server.
- Participants can verify one another cryptographically. In a room with a password or an invite-link secret this happens automatically; otherwise five words are shown for you to compare aloud, which detects an interposed connection.
- Every transferred block is hashed by the sender and re-hashed by the receiver, so corruption or substitution is detected before anything reaches your disk.
- The Content-Security-Policy forbids inline script, inline style and every foreign origin, and requires Trusted Types, so no text can reach a place in the page that would run it as code or read it as HTML. The page is cross-origin isolated: it loads nothing another site has not agreed to share, and no window from another site keeps a hold on it.
- Joining costs a proof-of-work computation, which makes scanning for live room codes expensive without the server needing to know who is scanning.
- Every message a peer can send is bounded in size and rate, so a hostile participant cannot exhaust another participant’s memory.
- Photos you send leave without the place they were taken: before a JPEG, PNG or WebP picture is checked or sent, your browser removes its GPS position, camera details, embedded text and anything attached after the image, without touching the picture itself. Formats it cannot clean safely (HEIC, video, raw) go out unchanged, and the send dialog says so.
- A picture you receive is shown only as a copy redrawn from its pixels in a separate, disposable part of your browser, so an image built to attack the browser, or with something hidden in it, never reaches the page as it is. The file you saved is not changed.
- Links in messages are checked on your device - nothing is fetched to do it - and following one first shows the site it really goes to, with look-alike letters, imitated brands and hidden destinations spelled out. Names that could be mistaken for one another in a room are flagged the same way.
- A voice or a face in a call can be imitated. Each person in a call is marked as verified or not, and safety words can be compared aloud or by scanning each other’s code with the camera, which is used only while that dialog is open.
- Pressing Escape three times within a second leaves the room at once (as the host, it burns the room), erases this browser’s copy of the application and its storage, and leaves an empty page.
15. Personal data breaches and confidentiality incidents
In the event of a breach likely to result in a risk to your rights and freedoms, we will notify [SUPERVISORY AUTHORITY] within 72 hours of becoming aware of it, and will notify affected individuals where the risk is high. Because we hold no contact details for anybody, individual notification would necessarily take the form of a prominent public notice on the service.
In Quebec, a confidentiality incident presenting a risk of serious injury is reported promptly to the Commission d’accès à l’information and to the persons concerned, and is entered in the register of confidentiality incidents the Act requires us to keep. That register is available to the Commission on request.
16. Your rights
Where the UK or EU GDPR applies you have the rights of access, rectification, erasure, restriction, portability, and objection to processing based on legitimate interests. Write to [PRIVACY CONTACT EMAIL].
In Quebec you have the rights of access and rectification under sections 27 and 28 of the Act, the right to withdraw consent, the right to cease dissemination and to de-index, and — since 22 September 2024 — the right to portability: to receive the computerised personal information you provided, in a structured and commonly used technological format. We answer within 30 days.
We have to be honest about what those rights get you here. We hold no identifiers that would let us find data relating to you — no account, no cookie, no stored IP address. Under Article 11 GDPR, a controller who cannot identify a data subject is not obliged to acquire additional information in order to do so, and the Quebec Act is to the same practical effect. A request for access will be answered truthfully and unhelpfully: there is nothing held about you to produce, and a portability request has nothing to export. Erasure happens on its own, continuously, as rooms close.
You may complain to a supervisory authority. In Quebec that is the Commission d’accès à l’information du Québec; in the UK, the Information Commissioner’s Office; in the EU, the authority in your country of residence. [LEAD AUTHORITY]
17. California and other US states
15.1 In the twelve months preceding this notice the categories of personal information handled are limited to identifiers, in the form of an IP address held transiently for the life of a network connection, and internet activity in the form of the connection metadata described in section 3. Both are collected directly from your device and used solely to provide the service you requested.
15.2 We do not sell personal information and do not share it for cross-context behavioural advertising, as those terms are defined by the California Consumer Privacy Act as amended. We have never done so. There is no financial-incentive programme, and we do not discriminate against anyone for exercising a privacy right.
15.3 We collect no sensitive personal information and therefore have nothing to limit the use of.
15.4 Rights to know, delete, correct and opt out may be exercised at [PRIVACY CONTACT EMAIL], subject to the same practical limitation described in section 14: we hold no identifier that would let us connect a request to any data. Residents of other states with comparable statutes — Colorado, Connecticut, Virginia, Utah, Texas, Oregon, Montana and others — may exercise the equivalent rights the same way.
18. Children
The service is not directed to children and we do not knowingly process their personal data. Since we collect no age information and hold no accounts, we cannot detect a child’s use. If you believe a child has used the service in a way that concerns you, contact us — though it is worth knowing in advance that there will be no stored data for us to delete.
19. Automated decision-making
There is none within the meaning of Article 22 GDPR or section 12.1 of the Quebec Act. The rate limiter and the proof-of-work gate are mechanical thresholds applied to a connection, not decisions about a person, and they produce no legal or similarly significant effect. No decision about anyone is made exclusively by automated processing, so there is nothing for us to inform you of and nothing for you to submit observations on.
20. Changes to this notice
We may update this notice. The version and date at the top will change, and material changes will be announced on the service itself. We cannot email you about it, for the reason this whole document describes.
21. Contact
[OPERATOR LEGAL NAME]
[POSTAL ADDRESS]
Privacy: [PRIVACY CONTACT EMAIL]
Person in charge of the protection of personal information (Quebec): [PRIVACY OFFICER NAME AND TITLE]
Data protection officer: [DATA PROTECTION OFFICER]
Last reviewed:
About · Why this · FAQ · Terms · Accessibility · Cookies · What’s new
Obleevo is developed by The House of Brendrof. Proprietary software, free to use.