
Apple Change Causes Scramble Among Private Messaging App Makers - ballmers_peak
https://www.theinformation.com/articles/apple-change-causes-scramble-among-private-messaging-app-makers?pu=hackernewsff2o9j&utm_source=hackernews&utm_medium=unlock
======
lacker
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_ let you do is send an encrypted
notification to a user's app, and then if the user is going to see this
notification, have the app locally intercept that, and decide what exactly to
display. So for an encrypted messaging service, you can send the encrypted
message, and have the app locally decrypt it.

The difference is that the push notification API doesn't let you send push
notification data that won't be visible to the end user. So to use this API,
your server needs to know that a user just received a message. It can't send
out something like an encrypted blob that could be a received-message or could
be a different sort of encrypted message like a read receipt, and let the app
decide locally. This isn't optimal for a private messaging app - ideally the
server wouldn't have to be able to distinguish your received messages from
other metadata. This is similar to phone call metadata leaking, where even if
someone can't eavesdrop on the content of your phone calls, you still don't
want them knowing precisely when you made a phone call.

So one weird thing about iOS is that the VOIP APIs did give you ways to
silently send an encrypted blob of data from a server to an app. This
functionality would be logical in the push notification API, but the push
notification API didn't support it and the VOIP API did, so developers started
using the VOIP API for it.

It makes sense that Apple wouldn't want the VOIP API used in this way. But
secure messaging apps have a legitimate reason to silently transfer encrypted
data from server to application. Making this impossible will weaken the
privacy that apps like Signal can offer, not improve it, because Signal will
have to know a little bit more about your messaging behavior in order to send
you push notifications.

~~~
EGreg
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 the app, it can do so
with background modes, such as sending a push notification via PushKit with
content-available: 1. The OS then schedules when the download may happen. If
the download doesn’t happen before the app is started, the app can simply send
a request at that time and download it, just like any other content-available
thing.

There is no legitimate use I can think of for silently sending data using VoIP
push except when you’re on a call and you want to send WebRTC type data (eg
say someone joined the call).

But here is the kicker: PushKit notifications are reputed to be delivered on a
lower priority basis than VoIP notifications. And that’s the big thing. Apple
can simply slow them down to make FB messages arrive slower than iMessage for
example.

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

~~~
azinman2
While I don’t work on this at Apple, I’ve never once heard of anything being
designed to punish a competitor like that.

------
comex
Note that the intended replacement API has been available for three years:

[https://developer.apple.com/documentation/usernotifications/...](https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension)

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, if a notification is marked as
displaying an alert, the notification extension gets a chance to modify (i.e.
decrypt) the content, but the end result must be an alert of some sort. If
it’s marked as silent, the notification extension doesn’t run at all: after
all, the data isn’t used for anything until the app asks for it, which can
only happen if the app is actively running, so the app can just handle
decryption itself. And if notification extensions were allowed to trigger on
silent notifications, app developers could send meaningless notifications to
keep their apps running in the background without the user’s awareness – the
same issue Apple is trying to address by cracking down on PushKit.

The problem is that the flag for whether a notification is silent or not is
visible to Apple’s server, whereas Signal wants to keep even that one bit of
information hidden behind its end-to-end encryption.

[https://twitter.com/moxie/status/1159127482143875072](https://twitter.com/moxie/status/1159127482143875072)

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

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

~~~
oneplane
Well yes, but that's only the case if the app insists on communicating this
type of data using the background push api.

------
portmanteaufu
This article is terrible. The change mentioned in the headline isn't explained
until the fifth paragraph and beyond.

> Apple’s change involves an API called PushKit, which was originally designed
> to be used in apps that let people make online phone calls using voice over
> internet protocol. .... Over time, many apps began using the tool for
> purposes other than Internet phone calls, including encrypted messaging apps
> that found it was the best method for decrypting messages in the background
> on iPhones. .... But app developers could also use PushKit to collect
> information about the location of users and other sensitive data, which
> concerned Apple. .... With iOS 13....the company is finally cutting off
> developers from using PushKit for any purposes other than internet phone
> calls.

~~~
msie
Wow, and to think of all the times I've held myself back colouring within the
app guidelines. Meanwhile other app developers are abusing the apis to no end.

~~~
Icathian
Well sure, but on the other hand now all your stuff isn't broken. Give and
take, I think.

~~~
AmericanChopper
Had a similar situation once. Apple announced a rule change that impacted our
business. We talked to them and realized we had to suck it up. We spent 6
months completely redesigning our app to fit in with the new guidelines.
Meanwhile we found out our competitors spend 6 months doing nothing but
complaining to Apple. Apple reneged on the change. We lost 6 months dev time
trying to comply with the new rules in good faith, our competitors spend those
6 months doing their regular work on new features.

~~~
pfranz
Working the refs works way more often than people think.

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

~~~
lacker
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 private.

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

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

~~~
oneplane
But why use background notifications for this type of data in the first place?

------
jjtheblunt
The title is (inadvertantly?) misleading, since the aforementioned private
messaging app makers are only inconvenienced because they were knowingly
misusing an API for which an incomplete API existed.

So, as Apple updates APIs, they're having to repay their own knowingly-
incurred technical debt to stop using what was the only thing working, a
workaround, before.

------
joecool1029
Hm. I think I'm already seeing SMS/VOIP apps show bugs that are trying to
comply with the changes. Google Voice app keeps showing last missed call
notification every time I open the app. (I have the app set to do calls over
circuit switched instead of data). I also noticed there was a recent move on
T-Mobile digits to move to data calling in their app on iOS.

It's definitely causing problems _now_ on 12.4.1 because it's a behavior shift
that app developers have to get done before 13 drops.

Apple forum thread on behavior:
[https://forums.developer.apple.com/thread/118607](https://forums.developer.apple.com/thread/118607)

------
floatingatoll
Previously on this same topic, 29 days ago:
[https://news.ycombinator.com/item?id=20629567](https://news.ycombinator.com/item?id=20629567)

------
skybrian
Innovation is often about using things in ways that were never intended. This
often conflicts with the ability to police other people's behavior.

Maybe the resolution in this case would be requiring notification decryption
to be open source with a verified compile, so Apple (and users) can see what
the code does?

Users need privacy, code doesn't.

~~~
RandallBrown
People were using APIs in a way that wasn't intended, so Apple built APIs for
the new use case. Seems like a pretty good way to handle the problem, without
requiring a bunch of people to verify code.

------
laythea
I'm not an expert here, but if the problem is battery life (?), then surely
the apps that abuse this will be outed by the users who will, by definition,
see the battery getting drained faster.

Apple, how about a battery-energy per app usage display so the users can
detect apps that call home/abuse battery usage, and then they can remove them?
Is this something that already exists? I would suspect not, as then apple's
own apps may get outed! The user could set an energy usage threshold and be
told/warned that an app is misbehaving.

~~~
colejohnson66
I don’t understand the cynicism; That feature already exists. It’s under
Settings > Battery. And users really don’t care. Facebook uses a ton of
battery and people keep using their app.

~~~
laythea
The article says "Apps that exploited PushKit could drain iPhone batteries,
Apple said." and "The basis for doing this is battery savings"

------
ajconway
Apple removed the ability of app developers to use the (somewhat) reliable way
to deliver events to apps without alerting the user.

There’s API that lets an app to decrypt visible notifications, but it’s
incredibly limited (it will crash if the process uses more than 5 MB if RAM,
if I remember correctly). This presents unique challenges as the app’s code
also takes up RAM.

There’s also an old API that enables developers to silently wake up the app in
background, but it’s highly unreliable (it won’t work more than 3-5 times per
hour or so). This one can still be used for tracking.

------
mickael
The notification are for signaling. The message notification can be distinct
and encrypted using standard push notifications. If the problem is with
metadata around the conversation (like typing indication, etc), they still can
be encrypted on the server but with a cleartext flag associated with them to
tell if the content should be pushed or not.

~~~
Andrew_nenakhov
You do not want any kind of cleartext alerts on read receipts or typing
notifications. Most people also don't want apple to know what type of data is
transmitted to your app.

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

~~~
floatingatoll
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?

~~~
Andrew_nenakhov
There is a lot of traffic in xmpp that is not message. Like, delivery / read
receipts, carbon copies, etc. It's often fully encrypted and a server doesn't
even know the contents and if it should or not be showing anything for this
event: it just has to tell an app to wake up, fetch messages, let it decide
what to do.

With this change, we're left with 2 notification methods: one that always
presents a notification banner (resulting in EXTREMELY BAD user experience -
banner on every read receipt, on every your own message sent from every
device, etc), or one that is extremely unreliable: it is delivered badly if a
user is low on battery, and never delivered if a user swipes an app away.

~~~
floatingatoll
So, I’m going to translate this because it will sound different in another
phrasing. This will sound judgmental, but I want to present the contrasting
view that Apple likely holds here, rather than a sympathetic ear (as many
others have provided that service already). No insult or harm is meant, and I
have made no effort to look up what your app does, so this isn’t personal at
all. Here goes.

You’re willfully circumventing iOS guidelines regarding Background App Refresh
in order to provide an experience that breaks two enforced behaviors that
Apple imposes on all apps.

First, in low battery mode, iOS reduces the frequency of non-alert
notifications in order to conserve power by reducing cellular traffic
frequency, often to the point of batching to once a minute or more. By
overcoming this behavior with the VOIP framework, you bypass the intentional
battery life protections Apple has built into the operating system.

Second, iOS enforces that no invisible background refreshes may occur once
apps are force quit%, unless and until they are reopened. You willfully are
circumventing this restriction that was put into place to respect user
intentions to “quit” an app by using the VOIP framework to perform background
activity even after your app is quit.

Both of these actions are taken with the express intent of breaking the
constraints that the Background App Refresh system places on all iOS apps, in
order to deliver an experience that has no “Fetching latest changes” delay
when the app is next opened, either during low power mode or after a force
quit.

Apple had the right to terminate your app from the App Store altogether in
response to this violation of their background app refresh guidelines, as they
make clear that their guidelines are not the sole and exclusive definition of
the boundaries of acceptable behavior, and are generally unfriendly towards
those who exercise loopholes to the detriment of their designed experience.

For whatever^ reason, Apple instead gave everyone three months warning that
this Background App Refresh loophole is being closed. The VOIP system is meant
to carry real-time communications that require the user to be immediately
notified, visually and/or audibly, and abusing it for non-visible
notifications is no longer permissible. Fortunately, the existing notification
system that everyone used prior to the VOIP loophole still works just as it
always has, and so the apps will have no trouble reverting to compliant
methods.

This will not only restore behaviors that users expect from low power mode and
force quitting apps, but will also ensure that the critical and significant
battery performance gains of low power mode’s reduction in background app
refresh update intervals are restored to all iOS devices afflicted by apps
using the VOIP hack today.

I hope this helps explain why “delivered badly” may be considered a better
outcome than “delivered ignoring low power mode and force quit”. I assume you
disagree with Apple’s choice to restrict background app refresh behaviors, and
this led you to implement the VOIP mechanism, but unfortunately that time is
over. I hope your users and app are able adapt readily and without fuss to the
return of the power-saving pre-VOIP paradigm+ for silent background refreshes.

% Nomorobo sends a _visible_ push notification if you haven’t fetched updated
rules in a while, offering to reopen the app and start a refresh if you tap
the notification. I rarely see it, but I’m grateful for it every time.

^ Facebook.app using this same approach

\+ Mail.app demonstrates this paradigm effectively, reducing fetch times to
“essentially never” in low power mode if you don’t have notifications
configured. It takes a good minute or so sometimes for it to download my Mail
after I wake up and check it, but my phone also only uses 5% battery
overnight, ensuring that my phone’s alarm clock goes off even when I can’t
find a charger. I’m very grateful that Mail.app makes me wait for my mail
instead of checking silently in the background and draining my battery, and
that in a nutshell is why low power mode is worth a ‘poor’ user experience.

~~~
Andrew_nenakhov
TLDR: you know nothing.

Longer explanation: You do not know how XMPP works. XMPP is a federated
protocol that requires a persistent connection between a client and a server.
XMPP consist of multiple independent servers. Client developers and server
owners are usually different parties.

To send a push notification to JabberChat app some XMPP server (say, xmpp.org
) must post a notification update to appserver hosted by JabberChat owners
(say, jabberchat.org), because only they can send push notifications to an
app. If you insist, like Apple, to transmit only 'meaningful' updates,
appserver owners will be able to snoop on all passing traffic. That is not
desireble bordering not acceptable.

So, XMPP naturally devised a way that only 'content available' notification is
transmitted to an appserver, which relays it to a client via APNS/FCM. A
client application then wakes up, connects directly to its own server (which
is likely INDEPENDENT from app developer!), fetches data and acts accordingly.
Now this capability to reliably fetch data without Apple / appserver
intermeddling is crippled, which introduces lots of privacy risks.

See XEP-0357 for more details.

You see, instant chat messages are exactly that kind of real-time
communications that requires a user to be immediately notified. The only
viable way to provide real-time notifications without violating user privacy
were these VoIP notifications, and apple just killed these.

All your logic applies only to centralised client-app architecture, and
totally not applies to any federated one.

Also, Apple's restrictions are honestly dumb. Smartphone is a computer and one
should not restrict how a user wants to use that computer. If a user needs
background tasks, just let them do it, only alert them about power usage and
let them decide if they need this app or not.

~~~
floatingatoll
I am sad to hear that didReceive(_:withContentHandler:) is not sufficient for
you to implement end-to-end encryption of the content of user-visible push
notifications using an encryption key exchanged prior to APN delivery. I hope
someday Apple extends their support for preprocessing received display
notifications to users to ensure that the intermediary only knows the
receiver’s destination address at most.

[https://developer.apple.com/documentation/usernotifications/...](https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications)

------
vonseel
If you were building an app that needs to do something like this in the
background today, what is the recommended approach if you're on a platform
like React-Native? Can JS even be reliably executed in the background?

~~~
lacker
For the vast majority of cases it’s better to just use the Apple push
notification API and not try to keep a background process running constantly.

~~~
vonseel
What if you need to decrypt the payload?

------
kevin_b_er
Or Apple could make a better messaging and notification system that's similar
to pushkit but without the supposed "sensitive data", or just fork pushkit to
have a "low permission" version of it.

~~~
csande17
They already have:
[https://developer.apple.com/documentation/usernotifications/...](https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension)

------
t0mbstone
My wife and I use Life360 every day for giving us notifications whenever we
leave work, arrive at home, arrive at our kid's school, etc.

We use these tracking notifications for all sorts of things. For example, my
wife won't start prepping dinner until she gets the notification that I've
left work.

I will be very annoyed if Apple's changes break tools like Life360. I opted
into the tracking for a reason. I don't need Apple making privacy decisions
for me. I'm more than capable of making the decision myself.

~~~
cromwellian
I also used Life360 to geofence my kids and get notifications when they leave
school and return home. It actually caught my son running away from school one
time, and when the guidance counselor couldn't find him, I was able to locate
him outside the school wandering around the streets.

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

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

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

------
Blinks-
It seems like a user side configurable app permission such as "allow this
application to use PushKit for non VOIP related functions" would take care of
this without breaking functionality. However if the author of this article is
correct it seems like this is more a jab at Facebook messenger than anything.

~~~
reaperducer
_" allow this application to use PushKit for non VOIP related functions"_

The number of users who would understand that phrase and find it useful in
making a decision is roughly .000000001%. Maybe.

~~~
Wowfunhappy
Nitpick: I'd think it's significantly more than that, not because the number
of users is large, but because .000000001% is mindbogglingly small. Remove a
few zeros!

~~~
dave5104
I don't think they were going for an accurate number. I actually think the
hyperbole helps make the point they're making in this case.

