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

51–60 of 110 posts

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#51

Post by _bxg1 »

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…

Sounds like they're really running up against a genuine conflict of trust. Apple doesn't really trust iOS apps to be "real programs" that just run on your device and do whatever they want, even sandboxed away from the rest of the system. Processing and data transfer is forced through Apple's special-made API hooks for purposes of battery life/performance management and privacy. Apple doesn't trust app developers, and developers of these apps don't trust the client OS.

I don't think there really is a single solution that works for everybody, although I wouldn't mind Apple providing an opt-in app permission for "make arbitrary network connections in the background". The privacy argument against that seems pretty academic, though the battery argument is stronger.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#52

Post by pfranz »

AmericanChopper wrote: post #25
Icathian wrote: post #20

Earlier quoted context omitted.

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

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 fa…

Working the refs works way more often than people think.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#53

Post by fooey »

msie wrote: post #9
portmanteaufu wrote: post #2

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 t…

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.

Approval process roulette is exciting enough when you think you're following the guidelines.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#54

Post by dave5104 »

Wowfunhappy wrote: post #38
reaperducer wrote: post #5

Earlier quoted context omitted.

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

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!

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#55

Post by prophesi »

lacker wrote: post #40
turdnagel wrote: post #32

Earlier quoted context omitted.

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?

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 c…

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#56

Post by EGreg »

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

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#57

Post by mobilio »

madrox wrote: post #33
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.

From PushKit's documentation: PushKit notifications also have the following advantages over user notifications: - The device wakes only when it receives a PushKit notification, which can improve battery life. - Upon receiving a PushKit notification, the system automatically launches your app if it isn't running. By contrast, user notifications aren't guaranteed to launch your app. - The system gives your app executio…

Correct!

But also some authors uses PushKit to keep their app constantly running in background.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#58

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

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#59

Post by RandallBrown »

skybrian wrote: post #42

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.

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.

Re: Apple Change Causes Scramble Among Private Messaging App Makers

#60

Post by RandallBrown »

t0mbstone wrote: post #4

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…

I can't see any reason that Life360 would be using a VOIP API for location tracking when Apple's own location tracking APIs work quite well.
Post reply on HN