Add Lockdown Mode

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 in which many features are disabled. I don’t propose to tie this to iOS Lockdown Mode, from a quick search it seems the apps are not supposed to react to OS-wide lockdown mode as there is no official API and only unofficial ways to detect it.

I originally thought about having some mode that is not enabled permanently, but something user can enable in case of “attack” (receiving spam, being added to unwanted groups etc.) that they don’t want to deal currently, in this case this feature may disable more things, like automatically ignore all contact requests so it is possible to keep chatting in existing chats without having to deal with the problem immediately.

3 Likes

Another idea would be to have a security slider like Tor browser. This UI offers users a simple way to balance security needs with desired functionality. For example Delta Chat could have a “high security” level, a “maximum functionality” (low security) level, and “custom” for when the user changes individual settings.

The “high security” level would disable calls and P2P in webxdc (I’m not sure what is the security benefit to disable all webxdc apps completely and I don’t know anything about the third party libraries for animated images playback, I guess they should also be disabled). And maybe Google’s unaudited FCM code blobs should also be considered here.

Ideally calls and even P2P in webxdc would get proper Tor support in future but until then it would be nice to have a simple way to disable them.

I wonder if an entire “mode” is the way to go, rather than granular per-feature controls. Just show warning dialogs (with a “don’t show this again” checkbox) when launching a WebXDC app or starting a call for the first time. Similar to “load remote content” in the HTML email viewer.

2 Likes

I favour granular controls. If I am being harassed through contact requests, say, I might want to queue them silently instead of getting notifications, but still have P2P calls with existing contacts. @WofWca’s suggestion of initial warnings makes sense, with a menu buried in the settings for changing setting later if needed.

“Balance” language is often used to present false choices (“We must balance privacy and child protection”, or “climate and the economy”). Each individual function may have security risks, but that is down to the design tradeoffs of the individual function implementation. For instance, when I said P2P could rather intrinsically leak IPs, I did not mean that it was impossible to do P2P over Tor or I2P, which would hide IPs. The UI should avoid presenting tradeoffs as though there are no alternative ones; I think a security-functionality slider implies a tradeoff which is not unavoidable.

Deltachat after all is both more secure and more functional (in terms of reliability) than alternatives. :slightly_smiling_face:

1 Like

Yes the examples you give about child protection and the economy are false choices but that’s not the case here. Any person who uses DC today has a clear choice between using functionality like calls and P2P realtime channels for webxdc and exposing your IP address. That’s not a false choice.

Sure devs could improve the implementation and make it more secure if they have resources to address it which is why I wrote:

There is a tradeoff today and alternatives do not yet exist. If the UI pretends otherwise then that is a deceptive UI. If the UI warns users of the risks and gives them an easy way to manage that risk by disabling features with higher risk then that is a honest UI which informs and empowers users to make the right choice for their situation.

Completely agree! But the tradeoff is granular and implementation-specific; the info and choices should be too. I was just opposing lumping together a bunch of different features on a subjective privacy-security spectrum, and having a single slider to control them all. I think that would mislead and disempower the user.

I can see pros and cons both to the granular and non-granular approach, but importantly both approaches let users opt in to features with more risk, while the current implementation does not inform or warn users of risks and puts responsibility on users to opt out of features with more risk, one at a time, which is the worst approach from the security point of view, as the user can easily miss something and forget to disable something or not know which features have more risk. Even long term users need to do research with every app update if there are new features they need to disable which is very inconvenient.

A slider would not stop users from changing individual settings, this would set the slider to “custom” level.