Considering the BND's (German equivalent of NSA) love of intercepting traffic and gathering metadata about citizens, I wouldn't put "funded by the German government" in the Pro column.
It may be a case of German government's right hand not knowing what German government's left hand is doing. An open source distributed framework can't be coerced into routing its messages through a central server for surveillance.
While Signal client app source is open, the server side isn't and the global system (and Moxie in particular) is notoriously hostile to federation or any sort of free interoperability. For a communication network, this reduces the benefits of openness to almost nothing, and, at least from my PoV, do not bring any kind of freedom or security to the users.
While I can imagine a free ecosystem being somehow centralized, I firmly believe that Signal is on the contrary an illustration of centralization imposed against user freedom which suggest that these properties may not be so orthogonal.
No, you need to use a library that allows the user to configure the push server, which should be configured device-wide and communicated to the app server.
One, end-to-end encrypted push service can make any intercepted data useless, as you cannot even know if the traffic corresponds to a message or is just a ping, let alone which app or contact the message is from.
I actually doubt this is the case. Pings probably happen on some relatively-predictable interval, while a back-and-forth conversation between two parties is going to result in push notifications with much shorter intervals than any reasonable ping implementation would use. The metadata might be limited in value, but it still has some value, and I think it could easily be distinguished from pings.
Sure a determined attacked with control over hardware in the network path can analyze the timing and packet sizes.
However a smart application/protocol writer could make make a ping and a message delivery take the same number of bytes. Which of course means some wasted payload on pings.
Additionally if trying to track peers you could every N seconds send a ping OR a message. After all if you succeed in sending a message you know the peer is reachable.
So it's possible, but no idea how careful OpenPush is though.
Any attacker in a position to inspect traffic in the path between a push service and a mobile device is probably determined. I agree about the countermeasures, though.
I've pondered DHT nodes for a basis privacy protecting network of peers. There's a fair bit of traffic for tracking peers. Each peer could use their peerID as a public key. A bit of padding on the normal traffic (mostly get, put, ping, and findpeer) could hide messaging.
Likely not a good fit for TCP streams (like tor), but could easily hide enough bandwidth for instant messaging (like signal) or email, er email like service. Could hide store/forwarding, include onion routing (bouncing through a few nodes), and be quite resistant to traffic analysis.
If each node send X packets of Y bytes to Z nodes per minute then it would be quite hard indeed to tell who you were talking to.
Maybe give peers a few choices in high bandwidth, medium bandwidth, and low bandwidth configurations. All would just vary in the number of nodes they track.
I see no reason make this negative link. The BMBF is a research agency which gives out grants for research through public calls (somewhat similar to the NSF in the US).
There are no strings attached, besides providing reports on scientific contributions achieved throughout the project.
It's not like the BND will come knocking on your door saying make algorithm X weak or you will not receive funding (or worse).