Presence Technology

What Is the Real Value of Social Media?

Michael Osterman — Thu, 03 Nov 2011 22:22:30 +0000

This post is aimed at people who don’t think that social media offers much real business value and that it’s more time-waster than productivity tool. One of my favorite quotes from Jimmy Fallon:

“Did you guys notice this? Twitter was down for two hours on Saturday. It was horrible. I was forced to call random people out of the phonebook and just tell them what I had for lunch.”

And that pretty much sums up how many people view social media—as an avenue for possibly meaningful content, but primarily as a means of sharing information that doesn’t have much business value. However, while social media actually does provide substantial business value, I believe two of its more important benefits in a business context will be (a.) its ability to allow people to communicate useful information in a way that would simply seem silly when delivered in another format, and (b.) to delve into a knowledge base of information that today is more or less kept hidden in people’s brains. Here’s what I mean:

Imagine that you wanted to tell people you were at a particular Starbucks, enroute to another city, attending a conference next week, etc.—information that might be relevant to maybe three people at any given time (who might be at that conference or a block away) in your circle of friends, associates or acquaintances. Now, imagine sending an email with that information to a few thousand people three or four times a day. Worse, how about sending them a fax? It simply wouldn’t happen, and you wouldn’t be able to obtain the benefits of sharing this useful information.

Of course, this is an obvious example of how social media is used today, but it underscores the point that social media represents a new medium, not a replacement for email and other, more traditional forms of communication. Our own research shows that the a much larger proportion of people view email as more important compared to a year ago than view it as less important, indicating that social media really is a supplement to traditional communications, not its substitute.

More important, social media—particularly purpose-built, corporate social media—represents something of a knowledge directory that is generally not available via other systems. While the idea is not new (Linkadoo and others were focused on this years ago), social media enables the sharing of information in ways that are simply impractical via other methods. Let’s say you want to find someone with knowledge of Hadoop-based software who also had worked in healthcare earlier in their career. Or someone who was familiar with the particular marketing manager with whom you’re on the phone right now. Or you need to find just the right restaurant for a customer event in a city with which you’re unfamiliar. The right social media capability can act as that repository and distribution mechanism for the tidbits of knowledge that are perhaps too obscure to put into a database or to codify on a resumé or that would never be assembled across the diverse array of contacts you might have on Twitter or Facebook. In short, social media represents a tool for bringing that kind of information together and to provide real business value as a result.

And, in case you’re wondering, I had an enchilada and an apple for lunch today.

Inbox Love – A New Conference on Email

Ben Gross — Mon, 14 Feb 2011 21:59:01 +0000

Inbox Love, a new conference on email, will be held on February 25th at the Microsoft Conference Center in Mountain View, California. The speakers and sessions look great. 500 Startups’ (Dave McClure) is producing the conference along with OtherInbox (Joshua Baer) and AwayFind (Jared Goralnick).

I attended and spoke at the pre-event meeting for Inbox Love in December. The attendees and speakers were excellent and it looks like the main event will be even better. I wrote about it in Inbox Love and Recent Innovation in Email.

If you had asked me a few years ago if I thought that in 2011 there would be a new email conference and a whole host of fantastic new email products and services, I would have said no. I’m happy to say that I would have been wrong. Registration for Inbox Love is now open.

Sessions at Inbox Love include:

The Implicit Social Graph
Inbox Infatuation: Will They Still Love Your Product in the Morning?
The Psychology of Behavioral Change: Proven results from 1 million+ emails that delight, engage, and influence users
WHEW! This Email Smells Bad…Has It Expired?
If They Mated: Email, Voice, SMS & The Next Generation of Communication
The Love Connection: Platforms & The Future of Consumer Email
The Love Connection: Platforms & The Future of Business Email
The Integration of Email & Social
Privacy vs. Personality: What’s in an Email Address?
NextGen Email Apps

The list of Speakers at Inbox Love includes:

Joshua Baer - Founder & CEO, OtherInbox
Victoria Bellotti - Principal Scientist & Manager at PARC
Bill Boebel - VP of Strategy, Rackspace
Jeff Bonforte - CEO, Xobni
Manlio Carrelli - CMO, Intermedia
Amy Ellis - Head of Integrations & Partnerships, MailChimp
Miriam Geller - Director of Product Management, Yahoo! Mail
Jared Goralnick - Founder & CEO, AwayFind.com
Auren Hoffman - CEO of Rapleaf
Fletcher Jones - Product Lead, AOL Mail
Pierre Khawand - Founder, People-OnTheGo
Jeff Lawson - Co-Founder & CEO, Twilio
Dan Martell - Co-founder, Flowtown
Dave McClure - Founding Partner, 500 Startups
Paul McDonald - Product Lead, Gmail
Scott McMullan - Google Apps Partner Lead for Google Enterprise
Josh Merchant - Co-Founder & CTO, Lymbix, Inc.
Alex Moore - CEO, Baydin
John Robb - Senior Director — Zimbra products & marketing, VMware
Isaac Saldana - Co-founder & CEO, SendGrid
Tom Sather - Email Deliverability Consultant, Return Path
Mark Schmulen - General Manager, Social Media, Constant Contact, Inc.
Ramit Sethi - Author, “I Will Teach You To Be Rich”
Jonathan B. Spira - CEO & Chief Analyst, Basex
Rahul Vohra - Co-founder & CEO, Rapportive

OpenID Trends: Improved Usability and Increased Centralization

Ben Gross — Thu, 26 Aug 2010 08:34:29 +0000

The OpenID authentication framework is the most well known of the federated user-centric identity systems. OpenID has effectively become the first commonplace single sign-on option for the Internet at large. Most sizeable Web-based service providers such as AOL, Google, Facebook, Microsoft, MySpace and Yahoo! have integrated at least limited support for OpenID. Services often run OpenID authentication side-by-side with their in-house developed authentication or as an alternate method of authentication. Once the user has authenticated via their OpenID provider, their credentials can be used to automatically sign the user into other services previously linked to their OpenID. Widespread support has made OpenID the de-facto authentication mechanism for low-value transactions on the Web.

Two quick and somewhat loose definitions. An OpenID Provider is part of the backend of an identity system that offers an authentication services to other systems known as OpenID Relying Parties. Say your favorite blog requires that you log into Google to verify your identity to comment on a post. In this case Google would be the OpenID Provider (Identity Provider is the generic term) and your favorite blog would be the Relying Party since it depends on Google to handle the details of authenticating you so you can post.

Usability

OpenID has made great improvements in usability in the last several years. Many people found early OpenID implementations confusing. Users needed to first enter the URL that served as their OpenID identifier such as http://username.openidprovider.com. Without an existing cookie, users would have to enter their email address and password to complete the authentication. In addition, the users browser window was typically redirected to the OpenID provider’s site and then redirected back to the service they were trying to log into resulting in further confusion. Service providers found that the combination of URL-based identifiers and a login sequence differed from the entrenched standard of a username and password combination confused many people.

Each of these factors significantly reduced the usability of OpenID. However, OpenID specifications and implementations have evolved to mitigate and eliminate many of the usability problems. In many current deployments, users simply click on the logo their OpenID Provider (e.g., Google or Yahoo!) and then log in with familiar credentials without realizing the authentication is OpenID-based. One significant unsolved usability problem is that OpenID offers no support for Single Log Out. In the case of public or shared computers this situation is a significant security risk, as well as a usability problem, as subsequent users may find themselves signed in under the wrong user name when navigating to new sites.

User centric identity theoretically offers the end-user more control over his own identifiers, however in practice the amount of control is dependent on the amount of control the user has over the domain name or service of the OpenID URL. Users may maintain multiple OpenIDs and OpenIDs may be delegated. For example, an individual may wish to use a personal domain as an OpenID URL. The problem is this requires the skills to run the OpenID server as well as the overhead of maintaining and securing the server. There are two straightforward solutions to OpenID delegation, both of which require some technical facilities. The first—and most common—requires inserting a block of HTML containing the delegation commands on a Web page on the site being delegated to the OpenID Provider. The second requires adding an additional DNS CNAME for a host on the site that is being delegated to the OpenID Provider. Most individuals are highly unlikely to have this knowledge; the desire to obtain it, or even the knowledge that it exists.

Centralizing the Decentralized

OpenID was designed as a decentralized, federated, user-centric identity system. The OpenID infrastructure as a whole is decentralized. There are no dependencies on any single piece of hardware, software, service, individual, or company. The independent OpenID Foundation holds the intellectual property for the OpenID standards. The lack of dependencies removes the vulnerability of a catastrophic single point of failure.

I would argue that the common use cases for OpenID are increasingly centralized and realistic options for individuals to have any real control over their OpenIDs is decreasing. I recognize that some may argue with the last statement, but I would like to use a simple metric, which is the answer to this question: Can you take it with you? In the vast majority of common use cases, the answer is no. I would argue that the only viable way to have a true user-centric OpenID is to own a domain name and to have control over its DNS. The lack of end-user control does not mean the system functions any less efficiently, the opposite is quite likely true, but it does mean that it is not particularly user-centric.

In practice, OpenID appears to be heading towards greater centralization for Web-based authentication. Many services that offer OpenID authentication only accept authentication from a very limited set of OpenID providers. Services that accept OpenID authentication from any OpenID provider often place the general authentication in a less prominent location. Service providers have an incentive to limit authentication services they accept as it can significantly reduce risk and complexity and most users already have credentials from one of the major service providers. I believe this situation is not inherent to OpenID and would likely occur with any successful user-centric identity system. For example, Twitter does not support OpenID, rather it uses OAuth for both external authorization as well as authentication. Many services offer support for authentication via Twitter OAuth in the same interface as other providers that use OpenID.

Furthermore, most large OpenID enabled services are Identity Providers meaning they offer an authentication mechanism to other services. Most smaller OpenID enabled sites are OpenID Relying Parties meaning they accept authentication from OpenID Providers. OpenID Providers typically offer authentication services, but do not accept outside OpenID authentication themselves. Effectively, a few OpenID Providers serve many OpenID Relying Parties. Delegating the development and maintenance of user account management systems and password reset flows are benefits for offering authentication as an OpenID Relying Party. In addition these services gain the benefit of any advances in OpenID security and usability.

OpenID Increasingly Popular

In the close of my 2008 article: “The Promise and Problems of OpenID,” I wrote: “OpenID is clearly gaining in adoption and importance. Currently, OpenID is both too lightweight for enterprise identity management and too insecure for sites with financial or other highly sensitive data. Some of the current problems will be mitigated by OpenID extensions and new more secure mechanisms for OpenID authentication and improved phishing protection. Businesses, especially those with consumer Web-based services, would do well to familiarize themselves with the technology and pay attention to its progress.”

When people authenticate to poplar services via OpenID without having to even know they are using it, this indicates OpenID is becoming a mainstream authentication infrastructure. The protocol is evolving rapidly and it appears that common implementations in the future may be hybrids of OpenID and the OAuth authorization protocol. Still, there are substantial costs to implementing, managing, securing, and supporting user account management systems. Offering authentication as an OpenID Relying Party can potentially significantly reduce these costs and the friction for new account signups for people with existing OpenIDs. However, this reduction in cost comes with a loss of control over user account information that must be weighed against the benefits. Even though long-term stability for OpenID may be a ways off, it is clearly a critical technology to monitor.

How Standard Is FaceTime on the iPhone? Packet Capture Verification

Ben Gross — Tue, 13 Jul 2010 22:01:17 +0000

Apple CEO Steve Jobs announced FaceTime video conferencing for the iPhone 4 during his keynote at the Apple World Wide Developer Conference (WWDC) in June. FaceTime takes advantage of new frameworks that are part of iOS 4 in addition to the new hardware capabilities of the iPhone 4 including the front facing camera, the high-resolution Retina display, and the increased speed of the A4 processor. Jobs stated that FaceTime based on existing standards and that FaceTime itself would be published as an open standard. Packet captures of FaceTime sessions give a clearer picture of which standards Apple employs and how Apple implements these standards.

Jobs’ demonstration showed a seamless video conferencing experience that could be initiated directly as a video chat or by upgrading a traditional voice call to video. FaceTime currently only operates over a WiFi connection on an iPhone 4 and not on earlier devices. Jobs said that Apple was working on carrier agreements to allow FaceTime to work over a 3G connection. You can read a transcript of the 2010 WWDC Keynote at Macworld, view a gallery WWDC 2010 keynote images at The Mac Observer or watch the official video of the Apple WWDC 2010 Keynote Address.

Jobs stated that FaceTime was based on H.264, AAC, SIP, STUN, TURN, ICE, RTP, and SRTP standards. Stephen Strowes has a nice description of the standards and how they interact in his post iPhone4, Facetime, and open standards. Even though Jobs explicitly listed the standards on a slide during the presentation, I could find no official mention of the standards on the Apple web site or a record of a submission of FaceTime to a standards body. Apple will certainly publish all the details in time, however I wanted to see what I could verify at the present time.

I assumed that observing a FaceTime session with a packet sniffer would provide all the information needed. Unfortunately my iPhone 3GS is not capable of running FaceTime, so I looked for others who had analyzed packet captures of FaceTime sessions with an iPhone 4.

Arjun Roychowdhury and FryGuy both posted quick analyses on June 25th. Both primarily looked at the voice portion of the call setup. In Facetime on Iphone 4: Vanilla unencrypted STUN and SIP, Roychowdhury used Wireshark to find that Apple implemented the voice setup portion using standard SIP mechanisms. He posted further clarifications in the comments. FryGuy published similar findings in iPhone 4 and FaceTime Packet Capture using a Cisco ASA capture filter.

Joshua Wright’s ongoing series in the Packetstan blog is far and away the most detailed analysis of the FaceTime protocol. Wright nicely describes his use of Wireshark, videosnarf, and openssl so that others can replicate his experiments. In Face Time (part 1: Introduction), Wright provides a quick characterization of a FaceTime session, which traffic is delivered of TCP vs. UDP and which portions are encrypted. In Face Time (part 2: SIP and Data Streams), he dissects the SIP portion of the session with Wireshark and uses videosnarf to analyze the RTP media streams. Wright found that FaceTime extends SIP MESSAGE authentication in non-standard way and that neither the audio nor the video portions of the FaceTime sessions are encrypted. Finally, in Face Time (part 3: Call Connection Initialization), Wright finds that FaceTime authentication uses Jabber/XMPP with SSL on TCP port 5223 that connects to a Jabber server at Apple with client certificates. The certificate-based authentication means that Apple will be able to control which devices are able to connect to its own servers. Wright speculates that the certificate could be extracted from a jailbroken iPhone and used with other clients. Joshua’s own blog, Will Hack For SUSHI, is sporadic, but excellent.

What You Do Is Really What You Believe about Privacy

Michael Osterman — Tue, 22 Jun 2010 15:13:10 +0000

There is a seemingly endless barrage of news stories about how an email provider, a social networking site, a credit card processor or some other vendor has violated somebody’s privacy by divulging credit card information or Social Security numbers or Wi-Fi login credentials. While the tone of these articles generally is meant to reflect the perceived user indignation at these violations of privacy, how much actual indignation is there, really?

A study published by the Ponemon Institute yesterday found that while people say they’re concerned about privacy—more than four in five users of social networking tools expressed concern about their security while using these tools—the bottom line is that they really are not:

More than one-half of the individuals surveyed take no precautions to actively protect their computers or their data while using social networking sites.
About two in five users post their physical home address when using social networking tools.
Assuming that a social networking provider did not protect their privacy, more than 40% of users would still use that provider.
More than nine in ten users don’t review a Web site’s policy on privacy before they use the site.

If these results are to be believed—and there’s certainly no reason they shouldn’t be—the vast majority of people say they’re concerned about privacy, but their actions indicate that they really are not. Many say that they are upset when a vendor gathers or reveals personally identifiable information about them, but then they tweet or post their location or vacation plans or some other equally confidential information.

Now, to be fair, if you want to reveal your own information, no matter how confidential, you have that right. And a vendor clearly does not have (or shouldn’t have) the same rights over your information unless they have specifically reserved those rights. If a vendor does share your information or use it in some way, it’s generally because they have reserved this right as stated in their privacy policy—something that fewer than one in ten of us actually read. We should.

Safe Real-Time Communications

Stephanie Jordan — Wed, 30 Sep 2009 19:56:34 +0000

Last week US_CERT republished a Mindi McDowell and Allen Householder article on using instant messaging and chat rooms safely. I thought it was a good reminder, and worth sharing some of the offered tips.

Included in the description of real-time communication tools is instant messaging and public or private chat rooms/forums. The authors also included “chat robot” software services, like weather reports, stock status, or movie listings, noting that users may not realize that the responses are coming from a bot, not a real person.

McDowell and Householder offered the following list of dangers: (This is the good reminder part and perhaps worth passing along to users.)

Identities can be elusive or ambiguous. Not only is it sometimes difficult to identify whether the “person” you are talking to is human, but human nature and behavior isn’t predictable. People may lie about their identity, accounts may be compromised, users may forget to log out, or an account may be shared by multiple people. All of these things make it difficult to know whom you’re really talking to during a conversation.

Users are especially susceptible to certain types of attack. Trying to convince someone to run a program or click on a link is a common attack method, but it can be especially effective through IM and chat rooms. In a setting where a user feels comfortable with the “person” he or she is talking to, a malicious piece of software or an attacker has a better chance of convincing someone to fall into the trap.

You don’t know who else might be seeing the conversation. Online interactions are easily saved, and if you’re using a free commercial service the exchanges may be archived on a server. You have no control over what happens to those logs. You also don’t know if there’s someone looking over the shoulder of the person you’re talking to, or if an attacker might be “sniffing” your conversation.

The software you’re using may contain vulnerabilities. Like any other software, chat software may have vulnerabilities that attackers can exploit.

Default security settings may be inappropriate. The default security settings in chat software tend to be relatively permissive to make it more open and “usable,” and this can make you more susceptible to attacks.

Other tips to users include: try to verify the identity of the person you are talking with, and be conscious of the information revealed during a chat, especially sensitive business information over public IM services.

Some of this is common sense, but as the old saying goes: “common sense isn’t always common.”

===

Eye on Messaging is written by Stephanie Jordan, editor in chief of Messaging News. If you have story ideas or news to share, email her: sjordan [at] messagingnews [dot] com

New Directions in Push Notifications for Desktops, Mobile Phones, and the Web

Ben Gross — Fri, 11 Sep 2009 07:00:00 +0000

For the Internet connected population, the problems of access to information have long shifted from limited availability of information to problems of narrowing down the flood of relevant information to a manageable amount. Filters have become increasingly sophisticated, but timely, relevant, and unobtrusive display notifications for the information we want are still a work in progress. This article explores recent developments in notifications for desktop clients, mobile phones, and Web applications. Notifications range from the mundane “Your backup is finished” or “Someone just responded to your column online” to the important “Your flight is delayed and has a new gate” to the urgent “A large out of state jewelry purchase just appeared on your credit card” or “Your corporate mail server and primary database are offline.” Many of these recent developments are very much in the experimental stage, but are clearly leading to important changes in how we receive information. For those willing to tinker a bit, the new capabilities are impressive.

Notifications for Desktop Applications

Display notifications are commonplace. These are the little boxes or bubbles that often appear on the lower right hand corner of your screen when you receive an instant message or a contact goes online or offline. Surprisingly, none of the mainstream operating system vendors have included an easily accessible and well-documented notification system for both system events and third-party applications. Many developers have created their own notification systems to fill the void. On Mac OS X, the open source Growl project has become somewhat of a de-facto standard system-wide notification system. Growl offers a simple way for developers to deliver event notifications and it is widely supported by independent developers. Growl offers a great deal of control to end-users both for the display style, the frequency and duration of notifications, and any sounds associated with notifications on a per-application basis. Growl can optionally receive requests for notifications from networked services. Growl has been ported to Windows and has inspired a similar, but incompatible, notification system for Windows called Snarl. Growl has also inspired a Linux-based system called Mumbles that is compatible with Growl network notifications. Linux has several notification systems available including Galago/libnotify and Notify OSD.

Two recent developments, Yapper by Jeff Lindsay and Silent Diving Seagulls by Abi Raja have the potential to greatly enhance the utility of Growl by allowing the notification system to receive requests via XMPP/Jabber. Currently, networked Growl requests require a direct connection, which is problematic for users behind firewalls or NAT devices. XMPP is an open standards-based protocol for real-time instant messaging, presence, more recently VoIP, and structured data. XMPP forms the basis of the Google Talk service and many enterprise instant messaging systems.

Yapper creates a small local server that can join the Jabber network, listen for requests, and relay them to Growl. Silent Diving Seagulls combines and extends several Firefox extensions into a single cross-platform extension that can relay requests to Growl, Snarl, Mumbles, and Libnotify. Lindsay and Raja are working together to develop a standard and cross-platform reference implementation for delivering notifications over XMPP that will interface with existing notification systems. Lindsay has already written a XMPP to HTTP protocol bridge, which could further simplify developers by allowing notifications to be created from HTTP requests. Wordpress, FriendFeed, and third-party Twitter services already offer mechanisms to subscribe to feeds via Jabber, which could then trigger notifications.

Notifications for Web Applications

The absence of a standard for notifications for Web-based applications is even more obvious. We are increasingly dependent on Web-based applications rather than desktop applications. The problem is there isn’t a straightforward way for Web applications to notify users through the system that an event has occurred. In order to receive a notification, your browser must be the primary open application and the Web application you are running must be the front-most tab. Otherwise, there is no way for the application to let you know that you have received a new email or IM, your bank session is about to time out, that you have received a new message on a social network, or that the search query you are running has produced new results. Some developers work around this by distributing specialized notifications systems such as the FriendFeed notifier that maintain their own network connections or by piggy-backing on their own instant messenger client as Google, Microsoft and Yahoo! do.

Fluid and Prism are site-specific browser creation tools. They allow users to effectively turn a Web application into a desktop application, by creating a copy of the browser that works with a single site such as Gmail, Facebook, or Pandora. This new application has all the properties of a desktop application with its own dock or taskbar icon, the ability to run on startup, and the ability to be minimized. Fluid and Prism both include notification APIs for Web applications. Abi Raja created a Firefox extension called Yip that recognizes both Fluid and Prism notification APIs and can relay them to Growl, Snarl, Mumbles, and Libnotify. Raja’s Silent Diving Seagulls extension is built on top of the Yip extension. Growler, by Aditya Mukherjeey, implements Yip-like functionality for Safari on Mac OS X. Despite the limited support, Web-based services—such as the Meebo instant messenger client and the Flittr Twitter client—already implement Web notification APIs. Other individuals have contributed many Greasemonkey plugins to add Web notifications to existing Web services such as Google Voice.

Push Notification Services for Smartphones

Apple push notifications provide a mechanism to alert the user in the form of a popup message or a modified icon with a red number indicating the number of new messages. For both consumers and developers, push notifications have the advantage that an unlimited number of notifications are included with the base data plan and that they can be delivered over both cellular data and WiFi data. Given the potential rewards for a successful product on the iTunes App Store, developers are adding push notifications to iPhone applications at a rapid pace and many more have announced that support notifications are imminent. eBay, BeeJiveIM, E*Trade Mobile Pro, Yahoo! Messenger, and the Zillow real estate application all offer push notifications natively. Applications like Boxcar and GPush add push functionality to existing Twitter applications and Gmail. Pinger’s Textfree iPhone application allows users to send SMS messages for free. Users can also receive SMS messages for free, although they are delivered to a @textfree.us address and read in the Textfree iPhone application. Recently the service added iPhone push notifications so that Textfree notifies the user in a way that feels like an SMS.

Far and away the most interesting iPhone push application I have seen is Prowl–an inexpensive iPhone application and plugin for Growl on the Mac and Growl and Snarl on Windows that can send desktop notifications to an iPhone via the Prowl service. To start receiving alerts, the user simply needs to create a Prowl account and register the account with the Prowl iPhone application. Prowl immediately gives desktop applications that work with Growl and Snarl the ability to send notifications to the iPhone. There are settings to control which applications are allowed to send notifications; settings to control the look of the notifications; and settings to control when the notifications are received by defining a quiet time where only notifications designated as emergency are allowed through.

The most compelling feature of Prowl is its API, which allows you to generate iPhone notifications from many applications independent of Growl. While the process is still very much in the do-it-yourself category, nearly any application or service can send iPhone notifications with Prowl. Third-party developers have already written Prowl libraries for many popular languages as well as plugins for other applications and services.

New and noteworthy for 2/9/09

Ben Gross — Tue, 10 Feb 2009 02:22:24 +0000

KnujOn 2009 Registrar Report: KnujOn released a February 2009 update to its registrar report that focuses on domain name “registrars that have a concentration spam, abuse and illicit activity”. It is important to note that some registrars are much larger than others and while they may register many spam oriented domains in absolute terms, these may only be a very small percentage of their overall holdings.

SlideShare makes PowerPoint social (also sends it to the cloud): The SlideShare Ribbon for PowerPoint 2007 is a plugin that lets PowerPoint users store, access and search for presentations directly from SlideShare. The plugin also provides access to social features from SlideShare including contacts, groups and connections to Twitter and FriendFeed.

The $300 Million Button: A telling story about the importance of design and usability testing when developing web services, particularly ones with ecommerce components. This is an article by well known usability expert Jared Spool about the redesign of a checkout flow for a well known online shopping site. A single change in removing the forced and largely redundant registration resulted in a forty-five percent increase in monthly sales, estimated at nearly three hundred million dollars a year.

New and noteworthy in OpenID and OAuth 2/2/09

Ben Gross — Tue, 03 Feb 2009 06:53:35 +0000

Why Twitter’s New Security Solution Could Pave the Way to a Future Web of Mashups: Marshall Kirkpatrick at ReadWriteWeb describes why Twitter’s initial trail and eventual rollout of OAuth for standards-based delegated authorization is important for Twitter and is an indication of where the general adoption of OAuth is going.

OpenID + OAuth: Two Great Tastes That Taste Great Together: TechCrunch writes about the new test between Google and Plaxo of an OpenID OAuth Extension. This extension allows the approval for an OAuth request token to be embedded in an OpenID authentication request.

Explanation: The Difference Between OpenID and OAuth: Malcolm Tredinnick writes a nice summary describing the different problems that OpenID and OAuth are trying, which mirrors the difference between authentication and authorization.

OpenID Gets Explained, Maligned, and Dropped: Lisa Hoover at OStatic covers some of the difficulties with OpenID. She makes the argument that while there are a great many theoretical users, there are far fewer actual users of OpenID.

New and Noteworthy for 10/1/08

Ben Gross — Thu, 02 Oct 2008 00:44:43 +0000

People more likely to lie by e-mail: New research summarized by the Social Capital Blog discussing a study on the trustworthiness of people across different communications media. The study concluded that people were significantly more likely to lie in email.

Ambient Email Notifier: An interesting do-it-yourself hardware hacker project to build an LED-based email notification device that can change colors and brightnesses based on the type of email received.

ANT Censuses of the Internet Address Space: A large and long term, going back to 2003, research project from ISI to collect data about the internet address space (IP address allocation). The project includes visualizations and papers. The topic of IP address exhaustion is very current and many business have a vested interest in understanding the projections.