Judging by the massive response on Twitter in support of her opinion, I think that most people tend to agree. However, I think that the vagueness of her description of the incident leaves much to the imagination, and is causing people to leap to condemnation of the talk, the conference, and the industry. I am not saying the condemnation is unwarranted, but my feelings about this particular event are complicated, and I think yours might be too, if you knew more of the details.

The talk in question was titled The Ten Dirty Words and How To Use Them. The talk was given by my friend Andy Lee, and his synopsis from the conference session descriptions reads:

In 2003, I came up with “The Top Ten Cocoa Words That Sound Dirty But Aren’t.” By finding APIs via this arbitrary way, we talk a random stroll through Cocoa, which can stimulate curiosity and lead to new discoveries and new questions. What would you guess NSInsertionPosition is for? (I incorrectly guessed text editing.) It can also be worthwhile reviewing familiar ground. We all autorelease — some of us every day — but it may still be possible to learn a thing or two about it. I will talk about the proper use of each word in the list.

To give you a more specific idea of the offensiveness of the API method names that Andy discussed, take a look at his blog post listing the API methods under discussion. [Update: MacTech has just posted slides from the talk.]

The genius of this talk is it takes a running gag in the Cocoa community, that occasional API names here and there were unfortunately named, and runs with that gag as a scaffolding for exploring the specific APIs in more detail. As for the sexual jokes, I think they basically write themselves in the individual minds of the audience. As anybody who has sat through an all-too-dry conference talk about the specific technical blah, blah, blah of any subject can attest, it is generally a good idea to inject some humor into a talk’s structure.

So was the humor in this case too much, or too vulgar? I’m sure that Brittany was not the only person in the room who was offended by the talk. On the other hand, as the one “comic relief” talk in a 3 day schedule that contained more than its fair share of professionalism, I think it’s probably fair to say that some members of the audience were relieved to have a chance to laugh about something.

Injecting humor into any talk is dangerous. Especially with a diverse crowd, you are liable to offend somebody. Jokes of a sexual nature are even more dangerous. Even if the joke is not sexist, per se, there is a strong possibility that members of the audience will take offense because of sexual taboos in society. I also imagine the discussion of sex in a strongly gender-imbalanced setting will make members of the minority gender more uncomfortable than the rest of the room.

But neglecting to inject humor is also dangerous. The Mac and iOS communities have a strong tradition of humor in our conferences. Many of us feel annoyed and cheated by a conference if there isn’t a bit of liveliness. So, it goes both ways. It’s important to process this incident carefully to understand how it went wrong. Was the problem that there was a session with a noticeably lower level of “seriousness” than the other sessions? Was it that the session’s jokes were of a sexual nature? Or was it that the sexual nature of the talk’s jokes were not made clear enough to the audience before it took place?

I think what is happening on the web now is many people are seizing onto the angle of Brittany’s complaint that most resonates with their own frustrations about the conduct of our community. This is a valuable reaction and a good opening for further exploration. But what isn’t useful is the large number of people who are condemning the conference and the speaker without significant information about the context of what happened. I hope that I have at least helped to clarify that to some extent. If you still feel that blanket condemnation is the appropriate response, then I’m happier with your opinion now that you’ve read mine.

Let me break the announcements today into three policy change assertions, and how I react to them.

1. Access to Twitter direct messages will require a new level of user-granted permission. This is a great thing! I recently tweeted that exactly something like this was necessary, because I’ve grown tired of giving every damn service that I wish to connect to Twitter, access to all my confidential direct messages. The new permission allows developers of client apps to state their desired permissions, and those permissions will be listed prominently on your list of approved applications.

   Verdict: Kudos, Twitter.

2. Developers of Twitter clients will be required to use OAuth in order to gain this new permission. In laymen terms, this means client apps can’t log you in with just your username and password. You will need to be redirected to the web. This requirement is ostensibly because Twitter wants to increase the likelihood that end-users will be made aware of exactly which permissions a client application is requesting. Without this requirement, a native application could claim to seek read-only access, but behind the scenes be using your username and password, by way of Twitter’s xAuth solution, to request a higher level of permission than you intended to allow.

   I concede that this requirement is, on the face of it, an added protection for customers who are wary of providing Twitter credentials to an untrusted app. But here’s the catch with native software: you better trust it, because there is no shortage of ways in which it could screw you. It’s running with some degree of elevated permission on your own device. Twitter putting shackles on native app developers in the name of security is laughable. For example, it would be easy for an untrustworthy native app to provide a custom, compromised browser view that purports to drive a user through the Twitter OAuth permission flow with a given permission, but is actually requesting a different level of permission in a second, undisplayed web flow.

   This is not to say that we shouldn’t bother reining in native software that may be flawed or whose permission we may want to revoke. This is what is so clever about the xAuth workflow, the compromise that allows native apps to authenticate as if by way of an OAuth flow, but using a user’s username and password to facilitate the process. If an end-user or Twitter itself loses confidence in an xAuth based application, they can still revoke access to the application in the same way they would for any other OAuth managed client.

   Verdict: Nice try, but if you don’t trust your native software, Twitter can’t do much to keep you from getting screwed.

3. These requirements apply unilaterally to all native clients. Except Twitter’s. I grant you, it makes sense for a company to exempt itself from security restrictions that are imposed to prevent “bad guys” from taking control of a user’s credentials and doing damage to the user or to Twitter itself. But this story is complicated by the fact that Twitter entered a competitive market of native clients of its own system, where for years it was not a player, and then proceeded to adopt increasingly developer-hostile attitudes. In particular towards developers of software that aims to fill that coveted role of a “general purpose read/write Twitter client.”

   Is it illegal to do what Twitter has done? Absolutely not, nor should it be. But in my opinion these 3rd party developers were a valuable asset that was pivotal in building passion for Twitter in the earliest years of its existence. Many of the features that we take for granted in Twitter itself were prototyped in 3rd party native applications. Hell, even Twitter’s own native Mac app was itself a 3rd party application (Tweetie) until not too long ago.

   Twitter’s attitude towards these developers seems to be: thanks for all the help, but we’re done with you. The fact that Twitter is willing to “whitelist” their own apps further suggests that this may not be a pure security play. Only legitimate developers of trustworthy apps would be interested in seeking an API key to connect to Twitter. If your aim is to write malevolent software that abuses Twitter or its users, you should be content to take an app like Twitter’s own Mac client, extract the portions that communicate “securely” with Twitter, and build your own app that only the savviest user will notice is actually posting to Twitter as “Twitter for Mac.”

   Twitter’s willingness to exempt any apps from the OAuth procedure is a concession that they don’t view xAuth authentication as inherently insecure. But they want to limit which API keys get the privilege of continuing to use it. So, expand that list of API keys. At the very least, add long-time supporters such as Iconfactory’s Twitterrific. Better? Provide some kind of approval process through which any qualified developer can seek first-class status. Best of all? Stick to what OAuth and xAuth are best for: providing the power to revoke access for bad actors after bad intentions are discovered. Forcing applications through OAuth is not going to prevent offensive, buggy, or intentionally malevolent code from being authorized by users, but it is going to degrade the user experience for all native clients except, oh, how about that? Twitter’s own.

   Verdict: Dick move, Twitter.

My primary product, MarsEdit, is a desktop blogging client that interfaces with Tumblr, among dozens of other types of blogs. The reduced reliability of Tumblr, and in particular of its API, has meant a deeply compromised experience for our customers in common. This means that I also suffer some pain in the midst of Tumblr’s flakiness, because I have to support an unreliable service and explain to customers that MarsEdit is affected by Tumblr downtimes as well.

Some of Tumblr’s greatest assets are the deeply respected bloggers who trust Tumblr to host their writing. They serve as implicit spokespeople for the service each time they publish an entry, and more explicitly so when participating in Tumblr’s own social network, raving about the site on Twitter, at conferences, etc.

As flakiness continues, the tone of endorsements is turning negative. I regularly see sarcastic snipes against the service in my Twitter feed, and even on blogs that are hosted by Tumblr itself. Garrett Murray’s frustration peaked yesterday when he posted a sarcastic revision to Tumblr’s increasingly famous “downtime” graphic. Steven Frank of Panic fame chimed in today on Twitter:

It occurs to me that Tumblr is also growing exponentially with no apparent income source. I should look for a new home, pre-dickbar.

Tumblr has a problem. Since late 2010 and for all of 2011 they have been suffering enough downtime and flakiness that a growing chorus of users is lambasting the service. Without judging whether that’s fair or justified, let’s accept that what used to be a widely lauded service is becoming a widely criticized one.

But how big of a problem is it if, as Steven Frank suggested in his tweet, the service continues to grow its membership by leaps and bounds? My theory is Tumblr’s continued success in signing up new customers is both thanks to and at the expense of their influential early adopters. Folks who helped to build Tumblr’s reputation over the past several years are now suffering, presumably because of Tumblr’s ravenous ingestion of new users. If this keeps up, the influential “power-bloggers” will quit Tumblr and move on to more reliable services. Tumblr will be left with millions of users, who I’m sure are perfectly nice people, but who don’t exert as great an influence in the web world.

What should Tumblr do? If the failure to rein in performance and uptime issues is connected to success in signing up new customers, then they should stop signing up new customers. Sound foolish? In Tumblr’s position I would do whatever it takes to bring back the level of service that users enjoyed before the “great downtime of 2010.” Happy, influential customers paved the way for Tumblr’s success, and bringing back that enthusiasm is the best way to perpetuate success far into the future.

If Tumblr turned off new user registrations today and added a “notify me when more new users are being accepted” sign-up form, it would provide breathing room to focus on fixing the experience for current customers. Framed correctly, it would also make those customers feel cared for and important, something they probably aren’t feeling so much at the moment. Yes, for prospective customers it would be a slap in the face. Nobody wants to feel shut out. But if given a choice, protect your existing, not future customers. Web services build buzz all the time with limited, invitation-only beta testing intros. It would be a step backwards for Tumblr, but it would also re-establish a sense of exclusivity that would pay dividends after issues are resolved and open enrollment returns.

It’s easy to armchair-quarterback another business when you don’t know any of the details. I’m sure the challenges at Tumblr are diverse and hard to pin down to my convenient diagnosis of “too many users.” But if you’re bailing out a sinking boat, the first thing to do is stop admitting new passengers.

I hope Tumblr figures out a way to solve this for the long run. My customers depend on it. Their customers depend on it. And the longevity of the company itself depends on it.

Some of Ian’s remarks are inspiring, and may encourage you to blog more even if you already know what blogging is. I particularly like the simplicity of:

Blogging is sharing something you have created online. And then doing it again tomorrow (or next week, or next month, or next year). And again.

My initial reaction, like Caterina’s, was to assume there is something wrong in the Gravatar model. Why should somebody be able to masquerade as me simply by guessing the email address I associated with Gravatar? But Matt Mullenweg of Automattic, which owns Gravatar, explained concisely that the fundamental problem of impersonation cannot be prevented by their service. An impersonator could just as easily have associated a new email, “fakecaterina@example.com” with Gravatar, and uploaded a copy of her avatar.

A Hopeless Situation?

I am convinced by Matt’s claim that Gravatar is not in a position to prevent impersonation. However, it’s possible to imagine ways in which Gravatar could promote authenticity. Gravatar already allows me to create an account through which I claim email addresses and can control which avatars should appear for these addresses. In addition, it allows me to confirm that account’s association with certain services such as Blogger.com, Facebook, Twitter, etc. This, combined with the fact that use of Gravatar is already widespread on the web, makes it a great candidate for serving as an arbiter of trust in arbitrary contexts on the web.

Web sites that make use of Gravatar’s services are currently able to fetch an image associated with a particular email address, by manipulating (hashing) the user’s email address in such a way that the email address is no longer discernable, but Gravatar can easily look up the associated avatar image.

There are steps that Gravatar could take to make possible the “authentication” of specific Gravatar appearances on the web. It would be exhausting to elaborate on the variety of ways this might be done, and many of the options that spring to mind also bring to mind many pitfalls and annoyances, not to mention significant service demands on Gravatar. Maybe the authentication would require hosting sites to present authentication keys, or maybe users would just whitelist particular comment URLs. Let’s not get bogged down in details: the details are for companies like Gravatar to take on if they choose to meet the challenge.

In a world where Gravatar offered some form of per-use authentication, a site like GigaOm could show a trust icon next to commenters’ avatars, or maybe it would be integrated into the avatar as a form check-mark badge or something. Click on the trust icon and it might take you to a Gravatar page where a curious reader could gauge authenticity with Gravatar’s help:

The Gravatar being shown at <link to e.g. a comment url> was verified by Daniel Jalkut, a registered Gravatar user. Daniel is known to be associated with Twitter ID “danielpunkass”, and controls the web site domain http://www.red-sweater.com. For more information, view his profile here.

The current Gravatar user profiles already lean strongly towards identity confirmation. Some clever techniques for authenticating comments would not eliminate impersonation, but would allow identity-concerned users such as Caterina a means of participating in web conversations while proactively confirming their own identities.

Marco provides a handy bookmarklet that you can add to your browser’s button bar, so when you find something cool you just click “Read Later” and it gets added to your Instapaper collection. This is handy, and if you’re using a browser like Safari, these bookmark bar items even get mapped to default keyboard shortcuts based on their position, e.g. Cmd-1, Cmd-2, etc.

My news reader of choice, NetNewsWire, also supports Instapaper, allowing me to easily add any news item’s underlying content to my “Read Later” list. In NetNewsWire, the keyboard shortcut is Ctrl-P (for paper!), and I’ve gotten hard wired to punting stuff to my reading list with a quick flick of the keys.

For months I’ve thought it would be nice if I had the same workflow in Safari and in NetNewsWire: see something, want to read it, don’t have time, press Ctrl-P. I don’t know why I took so long to sit down and spend the 5 minutes it took to write an AppleScript wrapper for Marco’s bookmarklet, and install it in my scripts folder to invoke with FastScripts.

If you want to be cool like me:

1. Download and install FastScripts. Free for up to 10 shortcuts!
2. From the FastScripts menu-bar icon, select FastScripts -> Create Safari Scripts Folder.
3. Download this script, and move it to the Safari-specific scripts folder: [Home] -> Library -> Scripts -> Applications -> Safari
4. Switch to Safari.
5. While holding the Cmd key, select “Read Later” from the FastScripts menu.
6. Assign a keyboard shortcut of your choice. (Ctrl-P for NNW-likeness).

Now whenever you see a cool page in Safari, just press Ctrl-P to instantly tag it for later reading.

Update: David Kendal observes on Twitter that you can assign custom keyboard shortcuts to bookmarks in Safari by simply using the System Preferences Keyboard Shortcuts and assigning to the correctly named bookmark. I was not aware that this would work with bookmarks! Very cool. It diminishes the necessity of the above workflow considerably, though I was pleased to be able to take “Read Later” out of my bookmarks bar. Another downside to the System Preferences route? Apparently the keyboard shortcuts will never take effect until you’ve shown the menu that they appear in at least once per Safari-launch.

Long time readers of this blog will note that I’ve had my dry periods as well. But watch closely: I’m blogging now about a thought I had just earlier this evening, while reading Twitter updates and responding to them. Colin Barrett complained that his perfectionism is limiting his blogging:

I plan to write more; I think my @secondconf talk on freelancing would work well as a series of posts. Just gotta get past my perfectionism.

I’m incredibly familiar with this line of thinking. In fact, it’s a variant of the indefinitely postponed software releases that I just wrote about. I read Colin’s tweet and, before I had even noticed that the neurons in my brain were firing, I had responded with a bit of encouragement:

@cbarrett The modern business model for solo writing is to blog your first draft and sell your final.

I’m referring to the fact that very few blogs are edited to the level of professionalism you might find in literary or scientific journals. On the contrary, some of the web’s most celebrated bloggers have let their essays loose in a semi-rambling form, only to piece them together later into a more refined, salable volume. Rands in Repose and Joel on Software spring to mind in the techie world, while writers such as Heather Armstrong and Julie Powell turned their respective parenting and cooking blogs into million-dollar enterprises.

The ever-so-thinly veiled message? Don’t worry so much. Just blog it. If you are among the lucky few who achieves perfection effortlessly, then by all means carry forth. The rest of us are lucky if we coerce a unit of coherent thinking out our brains and onto the web. Perfectionism? Your editor will help you achieve it after you’re famous.

This pursuit was of course assisted by Google itself. It has a nifty advanced search feature where you can specify a date range for the results. Unfortunately the algorithm for assigning dates to pages seems really buggy, and you end up with a lot of false positives for the date range you specify. For example, Google was being talked about in 1973?

I was able to find some interesting newsgroup postings from Sergey in 1994. On August 18, 1994, he sought advice about booking air travel from San Francisco to Baltimore. In 2010, this conversation would almost certainly not happen, as any number of powerful airfare search engines crunch the numbers and compare rates across carriers, dates, and airports.

But even more interesting to me is a math question posed in 1994 about the Karhunen-Loeve theorem:

Hi,

I ran across a reference to a Karhunen-Loeve transform in a paper I was reading and from the brief mention it seems that it is relevant to my research.  However, there is no pointer to where I could find more information.

Could someone let me know what a good reference for the Karhunen-Loeve transform would be?

thanx
–sergey

Today you just type “Karhunen-Loeve” into Google to get the answer.

Georg C. Brückmann chimed in with a semi-solution, which is a URL template you can use to jump directly to a PayPal transaction by ID. Take the root PayPal URL for your country, and add “vst/id=” followed by the PayPal transaction ID. In the United States, this leads to a URL like: https://www.paypal.com/vst/id=1234.

It’s sad to say that remembering a static PayPal URL and pasting in the transaction ID in the magic location is indeed easier than navigating PayPal’s slow and awkward transaction history UI. But it could be even easier with a little automation.

Jump To PayPal Transaction ID is a simple AppleScript that prompts you for a transaction ID, constructs the desired URL, and opens it in your default browser. If you don’t live in the United States, open the script in AppleScript Editor and alter the template URL contained within it.

I put this in my Safari-specific scripts folder:

[Home] | Library | Scripts | Applications | Safari

So it’s available from FastScripts whenever I’m in Safari. Problem solved.

Be gracious. Be thoughtful of other peoples’ interests. Don’t be a whiner. Be generous. Be inclusive. Pay it forward… you get the picture.

Have you ever noticed this phenomenon of the internet? As the ultimate reference archive, it reveals the most arcane and lesser-known facts of science, art, and trivia. It teaches us about the world. But as the ultimate social connector, it teaches us about people, how we do or don’t, and how we should or shouldn’t get along with each other.

I experienced this the other day when I was tweeting enthusiastically about Tweetie for the Mac and how I might be interested in taking the product over if it doesn’t fit into Twitter’s plans for the app. In the excitement, I not only violated one of the social rules of politeness by filling my followers’ Twitter screens to the brim, but I made the mistake of taking a stab at a company called Brizzly.

See, my friends Buzz and Neven built a wonderful iPhone Twitter app called Birdfeed. A few months ago, Brizzly acquired Birdfeed from my friends, and revamped the user interface a bit to match their style. I’m not a fan of these revisions, and I have stuck with the original Birdfeed app on my phone. But I used this distaste for the UI changes to fuel a less constructive tweet that I would characterize as a “low blow” against Brizzly. I have since deleted the original tweet, but it prompted a response from Brizzly’s CEO:

@phopkins He may be hella cool but does he realize that smacking Brizzly isn’t going to get him anywhere?

I immediately had one of those wake-up-call feelings where you realize that what was just mindless banter at “somebody else’s” expense was actually at the expense of somebody very particular. Yes, I reminded myself, there are actually people on the internet:

I should know this by now: there are people behind products. Ashamed of my tasteless treatment of Brizzly, and by extension, @shellen.

Some people who don’t know me very well assume that because my Twitter name, @danielpunkass, is a bit crass, that I must be a provocative and thoughtless person. They are surprised to meet me in person and find out that I’m actually pretty nice.

What my Twitter name represents to me is my willingness to be the cheeky one. To defy the standards and be a bit of a jerk when it’s called for, but only when it’s called for. Sometimes, the most unexpected, uncalled for, provocative, defiant move you can make is to be nicer than people expected you to be.