Aaron Parecki

@amreldib yeah I'm skeptical it's going to automatically figure out my sleep patterns while traveling, despite the app knowing my location

@uhhyeahbret Yeah! It's functionally the same, clearing up some ambiguities and improving the language. Hopefully see you tonight at HWC?

@rogue__leader so some services use the password grant to exchange a un+pw for a token, and build the login interface natively.

@rogue__leader Well for first-party apps there isn't really a phishing risk, it's normal to type your password into the service's own app.

@rogue__leader Yeah the Google case is interesting since they're doing it with their own apps!

@rogue__leader The Google Inbox and Voice apps do it! I know I've used a couple more, but can't remember off-hand.

@rogue__leader Yeah sorry, 140 chars isn't enough 😭

Before SFSafariView, the only way to securely do OAuth was to launch the native Safari browser. This meant you'd get bounced out of the app, which a lot of developers didn't want to do to their users. I don't disagree that this was a bad experience, and plenty of people feel the same.

What ended up happening is people instead started embedding the WebView into their apps, in order to avoid having their users bounce out of the app and come back. The compromise in this case is that people would have to type their password to log in, because the embedded WebView doesn't share cookies with the system browser.

It took Apple a long time to roll out SFSafariView, so there are just a lot of apps out there that still have the embedded WebView.

Advantages of WebView:
• Does not make the user leave the app to complete the OAuth flow

Problems with WebView:
• User has no way to verify they are on the real website, so phishing attacks are undetectable
• Does not share system cookies, so users have to type their password every time

Advantages of SFSafariView:
• Does not make the user leave the app to complete the OAuth flow
• The user can see the address bar so can verify they're on the correct website
• Shares system cookies, so the user won't have to type their password if they've already signed in using the native Safari app

I should probably turn this into a proper blog post.

@rogue__leader SafariViewController is the best of both worlds. Visible URL, no bouncing out of application, shared cookies.

@rogue__leader The problem with embedded WebView is users will have to type their password there anyway, since it doesn't share cookies

@rogue__leader Prior to SafariViewController, devs weren't willing to bounce ppl out of the app, the only other way to have a visible URL