
Now Resolved: FB iOS SDK Outage Causing Disruption to 3rd Party iOS Apps - dfabulich
https://developers.facebook.com/blog/post/2020/07/13/bug-now-resolved-fb-ios-sdk-outage-causing-disruption-third-party-ios-apps/
======
dsukhin
I clicked, pleasantly surprised and expecting a post-mortem. Instead it's a
corporate PR admission of guilt and non-apology. If your audience is
developers who implement the SDK, a more detailed explanation is the only
respectful option.

Moreover, the actionable advice to upgrade the SDK is a complete non-technical
non-sequter seemingly put as a distraction:

\- They admit it was a server side change that caused the crashes. SDK version
doesn't change that.

\- No breakdown of which versions were affected (or was it everything?).

\- Is a newer release safer? Were changes made that we would get by upgrading?

Did anyone by chance MITM the server payload to understand the bad code/bug?

~~~
mastazi
I fully agree with you that they should have put out a post-mortem, that's
what I was expecting as well, when I clicked the link. I disagree on it being
a non-apology however, since the sentence below, quoted from the article,
seems like an apology to me.

> This is the second similar incident this year. We want to apologize for the
> inconvenience these events have had on our developers and their users.

~~~
cflewis
It’s not much of an apology because the final paragraphs try to push any
future responsibility onto the SDK consumers by saying they should make sure
they are updating as fast as FB would like them to.

It’s an odd addendum to put in and appears ominous to me.

~~~
asdfasgasdgasdg
If they want to push that responsibility they should do it officially rather
than as a suggestion. The company I work at has a concept called a "build
horizon." The rule is that clients have to be updated within the horizon.
Internal services do not have to consider internal clients older than the
horizon, and may break them arbitrarily. In effect this means that even the
least with it internal clients rarely let their internal releases languish
more than about half the length of the horizon, because of the associated
risks of missing the cutoff.

There are many similar successful concepts that cap the maintenance window
that services must tolerate, while at the same time giving developers enough
forewarning to understand what is expected of them.

------
dfabulich
> This is the second similar incident this year. [...] While we can’t
> guarantee a bug-free experience, we have learned from these events and
> continue to improve the stability of our SDK.

What did they learn, exactly? There wasn't a postmortem on the prior incident,
and it would seem that no postmortem is planned for this incident, either.

~~~
jkingsman
A postmortem has been requested; whether we'll see it... who knows.

[https://github.com/facebook/facebook-ios-
sdk/issues/1385#iss...](https://github.com/facebook/facebook-ios-
sdk/issues/1385#issuecomment-656768967)

~~~
tmpz22
If there’s no postmortem I think it’s pretty safe to assume the mistake(s)
were embarrassingly simple such as a disturbingly poor CI process for a multi
billion dollar company.

There is no shame for a bad config push... it happens... but there’s a huge
amount of shame in having an ego so big you cannot admit it.

~~~
jiggawatts
They invented the "move fast and break things" attitude.

That's fine for a social network, but by forcing the SDK to be directly
integrated into third party apps, they're forcing their attitude onto
developers that have a "move slowly and don't break things" attitude.

I'm shocked that they have this rule, that developers play along, and that
there's apparently _nothing_ that can be done about this.

If there was some easy way to find out which iPhone apps that I'm using have
the FaceBook SDK installed, I would mercilessly uninstall all of them.

But as a consumer, I'm completely blind to the privacy-violating malware that
is being forced upon me by faceless corporations.

Yay.

