There are a few problems with delivering alerts via SMS, but they mostly boil down to this: SMS is not very private.
For vulnerable audiences, it’s preferable to not collect any subscriber information at all. This isn’t possible with SMS, because you have to know the recipient’s phone number to deliver a message. Unless you’re talking about burners—which most people won’t have—that phone number is tied to a real identity. This is a vulnerability in at least these scenarios:
- If the alerting app itself gets targeted (whether by LE or other malicious actors), user-identifying information could be leaked.
- Phone companies cooperate with LE, through legal process (subpoenas) or otherwise, to find out which phone subscribers are receiving SMS alerts.
- LE , IC, or well-resourced hackers snoop on the SMS network.
Privacy by Design is a set of principles for thinking about user privacy throughout the design and implementation of information systems.
Can we provide alerts without knowing anything about subscribers? I think the answer is yes, if we let the device do more work.
Instead of sending directed alerts to individuals, we can instead publish the entire verified-alert database, which each user’s app will download. This database should be fairly small, and can be compressed to preserve users’ bandwidth. The app will then decompress the package and load the database, geolocate the user, and determine whether any new alerts are relevant to the user. If so, it can then issue a local notification.
Privacy benefits:
- No user information is collected in a subscriber database.
- No information goes through SMS.
- No push notification is sent across the network or touches Google or Apple servers.
- No geolocation data leaves the device (not even a ZIP code).
- All network traffic can be encrypted.
It’s true that the user’s IP address and other information might be logged by the server that’s distributing the database. If the server is self-operated, this is easily controlled by changing that server’s log retention. (But, see below under Threats for tradeoffs regarding this approach.)
Both iOS and Android make it possible for apps to run in the background. We can use this functionality, and have the background process do all this work, including polling the server periodically to see if there is an updated database (which should be one simple HTTP HEAD call).
Additionally, the app could register for push notifications. But instead of sending notifications with user-specific data, the only notification that would be sent would be a “silent” notification to tell the background process that new data is available. The app would then download the compressed database and go to work as described above. In this scenario, a push notification does go through Apple or Google servers, but it has no user-specific content. It’s worth exploring more whether this is necessary.
Apple developer documentation: see “Configuring a Silent Notification” heading https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html
Firebase Cloud Messaging is a cross-platform way to deliver silent push messages to iOS and Android. (It piggybacks on Apple's APNs push notification delivery system for iOS.) https://firebase.google.com/docs/cloud-messaging/
Even with this design, there are still points where user data is collected, or could (potentially) be compelled to be collected.
Because the app connects to a server to download the alerts database, this connection to the server will be a point of interest. While the server operator can turn off logging, it's conceivable that the operator could be compelled by legal process to turn logging back on. And while the content of connections could be encrypted using TLS, the fact that connections were made would be observable by an eavesdropper.
Instead of self-hosting the database package, hosting it on another popular domain with TLS helps guard against eavesdropping. Even if the connection is observed, it would look like every other encrypted connection to google.com or amazonaws.com.
The tradeoff is that this hosting provider's logs may be subject to legal process. However, on balance, because the database package itself does not contain any contraband data and should not itself be deemed incriminating, I expect these hosting providers would be able to mount a successful defense to an attempt to obtain them indiscriminately. However, this is still a risk.
If push notifications are used to wake up the app, then users' identities will be associated in some manner with the app in Apple and Google logs. This means using the app will not be fully deniable by app users, assuming those records can be obtained. This is still far, far better than SMS, which is run by phone companies. Apple and Google have good track records on both security and standing up to overreaching government data requests. Phone companies, on the other hand, are uniformly terrible.