{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibou24oybw2osqrwxfqaxu67wgylwgxrs5ohkuz3mqkzpi5ls4odq",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mk7bdwj6obc2"
  },
  "path": "/t/daniel-boctor-apps-refuse-to-patch-design-flaw-that-tracks-everything-you-do/33126#post_14",
  "publishedAt": "2026-04-23T23:01:51.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "github.com/mollyim/mollyim-android",
    "[Feature request] Add a switch to enable/disable sending delivery receipts",
    "beantaco"
  ],
  "textContent": "I created a feature request for a switch to enable/disable delivery receipts on a per-contact basis and submitted it to Molly (fork of the Signal Android client).\n\ngithub.com/mollyim/mollyim-android\n\n####  [Feature request] Add a switch to enable/disable sending delivery receipts\n\nopened 05:36AM - 30 Mar 26 UTC\n\n\n\n          beantaco\n        \n\n### Guidelines - [x] Yes, I have searched the existing requests ### Feature De…scription A [research paper](https://arxiv.org/pdf/2411.11194) called \"Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers\" published October 2025 demonstrates an attacker can abuse instant messaging apps' delivery receipts to track users. Molly is aware of this security vulnerability and has opened [an analysis issue](mollyim/mollyim-android/issues/646) to address it. Details of this vulnerability and Signal's response can be found in the paper, [this Signal Android pull request](https://github.com/signalapp/Signal-Android/pull/14463) and [this Signal community forum thread](https://community.signalusers.org/t/better-security-against-sidechannel-and-protocol-attacks-defcon-2025-security-flaws/72289). In light of this vulnerability and AFAIK no mitigations implemented by Signal to address it thus far, I propose a switch to enable/disable sending delivery receipts on a per-contact basis. - When the switch is enabled, everything operates as normal. - When the switch is disabled, the user can receive messages from the contact without the contact being notified their messages are being delivered to the user; this would make the user appear offline to the contact whether or not the user is actually online or offline. - When the user attempts to send a message to the contact, either the user is prompted to re-enable sending delivery receipts or the switch will be automatically re-enabled (whichever is preferable to implement). - I suggest the switch be located at the same place in the UI adjacent to the \"Block\" switch. - When sending delivery receipts is disabled for a contact, the UI displays a small icon to that effect, exactly or adjacent to where the block icon would display when a contact is blocked. One problem I see is, unlike the block setting, the switch will have effect only on the device the user sets/toggles the setting, and I don't know if there exists a mechanism to transmit the setting's state to the user's linked devices. Otherwise I believe adding this switch would not interfere with the Signal Protocol or reliability. when the switch is enabled it will just make the user appear offline to the contact who will no longer receive delivery receipts. I invite people to comment on this proposed feature and the technical and social pros/cons of it, corrections of my misunderstanding etc. My thoughts on the vulnerability and its mitigations are outlined below. *** Users concerned about this vulnerability being exploited against them have the technical option to block suspected attackers, thus AFAIK disabling delivery receipts being sent from their client to the blocked contacts. However, recommending this action to users has some problems. - Users have no way to find out via the Signal UI that delivery receipts are being sent from their client and to which contacts those are being sent to. - Users may lack liberty to block certain contacts because of social pressure or a need to communicate with the contacts. Examples of users who may be concerned about this vulnerability and when blocking may be inappropriate include - A worker and their nosy boss and nosy coworker. - A victim/survivor of ongoing domestic violence and their abuser. - An activist and their comrade who has had their device seized. Temporary blocking would stop delivery receipts being sent to the blocked user while allowing communication, but the blocking user would fail to receive messages from the blocked user while the block is in place, thus an impractical mitigation. As of now, users of the official Signal client have these mitigations. - To limit the amount of information sent to potential attackers, disable read receipts and typing indicators. - To stop sending delivery receipts, close the Signal app while not in use. To be sure of this, turn off internet connectivity. - To read messages you have already received without sending delivery receipts, open and close the Signal app while internet connectivity is turned off. Obviously these mitigations are all or nothing and cannot be tuned on a per-contact basis. Further, keeping the app closed and internet turned off severely affect people's ability to use the app and their own device properly, again impractical. Edit to add: Delivery receipts are a privacy issue even as designed and intended, by indicating (the unfilled double tick icon) when contacts receive messages, leaking contacts' online status. This is something I have felt discomfort about as a long-time Signal user. If a switch to enable/disable sending delivery receipts on a per-contact basis is added, users could disable sending delivery receipts to suspected contacts, while being able to use the app properly without shutting off internet and closing the app down, and while still being able to receive messages from suspected contacts. References: - [The research paper](https://arxiv.org/pdf/2411.11194) - [mollyim/mollyim-android issue #646](https://github.com/mollyim/mollyim-android/issues/646) - [signalapp/Signal-Android pull request #14463](https://github.com/signalapp/Signal-Android/pull/14463) - [Signal community forum thread](https://community.signalusers.org/t/better-security-against-sidechannel-and-protocol-attacks-defcon-2025-security-flaws/72289)\n\nExtract of feature description\n\n> In light of this vulnerability and AFAIK no mitigations implemented by Signal to address it thus far, I propose a switch to enable/disable sending delivery receipts on a per-contact basis.\n>\n>   * When the switch is enabled, everything operates as normal.\n>   * When the switch is disabled, the user can receive messages from the contact without the contact being notified their messages are being delivered to the user; this would make the user appear offline to the contact whether or not the user is actually online or offline.\n>\n\n\nThis is meant to deny information from _creepy companions_ (attackers who are in the user’s contact list) and obviously won’t work against _spooky strangers_ (attackers who are not but know the user’s phone number).",
  "title": "Daniel Boctor: Apps REFUSE TO PATCH \"Design Flaw\" that tracks EVERYTHING you do"
}