That was monumentally stupid. Security/privacy by obfuscation (GUIDs) is no security at all but a predictably incrementing ID number? I agree that retrofitting the system to use GUIDs is a bit hard but they should've considered it in the first place since it's a very small investment that would make browsing private pics extremely harder.

==>So /photos/[serial]-M-[md5(serial, secret)].jpg

Josh , what is the -M- variable ??

I am a casual user of smugmug. I do not WANT them to use GUID's. I LIKE that I can iterate my photo's easily. To me its a feature, not a bug, and one of the big reasons I like smugmug.

just my .02

/pd:
That's the image size label (M=medium).

Joshua Schachter:
Whatever GUID scheme they were to choose, it would be a massive outrage among users. Imagine millions of dead links on hotlinked images.

Unfortunately, poor design decisions in the very beginning tend to be quite difficult to change later. What's reasonable to do now is to leave the existing URLs as they are, fix the security bugs found by Philipp and Tony and think about ID randomization or GUID scheme for new albums.

SmugMug user Doug:

> I LIKE that I can iterate my photo's easily.

Except you can't iterate through your own photos easily because your own photos are not necessarily using sequential numbers due to the number of photos being constantly uploaded, so I don't understand how this helps you...

Interesting…It seems that they have adequate privacy controls, it is just tricky to figure out how/where to enable them. They should change the wording to be less confusing! It is much more effective when sites really spell out the privacy controls and emphasize their power- similar to what Pixamo has done.

Philipp, thanks for raising this issue in public. I reported it to SmugMug almost a year ago and they insisted that there was no problem. If SmugMug wants to support users who prefer a simplistic sequential numbering scheme, that's fine, but SmugMug should offer an alternative for those of us who would like a bit more privacy.

Jeff, that's interesting because Don said in his first email to Philipp (which he's now published on his blog):

<< I’m in completely agreement, that GUIDs would help greatly here, but I’m afraid our system wasn’t built for GUIDs, and retrofitting our code and database to support GUIDs would be an extremely expensive proposition. Not that we’re not willing to do it – we would certainly consider it – but yours is the first request I’ve see in years to do so. >>

From: blogs.smugmug.com/don/2008/01/ ...

Do you happen to still have the emails exchanged between yourself and SmugMug?

Tony, if he does have an email, then that opens a totally new can of worms for Don /SmugMug- its called as a "Due Diligence" and "Reason to Belive" statutory instruments can be triggered!!

I do have the emails. They went to SmugMug support and the replys came from Andy Williams. I didn't ask for GUIDs, but I did ask for a solution (I mentioned an alternative suggestion that would have prevented simplistic enumeration).

Thanks for your post on this matter.

As a smugmug user, this issue alarms me because when I mark things as private I want them to be truly private--meaning that people can't see my photos.

What worries me is that smugmug's oversight on this matter points to other undiscovered oversights that are far worse.

I hope that smugmug will implement some sort of obfuscated ID system soon. Or at least give users the option to request an obfuscated URL.

I was on the verge of setting up another smugmug account but now I am looking to other services that are using GUIDs or MD5 hashes for gallery URLs and photo URLs.

Update from Don:

blogs.smugmug.com/don/2008/02/ ...

Were SmugMug honest, user-centered, and initially not so stupid as they now admit (if veiled in euphemisms of this and that), the whole upgrade to non-iterative urls would have gone faster and smoother. Instead, Philipp and others had to persist in bringing that --one would have thought beyond obvious-- issue up to these no-goodniks' attention (persist up to and including unpaid code forensics and hitherto unknown, novel attack vectors). In effect a few outside hackers had to perform UNSOLICITED LOBBYING for SmugMug's own good, because its leaders were --if for a moment-- incompetent [Randal L. Schwartz' case also comes to mind].

Leaving aside the assignment of blame, it'd interesting to know how much, in monetary terms, Philipp would judge the cost of that work (time x hourly rate = estmate)....

... and then compare that, no doubt reasonable, sum to potential cost to SmugMug of either having to defend itself in court after somebody, whose "privacy" has been breached, has sued for damages; OR that, AND h ving to pay real $uper-$ized settlement in a subsequent class action.

I know it's difficult to judge offhand, but, hey! we know you can do hextrix, but can you count in decimal? ;-))

Thanks Tony. I added this update to the post:

<<SmugMug announced they’re now calling the option “unlisted” instead of “private” – see new interface for creating galleries* – and they're also appending a key to new URLs to solve the problems of photo IDs being easy to iterate. All old photo galleries on the other hand will remain insecure as outlined above (unless the user e.g. moves them into a new album).>>

They don't seem to want to go through some forced transition phase to secure existing photos, as Google's Picasa Web Albums did a while back when they were pointed to their issues. A transitional phase like e.g. an email "please unlock your gallery until next month if you actually meant it to be public (there was a bug which made your private pics public)", which could additionally have consisted of helping customers who access existing pages via automated alerts ("the gallery is protected now, would you request the owner of it to grant you access?" etc.) In other words, instead of making insecurity opt-out, SmugMug made security opt-in for existing galleries... erring on the side of having a security vulnerability for users who don't take action now for whatever reason.

*Wonder why they're not using 3 radio buttons in their new creation interface – the "lock down" option, which asks you to define a password, ghosts the other two radio buttons anyway when you choose it – and call it "() public ... () unlisted ... () private":

blogoscoped.com/files/smugmug- ...

> Wonder why they're not using 3 radio buttons in their new
> creation interface ...

I guess that's because you can have a public gallery that is "locked down" with a password and external linking disabled. I assume those extra settings appear once you check the "Lock it Down" box?

Tony, picking the third button will ghost the other two radio buttons anyway (and preselect "unlisted")* – so it's already working pretty much exactly like 3 radio buttons would work. Their interface layout suggest you can have both "public" and "lock it down", but their interface behavior suggests you can never combine "public" and "lock it down" (lock it down always implies unlisted, their interface behavior suggests). So I wonder why they don't call the "lock down" option "private", as private implies not listing the gallery anyway... and perhaps call the "unlisted" option "only unlisted" or something.
Well, but those are minor interface discussions, and opinion may vary. The bigger issue seem to be the masses of old unsecured photos which remain unsecured even when their owners originally set them to private.

*Here's what you see with the right option checked:

blogoscoped.com/files/smugmug- ...

If this was my site, I would have splurged and gone for a sixth character for the keys.

601,692,057 combinations might be too expensive to exhaustively search today, but those URLs are going to be around for a long time.

34,296,447,249 would have been so much better, for the cost of one extra character. If you're going to redesign the site anyway, may as well do it properly.

> picking the third button will ghost the other two radio buttons

In that case, you're absolutely right. I guess this way it just reinforces the fact that locked down galleries are also unlisted.

I guess "lock down" automatically switches off external linking too. I guess that makes sense even if it's not as flexible as before. (Why would anyone want to password protect an unlisted gallery but still publicly link to the images?)

Roger, seems they also wasted 1 character by using underscore instead of a-z.

e.g.
bla.smugmug.com/gallery/4301686XBt8Wr
instead of
bla.smugmug.com/gallery/4301686_Bt8Wr

The string would still be splittable into ID and key by splitting at the first occurence of a non-numerical character.
This would also have made the URLs look less technical (and it would also prevent the admittedly minor issue that in some link-rendering contexts, link underlines make underscores disappear in the layout).

Then again, if they'd use a GUID instead of still printing out the ID in the URL, they could save even more characters because of the choice of more characters available per position.

> I guess that makes sense even if it's not as
> flexible as before.

Above dialog is when you create a new gallery... the new customization options when editing the gallery settings are still flexible/ confusing to some degree:

blogoscoped.com/files/smugmug- ...

"Special thanks to our customers and friends who weighed in with lots of detail both about the problem and the implementation, and Philipp for being so passionate and firm about the situation."

I tell you that Don guy – is an upfront dude – watching this story unfold and the action and reaction was really a neato experience. I wish all s/w vendors and service providers had the class of Don /SmugMug team. On the technically side of things I'll need to digress because thats really not my flavour, but on the social / community side.. I tip my hat to Phillipp, Tony and Don!!