Facebook SDK Issue Again Causing Numerous iOS Apps to Crash or Freeze

[AbSoluTc]

This was a very helpful article. I was puzzled as to why my Ubiquiti Amplifi wifi management app was failing to load. Then I saw this.

Much to my surprise that Facebook has anything to do with the management of my home wifi. I'm now on to Ubiquiti about why on earth Facebook APIs are required at all. I do not use Facebook and do not want them involved in my wifi network.

Beware!

is there a forum post I can get in on? I use that app as well and wasn’t aware FB crap was in it. I want to voice my concern as well.

 

[jonppa]

Fun Fact: If you use an "Firewall App" like Lockdown and you block Facebook, your apps works. Useless crap SDK, which should be banned by the app store rules.

I own you a beer.

Mindfulness app "Headspace" had crashing issues yesterday and this got me curious are they using the Facebook SDK. And yes they are.

The app makes connections to facebook and various other trackers even if I don't have Facebook integration activated. Seriously, WTF?! Just opening the app makes 31 connections that were blocked by Lockdown.

Lockdown app became my normal app on my iPhone, thank you a ton for this!

 

[MacBH928]

Death to this company...we need someone to create an Instagram alternative.

 

[V_Man]

Understood. See point 3.

At any rate, that’s a bet you would lose. I have two non-stock apps on my phone. Guess what they are.

You must not use your phone very much.
for anything but the basics.

Only stock apps is great. I actually try to stay with the Apple apps is possible.

 

[riverfreak]

Ok, fair enough. I don’t know anyone with less than about 20 non-stock apps.
By non-stock, do you mean non-Apple or do you literally mean, apps you’ve installed that weren’t on it when the phone came out of the box? Is your phone an iPhone?

I mean apps that were not installed when I purchased the device.

It’s great that this issue is raising awareness of the pervasiveness of Facebook tracking, even if you aren’t an active Facebook user. On-device firewalls like lockdown are a good start.
[automerge]1594471771[/automerge]

You must not use your phone very much.
for anything but the basics.

Only stock apps is great. I actually try to stay with the Apple apps is possible.

I totally agree.

Okay, I just checked. I have three apps: a VPN app, Sudo, and FF Focus. I forgot about the last one. And I do have the iWork suite (is it still called that?). Been awhile since I UGed my phone.

I’m content to endure the few services I need/want to interact with on mobile in a more tightly controlled browser experience (or better yet wait until I am on a desktop). Nor do I need persistent location services.

 

[riverfreak]

This was a very helpful article. I was puzzled as to why my Ubiquiti Amplifi wifi management app was failing to load. Then I saw this.

Much to my surprise that Facebook has anything to do with the management of my home wifi. I'm now on to Ubiquiti about why on earth Facebook APIs are required at all. I do not use Facebook and do not want them involved in my wifi network.

Beware!

Wow. That’s nuts. I had been looking at the Ubiquiti UDM but was turned off by the requirement of having a Ubiquiti account in order to use it.

Even many privacy focused services have used Facebook APIs in the past probably before most companies realized the faustian bargain they were making. Most of these were identified by users (via, eg Little Snitch) and removed.

 

[gnasher729]

Yeah most of the apps will run the API code even if its not being used.

There is a easy way to fix this, a Try Catch Block around the Facebook API calls, assuming Facebook does the right and throws a documented exception, even they you can still try catch any other errors.
That should be a given when relying on someone else's code base

I saw the description of the problem they had two months ago, and I can guarantee that there is no exception thrown (there's also the problem that iOS code is supposed to throw errors, not exceptions), but it just crashes. An absolute sign of incompetent programming, and not much that you can do about it. (Well, if my boss told me that we _must_ support Facebook login, there are things that I could do to prevent it from crashing my app more than twice).

 

[mi7chy]

Wow. That’s nuts. I had been looking at the Ubiquiti UDM but was turned off by the requirement of having a Ubiquiti account in order to use it.

A lot of Ubiquiti equipment can be cleansed with OpenWRT firmware replacement with the added benefit of removing the lock-in.

 

[sdf]

There is a easy way to fix this, a Try Catch Block around the Facebook API calls, assuming Facebook does the right and throws a documented exception, even they you can still try catch any other errors.

There's two major problems with this.

1. Unlike other platforms, exceptions on iOS are intended to be fatal. If you try to catch and continue, memory won't be freed and (maybe more importantly) resource locks won't be released.
2. Some of this code is probably run without the app code explicitly running it, in ways that exceptions will remain fatal.

The fix is really for the developer to stop including broken SDKs and for Facebook to fix their SDK.

 

[hot-gril]

That’s what they get for adding this spyware to their apps. Apple should reject apps that include all those Spyware SDKs in the first place

Eh, it's about the same as Google Analytics, which many sites use (including MacRumors).

 

[itsmilo]

Eh, it's about the same as Google Analytics, which many sites use (including MacRumors).

which is just as much spyware as Facebook but the topic was FB here

 

[AdmiralTriggerH]

There's two major problems with this.

1. Unlike other platforms, exceptions on iOS are intended to be fatal. If you try to catch and continue, memory won't be freed and (maybe more importantly) resource locks won't be released.
2. Some of this code is probably run without the app code explicitly running it, in ways that exceptions will remain fatal.

I’m not sure where you get that idea, both Swift and Objective-C have some rather robust error handling, the documentation is quite clear on this.
I have always been taught when relying on someone else’s API that is linked to and subject to change you should always code to check for any foreseeable error, and a check for a null object is definitely foreseeable.

The Swift Programming Language: Redirect

 

[sdf]

I’m not sure where you get that idea, both Swift and Objective-C have some rather robust error handling, the documentation is quite clear on this.

The documentation, of course: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety.

I'm not sure what you're trying to say here. The problem is the SDK makes mistakes that throw exceptions. You can't really deal with those from Objective-C or Swift; Swift exceptions are really just wrapped Objective-C errors, which are not the same as exceptions. (Actually, "wrapped" is the wrong word. But mostly the same.) Exceptions are intended to be fatal, and exceptions thrown off threads where you didn't directly call the function can't be caught even as insurance against crashing.

You really just need to stop using bad libraries. That's the only good fix.