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.

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.

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.

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.

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?

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 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 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.

It is quite insane how Apple filters entitlements and denies usage of them in a seemingly arbitrary way...