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]
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.
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.
You clearly do not work on the field. There's an industry for that. It's not uncommon as you think.
Consulted for a company who implemented access logs for law enforcement to telephone records. A friend works at ring just fetching data from the DB for the legal team after they receives pro forma requests.
And those are the regular cases since the 80s. with judges from regular courts. If there's a law those companies must follow they will implement the same systems as they had for other laws. Only that these new ones prevent them from discussing. That's the only difference. the rest is banal day to day from legal and the industry that exist to sell compliance services to them.
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?
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.
You can do quite a few things - it’s not a widely written about area of development (relatively speaking) but you have a surprising amount of stuff at your fingertips.
I built a finance app a few years ago that would take market data via a push notification, and then the transform extension would render it to a chart image and attach the image to the notification to avoid generating them server side.
> You can do quite a few things - it’s not a widely written about area of development (relatively speaking) but you have a surprising amount of stuff at your fingertips.
I would pay to commission a blog post on the topic if you’re willing to write it.
I unfortunately don't have time to do that, but I believe the Guardian did a similar trick some years ago for election result updates. Try googling around for that, it's very interesting reading.
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?
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.
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