Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Change Causes Scramble Among Private Messaging App Makers

theinformation.com

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#61

Post by oneplane »

comex wrote: post #31

Note that the intended replacement API has been available for three years: https://developer.apple.com/documentation/usernotifications/... According to Moxie, it does have a downside. Notifications must be marked as either displaying an alert or as silent. Silent notifications are invisible to the user, but can be read by the app; Signal uses them for things like typing indicators and read receipts. With the new API,…

But why is it a problem that the app must be running to decrypt the silent notification? The user doesn't know about it and won't know about it until the app is opened, but then the app is already open and can process the notifications.

As a user I really would not care if the 'read receipt' or 'is typing' notification is unavailable to an app while I'm not using it anyway. And when I'm using it, I don't see a problem with the app having to process some notifications in a different thread and update the UI accordingly.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#62

Post by oneplane »

lacker wrote: post #37
eridius wrote: post #17

It's pretty weird how the article doesn't even bother to mention that Apple has an official API for doing encrypted notifications, and I really have no idea why these apps are abusing the VOIP stuff instead of using the actual encrypted notification feature. The article quotes someone as claiming APNS isn't reliable, but with zero evidence, and it seems pretty darn reliable for all of the non-encrypted apps using it.

In Apple's API you can send an encrypted message and have the app decrypt it. But you can't send an encrypted blob of data and have the app decide whether that blob of data was a message to be shown to the user, or a different sort of data like a read receipt. So the server needs to be able to differentiate the types of data packets sent from user to user, in order to use Apple's notification API, which is less priva…

And that would be a problem if having 'is typing...' and 'was read' notifications had to be pushed realtime to an app that was in the background. What is the point of those notifications arriving in the app when the user isn't using it.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#63

Post by saagarjha »

oneplane wrote: post #61
comex wrote: post #31

Note that the intended replacement API has been available for three years: https://developer.apple.com/documentation/usernotifications/... According to Moxie, it does have a downside. Notifications must be marked as either displaying an alert or as silent. Silent notifications are invisible to the user, but can be read by the app; Signal uses them for things like typing indicators and read receipts. With the new API,…

But why is it a problem that the app must be running to decrypt the silent notification? The user doesn't know about it and won't know about it until the app is opened, but then the app is already open and can process the notifications. As a user I really would not care if the 'read receipt' or 'is typing' notification is unavailable to an app while I'm not using it anyway. And when I'm using it, I don't see a proble…

The complaint is that that the server now needs to know the difference between the types of messages passing through it.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#64

Post by freeone3000 »

oneplane wrote: post #62
lacker wrote: post #37

Earlier quoted context omitted.

In Apple's API you can send an encrypted message and have the app decrypt it. But you can't send an encrypted blob of data and have the app decide whether that blob of data was a message to be shown to the user, or a different sort of data like a read receipt. So the server needs to be able to differentiate the types of data packets sent from user to user, in order to use Apple's notification API, which is less priva…

And that would be a problem if having 'is typing...' and 'was read' notifications had to be pushed realtime to an app that was in the background. What is the point of those notifications arriving in the app when the user isn't using it.

The sender of these notifications doesn't know that the user has closed the app. What this means is that the message send from the sender through the server now has to include whether this is a message or a non-message, which has to be a flag in plaintext.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#65

Post by crummy »

EGreg wrote: post #56
lacker wrote: post #35

This article doesn't quite explain what's going on as much as I would like, so maybe I can add some more detail. The key problem from an app developer's point of view is that the iOS push notification API doesn't just let a server send an encrypted blob of data to a user's app, and have the app handle it locally, deciding whether it needs to display a notification to the user. What the iOS push notification API does…

I am a developer of a messaging app downloaded so far by 5 million users around the world. I was very concerned about this news and looked into it. Apple is simply doing away with silent push notifications through the VoIP API. Apps can still register an extension that will process arbitrary push notifications that result in a visible notification to the user. If the application needs to silently send something to th…

Could Apple have slowed down VoIP notifications before, to negatively affect FB messages vs iMessage?

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#66

Post by GeekyBear »

lacker wrote: post #35

This article doesn't quite explain what's going on as much as I would like, so maybe I can add some more detail. The key problem from an app developer's point of view is that the iOS push notification API doesn't just let a server send an encrypted blob of data to a user's app, and have the app handle it locally, deciding whether it needs to display a notification to the user. What the iOS push notification API does…

When the user is not running the app, what is the use case for the app waking up and processing data that is not an incoming message to be delivered to the user?

Facebook was using the VOIP framework to burn so much power after the user had quit the app that you would see articles pointing out that deleting the Facebook app could double the battery life of the device.

>Deleting This 1 App Can Literally Double Your Phone's Battery Life

https://www.inc.com/john-koetsier/deleting-this-one-app-can-...

If I am not running a messaging app, the only power draw I want to see from that app is decrypting an incoming message intended for delivery.

Anything else can wait until I next open the app.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#67

Post by Andrew_nenakhov »

In short: apple is breaking the only reliable way to deliver notifications. We're making an xmpp app and this breaks everything: regular silent notifications provided by apple work like shit.

We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#68

Post by vonseel »

Andrew_nenakhov wrote: post #67

In short: apple is breaking the only reliable way to deliver notifications. We're making an xmpp app and this breaks everything: regular silent notifications provided by apple work like shit. We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.

By “work like shit”, what exactly do you mean?

Slower delivery? Unreliable delivery?

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#69

Post by vonseel »

hombre_fatal wrote: post #26
jakear wrote: post #15

Earlier quoted context omitted.

Not a parent, but a recent kid, and I’d hate my parents having that kind of control over me. Though I guess I’d just turn off the phone. Which then makes me even more unreachable than if the tracking had never been instituted in the first place.

Running away from school is pretty serious. When I was a kid, I'd expect some serious repercussions from my father if I did such a thing. The phone just made the consequences arrive sooner, but it's not the root of the issue. And the commenter didn't give us nearly enough information to judge them, so let's not.

It doesn’t sound like anyone is judging here. And I agree, I would hate being tracked on my phone. I don’t share my location permanently with anyone. That just seems odd for adults to do. I was a kid before all of this was possible, but I’ve seen the tracking relatives have on their kids and it abhors me.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#70

Post by floatingatoll »

Andrew_nenakhov wrote: post #67

In short: apple is breaking the only reliable way to deliver notifications. We're making an xmpp app and this breaks everything: regular silent notifications provided by apple work like shit. We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.

What non-UI-resulting notifications does your app need to deliver that, as a user, will negatively affect the quality of my experience when not delivered through the VOIP method?

Why, as a developer, did you find that non-VOIP Background Data Refresh failed to meet your needs for creating a viable user experience - and what needs did it fail for?

Post reply on HN