Several days ago I began work on Turpentine, a Twitter client written in Ruby that currently runs as a CLI. After I got things working to my satisfaction, I decided to add OAuth — partly because the whole project is meant to give me exposure to a variety of stuff I’m not familiar with, and partly because Twitter will remove basic auth at some point in the future.

After going through the Ruby on Rails example, I got stuck at the post-authorization point — the example assumes the user will be in a browser, which obviously doesn’t work for me at the command prompt.

I tried to figure out the solution using the sample code and the OAuth gem it uses, but it was beyond my level. (Though I did learn that all the OAuth information is passed around using query strings.) At this point I decided I’d give up on trying to write the code myself, and switched over to the twitter_oauth gem. The sample code was tremendously helpful, and needed only a little modification to handle my scenario.

---

Because I’m working purely in Ruby in the moment, I’ve kept things simple by using YAML to manage login information.

Step one is to load the config.

CONFIG_FILE = 'config.yaml'
CONFIG = YAML::load(File.read(CONFIG_FILE))

The relevant part of the config looks like this:

oauth:
    consumer_key:
    consumer_secret:
    request_token: 
    request_secret:

I’ve registered my application for Oauth, so I’ve filled in the consumer_key and consumer_secret fields. (Not shown because the secret must be kept secret.)

Note: if you’re going to use the command prompt like I am, specify that your application is a client, not a browser.

Back to code. I begin by loading the values:

consumer_key = CONFIG['oauth']['consumer_key']
consumer_secret = CONFIG['oauth']['consumer_secret']
request_token = CONFIG['oauth']['request_token']
request_secret = CONFIG['oauth']['request_secret']

Check if the application has been authorized (i.e. check if the request_ fields have any information):

if request_token.nil? and request_secret.nil?
  # not yet authorized
else
  # authorized
end

Authorization is the most code-heavy part of the process.

if request_token.nil? and request_secret.nil?
  client = TwitterOAuth::Client.new(
       :consumer_key => consumer_key,
       :consumer_secret => consumer_secret
       )
  request_token = client.request_token

  …

Here, we give twitter_oauth the application’s key and secret and let it work out the address that we’ll use to authorize Twitter access.

  …

  puts "Please open the following address in your browser to authorize this application:"
  puts "#{request_token.authorize_url}\n"

  puts "Hit enter when you have completed authorization."
  STDIN.gets

  …

The user is then prompted to open the address, which will ask if they really do want to authorize the application:

Finally, we put the user’s new request token and secret into the configuration file:

  …

  access_token = client.authorize(
      request_token.token,
      request_token.secret
  )

  File.open(CONFIG_FILE, 'w') do |out|
    CONFIG['oauth']['request_token'] = access_token.token
    CONFIG['oauth']['request_secret'] = access_token.secret
    YAML::dump(CONFIG, out)
  end
else
…

Things are a lot simpler if we’re already registered:

…
else
  client = TwitterOAuth::Client.new(
    :consumer_key => consumer_key,
    :consumer_secret => consumer_secret,
    :token => request_token,
    :secret => request_secret
  )
end

Now that we have a functional login, we can use the gem’s built-in functionality to do useful things like get the friends timeline:

puts client.friends_timeline

And proceed as if everything used basic auth.

Transcription of Citizen Garden episode 9, ‘Opening Preconditions’.

This one was informative for me because although I was vaguely aware of Ma.gnolia’s plans for their version two release, I didn’t know about the technical aspects — requiring OAuth, self-hosting, and open source code.

The discussion about using OpenID and related ‘open web’ technologies to automatically tell web services where things is quite appealing. This podcast episode is from late August, so maybe work has already begun on implementing such concepts.

But the most interesting part, to my mind, was the idea of using the fact that services tend to come in categories — bookmarks, social networks, and so on — we can export data from those services on a regular schedule and back it up for safekeeping. Then, if we decide to move services (e.g. MySpace to Facebook) or the service goes offline, we’ll have full access and control over our ‘social objects’.

If you think about it, this is really why the open web movement exists. The open web revolves around the idea that if I put information into the system then that data belongs to me. If I fill out a Facebook profile or use Twitter or make a bookmark on delicious, it’s true that somebody owns the system that allows those things — but what use would the system be if I didn’t use it?

So it’s about ownership. But ownership implies freedom — freedom to do whatever I want with my information, since I control who has it and what they can do with it.

This is something that companies offering hosted services dislike. Their business model is generally based on the idea that once you put your information into the system it’s stuck there. Investors see much more revenue potential in a captive audience, because the audience has no choice but to use whatever’s being offered, unimpressive as it may be — a non-technical example would be product placement.

And this is where the whole idea really becomes useful. An important part of the open web is data portability — the ability to easily transfer my information between services. Suppose I’m on Facebook, and I decide I want to try a different social network. With data portability, I’m able to tell the new site about my existing Facebook account and let it import all my friends.

This means that the power situation is changed. I’m no longer stuck using whatever site my friends have chosen. I’m no longer forced to trust that the site I’m on will continue to provide new features and a useful service. Instead, by using a service I’m actually endorsing it, because I’m not obligated to stay there.

It also entices the site’s owner to improve their service. When a site maintains its user base through feature offerings, they’re less able to simply make something good and then let it sit. Innovation is hard, but when it works everybody wins.

But despite all that, I set out to publish a transcript, not an essay. Here we go!

Participants

• Larry Halff
• Scott Kveton
• Chris Messina
• Will Norris

Transcript

LH: Hello!, and welcome to episode nine of Citizen Garden. I’m Larry Halff…

CM: I’m Chris Messina.

SK: I’m Scott Kveton.

WN: And I’m Will Norris.

LH: And we’re here today… I’m freshly back from Seattle after making a big announcement at Gnomedex that Ma.gnolia is being rewritten from the ground up as an open source, downloadable tool. Actually, it’s being broken up into several pieces. I think that’s the more important announcement; there’s a lot of open source publishing platforms out there… blogging tools, there’s even, y’know, I think, a handful of open source social bookmarking systems. A more important thing about what we’re doing is that we’re really trying to pave the way forward with the open web, and part of that is getting these decentralized and federated systems talking to each other. And open source happens to be one way to advance that cause.

CM: Let’s back up here a little bit, ‘cause I’d like to sort of understand better where this idea came from — why you would take this approach when, y’know, you’ve built up a pretty good audience on Ma.gnolia, you’ve got a good user base there, and you’ve done really well so far in supporting a number of these open protocols like OpenID and supporting microformats and OAuth and so forth. but how does open source or open sourcing the platform actually support the open web — and what actually motivated that decision?

LH: Well, I think the primary motivation was seeing that the social aspects of these publishing tools doesn’t really scale when there’s the big single point of failure. and Ma.gnolia has had downtime, Twitter has the infamous ‘fail whale’, Flickr gets massages — and all these things happen, and when it happens you sort of… you lose access to a pretty important piece the flow of your online life. And as they grow, the load that’s caused by exponentially putting out… the exponential effect of putting out all these social connections and publishing and keeping everyone up-to-date just doesn’t… just isn’t really gonna scale in the long term. And I think, y’know, what we’re seeing with Twitter now is nothing like what we’re gonna see with that kind of tool down the road. I mean, hardly anyone really uses Twitter…

SK: Yeah, like a million users maybe.

LH: So I think we really see an important next step is to finding out a way that these things can be pushed out to the edges, yet still have the social functionality of getting everyone talking to one another.

CM: Now one of the things I think, y’know is interesting… so, Scott is with us at Vidoop; he’s also the chair of the OpenID Foundation, and he’s, y’know, sort of one of the champions of decentralizing identity and things like that. I think it’s sort of interesting to think about how OpenID in some ways creates the preconditions for Ma.gnolia going open source, by allowing people essentially to have sort of a cargo horse on which they stack a bunch of things — their photos, their bookmarks, and so forth. Maybe you can — Scott — talk to us a little bit about how you see OpenID maybe as that beginning point that… allows for this type of decentralization that Larry’s talking about, where there are much fewer single points of failures, or at least these concentrations that maybe are creating these pressures on the network.

SK: Okay! Uh, yeah, absolutely! So there’s, y’know, we’re three years into OpenID now, and it was really funny at OSCON, actually — and I think Chris you were on that panel with me, weren’t you?

CM: Possibly, yeah.

SK: Leah Culver got up…

CM: Oh, right.

SK: … started just dropping f-bombs about how she just thought OpenID was dumb, she’d never use it, da da da da. And y’know, in reality, it’s… it is a URL-based system, and that’s just… users have not, y’know, grokked that. But I think what we’re starting to realize is the value is proving a potential service endpoint, which means nothing to users.

CM: [Nor necessarily?] should it…

SK: Right, absolutely.

CM: For now.

SK: … but for developers it’s extremely important. So, y’know, some of the challenges that we’ve been facing in the OpenID community are around security and usability. If we can make it easier for people to identify themselves — whether with an email address or identity in the browser — then they can get in, prove that they are some end point without having to know what that endpoint is, and then start to put their data there. and then we start that… that lays the groundwork for things like y’know, lower-case data portability and the ability to, y’know, have more control over who provides your… or manages your data.

CM: Yeah, I’ve been thinking about these things lately, and it… it’s interesting to reflect on what assumptions we bring to these problems, especially around sort of, as you talked about, the developer part of the equation, where you’re starting to think about and understanding well, if a developer starts to tackle a problem, trying to build a new service on the social web, what assumptions can they make today that they couldn’t make before? And previously maybe you made an assumption that people would have an email address before; okay, great, then you could send them a password or a token, and they can prove received that token — that’s a way of confirming… that’s a durable identifier, but you can’t really attach services to it. You can’t actually look up that email address and ask it, y’know, ‘well where is this person’s photo store’, y’know, ‘where is this…’ — there’s no directory for that. Using URLs as identifiers sort of helps to at least make that situation a little bit better. So I’m actually interested in hearing from Will, ‘cause Will and I work on the DiSo project together. How do you think the ability to use unique URLs to identify people — which then have services offered at the end of them — changes what you can sort of take for granted? What are the building blocks now, that when you approach building a new application, you’re like oh, well they probably have identity, they probably have, y’know, some service that they’re gonna use, we’re just gonna throw it all together and make it happen?

WN: Yeah, right. I mean, we’ve been trying to address those exact problems of ‘how can we build that infrastructure so that you can take advantage or take it for granted?’. And like you said, y’know, you can’t attach these services to email addresses. Recently, I co-authored a spec — and we’re now using this with a lot of our stuff — called ‘EAUT’, which is e.a.u.t. It’s Email Address to URL Transformation. It basically allows… it’s a really standard way of taking that email address and talking to whichever email provider it is that provides that, and say, y’know, ‘how can I turn this into a URL that I can then go and try to find these kinds of services on that URL?’. So y’know, Yahoo! can host their own thing, Google and all this, and then we also have this fallback service. But the idea is that, so, we can use an identifier that users are familiar with, and comfortable with, and use everyday, and they love — it’s their email address — but still be able to get these additional kinds of things. So, y’know, when I go in to whatever it is, I can give my email address, it can be converted into an OpenID; this application can then go and look at my OpenID and say ‘hey, y’know, we need to publish a bookmark, where should I do that?’ And, y’know, I could be doing that on Ma.gnolia proper, or if, y’know, I have my own Ma.gnolia instance running, with the new open source version, or if I’ve, y’know, maybe… maybe Vidoop, y’know, we set up our own, for our employees, I can say y’know what, that’s where I do mine. And so all I have to do is present my identifier, and, y’know, magic happens, basically, and this consumer can push that bookmark out to wherever it is that that I store them.

LH: Right. I think it’s important, it’s like that’s another precondition we haven’t explicitly mentioned. It’s like, we have the… we know identity exists, and we also, with the unsung but super-important spec XRDS Simple is really key to making that happen, because at least for programmers, it’s like, they can go to the end of your OpenID, and they can say ‘well, this is someone’s identity URL’, and they can get a whole bunch of links off of that. But they’re really meaningless until we have a way of saying ‘what do each of these links do?’, and so I think, I just… point that out as a key piece to that, which isn’t just having the thing, but also having the mechanism to say ‘what can we do with these different things?’.

CM: To put that another way, it’s kind of like when you go to someone’s blog and they have a sidebar that lists all their other profiles. What we’re trying to do, I think — and this is sort of what this discovery protocol is all about — is taking that list of URLs and making them make sense to computers, essentially. So that when it sees a Twitter icon, y’know, more or less, it’s like ‘oh, that’s a status update service’, or ‘that’s a microblogging service, therefore I can post messages to it, if I’m authorized to do so’. Very similarly, if you see a little Flickr icon, or if you see a YouTube icon, those are different services that someone might use that actually have APIs that you can talk to. So if you can advertise those URLs through this discovery/specifications at the end of an OpenID identifier, that’s where the magic starts to happen. So, what I was actually interested in hearing you two guys talk about a little bit — and recently, y’know, you’re wearing the WordCamp shirt, and you were at WordCamp, will, and you talked about OAuth for WordPress. and this is, I think, very interesting, because we’re at a point where WordPress currently does not support OAuth. Most of its transactions are done with the standard username and password, which means that if you wanna, let’s say, blog from your iGoogle home page, you’re gonna have to enter in your WordPress username and password into iGoogle. Well that’s great, except when you start doing this across the web and so on, and that’s the password anti-pattern. now on the other side, we have Ma.gnolia, which already supports OAuth in the platform. And I’m interested sort of in hearing you guys talk a little bit about the pros and cons and the challenges of retrofitting OAuth and authorization-based permissioning into a platform like WordPress, whereas Ma.gnolia already has that — Ma.gnolia open is gonna come out supporting that from the get-go — what does that mean for people building on these different platforms? How does that actually improve the situation?

LH: I think it improves the situation that enables a lot more seamless experience for the end user that… I think combining OpenID with discovery with something like OAuth is, y’know… this is a whole lot of hot air, so I’m ashamed of the words that are about to leave my mouth, but the browser of the future…

CM: Uh-oh.

LH: There, I did it.

?: He did it! He did it!

LH: … will be like…

SK: Tshirt’s already been ordered.

LH: The browser of the future…

CM: dot com!

SK: That’s right. Do we have that yet?

LH: … when I go to save a bookmark, instead of it saving in by browser — it will have known my OpenID already, because when I launch my browser and it’s first setup, it says ‘what is your OpenID?’ — it will have verified that, it will have discovered my online bookmarking service, and it will know where that lives, and as part of that process it will have authorized access to my bookmarking service account though OAuth, and I will have said ‘yes, this browser allowed to post things to my bookmarking service’. And so ‘save bookmark’, it will be seamlessly integrated to me. And that really is the end-user benefit for all this, despite all the horrible, geeky, completely incomprehensible nerdiness and the ongoing usability issues with OpenID, which Ma.gnolia open has cracked open again.

CM: Yes.

LH: If you wanna participate in a great little thread about OpenID usability, go to the magnolia-2-discuss group on Google.

SK: Yeah, y’know, if there’s one thing I’ve learned over the last three years of the OpenID stuff, is it doesn’t matter how open it is, if it’s not usable, it’s broken. And so that means, y’know, I think usability has to come first, and I think we have to break some things around the openness of it to get it right first. And we’re seeing, y’know, Facebook — we were talking about this today. Y’know, what Facebook is doing sort of, y’know, in the eyes of a lot of folks who are very open-centric — which doesn’t really make sense, but anyway — they see that as awful, because they…

CM: Whoa, wait; be more specific about what Facebook’s doing.

SK: Well, they’re embedding an <iframe>, effectively, on other sites — and this is effectively what Google is doing as well.

CM: That’s right, that’s right.

SK: And, y’know, that’s all well and good for the sites themselves — they don’t actually get the access to the user information — but, they can get more people and pageviews, which could be really important to them. but from an open perspective, it’s not that open, to be able to do that. And… what’s the other thing I was gonna say? God, this coffee really does — oh my god! sorry.

LH: These guys bought you Blue Bbottle before?

WN? Sponsored by Blue Bottle…

LH: I am writing without Blue Bottle here.

CM: It’s a plug for the [something]. Oh my god.

SK: It’s good stuff.

LH: But, so I mean… so I think we were getting… we were also talking about the whole convergence to this stuff, and what’s, like, what’s… the work you’re doing with WordPress, and like, where’s… do you see that headed in a similar direction? Is WordPress thinking about this?

WN: In a similar direction as..?

LH: As sort of, like, end-to-end integration…

CM: Well the interesting thing is that Weave — which is a Mozilla Labs project — is kind of in that direction, where it actually does kind of what you described, Larry, in allowing you to kind of sign in with some accounts, through OAuth actually authorize the browser to both publish your bookmarks and download ones that you’ve already saved — very much like a MobileMe for the rest of us, in a sense, for those of us who are not gonna pay Apple or whatever to do so. And all of… the entire sort of service stack of MobileMe could be more or less built on open technologies. It’s interesting, though, to think about what it would mean for someone like WordPress, or even someone like Drupals of the world and so on to really embrace some of these technologies, and to look at the opportunity that the browser, y’know, deep browser integration and web service access and offline storage, to some degree, would offer. And so I guess the question for Will is sort of around, y’know, what would OAuth mean to the WordPress platform? How would that accelerate the development of things, how might that make WordPress a different type of integral platform for publishing all sorts of different services on the web, perhaps?

WN: Well I guess, I mean… the most immediate use case, I think, that we’re gonna see with getting OAuth into WordPress is just allowing whatever service it is to publish to WordPress without needing the user’s credentials. So, this could be something like the WordPress iPhone app, this could be MarsEdit, it could be… Flickr already has a way where you can push your photos directly from Flickr into your WordPress blog…

CM: Well Ma.gnolia 2 actually offers publishing your bookmarks to your blog.

WN: Oh, does it?

CM: But right now, I believe, you have to take… it’s the password anti-pattern.

LH: Yeah. It’s the password… nobody… yeah. The major blogging platforms except for Blogger — which we don’t support because they don’t use the MetaWeblog API — use OAuth authentication. And I mean, that’s great for Google [something].

CM: And Movable Type is going to be supporting OAuth in the next release, I believe.

SK: It’s already out.

LH: It’s already out.

SK: The libraries are there, they’re in the core release… four, two, whatever it is.

CM: But still, we’re still at a point where we need that deeper integration, but…

SK: Well, yeah, and just kinda playing off that a little more is that a lot of people that I’ve seen are using WordPress as kinda more of a persistent storage of their social objects. Y’know, with Ma.gnolia, y’know, you have… there’s things going on with Ma.gnolia, but, y’know, Ma.gnolia might go away tomorrow, or I might wanna move to some other platform, so I wanna have a copy within my own control. So, y’know, I do a nightly pull or push or whatever to my blog. People do that with their Twitters — er, their tweets, y’know, they’ll do a day’s worth of tweets as a blog post.

?: My tweets are very important.

SK: Well yeah, absolutely, that’s how people feel. And whatever that…

LH: Live coverage of the Olympics…

?: [something] my addiction.

SK: So yeah, I mean… just simply using WordPress as kind of a persistent storage of these objects that are within the individual user’s control. And in order to make all that stuff happen in a secure way, yeah, absolutely, you’re gonna need a secure mechanism for pushing that in, and that’s gonna be OAuth at some point, once we get that built.

CM: And I think… well I dunno, we probably should wrap up pretty soon…

LH: I think we’re heading towards that.

CM: Yeah, well… so I guess actually we could close on some final thoughts, since this has sorta been a whirlwind discussion… and there’s much more, obviously, we could talk about. What it sounds like you’re talking about — I really like the way you framed it in terms of kind of your store for social objects, your generic store, is that increasingly we’re gonna have specific tools that do a good job at storing different types of social objects and providing metadata around those objects. So we’ll have Ma.gnolia, the Ma.gnolia bookmarks is like the WordPress of bookmarks in a sense, so you might use your self-hosted WordPress — I’m sorry, Ma.gnolia install — to host bookmarking-type things, which have certain screenshots of the webpages, maybe some tags, so on and so forth…

LH: And have access to all that’s going on out there.

CM: Right. And maybe you’ll also be able to push those bookmarks out, and also pull things in via that type of channel, because again, that channel is designed specifically for those types of objects. Then you have your Flickr, which might be a better photosharing application, or maybe you wanna use Facebook to view photos. I mean, who knows. Whatever the case is, moving these objects around into different web applications seems to be where this is gonna go, and being able to push the data around fairly [in a] fairly straightforward way using OAuth to control sort of who has access to read/write, that’s important, and then coming up with the standard protocols so that each endpoint kind of understands what kind of data is being pushed around is also a matter of import, I think, as well. So it’s really interesting to think about how we can actually move to real cloud computing using these types of protocols. So that was a longer closing from me, so what do you think?

SK: Yeah, I think… I think as we move closer and closer to having… putting users in control of their data — and I actually really like that term ‘social objects’ — because to me social networking actually isn’t something you do on the internet, it’s just a feature? And especially when you apply it to things like bookmarking services or photosharing sites, I wanna be able to bring my social network along with me. It should just be a foregone conclusion. And so to me, the work that we’ve all been doing has been headed in the direction. And, y’know… good stuff.

WN: Yeah, me too. Plus one. Plus one!

SK: Plus one for me.

LH: I think for me, it’s like, what we’re gonna be seeing next, since — is that mandatory, do you have to close with ‘what’s next’?

CM: No.

SK: Absolutely!

LH: But I’m gonna do it. What we’re gonna be seeing next is — and Ma.gnolia isn’t the first — but we’re gonnna be seeing these kind[s] of services becoming more decentralized, which means… which means creating another problem. But the ‘more decentralized’ means more reliability, more control, more adaptability to individuals’ needs. But that removes a lot of social functionality, removes a lot of community, removes a lot of interaction. So we’re gonna be seeing that problem solved. We already know how to decentralize; we do it with blogs. It’s there. But we’re gonna be seeing the federation problem being solved over the next few months. And we’re gonna see how we can bring those together in more of a ‘small pieces’ type solution [something] social network.

SK: We’re gonna solve the problem in six months?

LH: Yeah. Yeah.

SK: All right, let’s go.

CM: We’ll be there.

LH: High five.

?: Yeah!

CM: So just one more plug for… it’s Ma.gnolia.org is where you’re gonna find this stuff, and it’s ma-dot-gnolia-dot-org, that’s where you can find out more about the announcement, the m2 — as it’s being called — charter, and…

LH: And the Google group.

CM: Yeah.

LH: Come and join and contribute to the discussion.

CM: There you go.

Transcription of Citizen Garden episode 10, ‘Phish My Phail Whale’.

This took about four and a half hours to transcribe, and another to edit for publication — not a very good rate, but this is my first attempt at something like this. I think podcast transcription is important, if not necessarily exciting — even ignoring the accessibility issues of podcasting, transcriptions allow search indexing and make it more convenient to refer to topics that are discussed.

I’m willing to do more of this sort of thing for interesting material, though I’m not sure I’d want to go much longer than the half hour presented here.

PS: I’m not sure what would be the ideal markup for transcriptions, so I’ve made a guess based on an Adium message style I wrote that’s in turn based on an experimental conversation microformat which has since disappeared from the microformats wiki. Suggestions for improvement are welcome!

Participants

• Larry Halff
• Chris Messina
• Alex Payne

Transcript

LH: Hello, and welcome to episode ten of the Citizen Garden Podcast. I’m Larry Halff…

CM: I’m Chris Messina.

LH: And today we are joined by…

AP: Alex Payne, I’m API lead over at Twitter.

LH: So it’s been an exciting week over here…

CM: Yeah, it’s actually, it’s been a while since we did our last podcast.

LH: It’s true. But this is episode ten, which means we actually did nine of them last year.

CM: That’s true, so that’s not too bad; that’s almost once a month.

LH: Almost.

CM: Almost, y’know. That’s like a baker’s dozen.

LH: I don’t think that’s how they were distributed, though.

CM: No. Anyways. So, it’s January seventh, happens to be my birthday…

AP: Happy birthday!

LH: Happy birthday!

CM: Thank you. We’re talking today about Twitter, but in the context of perhaps a larger story around security, phishing, authorization, identity, blah blah blah, all that good stuff. Maybe for some background, Alex, you wanna tell your story or your impression of what actually happened in the two incidents that seemed to cause so much controversy over the last week.

AP: Sure. So, sometime over this past kinda New Year’s holiday weekend, we started noticing several phishing attacks going around. The first one was pretty benign, and then the subsequent ones seemed to grab a user’s account and sent around some direct messages propagating links to not just this Twitter-oriented phishing site, but also to phishing sites for Facebook and a couple of other social networks.

CM: This is, like, the access-logins.com website.

AP: Yeah, which could not be a more blatant… I mean, we were joking about it around the office. It might as well have been phishing-site.com, but…

LH: I got that one link!

AP: Yeah, I’m registering that domain when I get home, actually; backup career. But, so, it turns out phishing… we think of Twitter’s user base as getting more mainstream, but the core of it is very techy; but even against our relatively techy userbase it was still pretty successful. So, our administrators and support folks spent a bunch of time clearing out affected accounts and resetting passwords for people, trying to scrub out the phishing URLs, and we mostly put a stop to that. But just before that crisis ended, someone decided to use a dictionary attack against one of our support staff, and she happened to have a common dictionary word — ‘happiness’, since it’s been reported in the news. It’s…

CM: It makes me happy that that’s her password.

AP: Yeah, I mean, I’d love to log in with that password every day, but… so, a dictionary is just… you try every word in a dictionary against a username. It’s been an attack people have been using since back in the days of VAX systems and that kind of thing. And unfortunately it still works, and because we didn’t have any rate-limiting on authentication, we didn’t force people to solve a CAPTCHA or do something like that after they’ve logged in with lousy credentials too many times. So, we fixed that —  it’s reactive security in action! — and we’ve now got all of our support staff using strong passwords, and I’ve been encouraging people to use a great tool for the Mac called 1Password, which lets you generate strong passwords, store them, that kind of thing. So, we’re talking a bit more internally about building security into our day-to-day practice. It’s something that I think is really difficult for a fast-moving business to do. You wanna spend your time building exciting user-facing features, not locking stuff down, but it’s just the reality of being on the web. There’s lots of bad folks out there.

CM: Now, what kind of background would you say you have in security issues and things like that? What kind of experience are you bringing to this current situation?

AP: I’ve kind of bounced back and forth between doing web development and doing security stuff. Actually, one of my very first jobs when I was still a teenager, I was a web developer, and the company got broken into, someone decided to…

CM: … physically, or..?

AP: Electronically.

CM: Okay.

AP: So, someone decided to use our server to hang out on chat rooms in Lithuania or something, and trade warez and that sort of thing.

CM: There’s like ten people in Lithuania, so it’s…

AP: Right, and they were all on this IRC channel. So, I got a very rapid education in, y’know, all right, this is how we wipe and reinstall machines, secure it from the ground up. I got really interested in intrusion detection, all that security stuff that big in the ’90s, and just kinda continued down that road. I spent a couple of years working for a sorta information-security–oriented government intelligence contractor, and there I continued to do sort of a mix of web stuff with towards security. And as a hobby around that time, some friends of mine and I helped run the hacker game at the DEFCON conference every year, ‘capture the flag’. So, we competed in that one year, and then this group of friends took it over, and they’re still doing that. Most of them are back on the east coast. That was fun. I got to write web apps and see if they stood up against the best hackers in the world, and that sort of thing. So, security’s been both a hobby and sort of a professional thing for me, from time to time.

CM: so that brings up an interesting point… I was sort of aware of some of your background in security stuff. It kind of leads into a question about Twitter, of course. I mean, if this was your hobby, and you’re the lead of the API stuff… Twitter is more or less a porous application. I mean, it’s been reported, actually, I think in 2007, that most of your traffic comes from off-site sources — meaning that people are not coming to twitter.com, necessarily, and interacting with the service; they’re doing it from Twitterrific or from other applications, or third-party websites like [Hahlo?] and things like that. So I guess, the first part of this question is ‘how secure is Twitter’? I mean, when people are using it and so on… if you were back playing capture the flag, how long would it take you to capture the Twitter flag?

AP: Well, I think there’s sort of a couple of things. The first is that most of the information on Twitter is designed to be open. People can have protected accounts… my personal opinion is that I wish we didn’t have that feature. I feel like people get so much more out of Twitter when they have a public account. I know that there are some people who just aren’t comfortable with taking their thoughts or taking their social network out in the open. So we accommodate them, but it’s a relatively small part of our userbase. And one of the main problems we’ve had over the past couple of years has been ensuring that protected accounts never leak. We’ve definitely had points at which our API has inadvertently exposed people’s protected tweets because our code has to accommodate this complicated privacy intersection of ‘user a is looking at user b’s friends, which can include user c, who may or may not have authorized user a, but has authorized user b’. And with all the caching logic and stuff in the middle of that, there are bound to be bugs, and there have been security problems around it. That’s, I think, the biggest issue we’ve had with Twitter. I’m pretty confident, given that we’ve got two different test suites now for the API, one sort of baked into our application and one completely external, that look for some of these security issues… and we’ve hired other kind of security-minded folks — one of our hires last year was John Adams, who was a member of the l0pht hacking group back in the day…

CM: He also wrote some of the Declaration of Independence, I heard… sorry.

AP: Took me a second. So, between John and I and the other folks, we’ve tried to sort of, in our spare time, look at Twitter from a security perspective. I wish that we could say that we’d done a full security audit and that we’d brought in an outside team — that’s one of the things I’m hoping we can fit into our schedule sooner rather than later.

LH: One of the interesting things is the phishing attack that happened. It’s sort of like, outside of the realm of a lot of the standard security procedures.

AP: Oh, sure.

LH: And it’s like, very… securing your site against, like, engineering-type hacking is very different than trying to secure your against social-type hacking. And it’s really easy to hack around sites where you’ve tried the security and social hacking. So, for instance, it was one of the things — I think it was even someone [who] was at the OAuth summit, or was it the OpenID summit? — they were talking about one of the new anti-phishing things is showing… you pick an image when you log in…

CM: Site seal.

LH: … the site seal idea, which a lot of banks have now. But they found basically, you can trick people out of that almost all the time by saying ‘site seal is not available at the moment’. So people read that and say ‘oh, well I can’t get my site seal, but I need to get to my bank account, so I’m gonna sign in anyway’.

CM: You should just put, like, a broken image or something like that.

AP: And I mean, certainly the fact that most of our longer-term users know that we do occasionally enable and disable features depending on traffic and that kind of thing; they’re used to saying ‘well, I can’t get to this part of Twitter right now’, so I don’t know how effective that would be. This other social kinda web-oriented security thing that’s come up is just… we’ve had problem after problem with sharing stuff via JSON, having callbacks, and… you’re trying to support mashups… a couple of folks — older, kinda comp. sci. folks — that I follow on Twitter have joked at times that from their perspective, the whole social web is kinda one big cross-site request forgery attack. Y’know, if you’re not involved in the social web culture day-to-day, where you’re excited about this stuff — if you come at it from more of a privacy perspective, it’s like ‘this is really scary’. Y’know, the whole mashup thing is basically… it takes advantage of the fact that browsers still have a pretty primitive security model. I sorta wonder how much of the mashup culture if people went back to the drawing board with browsers; went back to kind of…

CM: Well, if they did it the right way.

AP: Yeah, basically.

CM: Yeah.

AP: Yeah, so, we’ll see. And people having to come up with really complex solutions for that.

CM: Yeah.

AP: Like Yahoo! sort of turning Yahoo! Mail into this host for JavaScript apps, mashups, and that kind of thing. But they’ve had to implement…

CM: Basically they have to rewrite JavaScript.

AP: Yeah, Ben Laurie’s Caja project, which is a whole capabilities-based secure reimplementation of JavaScript. So, y’know, that’s pretty heady lengths to go to just to be able to support mashups. But over and over again, we’ve had people point out that ‘Hey, I can get to this data via Javascript, and a malicious site can control it’ because some old browser allows them to redefine the array data structure, or take control of callbacks, or that sort of thing. So that’s another area where we’ve had to be reactive and not proactive because, y’know, the community has been out there finding all of these bugs that you wouldn’t find if you sat down for a hundred hours.

LH: There was sort of…

AP: And the other thing is…

LH: And the angry mob sort of misguidedly decided that the solution to the phishing attack was the long-awaited Twitter implementing OAuth. So the meme went around of, like, ‘Why hasn’t… I’ve been phished; why hasn’t Twitter implemented OAuth?’.

CM: Well, the password anti-pattern became kind of a household word, like, over the past two weeks.

LH: It was like… people… it was pretty wrong, because OAuth is not… would not secure against phishing.

CM: … would not have solved these problems.

AP: Right. Yeah, I mean, it’s become so much of a household concern that I was talking to a reporter the New York Times about it the other night, and she was asking for sort of a layman’s explanation of OAuth — but, thankfully, she read enough of what was going around on the web that day that her angle on the story wasn’t ‘if only Twitter had put out OAuth there would have been no phishing.’

LH: Wouldn’t that be great if OAuth had solved all phishing?

AP: Or OpenID, for that matter.

CM: It basically… it made everybody like fifteen IQ points smarter. It’s amazing! It’s amazing what the internet does.

LH: I mean yeah, so it’s like, I think that’s the problem, it’s… when people start doing armchair security…

CM: Let’s talk about that, though. that’s… I think on the one hand, there’ve been, y’know, some of us geeks that are out there, sort of pushing the meme of the password anti-pattern, because it is actually something that people should take seriously. More from the perspective that, y’know, just like with good… what I call ‘data hygiene’, you should be checking out the URLs of the sites that you’re visiting and so on to make sure that they are actually Facebook and not facebook.access-login.com, you should be considering where you put your password in on the web. And one of the problems we’ve seen is, of course, that with Twitter, on the one hand, you can make the argument that no, it’s not your bank, so you’re not gonna go broke if someone hacks your account —  but on the other hand, there’s a point to be made that Twitter stores a great deal of what I call sort of ‘data capital’ or ‘social capital’, and that if someone took over one of our accounts and we’ve been tweeting for a while, and we have some followers, that all of a sudden large number of people immediately are going to see something that we can’t take back. Y’know, it goes out over SMS, there’s no takebacks. So, this happened, of course, with Barack Obama’s account, y’know; a hundred and sixty thousand people, let’s say, receive an SMS from Barack Obama saying, y’know, go check out, y’know, this survey and get a free iPhone or whatever. And that’s a very strange thing to get from the president-elect.

AP: Sure.

CM: So, I think that the real consequence of not providing people who have, let’s say, accrued that social capital or data capital the opportunity to secure their accounts somehow means that there will be these mobs that say ‘Why didn’t you do this? This could have been prevented.’

AP: Sure.

CM: And the answer is, well, no, maybe it actually could not have been prevented, because people were tricked, and this technology doesn’t prevent people from being tricked. But by the omission of not doing it, you gave people that opening to complain and bitch and moan.

AP: Sure.

CM: And so one of the things I wanna talk to you about, though, specifically, is I know you’ve had some criticisms about OpenID and OAuth; you sound very skeptical of them. You’ve also said that the technology is not… even though Blaine and Twitter were part of the creation of OAuth — in fact Larry was the other sort of 50% of that — Twitter still does not offer that. So it would not have… you can’t say, ‘Well, they did have OAuth and the problem happened anyways, so clearly the OAuth was not the solution. Oh! the solution must have been to make people smarter.’ Instead, it fell onto OAuth. So I’m curious, what’s your thinking about that, and, y’know, what’s next in terms of this conversation?

AP: Sure. So, the road to OAuth has been kind of complicated for us. Blaine sketched out a prototype of OAuth in the Twitter codebase. It was there for a while, but like our early API, it was present but not documented. And a handful of developers, mostly via word-of-mouth from Blaine — folks like Kellen over at Flickr — started building Twitter applications that talked to this early sketch of OAuth.

CM: He’s one of the authors of flickrauth and one of the early writers of some of the OAuth [something]

AP: Sure.

LH: And the OAuth validation was wrong. It doesn’t…

CM: That’s right.

LH: It signs differently than OAuth does.

AP: Right, right. I mean…

CM: So it was there, it was wrong, it was taken away.

AP: It was a pre-spec implementation. I mean, it wasn’t even called OAuth per se, y’know; all the internal code had no reference to OAuth or the nomenclature of OAuth. And so at a certain point in the middle of last year, we said okay, there’s a real spec. I sat down to implement it. I took out Blaine’s old code, started putting in the new code, and was concerned about the quality of some of the Ruby code out there to handle OAuth, and at that point in time, working on the Twitter API was essentially what I did in my spare time after not sleeping after not working on other Twitter features…

CM: Which creates, usually, very secure code, y’know.

AP: Right, exactly. And so at the time, I was terrified to implement this kind of half-baked support for OAuth when the API wasn’t my full-time job, we hadn’t had time for a proper security review, and then talking to Eran Hammer-Lahav, who’s been a big voice on the OpenID spec. He happened to be in San Francisco, and talking to him, he said well, there’s a couple of things in the spec right now that we still wanna iron out; you shouldn’t necessarily put a full stop on implementing OAuth, but if you wanted to wait several months, you’d be implementing the sort of most secure version of the specification. I guess there was some chance that a timing attack could be accomplished…

CM: Do you know when that was, when you had that conversation?

AP: I wanna say this past summer.

CM: Okay.

AP: So with all those factors convening, we just decided to table it for a while, and at the end of last year, as Twitter had grown a bit, I was given the role of API lead and allowed to focus on that full-time, and was given one other employee to work with me on the API — who, up until recently, has been doing administrative duties on our search site. But getting the OAuth implementation done has been his project and now that most of his other work is behind him, that’s why it’s finally happening.

CM: Yeah.

AP: So that’s why it’s taken so bloody long just to get it out there — it’s just a matter of internal priorities. My opinion about the technology is kind of separate. I haven’t been dragging my feet on OAuth because I’m concerned about its threat profile or something. I agree completely that it’s a step forward from basic auth and having people submit their username and password, but mostly I’ve just wanted to make sure that it’s deployed with the same level of care that we’ve tried to deploy everything, particularly since kind of mid-2008 when we’ve really just tried to make a push to turn Twitter’s reputation as an unstable service around. And it seems like following that kind of slower development model has worked out pretty well — people don’t talk about Twitter’s instability quite as much.

CM: The fail whale just doesn’t show up quite as much.

AP: Yeah, exactly.

CM: We miss it dearly, but…

AP: So…

CM: But, y’know, I mean… not to [mislead?] or completely throw your words at you, but you did say — or tweeted, at one point — that, yes you’ll do OAuth at some point, but users and developers are gonna hate it.

AP: Yep.

CM: And that, that’s…

AP: I stand by that, actually.

CM: And I really wanna get your opinion on it, because one of the things that hopefully we can do is take constructive negative feedback and turn it into something that results in a number of bug issues that can be corrected.

AP: Right. And I mean, obviously it’s hard to fit a nuanced criticism into 140 characters.

CM: … in 140 characters, that’s right.

AP: So, when I say something like that, it sounds definitive, it’s not saying ‘they’re gonna hate it and we’re utterly unwilling to work with folks like Chris and Larry’…

CM: It just comes out that way.

AP: So…

CM: … in 140 characters!

AP: Yeah. So… some people’s rebuttals have been, y’know, similarly curt, and it’s just… it’s just a fact of the medium. And we all kind of enjoy throwing slings and arrows back and forth.

CM: Twitter is the new godwin’s law!… all right, go ahead.

AP: So… this isn’t entirely my personal opinion. The approach I try to take to developing the API is that we deliver API methods that mirror the features that we expose on the site, and we deliver API methods that are in direct response to what our developers want. We don’t… I don’t think we’ve ever said ‘here’s a method or an API feature…’

CM: … that no one wants.

AP: ‘… we’re going to deliver because we think it would be a great idea’. We always try to do things that the community’s asking for, and that’s part of what’s kept OAuth on our priority list. But the feedback that I’ve heard from developers who’ve implemented OAuth for other services has been pretty negative. People aren’t crazy about the quality of the libraries that are out there, they’re frustrated by the user experience issues — a lot of developers, particularly on mobile platforms, just kind of don’t know how they’re gonna handle OAuth in an elegant way. And, I guess, from the user’s perspective — I’m basing that a lot on the user studies we’ve seen about OpenID, which… users hating it is maybe an overstatement — but users being confused by it seems pretty fair — that seems to be like what the Yahoo! team found out.

CM: … with seven people.

AP: Yeah, with seven people.

CM: Y’know, I could survey my family and get the same response.

AP: Well, but that’s just it — chances are pretty good that, y’know, if you asked your mom to do the OpenID workflow as opposed to just putting in her username and password, it’s more confusing. That doesn’t mean, y’know…

CM: If you surveyed seven Twitter users, maybe they’ve used Facebook and they’ve authorized an application, for example.

AP: Maybe, yeah. I mean, we’ll find out. To me, it still seems like OpenID, OAuth are inevitabilities; it’s just gonna be a bumpy road.

CM: I mean, absolutely. Part of it is — and we talked about this briefly —  it’s like, y’know, Facebook Connect is great, ’cause it gives you a nice, y’know, bluish-purple button that, y’know, people can click and say ‘oh, I recognize that, Facebook Connect. Lovely.’ The problem comes when you wanna have choice, and when your friends are not necessarily on Facebook, but they’re on MySpace or they’re on Twitter, and you wanna bring your friends with you. And I think that’s one of the real hurdles that eventually, y’know, no, not everyone’s gonna be on AOL, y’know; they’re gonna wanna have their own email account some place else, and now you’re gonna have to figure out that interop. And you can imagine that at some point, somebody said ‘People will never understand email addresses. What is this ‘factoryjoe at aol’ nonsense? It’s just, y’know, it should just be like the single name.’. But then, of course, we figured out a way to move forward [from] that, and there was enough value there where people could… essentially internalize the notion that someone might actually be on a different server, and there was some way of referencing them.

AP: Right.

CM: Now, I mean, I’m curious then — what, first, what are your recommendations for people who are using Twitter? — y’know, what should Twitter users do in terms of securing their account — but also, what are some implementations of this type of… these alternative security approaches that you’ve liked? Because sure, you can say that the OAuth user experience sucks today and the OpenID user experience sucks today and that sort of sets the baseline; we can only get better from here… what are good examples that, y’know, are inspiring you?

AP: Right.

CM: … in terms of solving these problems.

AP: I don’t think that there are particularly inspiring patterns for security on the web. I mean, y’know… SSL — we were talking about this before we started recording —  SSL gets the job done, but when you start using SSL with certificates and all that kind of thing, you really need a kind of a organizational administrator to handle most of that stuff. So maybe a Fortune 500 can roll out SSL with certificates to all of their desktops connecting to their intranet or something like that, but we can’t realistically expect most, y’know, home users or users of a mobile device to make use of SSL. So I’m not sure today there’s a pattern that’s better than what OAuth suggests. There are a handful of Twitter apps out there that talk basic auth over HTTPS.

CM: Yeah.

AP: And that seems to be working pretty well for iPhone apps, for desktop apps…

CM: That doesn’t solve the problem of giving your credentials to somebody else; just that it’s less likely that they’ll be intercepted.

AP: Yeah. I mean if you trust the application, and…

CM: Right.

AP: … and you know that the credentials are only ever being stored on your own computer…

CM: Like, if you trust the application, like Twiply or something.

LH: Or Twitterrific.

AP: Twiply was web-based, right?

CM: Yeah, sort of joking… the one that was sold, and like ten hours after it collected eight hundred user accounts.

AP: Right. But in the case of desktop apps and iPhone apps, there’s some that are open source. There’s spaz, which is an open source Air app that runs on everything, Twitterfon is completely open source… so really paranoid users can audit the code for that sort of thing. That’s not a great solution for, y’know, mom and dad.

CM: There’s, y’know, there’s some other benefits, though, I think, of moving to this alternative model that arrive over time. One is rate limiting. Y’know, if you have these applications making use of the Twitter API and you have really no way of identifying them besides IP address… it would be nice if you could just shut off a class of, y’know, malfunctioning applications. Like, specific desktop applications, let’s say, that just do terrible things. You also get the benefit of having kind of a paper trail, of saying ‘these applications changed your account in some way’.

AP: Sure.

CM: And, y’know, a similar idea that Ian McKellar came up with just the other day was this notion of pushing changesets to your account, and then you could approve or deny them. It might be a little heavyweight and a little awkward, but, y’know, similar sort of idea, where instead of using consumer keys, it’s just like ‘I have this changeset, I wanna deliver this parcel to your account’, so at some point later on you come along and approve that, and it goes through.

AP: Right.

CM: So there are different methods there to solving this problem, but clearly, I think, there’s a balance between the complexity on the user side and what hurdles they have to jump through to have sort of a more secure experience where they’re not handing out their credentials, as I’ve said before, like a [something]. As well, you have to think about the developers, and make sure they’re not tasked with something that’s so arduous that it’s impossible for them to implement.

AP: Right.

CM: And it’s interesting to, y’know, ’cause you are gonna be — and you can speak to this in a second — you are gonna be rolling out OAuth as sort of a beta release soon. There’s a service called brightkite which lets you set your location or whatever, and they’ve done an interesting thing where, for developers testing on their sort of staging site or whatever — y’know, just testing applications — they allow them to use basic auth, just a way of trying out their stuff. But if you wanna actually interact with user data, then you have to move over to OAuth. And so there’s a nice sort of balance there where you can’t do any real damage with usernames and passwords…

AP: Right.

CM: … when you’re just trying things out to make sure your app works. But then when you wanna get into the real deal, then you actually have to go through the proper sort of, y’know, dances to make that happen. So…

AP: Right.

CM: I’m curious, in terms of, also… maybe an extracted question is: where are you with OAuth? When do you expect it to sort of land? What’s your process look like? And what kind of things are you working on right now?

AP: Sure. so… where we’re at with OAuth is that we’re very close to a private beta — by private, that pretty much means we’re gonna post a message to the Twitter development-talk group, and anyone that says they’re interested and looks capable of giving us decent feedback will get in. We’re not gonna super picky about it — fifty, a hundred people, that’s fine. So, we’ll go through the private beta for maybe two, three months, unless there are some glaring faults; then move into a public beta for another couple of months; then when OAuth [support?] is final, we’re gonna have six months during which we encourage developers to migrate their apps to OAuth, and at the end of that basic auth will be deprecated. And depending on how that release goes, with rolling out the next version of our API in general, we may put new API methods only behind OAuth, or bump up the rate limit for applications that OAuth, or just try to find ways to really incentivize developers to move over.

LH: That’s what we did with ma.gnolia, is like, you get… in order to get any of the stuff that’s new and version 2 of the API you have to use OAuth.

AP: Right.

LH: But you can still use all the old stuff with version 1 with the two older auth methods.

CM: And that’s sort of an interesting balance there, where, y’know, if you wanna do basic auth, you have the most basic functionality whatsoever. Y’know, you can post a message a day, or something… or thirty messages a day, or something reasonable, where if you’re lazy or an inexperienced developer, you can still create an app for your friends, but if you wanna put something out there that people are gonna download and use and install for a while, or put it on their mobile device — which could get stolen or whatever — then you actually have to go with something that will support that type of functionality, namely, using OAuth.

AP: Right. And I think one of the ways to… the nice thing about basic auth is that people can read the Twitter documentation…

CM: It’s basic, as you’ve said.

AP: Yeah. They can use curl and just poke at API methods, see what they get back. In the absence of that, we’re gonna need to provide a nice sort of interactive sandbox for the API.

CM: Yeah.

AP: And that’s something we wanna do in the next version, so you can test out a URL, see sample data, that kinda thing. But… I’m looking forward to what we’ll be able to do when we have OAuth — there’s a couple of things we’ve been wanting to be able to do for a while. We’ll be able to disable malicious applications from our end, so if we find a Twiply or something like that, we can just say ‘all right, for all the users that have this installed, it’s gone.’ Another nice thing is that we can build an application directory — right now, that’s sort of informally maintained on the Twitter fan wiki, and on a couple of other sites. but since every developer has to register every application, we can ask them for a little bit more information about their app, and we’ll have enough to build a pretty gallery where users can say, y’know, ‘show me all the mac apps’, ‘show me all the blackberry apps’, that kinda stuff.

CM: That’s pretty exciting. Now, it also suggests — and, y’know, this is sort of my interest, since I was recently elected to the board, but uh… — that it opens the door, at least, for Twitter to consider finally maybe doing OpenID at some point as well. Is that at all in the frameworks, or should I just wait another year, and once OAuth’s done then we can have this conversation again?

AP: You should probably not hold your breath. I mean, this is one of those prioritization things. I mean, right now, you can see all the issues that the API team at Twitter tracks — we keep all that open — and you can see that the OAuth issue has the most stars on it, has the most votes on it. But there isn’t an issue for ‘Twitter really needs OpenID’, because…

CM: Let me ask you something…

AP: … nobody’s asked, other than yourself.

CM: Other than me!, yeah. Well, y’know, I tend to be the outlier. How about delegation? We can start there.

AP: That, I think would be worth maybe…

CM: ’cause then I could use my Twitter account as my OpenID…

AP: Yeah.

CM: … without you guys having to do any work.

AP: Yeah. That I think would be worth doing; I think it would probably end up being Britt and Rael and the UX team that ends up implementing it; it’s not really API-related…

CM: Fair enough.

AP: We’re doing enough specialization at this point that, y’know, I can kinda say it’s their problem. I honestly think that’d be nice. At the very least, it would be nice if people can log in with their OpenID and make use of it. Twitter as an OpenID provider — I think we’d want to have a really great handle on the kind of phishing problems out there before we did anything like that — but you should be able to log in with your OpenID. That seems perfectly reasonable.

CM: Awesome. Well, that was great, then.

LH: Yeah. I think we’re gonna wrap this up?

CM: Yep.

LH: Thanks for joining us.

AP: Sure, thanks for the opportunity.

CM: Yeah, appreciate it.

LH: And we’ll talk at you next time.