Seems to be some suggestions now that apps were continuing to crash even after commenting out the FB implementation because FB is managing to do remote API calls just because the framework is linked.
> It does not matter. Their libraries are dynamic, and they abuse +load functions for classes with some business logic calls. So, +load will be called anyway on the application launch when dyld loads all linked frameworks.
and
> I really don't understand why it is still crashing when we turn it off? Could you please explain, why there is a remote connection even we comment out the implementation? Linking binary framework just enough to break things down, why? What do you do in background? Sending or receiving some data even it's not been initialized?
I'm shocked but perhaps not surprised at many of the comments in that thread. These people are app developers who voluntarily link in huge multimegabyte binary-only third party sdks, and then act surprised that the code they are linking is prone to crashing? It should be obvious that any bug in such an SDK might bring down any app, even on launch and even if your own code never makes an explicit call to the SDK.
Third party SDKs have free reign in your apps. They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.
It gives the SDK developers a foothold inside each app's sandbox/keychain/developer-specific app ID. It must be a gold mine for correlating and tracking users across apps and websites, breaking down the intended barrier between different apple developer team IDs and app containers.
Last time I checked one of these binary SDKs along the likes of FB, Gmaps, etc just running strings on the binary framework lib was enough to send chills down any developer's spine.
We are now in a “dependency-oriented programming environment” (D.O.P.E) world.
One the one hand, it’s easy to sniff at the use of dependencies, when we have these kinds of disasters, but on the other hand, dependencies give us the ability to do truly great stuff.
For example, I program Apple devices (not just iOS). I wrote my first Apple code in 1986, so I have some “prior art.” I’ve “seen it all.”
I remember the days of MPW and MacApp, which spent most of its life in beta (Photoshop was initially based on MacApp 1.0b9, when it was first released).
Writing a full GUI experience was hard. It could take weeks to get a fairly basic app up and going.
Nowadays, with the various flavors of the Cocoa Application Framework, I can have a fairly full-featured app up in just a couple of hours.
Cocoa (and its implementation SDKs, like UIKit) is a dependency.
That said, I like to avoid dependencies wherever possible, relying on real “core” dependencies, like OS infrastructure.
It’s just that I can’t justify building my own power plant, when I can simply pay for a hookup from the pole.
There’s a good reason for the current DOPE.
Many corporations are using DOPE to “embrace and extend,” to an extent that makes Microsoft’s antics in the oughties look like child’s play.
When we use an SDK as the basis of our apps, we are giving them a huge amount of trust. They have access to everything our app can reach, which is often a lot. It also means that we may not have anyone on staff that actually knows what’s going on, under the hood, as we rely on the dependency to do most of the heavy lifting.
Apple’s App Store approval process is a pain, but this is the kind of thing they try to avoid. There’s just no way they can account for everything, and some corporations are getting very good at the whole “camel’s nose” thing.
I think that the “Wild West” nature of DOPE will shake itself out, sooner or later, with a few solid, trusted SDKs rising from the ashes.
There’s just gonna be a lot of collateral damage, on the way.
One of the worst things, is to build on a dependency, then have it collapse (or corrupt) down the road. That can be devastating.
You can hack things through reflection. You can use Gradle directives to specifically exclude certain dependencies of your dependencies. You can use ProGuard to strip out the parts of libraries you don't need.
A side note: on Android, class loaders are definitely of no use for this purpose. Android runtime uses its custom bytecode language and file format that packs the entire classpath of your app into one .dex file. You can't load separate classes from these, only the entire thing all at once.
(yes there's multidex for large apps but the way classes are split between files is rather random in my experience)
Also arguing about phoning home in a constructor versus some init() function misses the point. Why would you dynamically link to an SDK that you don't initialize?
> They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.
Turns out if you're linking in code (or even calling out to it, but that's another level of effort) you should probably have the source, or have a person on your team who can do basic RE.
(For the iOS engineers reading along: please don't put network calls in +load, or __attribute__((constructor)), or a C++ static variable, or whatever other clever way you think you can get code execution before main.)
Not just network calls, but also the file system, or basically anything nontrivial.
C++ static variables can now be annotated with constinit to resolve issues like this: https://en.cppreference.com/w/cpp/language/constinit It basically asks the compiler to enforce that constructor calls can only do trivial things.
Eh, I wouldn't go that far; they do have their uses. But for a SDK author, it pays to be excessively cautious when putting things on the application startup path. (Something which the Facebook is well aware of, as the dyld session is always full of their company's engineers, and the architecture of their app shows that put effort into meeting launch deadlines…)
Every bad thing has its uses. If an SDK author wants to be a responsible participant in the app's startup path, it will defer its own setup to the app.
`__attribute__((constructor))` is most obviously a hack – like any great hack, it is useful enough to be implemented everywhere, but it will never be standardized because everyone acknowledges that it sucks. I used to use it! But it is extremely limited in its usefulness, and there are always better solutions to the problem.
Putting more code in a constructor is almost never advised. I would expect that whatever connection the Facebook SDK is making is not a blocker for application launch. (If you have more insight on why this code must unconditionally run this early, I would be glad to hear it.)
The gain from trying to eke out a millisecond by executing network or filesystem I/O code before main() is extremely marginal compared to the can of worms opened by doing that.
The next evolution of "every app in a sandbox" must surely be custom sandboxes for individual libraries within apps. The main app could selectively delegate permissions of its own (like network, camera) to the libraries, for example after obtaining user consent.
* Apple may ask, "what is this SDK doing and why can't it be done with IPC"?
* Other app developers may start thinking harder about the risks of SDKs and ask "why do I need this and how can I not take the reliability / security risks of code I haven't reviewed"?
* an unlikely, but not impossible outcome, is that people start looking at letting processes drop capabilities, maybe even forking SDK code into it's own subprocesses. But... why not just make the SDK ship as a separate process as part of a different app at that point? Linux I know has tons of capabilities available, yet security engineers often complain about tons of apps just not even trying to use them. So I'm skeptical anything major will change here.
But there's probably never going to be anything to guarantee that developers don't submit 3rd party code as part of their apps, effectively pretended it's their own. And as long as Apple can't tell SDK code from your original code, how can they do anything about it?
I suppose they could look at popular SDKs and make some sort of bytecode signatures of them, but that mostly just serves to figure out which apps use which SDKs, which might be useful for review or malware detection, but it's unlikely to have the fidelity to actually enforce stronger error boundaries or security boundaries.
From them: "The Facebook SDK automatically initializes when the app is opened. When the SDK is initializing, it fetches app settings from Facebook. If you want to block all network requests to Facebook, you can disable automatic initialization." If you want to turn it off, you're supposed to set in your app's plist <key>FacebookAutoInitEnabled</key><false/>.
If people are claiming that the SDK is still fetching despite adding that key, that could be breaking some compliance and consent laws...
> If people are claiming that the SDK is still fetching despite adding that key, that could be breaking some compliance and consent laws...
It is still a violation of GDPR as I as the user never have the chance to consent (or not consent!) to any data transfer to Facebook. But as no one seems to be willing to go after FB... sigh.
but that's the point: It can be. Just add that key to the plist file and the SDK won't initialize and won't do any requests by default.
This is absolutely on the app developers. Not knowing what an SDK you linked does or doesn't do doesn't absolve you from GDPR (or any law for that matter)
This is on FB for not being forthcoming and stating very clearly that the SDK is doing that in their docs.
Is it documented somewhere? Sure, probably.
But if your SDK is doing something _very unusual_ and goes against platform conventions and best practices, and 99,9% of the people integrating the SDK _have no idea_ about it, it's your fault for not explaining what and why you're doing it.
https://github.com/facebook/facebook-ios-sdk/issues/1373#iss...
> It does not matter. Their libraries are dynamic, and they abuse +load functions for classes with some business logic calls. So, +load will be called anyway on the application launch when dyld loads all linked frameworks.
and
> I really don't understand why it is still crashing when we turn it off? Could you please explain, why there is a remote connection even we comment out the implementation? Linking binary framework just enough to break things down, why? What do you do in background? Sending or receiving some data even it's not been initialized?