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.
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
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,
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 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, for example:
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.
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.
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.
ftr, in addition to already mentioned “lockdown mode”, the FAQ also outlines the IP-Address-Question in a more holistic way:
Who sees my IP Address?
The used relay needs to know your IP Address, as well as sometimes your contact’s devices if you have a call or use apps 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.
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.
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.
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.
Some IP addresses are dynamic and others are persistent, so this part of the FAQ is very misleading.
The Wikipedia article 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:
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?