Security and Third-Party Transports

A couple of weeks ago, news broke that governments might be spying on push messages delivered through Apple’s push notification system or Google’s Firebase Cloud Messaging.

(hat tip to Prof. Matthew Green for raising awareness)

IMHO, governments are only part of the problem. Apple and Google can read your push messages. While both firms claim that messages are encrypted, that is only for “data in motion”, as they are sent over the Internet. Messages in their servers are unencrypted. Not only can they access the data, but they can hand it to whoever they want to, not just governments.

While the current focus is on “Big Tech” push message systems, the problem is more general than that. Any third-party data transport system has the same sort of problem. Services like PubNub, Amazon SNS, Stream, and others that offer “publish/subscribe” and similar sorts of message-based APIs are very useful, but generally their data is encrypted in motion and not at rest. Those firms can see your messages, as can anyone that those firms allow.

Roughly speaking, I see two main ways of addressing this.

The best is to not send anything of significance in the message itself. Use it as a trigger mechanism only. So, the message might contain some sort of verb identifying what it wants the app to do, but nothing else. The app would then use other communications options (e.g., Web service calls) to do whatever it is the trigger is requesting. This allows you to focus on securing those other communications options, and you care less about spying on your messages.

The other is to encrypt your message payloads so that only the recipient can read them. This can work, but key management is a pain as always. IMHO, use this approach only if the messages do not require any other communications to be useful — if you are going to have to make a Web service call anyway, there is little value in packing data into the message itself.

Neither of these approaches help much with metadata. The message system providers (e.g., Google) and their favored partners (e.g., governments) can still examine which apps are getting messages, at what times and for what accounts (e.g., Google accounts). The only way to avoid that is to avoid using a message system provider, such as hosting your own messaging server. That has its own problems (e.g., background process limits in Android).

Using a push message system provider often is unavoidable. Letting them have your data is avoidable, by encrypting that data or not having any meaningful data in the messages themselves.