Facebook iOS SDK Remotely Crashing Spotify, TikTok, Pinterest, Winno and More (opens in new tab)

Totally not creepy.

[0]: https://nshipster.com/device-identifiers/#fingerprinting-in-...

And a lot of stuff is not related to FB Login.

Facebook launched Facebook Off Activity a while ago https://news.ycombinator.com/item?id=22178917

You can go to your profile, and check which third parties, or advertisers uploaded contact data of you, download backup data to see in json files which apps what sent about you ("App activated", "Made some purchase").

Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this. You always have the choice to not install the app (if you don't want to).

This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.

>> Yes, absolutely.

Much much worse: https://news.ycombinator.com/item?id=19595478

Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case

If I pay for the service, I can expect that the service is taking nothing more from me than the payments I make. Our contract is explicit.

If it's a free-as-in-beer service, then the user must realize that the business which is offering the service expects to get something for its purposes from the user, such as user's eyeballs and user's computing resources.

I mostly agree. But, in some(most) also the user by encouraging the developer to release updates and launch new features.

I support you in your courageous fight against nuance.

GPDR specifically allows for anonymized/aggregated data on app usage or marketing feedback: https://gdpr.eu/eu-gdpr-personal-data/

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

Unrelated to Facebook, but some malicious SDK already doing it. For example, Igexin(https://blog.lookout.com/igexin-malicious-sdk), and it's not the only one.

Be careful when importing anything.

It is not any arbitrary sdk, it is fb, probably one of the essential sdk nowadays.

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.

Some logical consequences of this outage:

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

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.

It's not that they aren't smart or don't learn but that FB's performance review process rewards optimizing for growth over reliability/sustainability.

e: you can downvote me but I lived it so you won't change my mind :)

Which begs the question why test engineers with leetcode trivia bullshit. You are yourself emphasizing why their interview process (and they are just one of many offenders) is so bananas inappropriate.

This comment reflects badly on your imagination. There are 00s of uses for a concrete brick -- let alone a single device with a plethora of distinct functions.

Strongly disagree on this. Exact opposite maybe but I don't want to generalize. Modern authoritarian tactics are pretty much impossible without engineering.