4 ms·

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-

by 0x0 6y ago

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.

steerablesafe 6y ago
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?
marcus_holmes 6y ago
Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?
- 0x0 6y ago
  An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.
- microcolonel 6y ago
  That's only if you don't review the changes, and trace the entry points at least.
ChrisMarshallNY 6y ago
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. BTW: I use the acronym “DOPE” for a reason. The spice must flow...
- oblio 6y ago
  For Java you can actually control a lot of this through a security manager: https://stackoverflow.com/questions/5401281/preventing-system-exit-from-api https://stackoverflow.com/questions/5401281/preventing-syste... And I think you can even control the loading through a custom class loader. It's a bit of work but it should give you decent oversight over the dependencies you really don't trust but have to use.
microcolonel 6y ago
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.
interskh 6y ago
I think there are two main reasons to include fb sdk - fb login - fb ads It is not any arbitrary sdk, it is fb, probably one of the essential sdk nowadays.
- 0x0 6y ago
  Sounds like an arbitrary SDK to me.
nirui 6y ago
> 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. Unrelated to Facebook, but some malicious SDK already doing it. For example, Igexin(https://blog.lookout.com/igexin-malicious-sdk https://blog.lookout.com/igexin-malicious-sdk), and it's not the only one. Be careful when importing anything.

by 0x0 6y ago

steerablesafe 6y ago

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?

marcus_holmes 6y ago

Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?

0x0 6y ago
An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.
microcolonel 6y ago
That's only if you don't review the changes, and trace the entry points at least.

ChrisMarshallNY 6y ago

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. BTW: I use the acronym “DOPE” for a reason. The spice must flow...

oblio 6y ago
For Java you can actually control a lot of this through a security manager: https://stackoverflow.com/questions/5401281/preventing-system-exit-from-api https://stackoverflow.com/questions/5401281/preventing-syste... And I think you can even control the loading through a custom class loader. It's a bit of work but it should give you decent oversight over the dependencies you really don't trust but have to use.

microcolonel 6y ago

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.

interskh 6y ago

I think there are two main reasons to include fb sdk - fb login - fb ads It is not any arbitrary sdk, it is fb, probably one of the essential sdk nowadays.

0x0 6y ago
Sounds like an arbitrary SDK to me.

nirui 6y ago

> 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. Unrelated to Facebook, but some malicious SDK already doing it. For example, Igexin(https://blog.lookout.com/igexin-malicious-sdk https://blog.lookout.com/igexin-malicious-sdk), and it's not the only one. Be careful when importing anything.