Hacker News Reader

Comment by dsukhin | Hacker News Reader

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?

View on HN

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.

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.

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.

Wanting to do something isn't the same as doing it.

Are you saying that because the author said "I want to apologize" instead of "I apologize"? I don't remember how this phenomenon is called but basically in English and other Indo-European languages there are expressions that don't really modify the meaning of a sentence, another common example is "you know, I think I'm going to have a sandwich" vs. "I'm going to have a sandwich" - the two sentences have the same meaning, the speaker is not really asking you whether or not you know that they want a sandwich. This might be confusing at first, depending on your linguistic background.

The relevance of upgrading is that the latest version didn't crash. While they clearly don't test server changes against every version of the SDK, they hopefully at least test it with the latest.

The crash was just that a dictionary decoded from json sent by the server contained null in a place where the code expected a non-null value. The actual payload difference would not be very interesting.

Time to get rid of this huge and buggy SDK. Just to offer FB login to apps it‘s kind of ridiculous this is required in the first place.

Not an app developer, so genuinely curious: would offering only Google and Apple SSO (alongside email and password) be enough coverage for most users to reduce signup friction? Apps are rolling Apple auth out now as the deadline for implementation has passed.

My understanding is that to use Facebook as an auth mechanism, you must use their SDK (and personal data vacuuming along with it), so dropping Facebook auth would allow apps to drop the SDK, which would be a win for both privacy advocates and users who enjoy their apps working even when Facebook breaks something.

> My understanding is that to use Facebook as an auth mechanism, you must use their SDK

Does anyone know more about this?

As far as I remember Facebook does support being and openid connect authentication provider so it should be theoretically possible without their SDK. But it might be that they put some practical restrictions in place to force usage of their API??

I believe the T's & C's of the FB developer platform specifies that you can only use the Android/iOS SDKs for auth. You can probably get around it using openid, but you risk your developer keys being revoked.

Lots of login providers are out now. Okta, Auth0.

> If your audience is developers who implement the SDK

I believe the audience is marketing and management.

the latest version (7.x) was not affected by this. we had a build that was working, but it’s impossible to release fast enough to matter.

Reply on news.ycombinator.com