[HN Gopher] Can Facebook provide postmortems on their iOS SDK cr...
___________________________________________________________________
Can Facebook provide postmortems on their iOS SDK crashes?
Author : Austin_Conlon
Score : 108 points
Date : 2020-07-12 20:21 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kevin_b_er wrote:
| Considering the SDK is setup to run, and crash, with just being
| linked in and not even a single call, FB should be responding.
|
| Their app is clearly phoning home during the self-initialization.
| For a period of time it was breaking massively, then suddenly
| not. That means some orders from the home server were bad and
| causing the SDK to crash the app out. All during a secret self-
| initialization the developer can't temporarily take out.
| onion2k wrote:
| _Apple_ should be responding. If a third party library is
| leading to massively downgraded performance of user 's devices,
| Apple should be warning developers that their apps could be
| rejected if they don't guard against the broken behaviour.
|
| The fact developers _can 't_ do anything is a good reason not
| to use the SDK, not just to accept the problem.
|
| If this continues to happen regularly Apple will start taking
| measures to stop the problem - and banning apps is a (very
| unlikely) possibility.
| swagonomixxx wrote:
| What I don't understand here is, how did this break apps that had
| "old" SDK versions?
|
| Did some HTTP call the initialization code make end up raising an
| exception on some unexpected status code and end up crashing the
| entire application?
|
| I don't understand why this kind of control flow is acceptable.
| Is it documented at least? And if it is documented, how come we
| can't fork this SDK (seems to be on GitHub, seems fork-eable) and
| remove this "feature"?
| bgdam wrote:
| It seems Facebook mandates the use of the SDK if apps wish to
| provide 'Login with Facebook' functionality. My question is this
| - Why would any company include this SDK, which is basically
| spyware into their apps, simply in order to have a slightly
| easier login flow? Is implementing a user authentication system
| really so complicated, that you guys think it is okay to give
| away control of your users, and even your app's ability to even
| startup without crashing, to a third party company over whom you
| have no control, who has no obligation to not break your app at
| their whim?
| [deleted]
| shaggyfrog wrote:
| You answered your own question.
|
| When the "business side" can claim a N% increase in
| conversion/daily usage/whatever having FB login, a developer
| will be tasked with implementing it uncritically, because if
| they speak up, they'll be punished.
|
| The "business side" doesn't give a crap about privacy or
| performance or any of that stuff. They just see the numbers,
| especially their potential bonuses.
|
| Late-stage capitalism, Baby.
| zumachase wrote:
| I think this is pretty myopic. As someone who straddles both
| sides of this, the world is not that simple.
|
| If the "business side" as you say isn't viable, then nothing
| matters. This has nothing to do with late stage
| capitalism...this is capitalism 101. If you're not hitting
| critical mass, you're dead.
|
| This take also continuously misses that most people, and thus
| must customers, are willing to trade privacy/performance for
| convenience. If that's not your cuppa, then hopefully there's
| an alternative.
| cocoflunchy wrote:
| Because everything is a tradeoff, and often having a good
| conversion rate is higher on your priority list than a lot of
| other things...
| zumachase wrote:
| > Why would any company include this SDK > Is implementing a
| user authentication system really so complicated
|
| "Login with Facebook" isn't popular because it saves developer
| time. It's popular because it massively reduces signup friction
| which results in higher conversion rates. These things are
| super important. We offer Google login with our only consumer
| facing app[1] and we see a solid 40% of accounts use that
| method vs. email. I would venture a guess that a sizable
| minority, bordering on majority, of those accounts would simply
| never sign up in the first place without some sort of SSO.
|
| I agree with your sentiments and frustrations, but whenever
| something seems to be too ridiculous to be true (as this might
| seem to some devs) there's often something else at play.
|
| [1] Squawk - Walkie Talkie for Teams https://www.squawk.to
| sargun wrote:
| Personally I use login with Google because: 1. I "trust"
| google auth - I know they won't store passwords in plaintext
| or anything funny like that 2. It's a centralized place I can
| use to rotate my keys 3. I can revoke accounts
|
| Signing up via email on each site means a password manager
| entry at a minimum, and probably no 2FA, or brute force
| resistance.
| bredren wrote:
| We know Facebook uses data they gather for competitive
| product reasons. I wonder how important Facebook's insight
| into signup and login auth for upstart products (like TikTok
| or fortnite) was for internal intelligence on where the wind
| is blowing / compete / acquire targets.
|
| FB SSO isn't really an option for an early stage consumer
| product, but if it were I can see Potential benefits to the
| products that are succeeding avoiding sharing real-time
| success metrics with FB.
|
| Presumably, Apple is also influenced by data like this via
| the App Store.
|
| For example Apple probably pays attention to Autosleep and
| other sleeping apps in deciding to build it into WatchOS.
| gnur wrote:
| I'm pretty sure it's not about it being hard to implement, but
| also about reducing friction to sign up/in.
|
| I'd personally never use sign in with Facebook, but for nearly
| all dev related services I prefer sign in with GitHub over
| creating another account somewhere.
|
| It also reduces the burden on security, you no longer have to
| think about where to store the usernames and passwords, how to
| hash them, how to compare the hashes to the plaintext password
| in constant time, how to prevent brute force attacks, how to
| prevent csrf and more. There is a reason that the sign in with
| X sign up flow is so popular!
| mgraczyk wrote:
| My websites have traditional email+password signup forms with
| Facebook and Google singup buttons beneath the form fields.
| Over 50% of new users use the social buttons instead of email.
|
| https://hunches.app/login
| jackewiehose wrote:
| I never understood "Login with ..." from a user-perspective.
| I'm supposed to enter my facebook/google login-credentials on
| some random website?
|
| How does the user know its legit?
| hn_throwaway_99 wrote:
| That's the whole point of OAuth - you _don 't_ enter your
| credentials on "some random website", but you only have to
| enter your credentials on the identity provider's site.
| Frankly I trust Google and Facebook to keep my credentials
| secure a lot more than some random website.
| jackewiehose wrote:
| But how do I, as a website-user, know who I'm telling my
| credentials?
| jay_kyburz wrote:
| I wonder how easy it would be to spoof a "login with
| facebook" flow on a mobile app.
| swagonomixxx wrote:
| Can't be that hard.
|
| On Apple though, your app might be taken down fast if you
| end up doing that. Doesn't mean you won't fool a few
| suckers though.
| gruez wrote:
| >simply in order to have a slightly easier login flow?
|
| Apparently you also need it if you want correct attribution for
| facebook ads, so the marketing dept might want it as well.
| vmception wrote:
| Login with Apple is coming for them, don't worry. Only a matter
| of time before Apple makes that even stricter and more
| dominant. I doubt Facebook's argument to the antitrust board
| will be compelling as Apple masks login data for the app and
| data broker, while Facebook only wants to aggregate it.
| rubber_duck wrote:
| As someone who uses Apple products occasionally (currently on
| MBP, used iPhones in the past) I doubt I would switch even if
| I went all in on the Apple ecosystem again. Their devices and
| software have annoyed me in the past to the point where I
| made the switch - anything Apple specific like this makes it
| a PITA move to a different platform.
|
| Google isn't perfect either - there is a low but realistic
| chance that they could kill my account at any time with no
| support options and I'm looking in to ways to protect against
| this while retaining the benefits - but in practice switching
| between mobile platforms and all desktop OS-es works like a
| charm. I use sing-in with Facebook when Google isn't an
| option. I'm really not concerned with data tracking - it's
| omnipresent at this point - not worth the energy to think
| about personally.
| vmception wrote:
| Sign in with Apple exists on other platforms
|
| No different than Google sign in while having a hardware
| ecosystem
| AlexandrB wrote:
| I fear Login with Apple is another poison pill. Sure it's
| better than some of the current alternatives, but if it's
| suddenly in Apple's best interest to abuse their position for
| data gathering, they will.
| sebastien_b wrote:
| Yup, they've introduced APIs in iOS 14 to make it easier to
| convert a regular login to "Sign in with Apple":
|
| https://developer.apple.com/videos/play/wwdc2020/10666/
| vmception wrote:
| Then it'll be ironic if an antitrust lawsuit turns into
| court ordered or legislative wins for user privacy and
| data-property.
| politelemon wrote:
| > Login with Apple is coming for them, don't worry
|
| That's an even greater cause for worry and I fear what will
| come of this, I would treat their login SDK as the same
| poisoned chalice that the Facebook login SDK is. Worst -
| they're effectively forcing app developers to introduce it if
| they have any kind of social login in their apps, which is an
| incredibly dick move. Any other company doing this would get
| negative attention but in our collective hypocricy we keep
| painting this in a positive light. It absolutely is _not_ a
| good thing... but this is HN.
| dcow wrote:
| I definitely agree with you that this is not a good thing
| and that Apple is pulling a 100% certifiable dick move by
| doing this. Who in their right mind would want to implement
| an email authentication method that just paid out 100k
| because someone found out they weren't actually
| authenticating emails. I mean come on... I'd love to see
| Apple eat their own dog-food on this one and then we could
| see if it's really ready for prime time.
| wonnage wrote:
| On the flip side, people used to argue for SSO as a
| privacy/security feature - rather than sharing your email and
| creating passwords with every site, just let a trusted
| intermediary like Google/Facebook handle those nasty details!
| sebastien_b wrote:
| But doesn't that mean if it gets compromised (which I think
| one popular one did a while back?), then you're basically
| screwed for every site you used it with?
|
| Personally, I always use email, plus 2FA when available. I
| don't trust "single" sign-ins anywhere - I'd rather control
| the access to the credentials myself.
| ffpip wrote:
| They still get your email with SSO. And name, profile pic
| too. Which they don't via the normal method.
|
| With SSO via Google, FB, you have to agree to share data with
| them.. email is a thousand times better
| creato wrote:
| Speaking as a user, I strongly prefer OAuth login whenever
| possible, so I don't need to manage a new account. I trust the
| security of big players like Apple, Google, etc. a lot more
| than random app/website developers. There is some range of
| value (to me) of services where I will be willing to log
| in/sign up with an existing OAuth account, but I will not
| bother if I have to make a new account.
|
| That said, which one it is matters. My order of preference is:
| Apple, Google, more minor players like GitHub, and way at the
| bottom of the list, I won't use Facebook's.
| Larrikin wrote:
| What security do you get from them that you don't get from a
| password manager and a random password for every service? I
| specifically avoid all external OAuth flows for my personal
| accounts because there is almost always an extra data grab
| associated with it.
| creato wrote:
| Password managers have a few problems. Sometimes they just
| don't work well (e.g. banking sites that partially
| obfuscate your username really confuse them). Sometimes
| websites make it hard to copy and paste passwords. Apps
| don't always work with password managers, requiring
| manually retrieving the password. But mainly, password
| managers are inherently a bit scary as a single point of
| failure. You might say that OAuth has the same problem, but
| I think it's better because no passwords are stored
| anywhere (even if encrypted), and I use a hardware 2FA key
| for my preferred OAuth account.
|
| I think the concern about "data grabs" is a bit overblown.
| I don't believe the OAuth logins that inform you of what
| information is being shared is lying, and if I don't like
| what is being shared I won't use it.
| zmer wrote:
| I agree. Given randomized passwords I don't see any risk
| with individual sign-ups rather than login partners. I will
| not sign up for a site/service if it only uses login
| partners for authentication.
| AlexandrB wrote:
| It's interesting how modern tech companies took Microsoft's
| "Embrace, Extend, Extinguish" playbook and ran with it. OAuth
| was supposed to be a standard that allowed interoperability but
| instead each company enforces the use of their own OAuth
| SDK/variant (see also Login With Apple).
| akerro wrote:
| What about https://www.keycloak.org/? Is it any good for such
| solution to half-own OAuth provider?
| oblio wrote:
| Debatable. You could implement the login with
| Google/Facebook/... APIs and not use their official clients,
| but many companies don't bother.
| yoavm wrote:
| It's apparently forbidden to implement the API directly
| without using the SDK when developing a native app.
|
| https://github.com/facebook/facebook-ios-
| sdk/issues/1385#iss...
| mschuster91 wrote:
| Facebook SSO is extremely convenient for the end-user: most
| people have an FB account and it's literally three clicks tops
| to get logged in, vs manually filling out a registration form,
| thinking of/remembering a password, confirming the email
| address...
|
| Also, it cuts down on support requests of the type "can you
| reset my account password?" / "can't login" massively.
| kochthesecond wrote:
| Login with Facebook tremendously reduces friction on signup. We
| get a verified email that we can trust, the name of the
| customer and a profile photo that automatically renews. But
| even more important we dont need to ask for a password.
|
| We can also ask for more, such as phone number (we dont ask).
| orasis wrote:
| Most of us app developers don't use it for login, we use it to
| optimize Cost Per Install campaigns when we advertise on a
| Facebook property.
___________________________________________________________________
(page generated 2020-07-12 23:00 UTC)