# Weaker security controls for webxdc apps \[disable P2P realtime channels disappeared\] **URL:** \ **Category:** Mini Apps\ **Tags:** privacy, p2p\ **Created:** [January 27, 2026, 5:04pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654 "2026-01-27T17:04:18Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![peppa](https://forum.delta.chat/letter_avatar_proxy/v4/letter/p/da6949/32.png) [@peppa](https://forum.delta.chat/u/peppa)\ **Post date:** [January 27, 2026, 5:04pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/1 "2026-01-27T17:04:18Z")
I noticed the switch to disable P2P realtime channels for webxdc apps disappeared. The change log says it is “deprecated” but I don’t see any other permission settings for webxdc apps or any other option to disable P2P realtime channels for webxdc apps. I don’t understand why the switch is deprecated and I am worried that webxdc apps can now potentially make P2P realtime channels without any way to prevent this. Is it still possible to disable P2P realtime channels for webxdc apps? I also saw in the change log that externals links can now be opened inside webxdc apps, which seems to go against the original sandbox idea that webxdc apps won’t be able to connect to random internet sites. I like the webxdc apps but don’t feel comfortable to use them if they can now expose my IP address without warning, and the ability to connect to random internet sites instead of staying only inside the chat seems to move away from the privacy and security promises of sandboxed “in-chat” apps. ---
**Author:** ![WofWca](https://forum.delta.chat/user_avatar/forum.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://forum.delta.chat/u/WofWca)\ **Post date:** [January 27, 2026, 5:29pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/2 "2026-01-27T17:29:48Z")
The “Real-time” switch has been removed in - [remove realtime preference toggle by adbenitez · Pull Request #4094 · deltachat/deltachat-android · GitHub](https://github.com/deltachat/deltachat-android/pull/4094#issuecomment-3625862865), where the arguments are outlined - [remove: option to disable realtime-channels by Simon-Laux · Pull Request #5925 · deltachat/deltachat-desktop · GitHub](https://github.com/deltachat/deltachat-desktop/pull/5925) > it happens often that people disable it in the past because they got scared by the description and forgot about it then complain that apps are not working as expected and need to be told to enable it > whatever you change for sure someone will complain, but I don’t think there will be many complains, most people don’t even know that option exists nor understand it > > also, it is already the same for calls for example, or when clicking a link someone sent to you in the chat > > you are also sharing your IP with the chatmail servers, etc. sharing it with your family and friends is the least of the concerns, this is nothing otherworldly, normally people don’t need to worry about this, and if they do, then the proper solution is to use a VPN or Tor (and leak the IP then to that providers, you see to use the internet someone has to know your IP) not to have several settings in Delta Chat * * * > [@peppa](#): > > externals links can now be opened inside webxdc apps, which seems to go against the original sandbox idea that webxdc apps won’t be able to connect to random internet sites. That is going to be behind an “Open this link?” dialog. Apps are still not supposed to be able to connect to the internet. See [in webxdc, allow to open dialog on clicking https: etc. · Issue #5785 · deltachat/deltachat-desktop · GitHub](https://github.com/deltachat/deltachat-desktop/issues/5785). Related: - Back when the option was still present: [Can realtime chat be disabled?](https://support.delta.chat/t/can-realtime-chat-be-disabled/3160) - > [@P2P and proxy settings](https://support.delta.chat/t/p2p-and-proxy-settings/4274/1): > > Could we have a setting to disable all P2P functionality ---
**Author:** ![ian](https://forum.delta.chat/user_avatar/forum.delta.chat/ian/32/3164_2.png) [@ian](https://forum.delta.chat/u/ian)\ **Post date:** [January 27, 2026, 6:42pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/3 "2026-01-27T18:42:57Z")
I disagree with the removal of the setting. > it happens often that people disable it in the past because they got scared by the description and forgot about it then complain that apps are not working as expected and need to be told to enable it I have read maybe a thousand messages on the forum already and I don’t agree that it happens “often” to any reasonable sense of the word. As it is already hidden behind an advanced submenu, it posed no danger whatsoever. If you think people previously were not disabling it due to wisdom, but rather due to stupidity, feel free to open a modal confirmation once after the next upgrade to remind the user that they should enable it if that’s their thing, but don’t take this away from us. I never use DC calls with random DC contacts, and I have various options for VoIP with ones whom I trust. Similarly, the circle to which I would be willing to do DC VoIP would be different compared to those who I would be willing to do some casual games with (or see also available collaborative real time chat webxdc). There aren’t that many public webxdc that rely on P2P exclusively to work in the first place. It would make sense to have a toggle for consent either globally, per webxdc, per group or per sender. It is possible to disable P2P or at least forcing TURN by many competing messaging apps. Also, did you know that such P2P solutions not only leak your WAN IP, but also your LAN IPs that may be able to fingerprint you further? Disclosing your IP (and networking fingerprint!) to your own chatmail server is not the same threat level as disclosing it to every contact. In certain circumstances, it would also enable them with silent pings to - track your whereabouts throughout the day, - how your delay and bandwidth capability change with network roaming kind and signal strength, - determine how many and what kind of devices you use at what times of the day, - your sleep & work schedule, - … A workaround already exists: > [@WebRTC "polyfill" over realtime channels (webxdc-x-WebRTC)](https://support.delta.chat/t/webrtc-polyfill-over-realtime-channels-webxdc-x-webrtc/3198): > > TL;DR let’s make a library that makes apps that rely on WebRTC work. Me and @adbenitez had this idea. The apps themselves wouldn’t have to utilize any webxdc APIs, it will be hidden behind the WebRTC polyfill we’ll have written. Below are mostly my implementation thoughts and ideas. webxdc realtime channels are a broadcast channels, so all peers receive the message you send, and vise versa, plus there is no metadata associated with each webxdc message. So, the problem can be more broadly de… Related: > [@Add Lockdown Mode](https://support.delta.chat/t/add-lockdown-mode/4357): > > Delta Chat can have “lockdown mode”, disabling: Calls P2P in Webxdc All Webxdcs completely Animated images playback that uses third-party libraries Uploading push notification tokens “Load remote content” in HTML mails or HTML mails completely Processing any SecureJoin messages (others scanning your QR codes or clicking your invite link) This may cover the feature request to disable all P2P functionality: iOS has a concept of [Lockdown Mode](https://support.apple.com/en-us/105120) in which many features are disabled. I don’t propos… > [@Add an option to disable webxdc](https://support.delta.chat/t/add-an-option-to-disable-webxdc/4610): > > Delta Chat is a fairly simple idea: a core written in Rust that contains all the important logic and different UIs for each OS. The problem is that webxdc apps expose a limited webview to other contacts. This means Delta Chat goes from having a minimal attack surface to a potentially larger one. Different OSes, with different webviews and versions that aren’t always updatable. I’ve seen that you’re planning to add an option to limit calls to certain users. Why not add an option to disable webxd… > [@Alternative P2P realtime chat method](https://support.delta.chat/t/alternative-p2p-realtime-chat-method/3554): > > I don’t know how feasible this is, but I had an idea for alternative P2P realtime chat connection method for users who don’t want to reveal the IP address. Once Tor is supported in core, maybe a realtime chat app can spin up an onion site when it is first started, and then communicates thru the onion sites? There would be disadvantages like a delay when starting the app and slightly higher latency, but maybe this option could make a nice alternative for users who don’t want to reveal the IP addr… > [@"Who can call me" setting](https://support.delta.chat/t/who-can-call-me-setting/4303): > > Continuing the discussion from [P2P and proxy settings](https://support.delta.chat/t/p2p-and-proxy-settings/4274/16): It would be nice to have a way to disable incoming calls, with a “who can call me” and at least two options: Anyone and Nobody. Not sure if it should be synchronized, probably not. E.g. I may want to always answer the calls from desktop and never from the phone. > [@WebXDC threat model?](https://support.delta.chat/t/webxdc-threat-model/3018): > > Hi, I’ve just came across this WebXDC idea through its implementation in Monocles Chat (which does not appear to be working at the moment, but that’s another story). I am trying to find a description of WebXDC’s threat model and security design considerations, but so far no luck. Would be very grateful if someone could point me to whatever information might be available on those topics. > [@Label for apps which use realtime chat](https://support.delta.chat/t/label-for-apps-which-use-realtime-chat/3484): > > I suggest adding a label to apps in the xstore which use P2P realtime chat so that users who want to avoid this or who have realtime chat disabled can easily identify which apps will or won’t work for them and not waste time into apps which do use realtme chat. Expected behavior Apps which use P2P realtime chat are clearly labeled in the xstore Actual behavior Impossible to dinstinguish between apps which do or don’t use P2P realtime chat in the xstore ---
**Author:** ![peppa](https://forum.delta.chat/letter_avatar_proxy/v4/letter/p/da6949/32.png) [@peppa](https://forum.delta.chat/u/peppa)\ **Post date:** [January 30, 2026, 2:41pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/4 "2026-01-30T14:41:12Z")
Thanks @WofWca for linking those Github issues, I didn’t see them before, and from the comments there I see I’m not the only person who has concerns about the removal of the switch. I’m sorry to see the switch go, but also sad that there was no communication with users about this. I find it concerning that my installed app silently downgraded the security from one release to the next without any warning at all. People who trust and rely on the app should not have to worry which security features will be silently disabled overnight. I don’t find the reasoning for this change which is presented on the github issue so convincing. > it happens often that people disable it in the past because they got scared by the description If the problem is the scary description then IMO the solution is to change the description to something less scary, not simply take away the feature for everybody. Or even add a warning to the description that disabling the switch breaks certain features. > and forgot about it then complain that apps are not working as expected and need to be told to enable it If people forgetting about it is the problem then the solution could be to prompt them to reenable it when they open an app which requires P2P realtime channels, again I don’t see any real need to remove the switch completely just because some people are forgetful. > also, it is already the same for calls for example, or when clicking a link someone sent to you in the chat Its the same for calls but threads [like this one](https://support.delta.chat/t/who-can-call-me-setting/4303) show that if anything, there is desire for a way to restrict calls precisely for this reason. So I think its unfair to introduce the calls feature and then use that as an argument to remove the P2P realtime switch, ignoring users who are actually asking for ways to disable or restrict the new calls feature precisely for this reason. People can at least avoid clicking on links or choose to open them in the Tor browser or with a VPN at their discretion, but users do not have the same discretion for webxdc apps. With the P2P realtime switch gone, it is all or nothing, and users who want to avoid exposing their IP will have to stop using ALL webxdc apps cos there is no way to be sure which apps do or don’t use P2P realtime channels unless you inspect every line of the source code yourself. > you are also sharing your IP with the chatmail servers, etc. This is not true if you use Tor or a VPN. (About this I also find the DC FAQ misleading when it says that the relay “needs” to know your IP address. The relay does not need to know your IP address. And the FAQ downplays the fingerprinting risk with IP addresses or ignores this risk completely, which might convince people with high threat models to use poor opsec, which is dangerous.) > normally people don’t need to worry about this, and if they do, then the proper solution is to use a VPN or Tor (and leak the IP then to that providers, you see to use the internet someone has to know your IP) not to have several settings in Delta Chat I have never before heard anybody say they are “leaking” their IP to Tor just cos their guard node sees their IP address. The point of Tor is that the exit node and the website or whoever is at the other end of the connection can’t see your IP, this is not what is meant by “leaking” your IP. And with traditional VPNs, users are at least free to choose which provider they trust or host their own VPN. Unfortunately for people who do care about this and use Tor or a VPN, P2P realtime channels bypass the Tor/VPN and expose the IP address where it wouldn’t normally be seen based on what I read [in this thread](https://support.delta.chat/t/alternative-p2p-realtime-chat-method/3554), for example: > [@Alternative P2P realtime chat method](https://support.delta.chat/t/alternative-p2p-realtime-chat-method/3554/4): > > iroh does not respect proxy settings even when connecting to the relay, don’t use proxy settings for anonymization. > [@Alternative P2P realtime chat method](https://support.delta.chat/t/alternative-p2p-realtime-chat-method/3554/10): > > Delta Chat does not send IP addresses in email messages, only the relay address. But then it tries to establish P2P connection with the help of the relay and this may expose your IP address. > > As long as there is no “relay only” option, I suggest you disable p2p if you are really concerned about someone who you use webxdc’s with tries to find out your IP address. Therefore its not correct to recommend that the “proper solution is to use a VPN or Tor” for realtime apps because this gives a false sense of protection while leaking your IP, unless the situation has changed or I misunderstood the advice above. If the situation has changed I would be happy to learn about it but I did not see any news of this mentioned here in the forum, on the DC blog or in device messages in the app istelf. > [@WofWca](#): > > That is going to be behind an “Open this link?” dialog. Its good to know there will be a dialog tho given that some games encourage players to rapidly tap the screen, I can imagine that click-jacking attacks could still be possible if the dialog is not implemented carefully. ---
**Author:** ![fei](https://forum.delta.chat/letter_avatar_proxy/v4/letter/f/59ef9b/32.png) [@fei](https://forum.delta.chat/u/fei)\ **Post date:** [February 16, 2026, 4:43am UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/5 "2026-02-16T04:43:42Z")
I am really disappointed about this as well. Delta chat’s apps being so locked down was one of my favorite design choices. In my opinion, “users are surprised the app doesn’t work” is not a good reason to remove the option entirely. There is precedent for other options like requesting permissions from users when they have not allowed permissions. Even in Delta Chat itself, if the camera is not enabled and one goes to scan a QR code, a “Permission required” popup will appear with an explanation of the necessary permission and a quick button to open the relevant menu. ---
**Author:** ![r10s](https://forum.delta.chat/user_avatar/forum.delta.chat/r10s/32/1513_2.png) [@r10s](https://forum.delta.chat/u/r10s)\ **Post date:** [February 16, 2026, 2:08pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/7 "2026-02-16T14:08:49Z")
ftr, in addition to already mentioned “lockdown mode”, the [FAQ](https://delta.chat/en/help#who-sees-my-ip-address) also outlines the IP-Address-Question in a more holistic way: > # Who sees my IP Address? > > The used [relay](https://delta.chat/en/help#relays) needs to know your IP Address, as well as sometimes your contact’s devices if you have a [call](https://delta.chat/en/help#experiments) or use [apps](https://delta.chat/en/help#webxdc) together. > > IP Addresses are needed for connectivity and efficiency. They are neither persisted nor exposed. Note that the IP Address is not like a detailed address you give to a delivery service, but much more coarse, often defining region or country only. > > As this is just how the internet and other messengers work by default, we do not offer options here or ask upfront questions. > > If you see your IP Address as a security or privacy risk, we recommend to use a VPN, in combination with system lockdown mode. Hunting down options in all apps on your system will leave gaps. For example, tapping a link exposes IP Addresses to unknown parties and is the by far larger risk here. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 16, 2026, 3:25pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/8 "2026-02-16T15:25:24Z")
IPv6 addresses can be remarkably specific and persistent. Some ISPs seem to assign them to individual connections, making them a unique identifier of a person or household. DC’s threat model also involves actors who control the user’s ISP. ---
**Author:** ![fei](https://forum.delta.chat/letter_avatar_proxy/v4/letter/f/59ef9b/32.png) [@fei](https://forum.delta.chat/u/fei)\ **Post date:** [February 19, 2026, 4:34am UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/9 "2026-02-19T04:34:55Z")
Okay, after reading more, I tried to put together my personal concerns. Even if the changes are not a concern for most users, and even if everyone agreed it was the best choice to remove the option entirely (vs other choices like changing the description and so on), it’s still the case that the webxdc security was silently changed. At least on iOS, there wasn’t even any listing in the Version History for the app, users would have to go outside the usual places to learn that it was changed. Additionally, the reasoning that “As this is just how the internet and other messengers work by default, we do not offer options here or ask upfront questions” made me a little worried about the future because many other apps do many things that concern me without notice. For example, I was really happy that unlike many apps, Delta Chat only connects to the relevant domains on startup. In the end, I mainly want to be sure that the team will let users know of similar updates that change the security and not implement them without communication. ---
**Author:** ![peppa](https://forum.delta.chat/letter_avatar_proxy/v4/letter/p/da6949/32.png) [@peppa](https://forum.delta.chat/u/peppa)\ **Post date:** [April 1, 2026, 5:02pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/10 "2026-04-01T17:02:20Z")
> [@r10s](#): > > ftr, in addition to already mentioned “lockdown mode”, the [FAQ](https://delta.chat/en/help#who-sees-my-ip-address) also outlines the IP-Address-Question in a more holistic way: > > > # Who sees my IP Address? > > > > The used [relay](https://delta.chat/en/help#relays) needs to know your IP Address If I use Tor or a VPN, my relay does not see my IP address, but it still works normally, contrary to what the FAQ says. It is not clear why the relay _needs_ to know my IP address, as claimed on the FAQ. > [@r10s](#): > > IP Addresses are needed for connectivity and efficiency. They are neither persisted nor exposed. Some IP addresses are dynamic and others are persistent, so this part of the FAQ is very misleading. The [Wikipedia article](https://en.wikipedia.org/wiki/IP_address) for this topic makes it obvious why the information presented in the FAQ is false: > Within a network, the network administrator assigns an IP address to each device. Such **assignments may be on a static (fixed or permanent) or dynamic basis**, depending on network practices and software features. **Some jurisdictions consider IP addresses to be personal data**. > IP addresses are assigned to a host either dynamically as they join the network, **or persistently** by configuration of the host hardware or software. **Persistent configuration is also known as using a static IP address.** > Sticky is an informal term used to describe **a dynamically assigned IP address that seldom changes**. IPv4 addresses, for example, are usually assigned with DHCP, and a DHCP service can use rules that **maximize the chance of assigning the same address each time** a client asks for an assignment. In IPv6, a prefix delegation can be handled similarly, to **make changes as rare as feasible**. In a typical home or small-office setup, a single router is the only device visible to an Internet service provider (ISP), and **the ISP may try to provide a configuration that is as stable as feasible** , i.e. sticky. The FAQ does not back up the claim that IP addresses are not persistent. > this is just how the internet and other messengers work by default Other messengers also demand your phone number and force you to use a central server by default, but DC aims to be better. Why lower privacy standards in this case just because other apps do? The justification “because other messengers do this by default” is selectively applied to this case but not to other cases, so the logic is not consistent. > If you see your IP Address as a security or privacy risk, we recommend to use a VPN, in combination with system lockdown mode. Lockdown mode is an iOS feature. What do people who use other platforms do? I mentioned above that another DC dev has said that **this is not sufficient to protect your IP address** for webxdc apps: > [@Alternative P2P realtime chat method \[without revealing your LAN & WAN IP\]](https://support.delta.chat/t/alternative-p2p-realtime-chat-method-without-revealing-your-lan-wan-ip/3554/4): > > iroh does not respect proxy settings even when connecting to the relay, don’t use proxy settings for anonymization. > [@Alternative P2P realtime chat method \[without revealing your LAN & WAN IP\]](https://support.delta.chat/t/alternative-p2p-realtime-chat-method-without-revealing-your-lan-wan-ip/3554/10): > > Delta Chat does not send IP addresses in email messages, only the relay address. But then it tries to establish P2P connection with the help of the relay and this may expose your IP address. > > As long as there is no “relay only” option, I suggest you disable p2p if you are really concerned about someone who you use webxdc’s with tries to find out your IP address. Either I misunderstood the advice, or DC devs give two different conflicting pieces of advice **which can’t both be true**. If I misunderstood the advice, I would be happy if someone corrects me about this. To clear up the confusion, can we establish which DC devs are the most knowledgeable about iroh, and can they confirm the advice presented in the FAQ that simply using a VPN with lockdown mode is guaranteed to never expose your IP address when using P2P realtime chat apps, as claimed on the FAQ and on the github issue for removing the P2P realtime switch? And will this also work for people who do not use iOS and therefore can’t use lockdown mode? ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [April 3, 2026, 2:23pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/11 "2026-04-03T14:23:55Z")
Iroh leaked your IP address even when trying to use a proxy. > > > \- Operating System (Linux/Mac/Windows/iOS/Android): > \- Core Version: 2.20.0 > \- Cli…ent Version: 2.15.0 > > \## Expected behavior > > \[Calls\](https://github.com/orgs/deltachat/projects/81)' traffic gets tunneled through the set proxy, at least when the client cannot connect directly, without using the proxy. > > \## Actual behavior > > The DC clients never use the configured proxy for calls. > > \### Steps to reproduce the problem > > 1. Set a proxy > 2. Start a call > > \### Screenshots > > \Image > > \### Logs ---
**Author:** ![WofWca](https://forum.delta.chat/user_avatar/forum.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://forum.delta.chat/u/WofWca)\ **Post date:** [April 4, 2026, 11:41am UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/12 "2026-04-04T11:41:31Z")
Iroh is not used for calls. Iroh is used for WebXDC real-time channels. For calls we use WebRTC. ---
**Author:** ![peppa](https://forum.delta.chat/letter_avatar_proxy/v4/letter/p/da6949/32.png) [@peppa](https://forum.delta.chat/u/peppa)\ **Post date:** [April 12, 2026, 4:23pm UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/13 "2026-04-12T16:23:29Z")
Yes, calls use WebRTC as @WofWca said and I think we all agree this exposes your IP. But for iroh I can’t find reliable information about this. The official DC position seems to be “just use a VPN” but on GitHub [even the DC developers seem doubtful](https://github.com/deltachat/deltachat-desktop/issues/3093#issuecomment-3734285861) this will work: > With the removal of the option to turn off webxdc realtime channels ([#5925](https://github.com/deltachat/deltachat-desktop/pull/5925)), it will be interesting if iroh connections go through to tor or not, I guess they do not. > Either way would be interesting to check if iroh goes through system-wide vpn if there is any. If the developers themselves aren’t sure iroh goes through the system-wide VPN I don’t know how ordinary users are supposed to know this or have any confidence in this. When one developer is doubtful that iroh connections will go through the system-wide VPN, another developer [warned against relying on a VPN](https://support.delta.chat/t/alternative-p2p-realtime-chat-method-without-revealing-your-lan-wan-ip/3554/10) to prevent exposing your IP when using P2P realtime chat apps, and now there are also false/misleading claims on the FAQ like IP addresses “are neither persisted nor exposed”, its very hard to be confident that just using a VPN is sufficient. It would be great if somebody with expert knowledge about iroh could clear this up and give an authoritative answer. Are iroh connections guaranteed to go through the system-wide VPN and never expose your IP address to the relay or to the other people in the chat when using P2P realtime chat apps? ---
**Author:** ![if7](https://forum.delta.chat/letter_avatar_proxy/v4/letter/i/73ab20/32.png) [@if7](https://forum.delta.chat/u/if7)\ **Post date:** [September 24, 2026, 2:43am UTC](https://forum.delta.chat/t/weaker-security-controls-for-webxdc-apps-disable-p2p-realtime-channels-disappeared/4654/14 "2026-09-24T02:43:22Z")
I would echo what others have said here. This is an important setting to have control over, and I think many people would appreciate the change being reverted.