Archive
Why OpenID at SmugMug?
We announced OpenID support last week. I then responded to some comments asking us why we were a provider first, rather than a consumer. Now, I’m answering some more comments basically asking why they should care about OpenID and how it helps SmugMug customers.
Honestly, I had no idea it wouldn’t be obvious how great this is. To me, the picture seems perfectly clear. There are no dastardly designs or secret agendas – to me, it just makes sense. Here’s are a few reasons why:
We are a pay site. Every SmugMug customer pays for the right to share their photos here. They get what they pay for. That comes with both pluses and minuses where identity is concerned, though. On the one hand, we have a much much stronger relationship with our customers than somewhere free like Hotmail, for example. On the other, we have no good mechanism to interact with viewers, who don’t and shouldn’t have to pay (or even sign up) to see their friends’ photos.
Let’s talk about the pluses first. There’s a much higher level of trust and respect between the customer and SmugMug than a free email provider. They feel secure in knowing that we treat their data carefully and with respect. They consider SmugMug to be their home (or at least a major part of their home) online. They strongly identify with the brand and even more strongly identify with the fact that their memories are stored and shared from our servers. They identify with us.
Do you see where I’m going with this? While everyone has multiple identities online, from email to IM, blogs to photo sharing, the ones where there is a volume of priceless content, such as their photo-sharing site or blog, are the ones our customers identify with the most. Email addresses are “less permanent” since they’re free, easy to forward, etc. Ask your typical passionate Flickr or SmugMug customer, though, and they’ll tell you about their passion for their photos and the pain and anguish it would cause them to move or if the service died. Note that not everyone falls into this category – but those passionate about photo sharing *do* fall into this category, and that describes every SmugMug customer.
Further, I believe the customer should get to choose which site they identify with most. I’d hate to limit them to only their email provider if they happen to hate their email provider. Just like everyone resonates with different brands of cars, jeans, computers, music, etc, they also resonate with different sites. Leave the power in the hands of the customer – let them choose their own identity.
Now, let’s talk minuses. Since there are no free accounts at SmugMug, we can’t interact as well with our viewers. They’re allergic to setting up “yet another account,” something I resonate with, or even passing over their email address. I completely get that – it really really sucks when you go to view someone’s photos at KodakGallery or Shutterfly and they demand your email address so you can get spammed till the end of days. It also sucks when you want to leave a comment at Flickr but can’t without signing up for a Yahoo account. What a pain.
OpenID goes a long way towards solving some of these problems. Comments can now be far more spam-free since identity can be verified, yet the commenter doesn’t have to go through the hassle of signing up for yet-another-account. Access controls to photos and galleries can be specified by the owner of the photos in such a way that sensitive data (like email addresses or passwords) no longer has to be exchanged. Even if we wanted to, SmugMug couldn’t spam someone using their OpenID to leave a comment or view a photo. That’s big – I hate giving my email address out to sites because so many of them *do* spam, you’re never sure which ones are the “good guys” like we are.
OpenID isn’t perfect. There’s no trust here – just identification. There’s still no complete single sign-on. There are issues with dangling stale IDs being left around. Consumer education is going to be interesting. But it’s still a huge step in the right direction. Just verifying that someone has an identity somewhere online gives you the ability to make your apps richer, regulate abuse more easily, and generally improve the user experience.
What’s not to love?
More SmugMug & OpenID
I hope you’ve heard we now support OpenID. If not, now you have. 🙂
A commenter asked politely (after deleting his first rant) why on earth we were being a provider, when being a consumer was more important. I completely disagree, and here’s why:
We should be both. And we will be. But I believe in releasing features quickly and incrementally, so I had to choose one or the other. I chose being a provider. Why?
You can’t sell lightbulbs to those without electricity. You can’t sell gasoline cars to those without access to gas stations. You can’t consume OpenID if there’s no-one who has an OpenID.
Up until AOL’s announcement, LiveJournal/SixApart was the best (and only?) source of OpenIDs on a reasonable scale (100,000+ users), as far as I know. That’s really not very many users. I figured throwing our 100,000+ into the mix would help. I certainly hope it has. AOL, though, threw 63,000,000+ into the mix – so now we’re even closer to a critical mass.
This is a chicken-or-the-egg problem, and I believe you need lots of providers with established user bases to jumpstart it. I’m glad there are tons of brand-new OpenID providers who’ll give you an ID for free – but I believe the real make-or-break metric will be existing services enabling huge chunks of people in one fell swoop.
We just swooped. 🙂
On a side note, while I rarely whine about our lack of coverage (generally, I believe the best way to get coverage online is to buckle down and improve your product), I was surprised to see our OpenID news fall on the net in complete silence. More than 30,000 people read my blog on Friday, but not a single blogger or news source I’m aware of picked it up. Digg can announce that they’ll have support “later this year” and get tons of coverage but we enable more than 100,000 people overnight, making us the 3rd largest OpenID provider on the planet, and no-one cares?
We didn’t do this to get coverage, we did it because I’m a geek and I think OpenID rocks. But a little, tiny bit might have been nice. I guess my “improve the product” theory doesn’t work after all. Can someone enlighten me as to what I’m doing wrong?
Oh, and I’m sorry for the whining. I’ll try not to let it happen again. 🙂
SmugMug embraces OpenID
The subject says it all and I’m thrilled. Here’s some details:
- We’re an OpenID 1.1 Provider. Hundreds of thousands of SmugMug customers can now use their SmugMug homepage URL as their ID on sites all over the net.
- We don’t yet support Diffie-Hellman association, so if plaintext isn’t ok, you’ll have to fall back to dumb mode. Sorry about that. I’m hoping we can support DH soon, but I’m really waiting for Wez’s PHP patch to use OpenSSL’s functions. I may end up creating a custom build, we’ll see.
- We’re planning on consuming OpenID for photo comments and other things shortly.
- We probably have bugs. Sorry about that – let me know and we’ll get them fixed.
OpenID is a fantastic idea, I’ve loved it since I first heard about it, and finally found a day to play with it. AOL recently announced support, and so did Microsoft. OpenID will be everywhere.
I’m a little worried with the direction OpenID 2.0 seems to be going – one of the great things about OpenID is how simple and easy-to-implement it is. I haven’t taken a good, close look yet, but the preliminary 2.0 spec seems to be complicating things a great deal. I see that as a Bad Thing(tm) but maybe I’m smoking crack.
The documentation for OpenID leaves a lot to be desired. Specifically, there’s no example messages, including sample values, for you to make sure your code is doing the right things. Luckily, the spec is so simple that some trial-and-error takes care of things, and someone has written a great narrative overview of the implementation. I will put up an OpenID page on our wiki that includes example requests and responses, including secret keys, so anyone else implementing this from scratch has some values to work from.
LiveJournal (and thus, Brad’s CPAN module used by lots of other services) seems to have some bug in it where it doesn’t like OpenID server URLs without a trailing “/”. It returns a useless (to me?) error message: “naive_verify_failed_network” which meant I spent hours and hours of time going over my code with a fine-toothed comb. Finally, out of ideas, I made a 1 character change to my HTML and everything magically worked. I don’t understand why, since the docs don’t state this, and Vox seems to have an openid.server without a trailing /, but oh well. It fixed my problem. 🙂 Hopefully this will help someone else figure out what that message might mean.
There are clearly still issues around OpenID, such as what happens years from now when your OpenID identities are lingering out there long after you’ve closed the account from which the ID was provided? Someone else may even own or use that old URL if it’s been repurposed. But there seem to be smart people thinking about the problem, so hopefully everyone will figure it out without bloating it or making it unusuable.
I think OpenID is huge, and I’m glad we’re able to move the ball up the field a few more inches.
Browser History – How we did it (as told by Yahoo)
I’ve been hounding GreenJimmy, our resident Web SuperHero, to write up our approach to solving the Browser History problem when using AJAX apps. I wrote in broad terms about our solution (and how it worked on Safari, the tough one, in addition to Internet Explorer, Firefox, etc), and promised that Jimmy would update his blog with a detailed explanation.
That was exactly a month ago, and Jimmy has written exactly nothing. I guess I need to employ more Lex Luthor management techniques, because clearly I’m sucking in the boss category. 🙂
Luckily, our friends over at Yahoo have a new Browser History Manager in the latest YUI release, and it does the same thing we did in the same way. Best part? They actually wrote up how they did it so the rest of the world can use it. So if you’re curious as to how to get Safari to behave with proper history, including full back/forward button support, go read up.
Many apologies for everyone waiting around (and emailing me) for our solution. Many thanks to Yahoo for stepping up to the plate and sharing.
Yahoo, YUI, & Browser History
Today, the YUI blog mentions they’ve released a great new version. As you probably know, we’re a huge fan of YUI – we couldn’t have done our fantastic new UI without it. We’ll be at the YUI party this week, celebrating with everyone else.
However…
When talking about the new Browser History Manager, they mention that “No one, as far as we know, has resolved the technical issues in a satisfactory way across the A-Grade.” Alas, that’s just not true – SmugMug has solved this technical issue, and we did it first. What’s more, the YUI team knows about it – we had lunch with them and told them exactly how we did it. Their Safari implementation is exactly the same as what we did and explained. We even offered to give our code back to them under a BSD license so they wouldn’t have to duplicate our work.
It looks like they missed one technical detail of our implementation, though. Safari has an issue with “permathrobber” (basically, the Safari throbber never stops throbbing) which we managed to solve.
Note that I’m not upset that they have a great Browser History Manager – far from it. I just wish they’d give us a little credit where credit is due, given that we pimp YUI any chance we get for them.
We built it first, they know it, and sharing the love is the right thing to do.
UPDATE: Just called Yahoo and the love is still flowing. 🙂 Turns out the two guys who wrote the Browser History Manager are new to the team, weren’t at our lunch, and had no idea what we were doing. Great minds think alike. 🙂 And Yahoo can’t accept our code currently, even under a BSD license, but they’re working hard at getting that changed. Sounds like an internal big-company roadblock.
Google – Please please please support email aliases!
If anyone from Google is reading this, please, hear my plea!
I, like many people, have more than one email address. One for work, one for home. It’s nice to keep them separate. I’m sure you know what I mean.
I also like to use Google’s services, such as Calendar or Docs. Since I use multiple computers, it’s nice to have stuff centralized out on the net. I’ve wanted this for decades.
But my friends & co-workers don’t always know which email address to send meeting invitations or document permissions to. So I get a Calendar invite or a Docs link, and click on it, and I’m greeted with “Sorry, you don’t have permission to use this.” WTF? I clicked on the unique link in my email, and I’m already logged into Google, what do you mean I don’t have access? Oh, duh, they used my personal email address instead of my work email address. Crap.
So I’m left with two choices: Just not interact with Google on this particular event or document (most likely) or email the party back and ask them to resend (least likely).
Please, Google, let me add email aliases (yes, verify that I actually own them first) to my Google Account so all your services will recognize me from my multiple email addresses. Pretty please? With a cherry on top?
Oh, and it’d be nice if our years-old application to Google Apps for Your Domain was accepted too, but that seems to have gone into the void. Doh.
Find Jim Gray using the power of the web
I’ll make this short and sweet: A ton of great people from lots of great companies teamed up and managed to get satellite and aircraft imagery up on Amazon so that you, and everyone you know, can quickly and easily help sift through and help in the search.
You can help find Jim Gray. Go now.
You can also read more here if you’re curious about the heroic efforts behind this part of the search.
Amazon S3: What would you like to know?
As I mentioned in my article about performance issues with S3, I’m speaking on the subject at ETech this year. I’m planning on spending roughly half the time on the business ramifications and half on technical architecture. And I’ll be posting the slides or a PDF or something here after the presentation.
But I’d love some feedback about what you would like me to talk about so you can get the most out of my presentation and/or the information I put up here.
Leave a comment telling me what you’re most interested in about S3 and our implementation and I’ll re-prioritize based on your feedback.
Thanks!
UPDATE: Slides from ETech 2007 are up.
The Dark Side of the Flickr Acquisition
You asked for it, you got it: SmugMug is offering 50% off to all Flickr refugees. Just sign up for our free trial using the coupon code flickr and if you like what you see, you’ll get 50% off your first year.
We’re getting some email from ‘Old Skool’ Flickr users asking us if they can get a discount because Yahoo’s making some changes they don’t like. Thomas Hawk has more coverage over on his blog, you can read the Flickr Forums for more reactions, and even check out the Flick Off group (aka the Flickr Accounts Mass Suicide Countdown group).
I’m afraid this is the dark side of acquisition, especially by a company that doesn’t seem to resonate with Flickr’s core passionate users. Every time someone inquires about acquiring SmugMug, we shut them down immediately because we’re terrified of exactly this happening – our user experience being damaged by a parent corporation that doesn’t “get” our customers.
I should be clear up-front, though, that while we’re thrilled you want to check us out – we’re not Flickr and we’re not trying to be. We’re short on social networking and long on advanced features like customization, style, and user interface. To make your photos look great, we are the place.
Give us a shot, though. It’s free to try, after all. And we have a track record of listening very closely to customer feedback and implementing what they want. So if you like most of what we have to offer, but we’re missing something crucial, let us know. We just may build it for you. 🙂
UPDATE: It was just pointed out that there’s a Flickr-to-SmugMug migration tool using our open APIs. I’m sure there are others, and I know there are SmugMug-to-Flickr tools, too, should you decide you don’t like our service after all.
Amazon S3: Outages, slowdowns, and problems
First of all, I’m giving a session on Amazon web services (with S3 being the main focus, with a little EC2 and other service love thrown in) at ETech this year. I’ll post a PDF or something of my slides here when I’m done, but if you’re really interested in this stuff, you might want to stop by. Wear some SmugMug gear and I’ll comp your account. 🙂
UPDATE: I’ve posted a call for topics you’re interested in hearing at ETech or in the resulting PDF. Let me know.
So there’s been some noise this month about S3 problems, and I’ve been getting requests about what we do when Amazon has problems and why our site is able to stay up when they do. I’m happy to answer as best I can, and I’d like to remind everyone that I’m not paid by Amazon – it’s the other way around. I pay them a lot of money, so I expect good service. 🙂 That being said, I think they’re getting too much heat, and I’ll explain why.
First, lets define the issues. During our history with Amazon S3 (since April of 2006), we’ve experienced four large problems. The first two were catastrophic outages – they involved core network switch failures and caused everything to die for 15-30 minutes. And by everything, I mean Amazon.com itself was offline, at least from my network view. (Due to DNS caching issues, even GSLB’d sites can look “down” to part of the world while remaining “up” to other parts. I don’t know if this was the case during these two times). We’ve had core network switch failures here at SmugMug, too, and they’re almost impossible to prevent.
The other two were performance-related. Not outages, because the service still functioned, but massively slower than we were used to. In the first case, which happened right as the BusinessWeek cover article hit newstands and during the Web 2.0 Summit, our customers were at our gates with pitchforks and torches. Our paying customers were affected and they could tell there was something wrong. Not good.
The second time, though, was in early January, and our customers had no idea. I emailed the S3 team to let them know we were seeing issues, flipped a switch in our software, and we were fine.
So what was the difference? We’ve been playing with using Amazon in a variety of different roles and scenarios at SmugMug. At first, we were just using them as a backup copy. That provided some great initial savings and a great deal of customer satisfaction as our customers became aware that their photos were safer than ever. As time went on and we grew more confident in Amazon’s ability to scale and keep their systems reliable, though, we moved Amazon into a more fundamental role at SmugMug and experimented with using them as primary storage. The week we started to experiment with that was the first of the two performance issues, and shined a bright glaring light on the downsides of using them in this way. We quickly shifted gears and are now quite happy with our current architecture, both from a cost view and a reliability view.
So what are we doing differently? Simple. Amazon serves as “cold storage” where everyone’s valuable photos go to live in safety. Our own storage clusters are now “hot storage” for photos that need to be served up fast and furious to the millions of unique visitors we get every day. That’s a bit of an oversimplification of our architecture, as you can imagine, but it’s mostly accurate. The end result is that performance problems with S3 are mostly buffered and offset by our local storage, and even outages are mostly properly handled while resyncing after the outage passes. For the curious, this architecture reduces our actual physical disk usage in our own datacenters by roughly 95%.
Further, we also have the ability to target specific Amazon S3 clusters. In January, we noticed that their West Coast cluster seemed to be performing more slowly than their East Coast cluster, even though we’re on the West Coast, so we toggle our primary endpoint to use the East Coast for awhile. This is the switch I mentioned earlier that I flipped, and it worked out beautifully.
Now, though, I think we come to the real meat of the problem. Are we upset about Amazon’s issues? Do we regret using them? Are we looking elsewhere? Absolutely not, and here’s why:
I can’t think of a particular vendor or service we use that doesn’t have outages, problems, or crashes. From disk arrays to networking gear, everything has bad days. Further, I can’t think of a web site that doesn’t, either. It doesn’t matter if you’re GMail or eBay, you have outages and performance problems from time to time. I knew going into this that Amazon would have problems, and I built our software and our own internal architecture to accommodate occasional issues. This is the key to building good internet infrastructures anyway. Assume every piece of your architecture, including Amazon S3, will fail at some point. What will you do? What will your software do?
Amazon does need to get better about communicating with their customers. They need to have a page which shows the health of their systems, and pro-active notification of major issues, a 24/7 contact method, etc. I’m on their Developer Advisory Council, and believe me, they know about these issues. I’m sure they’re working on them.
To put things into perspective, we have vendors which we pay hundreds of thousands of dollars to each year that seem to be incapable of providing us with decent support. Amazon is not unique in terms of providing a great product but average support. If you ask nearly anyone in IT, I think you’ll find that’s far more common in our industry than it should be and not unique to Amazon in particular.
Finally, S3 is a new service and yet remarkably reliable. Since April 2006, they’ve been more reliable than our own internal systems, which I consider to be quite reliable. Nothing’s perfect, but they’re doing quite well so far for a brand-new service. Oh, and their services has also saved our butts a few times. I’ll try to write those up in the near future, too.
Other Amazon articles:
See you at ETech!
SmugMug's Don MacAskill 