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 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 those affected were …
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.
It appears that Facebook throws app developers a bone in order to get pretty much unrestricted access to the user's device. This probably explains why quite ordinary applications request a laundrty list of permissions when installing ("but it doesn't work with images, why would it need access to the camera, photos and what-have-you?").
Using a language that implements even rudimenatry type checking might save everyone a lot of time and bother. We also need to explain to some of these programmers what the term 'deprecate' means.
> 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.
Uncalled for swipe at devs there. It doens't matter how well you know the library, if Facebook change a data type on the backend without notice and without updating their own library to deal with it there is nothing you can do. Obviously there are degrees of failure and with robust error handling you can mitigate things but if you rely on the library for vital functions like login then you're screwed.
Personally I avoid Facebook anything but if a client wants it sometimes you have to use it.
With the amount of people who just include a library on GitHub and never worry about what it actually does until said library falls over, it's not really uncalled for.
Personally, where I to include someone else's library, I would import it into my code stack, review the code to ensure that it does what it says on the tin and nothing else, and - after testing the thing to hell and beyond - include it in my production code stack.
Of course, it is then up to me to set a watch over that library to check when it is updated and what the update is, but that's my problem.
The rub is, developers hate problems, so they just link to library and let history run its course.
It's not because, in this particular case, developers had no way to avoid the issue that the argument does not stand.
The main rule when dealing with user input in one's application has always been to never trust said user. Expect the worst kind of mangled, hopelessly incorrect data. Ergo one sanitises incoming data and bails out early if something seems fishy. With third-party libraries and code it's no different. Even for one's own code and libraries checking input data (when called from a function, or as the return value from calling some method) has to be standard, not optional.
Clearly Facebook's library did not bother checking the input, which then cascaded into taking down the rest of the application with them. Of course, with JavaScript and increasingly more new languages that are weakly typed (Kotlin, Swift, Rust, etc.), a lot of (static & dynamic) type validation is being tossed out of the window, with things seemingly working fine until the runtime hits a type conversion that is impossible, throwing an exception.
With a language like Java that has no stack-based variables, one technically had to validate every incoming parameter for being a Null type. Since nobody every did this, NullPointerExceptions are still super-common in Java code. With weakly typed languages (like JS and Python) the only time that you will encounter the really fun bugs is when you get a stacktrace barfed at you (Python) or the app fails silently (JavaScript) while the code runs in production (because testing & staging is for losers).
Does anyone ever really trust code someone else wrote, or worse: code one wrote themselves?
I always tell the kids “Don’t trust anything coming from a server”. iOS guarantees that when JSON is parsed you get either correctly parsed data or just an error. Anything in that data needs to be verified, and if necessary rejected. You can’t just assume that you received a dictionary, it must be verified.
But at least crashing of an iOS application is rarely a security risk, and assuming that a Boolean value is a dictionary will lead to a clean crash.
Strikes again, another blunder from the blunder warriors
Honestly, if we tolerated this level fucktardery in the physical world, buildings would be crashing onto pedestrians heads every minute of every day
If you don't know how to build a solid structure, fucking don’t, if you need to constantly patch (sticky plaster) your structure made from soft stodgy shit, then clearly you’ve not fucking thought this through, a bit like your mother all those years back!!!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
