Comment by robbiet480
2 years ago
We at the Home Assistant Companion for iOS team have been wanting to implement end to end encryption for our push notifications for a while now but Apple has denied our request for the com.apple.developer.usernotifications.filtering [0] entitlement multiple times. Wondering if with today's news we could apply again and get it.
For context, we are sending ~35 million push notifications per month on iOS and ~67 million on Android, see more at [1]
[0]: https://developer.apple.com/documentation/bundleresources/en...
[1]: https://threadreaderapp.com/thread/1721717002946191480.html
We implemented APNS encryption for Firefox iOS without much trouble. Keys are negotiated out of band and message decryption is done in a Notification extension that allows you to pre process incoming notifications. Did not need any special entitlements.
Source code on GitHub.com/mozilla-mobile
Maybe their keys are safer than yours?
Not saying you are obviously compromised, but the simplest explanation after this news is that maybe they relay the authorization to NSA et al, and they OK'ed your case and not theirs for some reason...
The simplest explanation is that reviewer A was responsible for Home Assistant Companion's request and reviewer B was responsible for Firefox's request, and they judged the request differently. Or that implementation details made the two cases different. Or that the company policy changed over time between the two requests. "Apple can break Firefox's encryption so they happily allowed it" is certainly not the simplest explanation.
The simplest explanation is not that Apple is colluding with multiple national government's intelligence agencies which all specifically agreed to a conspiracy against Firefox's mobile browser notifications.
1 reply →
Just curious, why do you need filtering permissions for your use case?
Decrypting a push notification appears to be supported using 'mutable-content' with a notification service.
In fact that is the example used here: https://developer.apple.com/documentation/usernotifications/...
The filtering entitlement allows us to decrypt messages and, depending on the content, choose to not send any notification (for example if a user sends an app specific command, like asking for a location update). The example you linked requires that a notification is emitted at the end, which we don't want.
Zac also just let me know the other reason we need filtering is so we can properly unsubscribe users from notifications when one is received from a server they no longer are connected to.
for my understanding, you need that entitlement so you can send an encrypted invisible notification which you can then decrypt locally in your app and push out again as a local notification that doesn't go over the network (i.e. not use apns)? Or is doing this kind of stuff just weirdly tied to that specific entitlement?
Correct, we need to be able to filter to properly unencrypt notifications and pass them on as a local notification.
No, you do not need this just for decryption. This entitlement is only required if you want your Notification Extension to be able to silently eat the notification. Normally an extension must transform the notification then the system presents it to the user.
APNS is not a "let my server wake up my app in the background whenever and however often I like" mechanism.
Defer handling other things until either your extension or your app would have run anyway and do them at that time.
When you're transforming the push notification, can you make an https request?
Send a meaningless random ID, then do a get request to your API to get the actual content, then present it to the user.
Only a meaningless ID will transit through google/apple servers.
Honest question. I'm sure many thought about it before.
3 replies →
[dead]
Naive question: why not remove all sensitive data, or all data, from the notification and leave the context for a secondary API call?
Yup that is also a great way. Just send a message ID and fetch the actual content in the notification extension that can pre process incoming notifications.
I may be misreading the article, but does it seem like it alludes to metadata- and timing-related analytic techniques, rather than the contents of the notifications?
“...for metadata related to push notifications to, for example, help tie anonymous users of messaging apps to specific Apple or Google accounts.”
So maybe more, they (or somebody) send some messages to this account they want to ID, then request the specific device identifier that received notifications for that app at all of those times?
Would obfuscating the content make much difference with respect to that category of technique?
It is quite insane how Apple filters entitlements and denies usage of them in a seemingly arbitrary way...
Are the ones on Android encrypted i wonder? I hope so
They are not currently as we need to roll out e2ee with iOS and Android in lockstep as they both use the same mobile_app component as well as the local push stuff which bypasses Apple and Google but we would also like to encrypt.