Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

github.com

Post reply on HN
Print view View original

291–300 of 446 posts

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#291

Post by sigwinch28 »

speedyapoc wrote: post #274

Issue seems to be resolved, but the the comment on their bug tracker is almost infuriating. “ Earlier today, a code change triggered crashes for some iOS apps using the Facebook SDK. We identified the issue quickly and resolved it. We apologize for any inconvenience.” (1) At the scale of Spotify and other massive blue chip apps, this bug could have very well cost companies hundreds of thousands to millions of dollars…

Assuming that developers of these apps get the same license we plebs get (i.e. NO WARRANTY), then I see very little recourse.

Facebook are big enough to blow this off, and they know it. At least... they hope so.

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#292

Post by babesh »

emerongi wrote: post #228

The most popular apps on one of the most popular operating systems just plainly don't even open. What has this industry become? How are we so goddamn inept at writing software? This is an industry where we can automate testing - not many other industries have this capability - and we still don't have a simple test regime of "check if the app opens" for any of those apps. Somehow, at the most valuable software compani…

There is more complexity in this.

Proximate Issues

The app makers cannot easily prevent the crash since it is happening in Facebook provided code. Perhaps the only thing they could do is to code in kill switches. Another possibility would be to modify the Facebook code. That introduces maintainability issues.

The crash happened because of a server side change that triggered roughly the Objective-C equivalent of a null pointer exception.

Objective-C is an old unsafe language.

Ultimate Issues

Client-side libraries have a poor history in the industry. They are often written by server engineers who aren’t expert on the platform.

For instance, if it was really a static load method that called the server, then this was a poor design decision.

Furthermore, weaker server engineers are notorious for breaking backward compatibility. They don’t design nor build in tests to ensure backward compatibility. The backward compatibility must include backward data compatibility.

The above issues are indicative of organizational issues.

Facebook is a little bit of an outlier. It was notorious for badly written client libraries stretching back to the Facebook platform days. The joke was that their libraries may have been written by interns even though so many companies were dependent on them.

The Facebook libraries and the ilk are used for sign on through Facebook and ad attribution. The trade off an app maker needs to make it a whether to run ads on Facebook and whether to support sign in.

Facebook is not the only big company with these issues. Google’s equivalent also crashed albeit at a much lower rate due to a much more convoluted issue.

Apple introduced the Swift programming language to address the deficiencies in Objective-C. That these companies are running into these issues makes me wonder if they never transitioned to Swift. They are certainly way behind the latest version of the libraries.

To summarize, it is a cascade of issues some technical and some organizational rather than a single coding error. These issues span companies.

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#293

Post by johnvega »

Seems like FB way of forcing devs to use the latest SDK, unless FB shares technical details on what happened.

This is what FB for dev says:

"To make your app compatible with the latest iOS, be sure to use the latest Facebook SDKs for iOS."

https://developers.facebook.com/docs/ios

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#294

Post by vsareto »

yreg wrote: post #237
emerongi wrote: post #228

The most popular apps on one of the most popular operating systems just plainly don't even open. What has this industry become? How are we so goddamn inept at writing software? This is an industry where we can automate testing - not many other industries have this capability - and we still don't have a simple test regime of "check if the app opens" for any of those apps. Somehow, at the most valuable software compani…

The apps are broken serverside by Facebook. No amount of testing (automated or not) on the side of the app developers would have prevented this. Facebook's own apps did not break since they are on the latest version of FBSDK. What Facebook needs to do is to test whether their changes don't break other people's apps.

1. Mock dependency

2. Throw exceptions

Don't tell me "No amount of testing" just because you aren't responsible for your own dependencies.

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#296

Post by Nextgrid »

corndoge wrote: post #285
slipheen wrote: post #271

Earlier quoted context omitted.

Unless your app is designed for browsing Facebook, there's no reason that anything on Facebook's servers should affect if your app works. Many of the apps crashing are using Facebook for a portion of their app, such as one login option. Letting that take down the whole app is insufficiently defensive coding, whether in the app, sdk, or glue between them.

How do you defend against abort() in library code?

Don't include libraries which contain such code?

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#297

Post by beagle3 »

anonms-coward wrote: post #287
beagle3 wrote: post #214

Earlier quoted context omitted.

The same list you gave already applies to data already readable on Google Drive - most people have data that can be used against them on those drives. Also, many apps ask for (And get) permission to read contacts and messages on your phone. Claiming that this is the reason is sort of like rearranging the chairs on the deck of the titanic when you can see the iceberg. Much more likely it is to stop import/export to a…

The number of people who use whatsapp is an order of magnitude or more than the number of people who consciously use Google drive, as in people who know google drive exists. Even the people who have google drive, most of them have much less intimate data on it than in their private messages on WhatsApp. If we are to take the position that all users are tech literate and should be fully in charge of how their data is…

And you are still avoiding the equivalence that everything you describe is already happening with sms messages at least, and generally much more. None of your arguments carry any weight especially since they don’t explain why it’s ok for data to be unencrypted on your google drive in the first place.

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#298

Post by hyko »

monocularvision wrote: post #256
linux2647 wrote: post #247

Earlier quoted context omitted.

I disagree. While, yes, Facebook needs to test their SDK, app developers need to build resiliency into their apps to ensure third party dependencies don’t break their app. The developer adopted it into their app; it’s their responsibility to do the proper checks in cases like these where Facebook broke things on their end.

This is a native SDK that is crashing the process. There is nothing an app developer can responsibly do to prevent or recover from this crash. Other than remove the SDK, of course.

Yes there is: a remote kill switch that prevents the third party SDK from loading. That puts you back in control of the software you’re shipping.

Fool me once, and all that.

Re: App suddenly crashing on startup due to FBSDKRestrictiveDataFilterManager.m

#300

Post by mschuster91 »

vsareto wrote: post #294
yreg wrote: post #237

Earlier quoted context omitted.

The apps are broken serverside by Facebook. No amount of testing (automated or not) on the side of the app developers would have prevented this. Facebook's own apps did not break since they are on the latest version of FBSDK. What Facebook needs to do is to test whether their changes don't break other people's apps.

1. Mock dependency 2. Throw exceptions Don't tell me "No amount of testing" just because you aren't responsible for your own dependencies.

You can't mock it, that is the entire point. Simply loading the shared library of the SDK will execute the broken code.
Post reply on HN