If it feels like the software world is held together by string and a prayer, we don't blame you: Facebook SDK snafu breaks top iOS apps
(2020/05/08)
- Reference: 1588896787
- News link: https://www.theregister.co.uk/2020/05/08/facebook_sdk_snafu_ios/
- Source link:
A change in the Facebook SDK backend managed to crash many popular iOS apps that integrated the code library, used for implementing various Facebook services.
Around 1330 PDT on Wednesday, software developers were stumped when their applications mysteriously crashed after being launched by users. Among [1]those affected were Bumble, Doordash, Duolingo, Google, Pinterest, Soundcloud, Spotify, TikTok, Tinder, Venmo, The Walmart App, and others.
App makers can add the [2]Facebook SDK to their apps to use Facebook's Login system as a single sign-on provider, to access its analytics service, to get social graph data associated with the app user, to implement deep linking to content within the app, and to utilize Facebook mobile ads.
How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript [3]READ MORE
But third-party code magnifies the chance of bugs. Developers tend not to fully understand third-party libraries and tend not to pay much attention to flawed code there until it's too late.
Also, platform owners may decide they no longer want to allow certain functions for privacy or security reasons, as Apple has done, which may require developers to remove offending libraries on short notice.
The scope of the issue isn't entirely clear but it looks to have caused [4]many thousands of crashes. A few hours later, Facebook [5]fixed the issue and apologized.
"Yesterday, a new release of Facebook included a change that triggered crashes for some users in some apps using the Facebook iOS SDK," a company spokesperson said in an email to The Register , echoing the wording in the GitHub Issues post [6]announcing the bug's resolution. "We identified the issue quickly and resolved it. We apologize for any inconvenience."
Facebook did not respond to a request to clarify the source of the snafu, though a developer participating in a GitHub discussion of the issue [7]attributed it to a data type mismatch:
It appears the cause is this configuration the Facebook SDK is receiving from the mothership for restrictiveParams: "restrictive_data_filter_params" = "{"is_health_app":false}";
The value is expected to be a dictionary, not a BOOL.
Another developer [8]echoed that diagnosis.
What made the incident particularly galling to developers is that attempts to disable the SDK by commenting out the setup code [9]didn't work because Facebook's library uses a method called +load to ensure that the runtime initializes the framework.
A more developer-friendly design would allow the SDK to be loaded when needed – lazy loading – rather than up front in all cases. Facebook, however, would get less data in this scenario.
A more privacy-friendly design would allow those using apps that insist on integrating Facebook technology to disable parts or all of its SDK – just because you want to use an app like Duolingo doesn't mean you want to have anything to do with Facebook. ®
Sponsored: [10]Legacy Modernization: Finding Your Way With Low-Code
[1] https://twitter.com/aburninghilll/status/1258169688959352832
[2] https://developers.facebook.com/docs/ios
[3] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[4] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-625003276
[5] https://github.com/facebook/facebook-ios-sdk/issues/1374#issuecomment-625354650
[6] https://github.com/facebook/facebook-ios-sdk/issues/1374#issuecomment-625354650
[7] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624934457
[8] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624943780
[9] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624944045
[10] https://go.theregister.co.uk/tl/1936/-8553/legacy-modernization-finding-your-way-with-low-code?td=wptl1936
Around 1330 PDT on Wednesday, software developers were stumped when their applications mysteriously crashed after being launched by users. Among [1]those affected were Bumble, Doordash, Duolingo, Google, Pinterest, Soundcloud, Spotify, TikTok, Tinder, Venmo, The Walmart App, and others.
App makers can add the [2]Facebook SDK to their apps to use Facebook's Login system as a single sign-on provider, to access its analytics service, to get social graph data associated with the app user, to implement deep linking to content within the app, and to utilize Facebook mobile ads.
How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript [3]READ MORE
But third-party code magnifies the chance of bugs. Developers tend not to fully understand third-party libraries and tend not to pay much attention to flawed code there until it's too late.
Also, platform owners may decide they no longer want to allow certain functions for privacy or security reasons, as Apple has done, which may require developers to remove offending libraries on short notice.
The scope of the issue isn't entirely clear but it looks to have caused [4]many thousands of crashes. A few hours later, Facebook [5]fixed the issue and apologized.
"Yesterday, a new release of Facebook included a change that triggered crashes for some users in some apps using the Facebook iOS SDK," a company spokesperson said in an email to The Register , echoing the wording in the GitHub Issues post [6]announcing the bug's resolution. "We identified the issue quickly and resolved it. We apologize for any inconvenience."
Facebook did not respond to a request to clarify the source of the snafu, though a developer participating in a GitHub discussion of the issue [7]attributed it to a data type mismatch:
It appears the cause is this configuration the Facebook SDK is receiving from the mothership for restrictiveParams: "restrictive_data_filter_params" = "{"is_health_app":false}";
The value is expected to be a dictionary, not a BOOL.
Another developer [8]echoed that diagnosis.
What made the incident particularly galling to developers is that attempts to disable the SDK by commenting out the setup code [9]didn't work because Facebook's library uses a method called +load to ensure that the runtime initializes the framework.
A more developer-friendly design would allow the SDK to be loaded when needed – lazy loading – rather than up front in all cases. Facebook, however, would get less data in this scenario.
A more privacy-friendly design would allow those using apps that insist on integrating Facebook technology to disable parts or all of its SDK – just because you want to use an app like Duolingo doesn't mean you want to have anything to do with Facebook. ®
Sponsored: [10]Legacy Modernization: Finding Your Way With Low-Code
[1] https://twitter.com/aburninghilll/status/1258169688959352832
[2] https://developers.facebook.com/docs/ios
[3] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[4] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-625003276
[5] https://github.com/facebook/facebook-ios-sdk/issues/1374#issuecomment-625354650
[6] https://github.com/facebook/facebook-ios-sdk/issues/1374#issuecomment-625354650
[7] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624934457
[8] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624943780
[9] https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624944045
[10] https://go.theregister.co.uk/tl/1936/-8553/legacy-modernization-finding-your-way-with-low-code?td=wptl1936
Oh dear
App makers can add the Facebook SDK to their apps to use Facebook's Login system as a single sign-on provider, to access its analytics service, to get social graph data associated with the app user, to implement deep linking to content within the app, and to utilize Facebook mobile ads
Surely, they could have earnt a more honest living? An update of old saw "I told my mother I play the piano in a brothel, I didn't want her to know that I'm a developer that used Facebook's Login" could apply.