Virtual Sanity: John Brayton's WebLog

I was unable to attend the Google I/O conference this year, but I have been monitoring the news coming out of the conference with great interest.

One of the sessions was named ClientLogin #FAIL. The summary of the session discusses reasons that apps using ClientLogin for Google account authorization should migrate towards OAuth 2.0. My app, CloudPull, uses ClientLogin. Google has made it clear that ClientLogin is deprecated. I am typically eager to avoid using deprecated API’s, but I am very hesitant to migrate the CloudPull authorization mechanism from ClientLogin to OAuth 2.0.

ClientLogin allows the client app to build its own user interface around entering credentials. In the CloudPull first time user setup, the window looks like this:

This approach is not perfect. The protocol does not handle two-factor authentication in a particularly smooth manner. In order to do so, the ClientLogin protocol would need to be updated and every app using that protocol would need to be updated to allow two-factor authentication. The more generalized problem is that client apps need to be aware of any piece of information Google may ask for during the authentication process.

It is understandable, therefore, that Google wants to migrate towards OAuth. In general, OAuth tells the app to bring up a Google web page. The web page asks the user to identify himself or herself in any way that page chooses. The mechanism would typically be a username and password, but additional items such as captcha’s, two-factor authentication codes, and secret question/answer combinations could also be included.

My biggest concern with OAuth 2.0, and specifically the Google implementation of OAuth 2.0, is that a Mac-native app bringing up a web page for asking for credentials is very awkward. I see no way to do that without compromising the user experience. In addition, CloudPull still needs the username and password to access calendars via CalDAV. A future version of CloudPull is very likely to need the username and password to access email via IMAP. My impression is that Google will eventually provide OAuth 2.0 access to IMAP, but is in no hurry to provide OAuth 2.0 access to calendars via CalDAV.

Finally, there are other weaknesses in the OAuth 2.0 implementation:

• There is no read-only scope for Google Docs, Google Calendar, or Google Contacts. When an app requests OAuth 2.0 access to Google Docs, the authorization page tells customers that they are providing access to "manage" and "upload" data. Since CloudPull only ever reads Google data, this is likely to alarm customers.
• The implementation does not provide a good way for the app to force the user to log in to a specific account (Ticket 2488).
• There is no programmatic method of getting an OAuth 2.0 token based on a username and password (Ticket 2487). This makes it challenging to migrate existing customers from ClientLogin to OAuth 2.0 without manual effort on their part.

Google could provide a programmatic method of getting an OAuth 2.0 token based on a username, password, and list of API scopes. The OAuth specification specifically allows this. For specific accounts or circumstances that may require a captcha, two-factor authentication code, or something else relatively non-standard, falling back to displaying a web page would still be an option.

As an app developer, I am left with three choices:

• Continue writing to a deprecated API.
• Migrate towards OAuth 2.0, sacrificing the user experience of my customers.
• Write code to simulate navigating the login process in the background, screen scraping the resulting pages.

Sadly, continuing to use the deprecated API is the most appealing of these options.

If anyone at Google reads this and wants to contact me directly, I am at jbrayton@goldenhillsoftware.com.

Thank you for reading.

Related: OAuth 2.0 Questions, Requests, Issues

Marco Arment writes:

Developers are being shown that their apps — and their months or years of hard work, and in many cases, their entire businesses — can be yanked by Apple’s whim at any time for reasons that they couldn’t have anticipated or avoided.

It is difficult to fault Apple for taking a percentage of revenue earned from apps sold in their store. The problem is that the App Store is the only way to distribute an iOS app. This is not an inherent limitation in the hardware or software; it is a deliberately engineered restriction built into the iOS.

The iOS is already an incredibly popular development platform. However, Apple could remove the biggest risk of developing for that platform by allowing customers to install apps from web sites through Safari.

I recently put together a screencast for CloudPull. I thought I would share a few things I learned, with the hope of saving others some time.

Tools

I used these tools:

• ScreenFlow to record video and to do all the editing work. ScreenFlow sells for $99.
• QuickTime Player to record audio. QuickTime Player is included with Mac OS X.
• Audacity to filter background whitenoise out of the audio.

Recording Audio and Video Separately

I read several online sources claiming that one should not try to record audio and video at the same time — that it is very difficult to do a clean recording of both simultaneously. It seemed pretty unlikely to me that this was true. I speak and use a computer every day, and had never attempted to edit audio and video before.

Several hundred takes later, I concluded that this was very true. It is really, really hard to speak clearly and perform the actions needed on the computer at the same time.

My Workflow

I settled on this workflow to record each segment:

• Decide what I was going to demonstrate during that segment.
• Type a transcript.
• Record audio of that transcript using QuickTime Player, ignoring any pausing that may be necessary to wait for something on the screen.
• Remove white noise from the audio using Audacity.
• Record video, ignoring any pausing that may be necessary.
• Edit, inserting pauses into the audio and freeze frames into the video as necessary.

Multiple Segments

My screencast is divided into three separate segments. I edited this as one 2-3 minute movie. My ScreenFlow workflow would have been much, much simpler had I edited each segment separately, and then imported the resulting video into one master ScreenFlow project.

Time Investment

It took me four long days of work to get this done. Now that I almost know what I am doing, I think it would take me only one full day to do the same screencasts again. I mention this because this was a much, much bigger time investment than I anticipated. I am very happy to have screencasts for CloudPull and happy to have a new skill. However, it is not clear that this was the best use of four days of time at this stage in my product’s lifecycle.

I mention this not to discourage screencasting, but rather to help make an informed decision on whether it is worth the time investment.

Resources

I found this online course from lynda.com to be extremely helpful. I highly recommend it. The cost to subscribe to the course is $25/month. You don’t need the "premium" subscription; you can sign up for one month and then unsubscribe when you are done with the course materials.

This set of instructions shows you how to remove whitenoise from an audio file using Audacity. This makes a huge difference in the sound quality. In addition, if you do not remove the white noise from the audio any pauses you edit in will be very noticable.

I gave a five minute "lightning talk" about selling in the Mac App Store at a North Shore Web Geeks meetup. My slides are available for download.

Jeff Johnson:

What if we made a distributed Twitter? Like DVCS. All the hip young programmers today use DVCS, whether that’s Git, or Mercurial, or … yeah, Git or Mercurial. The key to DVCS is that there’s no single point of failure, no centralized repository.

"joabj" on Slashdot:

Now that Facebook has amassed more than 500 million users, a growing number of open source social networking developers are wondering if Facebook’s photo sharing, status updates and other features wouldn’t work better as Internet-wide standardized services.

I think of Twitter and Facebook as centralized blogging systems. Conversely, I think of blogging as decentralized social networking.  The primary goals of social networking services boil down to:

• Post information that you want to share.  In the case of Twitter, that information is in the form of "tweets".  In the case of Facebook, that information is in the form of pictures and status updates.
• Follow information posted by other users.
• Send messages to other users.

Compare that to blogs:

• Users post articles to blogs. An article can contain just about anything that can be posted to Twitter or Facebook.
• Users follow other users with RSS feeds from blogs.
• Users can typically contact a blogger using a form or email link on a blog.

In that respect, decentralizing social networking services is a solved problem. There are numerous blog engines and RSS readers. Many of them are open source. They communicate using open standards. Blogs do not rely on a single company or service, and therefore have no single point of failure. However, Twitter and Facebook were both started long after blogs became relatively common. Why are Twitter and Facebook so popular? It boils down to this:

Ease of use: It is not difficult to start a blog on a blogging service, and it is not difficult to use an RSS reader. However, Twitter and Facebook collapse those functions into easy-to-use web sites.

Telling your friends: It is easy to say "find me on Facebook". Saying "read my blog on virtualsanity.com and use an RSS reader to stay current; do you have a blog?" is a bit awkward.

I love the freedom that the open and distributed nature of blogs provide, but the ease of use that comes from centralized services is winning the mindshare of many users.

This is why I believe the new Reader feature of Safari does not harm ad-funded web sites:

1. The Reader button does not appear until the page is rendered, with ads.
2. Users have little motivation to click the Reader button until they have seen some of the ads and until the page layout annoys them.
3. The Reader-rendered article also lacks page navigation and other functionality.  A user that wants to further explore the site will need the original page.

I don’t think this will work:

Tech pundits are feverishly debating the question “is the iPad just a big iPod Touch?” Both sides are right.

I have had my iPad for three days now, and if I had to describe it in fewer than five words I would call it “a big iPod touch”. After all, the most significant difference between the iPad and the iPod Touch is the physical size of the device.

That said, those claiming this description unfairly diminishes the importance of the iPad are also right. The capabilities afforded by the bigger screen, improved performance, and improved battery life are enormous. This is evident in all the apps.

Safari on the iPad is almost indistinguishable from Safari on the iPhone and iPod Touch, but I can view any web page on the iPad without squinting or endlessly scrolling and adjusting the display size. Mail on the iPad, with its two pane interface, looks more like Mac OS X than it does the iPhone. NetNewsWire and Twitterific are two apps that take great advantage of the screen real estate of the iPad.

Finally, there’s the keyboard. The software keyboard on the iPad is much better than that on the smaller devices, but it comes nowhere close to the convenience of the hardware keyboard offered by a desktop computer. I am typing this with a Bluetooth keyboard on my iPad. While Apple could undoubtedly offer Bluetooth keyboard connectivity on its smaller devices if they wanted to, the smaller size would make that awkward.

While the iPad clearly has more in common with the iPod Touch and the iPhone than it does a desktop computer, I honestly believe that it “competes” more against notebook and desktop computers than it does against the smaller iPod and iPhone devices.

If there is one lesson to be learned from the Sidekick fiasco, it is spelled out perfectly in this Chicago Sun-Times article by Andy Ihnatko:

Lesson Three: “If you don’t own and control a local, physical copy of your digital media, then the existence of that media is merely hypothetical.”

I appreciate and heavily use cloud-based services, but I know that they and the data they store could disappear on me at any given moment. For example, although I use GMail with Google Apps, I make sure that I control the domain name, and I use Apple Mail combined with Time Machine to ensure that I have a local backup of that data under my control.

Folks that now me professionally know that I tend to favor open source software for infrastructure, such as database engines. I am a big fan of PostgreSQL and I have happily used MySQL on a few big projects. Today, I was fortunate enough to attend a free workshop from Oracle on their “RASP” platform. The content was quite good. The folks running the workshop were in sales, but they were remarkably technical and well-informed.

What is my point? First of all, thank you to Oracle. More importantly, I want to acknowledge and appreciate that Oracle has some good technology, and that it is the right choice for many (not all) applications.