[RFC]: Better indication and control of ongoing Talk recordings

[khnjrdm]

Tip

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Summary

A Talk recording, once started, continues capturing audio and video from the microphones and cameras of every remaining participant until every single one of them physically leaves the call. If the recording initiator leaves but any other participant stays, the recording continues indefinitely with no user-facing indicator strong enough to prevent forgotten sessions.

During that period, any audio and video captured by the remaining participant's device is written into the recording file. This includes phone conversations conducted on the same device, ambient environmental audio, and camera-visible content that has no connection to the Talk meeting.

Third parties can end up captured in the recording without any relationship to the Nextcloud instance and without knowing that recording is happening.

Steps to reproduce

1. User A initiates a call to User B in a 1:1 Talk conversation.
2. User B answers. User B starts a recording.
3. Both users talk. The recording captures them.
4. User B clicks "Leave call" and exits cleanly.
5. User A does not click "Leave call". They minimise the Talk client and return to other work.
6. Some time later, User A places a phone call on their mobile device. Speakerphone is used, so the audio is picked up by the computer's microphone.
7. The Talk recording captures the full phone conversation, including the voice of the third party on the phone (User C, unaffiliated with the Nextcloud instance).
8. Camera continues recording User A's activities at the desk for the same period.
9. Recording finalises only when User A is eventually asked to leave the call by User B.
10. User B receives the recording notification for the first time and discovers the file contains content that neither party ever intended to record.

Expected behaviour

Several correct behaviours could each individually prevent this. Any of them would be an improvement. Ideally, several are implemented together.

• The recording stops automatically when the recording initiator leaves the call. The person who started the recording is responsible for it. If they leave, the recording ends.
• Or the recording transfers to a remaining moderator who is prompted with a clear "you are now the recording owner" dialog and given an obvious stop control. If nobody accepts responsibility, the recording auto-stops after a short grace period.
• A leaving user who owns an active recording is warned with a modal: "You started a recording. Leaving now will [stop it / continue it with X as owner]. Confirm." The leaving user gets to decide the outcome consciously.
• Every remaining participant sees an unmissable ongoing indicator that recording is active. Not a small red dot in the corner. A persistent banner across the top of the call view saying "Recording in progress" that cannot be minimised or dismissed.
• A participant left alone in the call while recording is active gets a modal: "You are the only participant left. Recording will continue until you leave. End the call and stop the recording?" With an obvious default action of "End call and stop recording."
• Any moderator in the call can stop the recording, not just the person who started it.

Actual behaviour

• Recording continues indefinitely after the initiator leaves.
• The initiator has no way to stop the recording, no way to see whether it is still running, and no notification that it is still ongoing.
• The remaining participant has no unmissable indicator that recording is active. It is easy to forget the call is still connected.
• No modal, warning, or handoff occurs when the number of active participants drops to one.
• No moderator control exists to stop a recording once it has started, except (apparently) for the initiator.
• The only way to end the recording is for the last remaining participant to leave the call.
• If the last remaining participant is inattentive, distracted, or uses their device for other purposes during that time, all of that content is captured into the recording.

Impact

The severity depends less on the code and more on what the remaining participant does while the recording is running. If they leave immediately, no harm. If they continue with their day, arbitrary content ends up in the recording.

What actually happened when I hit this:

• A third party had their voice recorded through a phone call that was completely unrelated to the meeting. They had no account, no notification, no way to know.
• The remaining user's video captured their work activities for the duration: screen contents, documents open on the desk, whatever the webcam saw.
• The final recording contained all of this in one file, stored on the Nextcloud server, available for download or sharing.
• The person who started the recording had no visibility that any of this was happening until they noticed the "recording ready" notification was late.

This does not require malicious behaviour. It requires only:

1. A recording being started.
2. Everyone except one person leaving the call.
3. The remaining person forgetting that they are still connected to Talk while carrying on with other things.

Every Talk deployment with recording is exposed to this pattern. Recording consent given at the start of a call doesn't cover content captured hours later when the meeting is effectively over but the recording is still running.

In two-party-consent jurisdictions (most of the EU), the resulting recording is on shakier legal ground than most users of Talk probably realise. That's a downstream concern, not the core bug, but worth being aware of.

Suggested resolution

The minimum viable fix, in my view, has two parts:

1. When the recording initiator leaves the call, stop the recording automatically. If Nextcloud wants to preserve the option of handing the recording off to a remaining moderator, present the leaving initiator with a modal: "Stop recording, or transfer to [name]?" Never continue silently.

2. Show a persistent, undismissable "Recording" indicator to every participant while a recording is active. Not a small red dot. A banner across the top of the call. The word "Recording" and a stop button, visible from every device, at all times during a recording.

A more complete fix also includes:

3. Any moderator in the room can stop the recording, not just the initiator. Remove the implicit ownership of the recording control by whoever pressed the button first.

4. When the call drops to one active participant while recording is still active, show that participant a modal: "You are alone in the call. Recording is still active. Stop recording and end the call?" With "Yes" as the default action.

5. Audit the recording server's behaviour on protracted calls. A recording that has been running for more than N hours with only one participant is a strong indicator of exactly this bug. Consider a hard cap or auto-stop after some threshold.

Environment

• Nextcloud Server: 34.0.2.1
• Talk (spreed): 24.0.3
• Signaling server (HPB): nextcloud-spreed-signaling 2.1.1 (bundled aio-talk image)
• Recording server: nextcloud-talk-recording running natively as a Debian LXC
• Clients used to observe: Talk desktop app on macOS. Both User A and User B were on the same client platform.
• Room type: normal 1:1 conversation between existing Nextcloud users.
• Recording configuration: default video encoding via libvpx VP8, audio via libopus, WebM container.

Notes about existing behaviour that may be relevant

• Nextcloud has a recording consent feature (talk_recording_consent) which forces users to acknowledge, before joining, that a call may be recorded. This is a good feature, but it does not address the bug reported here. Consent given at the start of a call does not extend to content captured after the meeting is effectively over but the recording is still running.

• Talk 24 introduced a "Call from anywhere" widget in the avatar menu. It is possible this makes it easier to forget which Talk sessions are still active. Worth checking whether this feature interacts with the bug reported here.

The core ask is straightforward: a recording should not silently outlast the meeting it was started to capture. Everything else in the suggested resolution flows from that.

[Antreesy]

Thanks for report!

There's a valid point to address here, but not sure about the complete list of suggestions:

User B clicks "Leave call" and exits cleanly.
User A does not click "Leave call". They minimise the Talk client and return to other work.

Not trying to be rude, but those are two human errors in a row.

Room type: normal 1:1 conversation between existing Nextcloud users.

Every 1:1 participant, and every moderator in a group can stop recording. Limitation is that only owner can share it to the chat
I couldn't reproduce it. Could you confirm, if you're seeing a bug on your side?

Consent given at the start of a call does not extend to content captured after the meeting is effectively over but the recording is still running.

Recording is running because the call is not over, because not everyone left the call. We're aware of GDPR regulations, but I'm struggling to apply it here

Talk 24 introduced a "Call from anywhere" widget in the avatar menu.

Thanks for noticing, same indication applied there, so similar level of awareness:

Consider a hard cap or auto-stop after some threshold.

There is a server config for max_call_duration

Show a persistent, undismissable "Recording" indicator. Not a small red dot. A banner across the top of the call.

No. We're quite limited in controls area already to allocate more space to it than needed

present the leaving initiator with a modal: "Stop recording, or transfer to [name]?"

✅ Might be implemented for last moderator. But there's an edge case with possible network issues and forced reconnection, so should be an intentional user gesture

When the call drops to one active participant while recording is still active, show that participant a modal: "You are alone in the call. Recording is still active. Stop recording and end the call?" With "Yes" as the default action.

✅ Also worth adding it on empty screen (when participant is left alone)

[khnjrdm]

User B clicks "Leave call" and exits cleanly.
User A does not click "Leave call". They minimise the Talk client and return to other work.
Not trying to be rude, but those are two human errors in a row.

I wouldn’t necessarily characterise that as two human errors in a row. User B explicitly leaves the call, but does not stop the recording. That is an easy thing to overlook, and it seems reasonable to expect that when the user who initiated the recording leaves the call, the system should handle the recording state appropriately.

User A simply minimises the Talk client and continues with other work. That is perfectly normal behaviour for a communication application and should not necessarily be treated as a user error.

To me, this is more about defining the expected recording lifecycle and making the system behave safely by default, rather than relying on users to remember an additional step.

Room type: normal 1:1 conversation between existing Nextcloud users.

Every 1:1 participant, and every moderator in a group can stop recording. Limitation is that only owner can share it to the chat I couldn't reproduce it. Could you confirm, if you're seeing a bug on your side?

Consent given at the start of a call does not extend to content captured after the meeting is effectively over but the recording is still running.

Recording is running because the call is not over, because not everyone left the call. We're aware of GDPR regulations, but I'm struggling to apply it here

I also struggle with the GDPR argument being reduced to whether consent was given at the beginning of the call. The issue, as I see it, is what happens afterwards.

Yes, consent was given when the call and recording started. But if the other participants have left and only the person who started the recording remains, the context has fundamentally changed. At that point, the system is continuing to capture content even though the meeting has effectively ended from the perspective of the other participants.

The fact that the call technically remains active because one participant has not clicked “Leave call” doesn’t necessarily mean that the recording should continue indefinitely. This is especially easy to get wrong because minimising the client and continuing with other work is normal behaviour, and it is quite easy to forget that the call is still active.

So I don’t think the question is simply whether consent was given. The question is whether the system should have a safer default when the participants who were part of the meeting have left. For example, automatically stopping the recording when the initiator leaves, or when all other participants have left, would remove a fairly obvious risk of unintentionally recording content outside the intended meeting.

Ultimately, I think we should look at this from the user’s perspective: how can we make the process as simple, intuitive and lean as possible? The technology should be the enabler, not something users have to work around or remember the technical details of.

In this particular case, it seems clear that the process has some quirks. Requiring users to explicitly “hang up” or remember to stop a recording in a situation where the meeting has effectively ended is not necessarily an intuitive workflow. Rather than considering that simply a user error, I think it is worth looking at how the system can handle these situations more gracefully and remove unnecessary friction and risk.