Aaron Parecki

This will work well to test your webmention endpoint offline: https://github.com/voxpelli/node-webmention-testpinger

You can also install https://github.com/aaronpk/webmention.rocks and https://github.com/aaronpk/micropub.rocks locally, but they are a little more involved. I run both locally to test my development environment.

@schoschie That's crazy! This is a Lebara SIM, 3gb for 15€/month! (No voice or SMS, but I do that through Google Voice and iMessage)

The "Left" room is working on IndieAuth things if you want to come ask questions!

@reidab Yep the book bret recommended is great. I had the best luck reading a chapter and then practicing using the iOS "Ham Boss" app

This is great! Now I want to do something like this on my site too!

@btconf Thanks! Very excited to be back!

:sigh: at least it didn't crash my site!

Strange, it was doing pretty well with matching alternate codes for the other flights I was testing with. (I was at the gate watching other flights depart to use as my test data.) I'll have to try again with BER next flight!

@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

@rogue__leader Thanks! That, or launching Safari or the service's native application. SafariViewController will provide the best UX.