messaging
messaging copied to clipboard
w3f
Requirement: Designed with mobile / resource restricted devices in mind
In order for the protocol to be useful for heterogeneous devices, it's probably a good idea to consider what running on mobile would look like. Some of these concerns are addressed by the underlaying layers.
Some considerations:
- Internet connection is unstable and mostly missing
- CPU resources are limited
- We can't stay in background for a long time
- We are behind very strict firewalls that makes it hard for NAT to pass through
Agreed.
Internet connections being unstable play havoc with firm anonymity assurances, but that's unavoidable. We could perhaps adjust the cover traffic to make bursts of packets less suspicious, not sure.
There are avenues to reduce CPU load by building some packet headers and SURBs en mass when charging, well anything not destined for the handset. We should also design an "extreme QoS" scheme in which multiple "less important" messages get packed into a single "important" message to the same recipient. We might just be fine if apps actually transport less data, due to the privacy goals, including packet size restrictions and small messages seeing an effective higher priority due to the packing.
Can you explain this background restriction? Is this normally addressed using the notification server run as a party of Google play or whatever Apple does? There are two solutions here:
- Signal runs fine without Google Play, and hence without a notification server, so operating in the background is possible in Android. Almost nobody else does this. I must periodically spawn apps like WhatApp, Wire, etc to receive messages, as my phone uses Copperhead without Google Play.
- Linus Lotz wrote a privacy preserving notification server in Rust for his masters thesis. I've wanted to push him to continue the project for numerous reasons, like providing a notification server for devices not using Google Play, or acting as guard nodes for a mixnet. Interesting question: Could some privacy preserving notification server to use or hijack Google's own notification server tooling, so that people with Google Play need not run a second notification server task?
We do not want I2P's "everyone is a relay" approach anyways, so NAT sounds irrelevant for mobile, except.. I expect security mistakes in libp2p's secio, making all existing libp2p transports insecure. In theory, they'll add QUIC which requires TLS 1.3, but uses UDP which sounds problematic. We want a libp2p transport using TLS 1.3 over TCP anyways though.
Background restriction:
-
On Android it is definitely possible, but it's expensive due to maintaining a lot of p2p connections. E.g. see https://github.com/status-im/status-react/issues/6447#issuecomment-431849660. The difference with Signal is that (I assume) they use some basic JSON API, which is much more lightweight than what devp2p requires.
-
On iOS the process suspends by default, and IIRC can only be woken up by remote push notification. E.g. see https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_updates_to_your_app_silently - this mean it wouldn't use an existing P2P overlay network. IIRC This is the problem Briar is facing, at least at last CCC talk. There are some ways around this that we are exploring https://github.com/status-im/swarms/tree/master/ideas/086-push-notif-v2#flow-diagram-11-chat but generally speaking they rely on a trusted node (~provider) that knows how to reach a specific device.
That said, I'm not convinced something like push notifications should be a consideration at the mixnet layer. But IMO every node (incl mobile) should have the option to be a relay, even if that means it is expensive and can only run on e.g. Android. In practice it is likely mobile nodes will operate in a light mode.
Is there any value in mobile relays? I think Tor culls poor performing true relays, but Tor Browser never relays. I'd think mobile relays hurt us even more by being unreliable.
As a rule, you want users contacting only a few "guard relays" because if many packets go to the same malicious contact then sending them through many different first hops creates attacks.
We can leave push notification servers for future work of course, but push notification servers are fairly compatible with being "guard relays", so "maintaining a lot of p2p connections" sounds unnecessary.
It's not great for a "guard relays" to communicate with users through non-anonymous push notification servers run by Apple or Google, but not the end of the world either.
(1) Regarding the energy efficiency and keeping network connections. I wrote about it here, the problem is the wireless radio that never goes to the power-safe mode with devp2p.
(2) In iOS there is also Background App Refresh, though it might be disabled by a user or disabled when the phone is in power-savings mode.
(3) Regarding this.
Signal runs fine without Google Play, and hence without a notification server, so operating in the background is possible in Android.
Yes, it is possible to hack the system and use Android Services to keep some part of your app restarting every time it was killed by the system. There are also hacks on top of that, that use different types of system internals (Broadcast receivers, NDK hacks) to make these services "unkillable" (aka restarting always after they are killed no matter what resource restrictions are there). Though, that is an abuse of the OS mechanics and it will drain the battery very-very fast.
(4) The biggest issue to my eyes is that. Generally, mobile platform are "mostly disconnected". Essentially, then the app is woken up in background, you have a very short time budget to download data. It works quite fine if you have a centralized service (you do a DNS exchange+SSL handshake+download a JSON/Protobuf data). This exchange is short.
In p2p world, if you have to discover peers, connect to them, download data and verify it somehow, it usually take much longer. And you can't just keep open connections in background because either it is impossible (iOS) or will make a breakfast-frying-pan out of a user phone (Android).
I'm unsure how Signal runs without Google Play Services but the battery life seems acceptable. It's also possible Signal exploits that it takes over being your SMS app.
As hinted above, there could be p2p aspects of how these mix clients relate to the network's key infrastructure, choose their guards, etc., but really they should interact with their guards more like centralized services.
I'm unsure how Signal runs without Google Play Services but the battery life seems acceptable. It's also possible Signal exploits that it takes over being your SMS app.
Yeah, just running a service by itself doesn't make you drain your battery. But running a service that keeps a p2p connection with heartbeats open will. So, if, say Signal just re-syncs with a server every 40-50 seconds or so, it would be fine in terms of battery consumption. Implementation details is everything in that case.
Discussed during Brussels workshop; close this issue once reflected in the requirements.