Not everything that leaks is a defect. Sometimes a messenger exposes a piece of data on purpose, having weighed it against something it values more. Olvid, built around privacy by design, does exactly that in two places I looked at closely. Here is what happens, and here is why the vendor considers each one acceptable.
the recipient's IP
When you call someone on Olvid, the call is routed through a relay (TURN) server. On Android, the caller can name that relay. Point it at a server you control and, once the other side accepts, their device connects to it — making their IP address visible to that relay.
Olvid's position. The vendor decided to stop forcing its own relay in preparation for a future feature. It also argues that every way to start an Olvid conversation already requires the attacker to know more about the target — a name, a phone number — than the single thing that leaks here: the public IP of the phone. On that basis, Olvid does not consider the leak significant, and does not treat it as a vulnerability.
My view, for the record. A public IP is a different kind of data from the contact details needed to reach someone: it points at an approximate location and can change over time, so it is not simply implied by already being a contact. That said, this is a threat-model judgment, and I accept Olvid's conclusion that the residual risk is acceptable for its model.
iOS — pins its own relays
Android — accepts the caller's
Olvid's iOS client uses its own fixed relay addresses and ignores the ones a caller supplies; the Android client accepts the caller's. Olvid describes the Android behaviour as a deliberate rollback made for a planned feature, not an oversight.
Link previews: the sender, not the recipient.
Olvid builds link previews on the sender's device and embeds the result in the encrypted message. The recipient displays it without fetching anything — so, unlike many messengers, there is no zero-click leak on the receiving side. What remains is that the sender's device fetches the URL directly, with no proxy, exposing the sender's own IP to whoever controls that URL.
Olvid's position. A server-side proxy, like the one Signal runs, would mean Olvid itself sees every link its users share — which the vendor considers at odds with its privacy-by-design goal. It also notes the sender has usually opened the link already. So Olvid keeps the current design unless an approach is found that protects the sender's IP without a central party seeing every link.
I accept that reasoning. It is a genuine trade-off between two kinds of privacy, and Olvid has chosen the one that fits its model.
A disagreement handled well.
Both behaviours are real, and both are deliberate. Reported through ANSSI / CERT-FR, reviewed with the vendor, and — after I looked at the reasoning — accepted as trade-offs rather than defects. Several of my initial observations I withdrew along the way. That is how coordinated disclosure is supposed to work: not every finding ends in a fix, and a vendor explaining its model clearly is a good outcome too.