[turdnagel]

Came here to say the same thing. Even this description is _really_ light on details.

I'd love to see a technical breakdown of this problem. iOS 13 has a background task API - why can't that be used?

Incoming notifications can trigger application code to run - why can't that method be used?

[lacker]

iOS 13 has a background task API - why can't that be used?

The iOS 13 background task API limits your background tasks to a few minutes. So, they're useful for short batch tasks you don't want to interrupt when the app closes, like cleaning up a database. They aren't so useful for listening for a notification that could come after hours of inactivity.

Incoming notifications can trigger application code to run - why can't that method be used?

This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.

So, this isn't the end of the world, but it will hurt the privacy model of non-iMessage private messaging apps.

[prophesi]

Honestly, in terms of privacy, I think it's a decent trade-off (from what I gathered from this sparse article).

PushKit

Pros:

- Apps and their servers can be developed in a manner wherein the server doesn't know if it's sending a message or a read receipt (aka, no metadata leak).

Cons:

- "[...] developers could also use PushKit to collect information about the location of users and other sensitive data"

So with the traditional Notifications API, you lose that pro, but now _all_ of your apps with potentially ill-intentions can no longer glean your location and other data.

Edit: Though, another huge con to this is the amount of dev hours to abide by this change. It's already a pretty sizable engineering task to create a fast, secure, and end-to-end encrypted messaging app.

[JustSomeNobody]

> This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.

I guess I still don't get it.

A notification comes into the iPhone. iOS wakes the app. The user clicks the notification, the app opens, the user reads the message and the app sends a read receipt to it's own servers.

A new message would just be a new message. The user would type it and hit send. The app would send it to it's servers which would then use the push api to send a message to the recipient.

Edit: Ok, I get it. The point is one doesn't want a server knowing the difference between the two types of messages. That's a leak of metadata.