Change in SmugMug URLs for better privacy

[Baldy]

Some of you have been reading the debate in the blogosphere about SmugMug URLs to private images being too easily guessable. The blogs were not written by our customers, but they do make some good points. We've received a few dozen emails in response and they tend to fall into 3 camps:

1. Leave it as is. Your URLs are short and simple. Don't use GUIDs and mess your URLs up by having strings that look like:

3F2504E0-4F89-11D3-9A0C-0305E82C3301

in them.

2. The problem is SmugMug's choice of words. You should say "unlisted" or "hidden", not "private."

3. Can't you do something simpler than a long GUID so your URLs don't get so messed up but they're harder to guess?

So here's a proposal:

What if we were to add 6 characters--an underscore and 5 alpha-numeric characters to each URL? They would then end in something that looked like _hyqpb.jpg. That would mean up to 60,000,000 guesses per image.

This would apply to images going forward, public or private. For the 250,000,000 images on the site now, in order to give them a new URL, you'd have to move them to a new gallery. The downside is their new URLs would break any links to them right now that you have in forums or blogs.

Is this solution reasonable? If not, can you tell us why? Any other ideas?

Does this fit your definition of privacy? I have an email in my box from a customer who loves us but is shocked that we would think any image that can be seen by any other person could be considered private. In other words, when he marks a gallery as private, giving the URL to a friend would not enable them to get into the gallery. Anyone else feel that it should work that way?

Thanks for your feedback. We'd like to think this through and get it right but we don't want much time to pass either.

Thanks,
Baldy

[richpepp]

So here's a proposal:

What if we were to add 6 characters, an underscore and 5 alpha-numeric characters to each URL? They would then end in something that looked like _hyqpb.jpg. That would mean up to 60,000,000 guesses per image.


That seems like a nice idea to me. I also don't like the GUID idea as then we end up going down the TinyURL route which removes benefit of using our own domain name (photos.miseast.org/...).

I love the granularity of the security settings and have completely understood what 'private' meant but I can also see that with 5 different switches the number of options may be a little overwhelming for folks just arriving. Maybe you could also have a 'Quick Security' drop down box with just a couple of options that set the other switches up: e.g. 'Only people I invite with the password (most secure)', 'Anyone who knows the link to the gallery can see the pictures (less secure but simpler)', 'Everyone can see my photos but can't get the originals'. Clearly these aren't all of the possible options but the idea is not to iterate all of the possible options - just to give a small easily understood subset.

Rich

[scwalter]

I think smugmug provides all the tools needed to protect photos and I don't want super long URLs. In my opinion, it boils down to users not really understanding the choices. Guessing photo numbers for a private gallery only works if external linking is available, right?

One way to make sure people don't miss the choices is to combine them into one choice for "security". Currently there are quite a few choices there and most poeple probably don't understand the implications of all of them. I propose you combine the private, external linking fields into a drop-down list with the options:

- Public/Direct Links Allowed
- Public/Direct Links Prohibited
- Unlisted/Direct Links Allowed
- Unlisted/Direct Links Prohibited

and then explain how even on an unlisted gallery with direct links enabled, people could still get to your photos. You could even included password in the list too, but then it becomes 8 choices.

-Scott

[wellman]

I agree with scwalter that your main issue is one of education. Despite the fact that most folks understand exactly what your definition of "Private" is, that word alone probably gives too secure a connotation to someone not reading the details.

My suggestion would be a very well-thought-out tweak to the security settings UI and verbage.

As for the GUIDs... Seems like a good idea, too. The current system is simple enough, but it's not like I'm typing out or trying to remember URLs or image IDs. Copy and pasting a URL isn't going to get any more complicated by adding 6 characters. (The proposal of applying this to new/moved images is a good one.)

Thanks for your openness, your calm, and your solicitations for feedback. You guys all did a great job of not turning this thing into a torchfest.

[rainforest1155]

I think smugmug provides all the tools needed to protect photos and I don't want super long URLs. In my opinion, it boils down to users not really understanding the choices. Guessing photo numbers for a private gallery only works if external linking is available, right?

Keep in mind that the external links option doesn't prevent people from directly accessing image IDs. On popular request, years back, external linking keeps images only from showing up if a link is clicking on another site or forum, like Dgrin. If there is no referrer page (the link has been copied to the browser address bar) or if the referrer is blocked by some firewall software, people will be able to see photos with external linking turned off.

Sebastian

[mhilbush]

The short, simple URL is one of the small, but important features of Smugmug. I like it the way it is.

I believe this is primarily a terminology problem. Among the existing privacy options (private, password protection, external linking), I feel you already give me enough tools to manage the protection of my photos. IMO, adding more options will increase the combinations of the settings, and probably complicate things even further. If I really want to lock down my photos, can't I just make them private and password protected?

Having said that, I would tend agree that "private" might be a poor choice of terms, and perhaps you should consider renaming it. Aside from that, I would leave things alone.

Mark

[corbosman]

The truth to this whole discussion lies in the middle. Sure, it's partly a matter of words. Make it easier to understand what the different options are. Im quite computer literate but I sometimes get confused by the options as well. I like the words 'hidden' and 'protected' myself.

But I do think the original blog had a point that it is just slightly too easy to walk the image tree this way. A little too easy for comfort. It's just a matter of time before we'll indeed see some large zip with lots of private unprotected images on bittorrent. Try and explain that with a straight face to the person in your inbox Baldy. Thats a discussion Smugmug can't possibly win. Even if they are somewhat correct in that you cant get a specific image, that may not be the point of this as MySpace recently found out.

I think SM has no choice but to add some kind of extra characters. You cant just ignore this issue because there is a large imbalance in the consequences of this issue. People that think their images are truly private, say nude pictures of themselves, face severe consequences through exposure. While adding a few extra chars hurts almost no one to the same effect.

Personally I dont mind if SM uses GUIDs. I dont really understand why people get so worked up about URLs. It's not like you have to remember them. Maybe SM could somehow combine GUID with a non-hacky way to beautify your URLs. But if there is really that much resistance to GUID, 5 extra characters would work for me.

Or I have a totally different option. Allow people to add to the basic URL with their own selection. A small text box like:

http://uwimages.smugmug.com/gallery/3988206 (http://uwimages.smugmug.com/gallery/3988206_)[_fill in yourself with a max of X] to become http://uwimages.smugmug.com/gallery/3988206_underwater.

That way, you could give every single existing URL that option, but make it empty. People can opt to fill it in, to change the URL to that specific gallery without having to copy all images to a new gallery. I would say that is MUCH harder to brute force than a pre-defined string.

Cor

[denisegoldberg]

I also prefer the current url structure. I want people to be able to easily find my galleries.

I agree with Scott that the problem is the use of the word private. I like his suggestions (above). And it seems to me that people who really want to hide their world should be using smugislands.

My vote? Leave the url structure as is and change the use of the word "private".

Also - I link to my photos extensively, so I also agree that you shouldn't change the existing URLs unless the owner of the gallery indicates that they should be changed.

--- Denise

[cmason]

I think whatever URL you provide is fine by me, since I just cut and paste or email them to friends and family. Wouldn't notice one way or the other what it is.

I would like to comment that I believe a small bit of the problem is that the settings and configurations for this stuff are 1) skattered and 2) waaayyy too cute. You guys provide tons of good features, but then put them all over the config panels (better now with new panels), but also obscure them in funky words like 'smug islands' and 'hello world' etc. I mean I am all for having fun, but WTF do those mean? Why not use plain english when it comes to critical privacy settings, so we don't have to go use the Smugmug interpretation bible whenever we want to protect something? Put the cute elsewhere.

[georges]

First and foremost, this is a terminology problem. I do like the idea of changing private to unlisted.

Second - Please don't make extremely long urls. When I post a link to a single picture in a forum, or send a link to a friend, the urls are already too long. Once the url wraps to more than one line, many email readers don't handle the link properly. The is especially a problem when a wrapped link is in the quoted part of message thread.

As for tinyurl? Personnaly, I never click on tinyurls. I like to know where I'm going.

[olegos]

I disagree that this is terminology or user education or arranging options problem (although the options are confusing -- it's non-trivial that password protecting a gallery doesn't password protect the images in it, but this is secondary). The main problem, as is clearly described in the blogs, is being able to access private photos by iterating URLs, and this has to be fixed. There is NO benefit to us in having the URLs be numeric and sequential as they are. The proposed solution is fine with me, as is using GUIDs. I would only prefer that URLs stay under 80 characters long, so they don't start getting broken by some mail clients.

By the way, with this issue getting attention and many people trying it out for themselves, I believe one of my private galleries has been accessed: the stats show 1 access to medium size for every photo, with no accesses to thumbnails or any other sizes. I've changed all my private galleries to also hide owner (although there may still be identifying info in the photos themselves, or in the comments) for now, but I'm waiting for a real solution. I'm also very troubled by the reports that fully protected photos, in password protected galleries and no external links, can be accessed (the contest image). Looking forward to this issue getting fixed too, and explanation of the details afterwards.

[DJ-S1]

As for embarassing nude photos being found and posted online, isn't nudity prohibited on Smugmug anyway?

I personally don't care what the URL is, it doesn't affect me in the least. To Georges: Every email product I know of allows you to paste links into clickable text, like this (http://www.google.com). That eliminates any problem with super long links not working properly in emails.

I have to agree that the terminology is one of the big problems here. The word "private" means something very specific in Smugmug, and I think it is explained very well. However, if people don't read/don't understand/don't remember this then what happens? Obviously the person thinks that the standard Websters definition applies.

I would change the security gui a bit; maybe a "no protect", "medium protect" and "max protect" option for simple use and still have the total granularity available for advanced users?

Right now you have 6 main options, and so you have what, 64 possible settings? (It's been a long time since high school:rolleyes) I'm pretty comfortable with the settings and even I'm not sure what level of security happens when I have:

Public=no
Hello World=no
Hello Smuggers=yes
ext. links=no
protected=no
hide owner=yes

Exactly how locked down is that gallery? :scratch

As I'm typing this I also realized that setting the first 4 of those options to "no" makes the gallery more secure, but the reverse is true for the last 2 settings. Maybe they should all be one way; set everything to "no" and it's the most secure?

Just my thoughts - I'm very confident you folks will figure out the best solution for all concerned. :thumb

[hurricanesteve]

1) As a non-pro member, I don't have income riding on this issue, but I can imagine how I would feel if a 12-year old with Firefox download manager sucked all my photos out of a private gallery without having been given a single bit of information from me.

2) I agree with others that terminology is the enemy here. From my experience, especially in a multi-lingual global marketplace, you will never find a single set of terms/phrases that will appropriately describe the behavior. I have noticed in the blog entries, and in these messages here, a sense of "EVERYONE INTERPRETS THE WORD 'PRIVACY/UNLISTED/WHATEVER' IN THE SAME WAY I DO." Ah, if only.

2a) I humbly suggest a use-case based description of what each setting will and will not allow. Please include best and worst case scenarios to the best of your knowledge. Choose whatever terminology/descriptor you like. Think about describing the behavior of three 'users': I) Smugmug gallery owner, II) a person you want to view your photo(s), and III) a 'bad guy' who would like to steal/share your photo.

2b) Just as a final comment, SM's current terminology and descriptions are confusing to me. (I am a casual user. I am a native English speaker. I have had computers in my life since the age of 10. I have a graduate degree. I am in the tech industry. I am under 40.)

3) GUIDs are good. An option to turn on/off GUIDs for a gallery would be ideal from a user perspective. Users who still want the old linking/easy iteration can keep it. Those of us who dislike the easy access can shut it down. I don't know anything about SM's limitations from a structural standpoint, so weigh it against your costs. To revisit point 2, not everyone will understand what a GUID is, so use-case based descriptions will be necessary.

[digitalpins]

I also prefer the current url structure. I want people to be able to easily find my galleries.

--- Denise

I agree I like things the way they are

Maybe newbies dont understand that private (or by clicking NO option by the public setting) really means that they are still open for anyone to view but someone would have to know your url.


I would change the security gui a bit; maybe a "no protect", "medium protect" and "max protect" option for simple use and still have the total granularity available for advanced users?

Right now you have 6 main options, and so you have what, 64 possible settings? (It's been a long time since high school) I'm pretty comfortable with the settings and even I'm not sure what level of security happens when I have:

Public=no
Hello World=no
Hello Smuggers=yes
ext. links=no
protected=no
hide owner=yes


I also agree here with this above.... maybe these three "no protect", "medium protect" and "max protect" may help, because maybe those 6 options we have to select now could be a bit confusing to newbies

[olegos]

I also prefer the current url structure. I want people to be able to easily find my galleries. I agree I like things the way they are
I don't understand this. Do you really expect people to find your galleries by typing random numbers into URLs? What visitors do you think you're getting that you wouldn't get with a different URL scheme?

[denisegoldberg]

I don't understand this. Do you really expect people to find your galleries by typing random numbers into URLs? What visitors do you think you're getting that you wouldn't get with a different URL scheme?
You're probably right - I was thinking about the ability to access a category without a guid attached to it.

And I certainly don't want links to existing photos to change; I link to my photos from my blog and from other places on the web as well. Broken links would not make me happy.

I also have a hard time believing that adding another number onto a generated album or photo id would improve things at all. Changing the word "private" to reflect the english word for what private does today in smug makes more sense to me.

--- Denise

[mlee]

I don't have a problem with the way things are now--there are options to do almost everything to make your photos secure and changing to GUIDs or even adding a random string is going to cause more headache for everyone involved. The shorter/easier to link URL the better, IMHO.

When I first signed up a year ago, there was a bit of a learning curve when it came to figuring out what the different terminology meant, but after I understood it made perfect sense. I agree with changing the terminology to potentially ease that learning curve, but it really makes no difference to me today.

[olegos]

I don't have a problem with the way things are now--there are options to do almost everything to make your photos secure and changing to GUIDs or even adding a random string is going to cause more headache for everyone involved. The shorter/easier to link URL the better, IMHO.

When I first signed up a year ago, there was a bit of a learning curve when it came to figuring out what the different terminology meant, but after I understood it made perfect sense. I agree with changing the terminology to potentially ease that learning curve, but it really makes no difference to me today.
mlee, you're not making much sense. There is no option to make your photos inaccessible by simply iterating a number in the URL, which is the issue being raised -- unless you turn off all external links, making them also unlinkable directly from your blogs and emails as well -- and as I understand it's not bulletproof anyway and has been circumvented.

Then you go on saying that the existing options make perfect sense, but you still wouldn't mind having them changed -- while at the same time it sounds like you oppose changing the last component of the URL, which has no effect on user interface, learning curve, understandability of options, etc.

[mlee]

mlee, you're not making much sense. There is no option to make your photos inaccessible by simply iterating a number in the URL, which is the issue being raised -- unless you turn off all external links, making them also unlinkable directly from your blogs and emails as well -- and as I understand it's not bulletproof anyway and has been circumvented.

Then you go on saying that the existing options make perfect sense, but you still wouldn't mind having them changed -- while at the same time it sounds like you oppose changing the last component of the URL, which has no effect on user interface, learning curve, understandability of options, etc.

olegos, I'm not understanding you. If you want your photos completely private, why wouldn't you turn off all external links? When you set your galleries to allow external linking, you're making them available.

Also, as you allude, I said nothing about changing the existing options, rather changing the terminology.

[Baldy]

The main problem, as is clearly described in the blogs, is being able to access private photos by iterating URLs, and this has to be fixed.I feel this way too. I think the majority opinion is to leave the URLs simple, as they are today. But it would only take one person and an embarrassing photo to generate a very bad situation. In most cases, we try to please the majority but this looks like a case where we shouldn't go down that road.

I've also become jittery about the word private. There are many dictionary definitions, but this one resonates:

Not open or accessible to the general public: a private beach.

There are many ways your private URLs could become public without changing your settings. If you publish your private link in a dgrin post, for example, Google will index it and people will see your photos.

Unlisted is more like your phone, no? You can make sure you don't list it, but you know that if the number gets out people can call it. Isn't that clearer?

We're not ignoring what you're saying in this thread, we think it's great. My inclination from what I've read so far is to add the 6 characters to every URL to make them incredibly hard to guess but not make them insanely long like a GUID would do. And to refer to private photos/galleries as unlisted.

No decisions have been made so if we're being bone-headed, set us straight.

Thanks,
Baldy

[cmason]

"unlisted' maybe parochial...makes sense to us Americans, but chances are they call 'unlisted' phone numbers something else in other parts of the world.

just saying.....

[Baldy]

olegos, I'm not understanding you. If you want your photos completely private, why wouldn't you turn off all external links?We have kept the options of external linking and privacy separate by popular demand.

You may have a gallery you don't want people to discover on your SmugMug pages but you do want to post some of the photos in the gallery to a forum. There are many reasons why someone might want to do that. For example, some guy on my motorcycle forum came up with a great Photoshop of one of our most popular members. We didn't want him to know who dunnit, so we placed it in a private gallery with links turned on:

http://www.conary.org/bike/post/gdoggut.jpg

[hurricanesteve]

"unlisted' maybe parochial...makes sense to us Americans, but chances are they call 'unlisted' phone numbers something else in other parts of the world.

just saying.....

this echoes my comments also. The terms are arbitrary (but prone to misunderstanding regardless of which way you go, ie listed/unlisted is just as bad as public/private), it's the functionality of each setting that matters...which precise use-case descriptions would give.

You'd be better off just having LEVEL I, LEVEL II, LEVEL III, etc of privacy. Following interface design standards to meet 80% of your user-population's understanding with additional, advanced tools/settings for the power-users is where I would go based on my cursory understanding of Cooper-style analysis.

[olegos]

olegos, I'm not understanding you. If you want your photos completely private, why wouldn't you turn off all external links? When you set your galleries to allow external linking, you're making them available. I want to make them available only to those who I e-mail a direct link to, and nobody else (in practical terms).

Baldy, I think the source of the problem is that the image (and gallery) ID is numeric AND sequential. Leaving the URL the same length as now, but having the ID be a random sequence of upper and lowercase letters and numbers (maybe increase the length by two or three characters for future growth) would make the situation very much better than it is now, probably good enough, while not making the URLs much "worse" for those who care.

[mhilbush]

Baldy, I think the source of the problem is that the image (and gallery) ID is numeric AND sequential. Leaving the URL the same length as now, but having the ID be a random sequence of upper and lowercase letters and numbers (maybe increase the length by two or three characters for future growth) would make the situation very much better than it is now, probably good enough, while not making the URLs much "worse" for those who care. I would tend to agree with olegos. If you maintain the format of the URL, and replace the sequential numerics with randomized alphanumerics, I think you will retain the existing URL simplicity, while making it more difficult to mine images. Using alphanumerics in the identifiers will actually increase the available namespace for images, so you may not need to increase the length much, if at all. Having said that, it will still be possible for a determined individual to mine images. The degree to which this is possible may depend on the ability of SM to quickly "see" and respond to this type of activity.

Mark

[Baldy]

If you publish your private link in a dgrin post, for example, Google will index it and people will see your photos.I hate to disagree, Baldy, because I like your style but that statement isn't correct.

If you violate your privacy settings by placing a link to a gallery or image in a forum, we tell Google not to index it.

While Google behaves honorably when you tell them not to index something, your mileage may vary with evil spammer pedophiles.

[DavidTO]

My vote is to leave the URLs and behavior as is, and change the name of it to be more clear. What it should be called I am still undecided on.

[wellman]

My inclination from what I've read so far is to add the 6 characters to every URL to make them incredibly hard to guess but not make them insanely long like a GUID would do. And to refer to private photos/galleries as unlisted.

Sounds like a winner to me.

[darryl]

Just skimmed this thread. I tend to agree that it's more a nomenclature/language issue than anything. "Private" isn't exactly the right term. But "Obfuscated" or "Hard to find" doesn't have the right ring to it either.

I posted about this here (http://www.dgrin.com/showthread.php?t=82913), so in case you were wondering how this all started, and SmugMug's response here's the links:

http://blogoscoped.com/archive/2008-01-28-n59.html
http://blogs.smugmug.com/don/2008/01/28/your-private-photos-are-still-private/
http://blogs.smugmug.com/don/2008/01/28/first-two-security-winners/

As I commented on Don's last post, I really would love a little transparency into the "hacks" used to win the prize. Especially if the holes have now been fixed.

I've known about the CNAME redirect for awhile, but never really considered it a bug, since I actually am looking for a way to *find this information*.

Anyways, interesting stuff though. I'm bummed I missed my chance to make some money!

[olegos]

My vote is to leave the URLs and behavior as is, and change the name of it to be more clear. What it should be called I am still undecided on. You're right. Let's just change the option to say "Make photos available to anyone who decides to increment the number in a URL, and those you send a link to", so that it's clear what it's doing (the other choice being "Public"). And the problem's solved, right?

[olegos]

To those who think the current setup is fine and it's just a matter of terminology, consider this.

Say I see someone's public vacation photos. I suspect that there may be more photos from there, that the person is sharing with their familiy, but not the world. So I write a quick script to go over URLs with IDs in that vicinity, and can even automatically pre-filter the results based on say EXIF info. How likely do you think I'm to discover photos I'm not supposed to be seing?

I don't even need to search over the whole namespace, as Don's blog posts imply. If approximate time of the photos is known, the search space gets a lot smaller. Regardless of terminology, this is WRONG.

[DavidTO]

To those who think the current setup is fine and it's just a matter of terminology, consider this.

Say I see someone's public vacation photos. I suspect that there may be more photos from there, that the person is sharing with their familiy, but not the world. So I write a quick script to go over URLs with IDs in that vicinity, and can even automatically pre-filter the results based on say EXIF info. How likely do you think I'm to discover photos I'm not supposed to be seing?

I don't even need to search over the whole namespace, as Don's blog posts imply. If approximate time of the photos is known, the search space gets a lot smaller. Regardless of terminology, this is WRONG.


Yeah, well, I just don't agree. If you want your images locked down, throw a password on the gallery. I like the way it works. Simple and keeps the stuff hidden. I don't always need a full lockdown. :dunno

[jogle]

"unlisted' maybe parochial...makes sense to us Americans, but chances are they call 'unlisted' phone numbers something else in other parts of the world.

just saying.....

This is true. Unlisted phone numbers are called Restricted numbers here in New Zealand.

[devbobo]

This is true. Unlisted phone numbers are called Restricted numbers here in New Zealand.

it's commonly referred to as a "silent" number here in Australia, but I think that unlisted is going to get the message across.

[jogle]

it's commonly referred to as a "silent" number here in Australia, but I think that unlisted is going to get the message across.

True again, American tv is pervasive enough that I still knew exactly what Unlisted meant.

[DavidTO]

How about Shy?

:D

[I Simonius]

What if we were to add 6 characters--an underscore and 5 alpha-numeric characters to each URL? They would then end in something that looked like _hyqpb.jpg. That would mean up to 60,000,000 guesses per image.

This would apply to images going forward, public or private. For the 250,000,000 images on the site now, in order to give them a new URL, you'd have to move them to a new gallery. The downside is their new URLs would break any links to them right now that you have in forums or blogs.

Is this solution reasonable? If not, can you tell us why? Any other ideas?

Does this fit your definition of privacy? I have an email in my box from a customer who loves us but is shocked that we would think any image that can be seen by any other person could be considered private. In other words, when he marks a gallery as private, giving the URL to a friend would not enable them to get into the gallery. Anyone else feel that it should work that way?

Thanks for your feedback. We'd like to think this through and get it right but we don't want much time to pass either.

Thanks,
Baldy
1- First and foremost change 'Private' to 'Hidden' or 'unlisted' - that clears up all the confusion

next you can get on with increasing security at your leisure ( relatively speaking)

2- put a gotcha meassage somewhere proniment as whenever anyone goes to link URL in established gallery they might then forget and update for privacy - remind to do other way round ( I know I'd forget)

3- try the 5 alpha-numeric thingy on a test gallery for a while - it might go horribly wrong with unforseable things

4- you will have lots of users who move to new galleries and lots that don't - can this cause any problems?

5- oh nearly forgot - make it clear that if a gallery is REALLY to be 'private' then "here are the steps to follow", and make sure it is private i.e. make any changes necessary to give the requisit level of security to anything labbelled 'private' i.e. change current definition of private to mean 'pretty much totally secure short of giving it a secure server' ;-)

all I can think of right now

[olegos]

Yeah, well, I just don't agree. Don't agree that what I've described is possible and doable, or don't agree that it's a big deal and needs to get fixed?

If you want your images locked down, throw a password on the gallery. And don't forget to disable external links. By the way, being able to share galleries with my family by just sending them a link without a password, or requiring them to register for their own account, was one of the biggest reasons I went with Smugmug and not some of their competitors in the first place.

Simple and keeps the stuff hidden. It didn't [keep the stuff hidden] for Don. You're sure it will for you?

I don't always need a full lockdown. Neither do I, so? In fact, I almost never need it. Most of the time, what I want is a "medium lockdown" -- those who I invite should see my photos, the rest shouldn't.

[darryl]

Olegos wrote:
By the way, with this issue getting attention and many people trying it out for themselves, I believe one of my private galleries has been accessed: the stats show 1 access to medium size for every photo, with no accesses to thumbnails or any other sizes. I've changed all my private galleries to also hide owner (although there may still be identifying info in the photos themselves, or in the comments) for now, but I'm waiting for a real solution. I'm also very troubled by the reports that fully protected photos, in password protected galleries and no external links, can be accessed (the contest image). Looking forward to this issue getting fixed too, and explanation of the details afterwards.

and
To those who think the current setup is fine and it's just a matter of terminology, consider this.

Say I see someone's public vacation photos. I suspect that there may be more photos from there, that the person is sharing with their familiy, but not the world. So I write a quick script to go over URLs with IDs in that vicinity, and can even automatically pre-filter the results based on say EXIF info. How likely do you think I'm to discover photos I'm not supposed to be seing?

I don't even need to search over the whole namespace, as Don's blog posts imply. If approximate time of the photos is known, the search space gets a lot smaller. Regardless of terminology, this is WRONG.

Olegos: how would somebody crawling the photo space figure out the ID of your private gallery? I actually did some of this crawling (near Don's challenge), and couldn't figure out *how* the Blogosphere guys ferreted out the Gallery name and Owner.

Maybe they did it before Don plugged up the CNAME fix. If that's the case, then yeah, you might get lucky incrementing the gallery IDs of public galleries that were updated near the EXIF data of the photo. (On the other hand, I sometimes wait months to upload photos, so it's still kind of a crapshoot.)

Also, I never got to see the photo at all. Was external linking turned off? So a cut and paste would have worked. Interesting. So how was it fixed -- checking for a referrer from the specific SmugMug gallery page? But then won't that break people who browse behind certain firewalls, etc? Hrm...

[Baldy]

We're leaning towards adding the 5 alpha-numerics to each URL because it messes up the URLs as little as anything we can think of, but makes guessing hard. If we use both upper and lower case, each image has close to a billion possibilities to guess between.

Still, you're best off making the gallery private before adding pics or the URLs will be public, at least for awhile. In this scheme the URLs don't change as you switch from public to private.

Darryl, Don's been tweaking, yes. The last tweak went out mid-morning this a.m.

[jfriend]

We're leaning towards adding the 5 alpha-numerics to each URL because it messes up the URLs as little as anything we can think of, but makes guessing hard. If we use both upper and lower case, each image has close to a billion possibilities to guess between.

Still, you're best off making the gallery private before adding pics or the URLs will be public, at least for awhile. In this scheme the URLs don't change as you switch from public to private.

If you're trying to reduce guessability, have you thought about whether you need to make gallery numbers less guessable also? They look like they are also sequentially assigned upon creation and there are lots fewer of them than images (so a much smaller space to guess from) and each "private" one you find gives you access to a whole gallery of images, not just one image.

I just iterated through a few gallery numbers myself (manually in the browser bar, no script kiddy here) and it didn't take long until I found a private gallery. It was just some family photos, but it was marked as a private gallery. I myself don't use "private" galleries for security, but if you are trying to reduce the guessability of images, it seems you'll have to do so for gallery numbers too.

[Matthew Saville]

I think 5-digits of letters isn't bad, and would greatly increase privacy. It's like using a sharegroup.

Now, ironically, where can I find some reading on how to do a URL redirect, so that couples can simply type in "matthewsaville.com/so-and-so" and then get directed to their matthewsaville.smugmug.com/gallery/534534555_sdfggre address?

=Matt=

[Baldy]

If you're trying to reduce guessability, have you thought about whether you need to make gallery numbers less guessable also?Yeah, I should have mentioned that they're included too.

[jfriend]

I think 5-digits of letters isn't bad, and would greatly increase privacy. It's like using a sharegroup.

Now, ironically, where can I find some reading on how to do a URL redirect, so that couples can simply type in "matthewsaville.com/so-and-so" and then get directed to their matthewsaville.smugmug.com/gallery/534534555_sdfggre address?

=Matt=

That would be here (http://www.dgrin.com/showthread.php?t=20011) for a description of vanity URLs.
(http://www.dgrin.com/showthread.php?t=20011)

[scwalter]

We're leaning towards adding the 5 alpha-numerics to each URL because it messes up the URLs as little as anything we can think of, but makes guessing hard. If we use both upper and lower case, each image has close to a billion possibilities to guess between.

Still, you're best off making the gallery private before adding pics or the URLs will be public, at least for awhile. In this scheme the URLs don't change as you switch from public to private.

Darryl, Don's been tweaking, yes. The last tweak went out mid-morning this a.m.

If you are leaning that way, could you at least make it an optional gallery setting.

Or better yet, apply the extra code only to private galleries on the fly. That way, public galleries are as they are today. If I go change it to private, then you add the 5-digit codes. This also solves the problem of switching from public to private and having the old links work.

-Scott

[olegos]

... how to do a URL redirect, so that couples can simply type in "matthewsaville.com/so-and-so" and then get directed ... That would be here (http://www.dgrin.com/showthread.php?t=20011) for a description of vanity URLs.
(http://www.dgrin.com/showthread.php?t=20011) jfriend, you're talking about creating vanity URLs on SM, while Matt was asking about how to create redirects with his own domain. Matt, this is a question for the place that hosts your domain, but most likely they're using Apache (web server), so a search for "htaccess redirect" should get you lots of useful info. Or if your hosting provider gives you a control panel, look around in there, there may be a simple way to configure redirects that way.

[olegos]

We're leaning towards adding the 5 alpha-numerics to each URL because it messes up the URLs as little as anything we can think of, but makes guessing hard. If we use both upper and lower case, each image has close to a billion possibilities to guess between. Baldy, would it be possible to have the base number, before this extra part, be assigned randomly to the new galleries and images, instead of sequentially?

Darryl, in the scenario I described I'd be iterating over image URLs, not galleries.

[darryl]

jfriend, you're talking about creating vanity URLs on SM, while Matt was asking about how to create redirects with his own domain. Matt, this is a question for the place that hosts your domain, but most likely they're using Apache (web server), so a search for "htaccess redirect" should get you lots of useful info. Or if your hosting provider gives you a control panel, look around in there, there may be a simple way to configure redirects that way.

Matt: In a top-level .htaccess file, you'd put:

Redirect /so-and-so http://www.matthewsaville.smugmug.com/gallery/534534555_sdfggre


If your webhost doesn't give you access to .htaccess files, but does let you load PHP files, you could create the so-and-so directory and load this into an index.php file:


<?php
header( 'Location: http://www.matthewsaville.smugmug.com/gallery/534534555_sdfggre' ) ;
?>

[Allen]

So how would this effect all the embeded photos on the Smumug html type
pages using a link like this? A lot of these are pulled from private galleries.

<img src="/photos/xxxxxxxxxx-O.png" />

[jfriend]

So how would this effect all the embeded photos on the Smumug html type
pages using a link like this? A lot of these are pulled from private galleries.

<img src="/photos/xxxxxxxxxx-O.png" />

I think he said existing galleries would not be affected by the change, just new galleries. This is likely because there are zillions of links out there to photos already and they must preserve those.

[darryl]

Darryl, in the scenario I described I'd be iterating over image URLs, not galleries.

Olegos, you originally wrote:

Say I see someone's public vacation photos. I suspect that there may be more photos from there, that the person is sharing with their familiy, but not the world. So I write a quick script to go over URLs with IDs in that vicinity, and can even automatically pre-filter the results based on say EXIF info. How likely do you think I'm to discover photos I'm not supposed to be seing?


If you iterated through image URLs, as I have done in testing, you would actually be surprised how *few* photos end up clustered together. With 350,000 paying subscribers (per Don's confirmation on the sun.com video) spread around the globe, it's far more typical that you'll get an mix of all the photos that were being uploaded at the same time.

And again, since Don has fixed the CNAME problem, there's no way to figure out whose gallery a particular image belongs to, excepting cases where there's a Pro watermark or something.

[olegos]

If you iterated through image URLs, as I have done in testing, you would actually be surprised how *few* photos end up clustered together. With 350,000 paying subscribers (per Don's confirmation on the sun.com video) spread around the globe, it's far more typical that you'll get an mix of all the photos that were being uploaded at the same time. That's ok, I wouldn't be doing it manually. I'd have a script, downloading all the sequential images (going both up & down), then only keeping those that have the right info in EXIF -- and there is a lot there to go on (e.g. camera model, date, image number; trivial to filter automatically).

[asd]

I've been following this with great interest in the two blogs and now here. I'm glad to see that Smugmug's doing something about this. I've been with the service for a couple of years now and thought I pretty much understood the privacy/security options but never realized that this left things open to a script iterating through image or gallery IDs.

Anyway, I think that appending underscore and a handful of alphanumerics would work just fine. I'd also be OK with assigning random alphanumerics as image IDs to get even more compact (someone suggested this above). I think that 10 character alphanumerics give you about as much obscurity per image as the appended 5 alphanumerics do while providing a URL that's about 5 characters shorter. But I'll be happy with any approach that stops folks from iterating through.

I would very much like it if you also--eventually--added a tool for us to reset or import a gallery's image IDs into the new system rather than having to go setting up gallery copies.

I've been really impressed with the way Smugmug has handled this. I'm looking forward to hearing and seeing the final solution.

[mhilbush]

The bolt-on approach (embedding some alphanumerics into the existing gallery and image IDs) described above will certainly work. However, I've never been a big fan of this type of fix, as you will have to deal with the legacy of this approach in the future. It might not seem like much now, and maybe it won't be troublesome in the future, but you never know. That's why I suggested replacing the current sequential, numeric ID format with a randomized, alphanumeric format (I suppose you could call this the built-in approach). You also could embed a "check digit" into the naming scheme, which, while easily reverse-engineered, would add another degree of obscurity to the naming convention. Additionally, you can monitor and/or log URLs containing bad check digits, which gives your support/IDS folks something to look into.

Whichever way you go (bolt-on or built-in), I feel the change will be sufficient to reduce the ability to mine photos.

Mark

[Baldy]

Houston, we found the first problem. Firefox's ad blocker blocks any imaage with _ad in it no matter what follows.

[DavidTO]

How about instead of replacing this, just offer two levels: Simple Privacy and Advanced Privacy. I like it the way it is. :dunno

[wellman]

Houston, we found the first problem. Firefox's ad blocker blocks any imaage with _ad in it no matter what follows.
Out of curiosity, why the underscore? What's wrong with not having it? Is it that the first character of the appended string might be numeric?

[I Simonius]

How about instead of replacing this, just offer two levels: Simple Privacy and Advanced Privacy. I like it the way it is. :dunno

sounds good to me - does it really ned to be so complicated?
(but what do I know?):dunno

[Baldy]

True again, American tv is pervasive enough that I still knew exactly what Unlisted meant.We've kicked this around and tried to think of alternatives, like hidden or secret.

Unlisted seems to be the term everyone gets, even if they are international. They may not use the term in their countries, but they understand it when they hear it. The phone analogy resonates. It's also interesting to see how many people suggested this word in their blog posts around the net.

We'd present the choices as unlisted or public, not as unlisted or listed.

[I Simonius]

We've kicked this around and tried to think of alternatives, like hidden or secret.

Unlisted seems to be the term everyone gets, even if they are international. They may not use the term in their countries, but they understand it when they hear it. The phone analogy resonates. It's also interesting to see how many people suggested this word in their blog posts around the net.

We'd present the choices as unlisted or public, not as unlisted or listed.

A Sensible solution!

If you also go for a super secure option at a later date you could call it '"Secret' or 'Top Secret" or even 'Eintrit Verboten!" i.e. "NO ENTRY!" - :wink :D

[Baldy]

A Sensible solution!

If you also go for a super secure option at a later date you could call it '"Secret' or 'Top Secret" or even 'Eintrit Verboten!" i.e. "NO ENTRY!" - :wink :DHahaha, we were talking about that because we'd like to offer three radio buttons in certain circumstances. Secret played into Top Secret really well. But we decided they weren't clear enough.

[Baldy]

Or better yet, apply the extra code only to private galleries on the fly. That way, public galleries are as they are today. If I go change it to private, then you add the 5-digit codes. This also solves the problem of switching from public to private and having the old links work.

-ScottCan you explain what you mean by having the old links work? You mean you want them to break?

If I understand what you're proposing, this was our original scheme but we didn't feel we could allow the old links to break.

[brianb]

I pretty much second everything he said below. Personally I would rather have a GUID or GUID-looking ID (e.g. D3B5A-1CD8A) than the current number with characters appended (e.g. 2355236_a6n3c8), as I think the former looks cleaner (or at least use a hyphen instead of an underscore if you do append something). But in the end, either way would work. I also second the ability to convert images/galleries to the new URLs/IDs "in place" instead of having to move them to another gallery then back or something like that.

Thanks!
Brian

I've been following this with great interest in the two blogs and now here. I'm glad to see that Smugmug's doing something about this. I've been with the service for a couple of years now and thought I pretty much understood the privacy/security options but never realized that this left things open to a script iterating through image or gallery IDs.

Anyway, I think that appending underscore and a handful of alphanumerics would work just fine. I'd also be OK with assigning random alphanumerics as image IDs to get even more compact (someone suggested this above). I think that 10 character alphanumerics give you about as much obscurity per image as the appended 5 alphanumerics do while providing a URL that's about 5 characters shorter. But I'll be happy with any approach that stops folks from iterating through.

I would very much like it if you also--eventually--added a tool for us to reset or import a gallery's image IDs into the new system rather than having to go setting up gallery copies.

I've been really impressed with the way Smugmug has handled this. I'm looking forward to hearing and seeing the final solution.

[scwalter]

Can you explain what you mean by having the old links work? You mean you want them to break?

If I understand what you're proposing, this was our original scheme but we didn't feel we could allow the old links to break.

I am proposing that when a gallery changes from public to private, it gets the extra characters added. I really think the best option is to only have the extra characters for private galleries. I think having the old links break would be okay as long it can be user controlled, kinda how smugmungous was rolled out. New images uploaded into a private gallery automagically get the extra chars, and then have an option to regenerate the image numbers by rotating/cropping/whatever. This would allow people with private galleries containing all of their site/theme graphics to copy them to a new private gallery and fix up their CSS with the new images.

-Scott

[Baldy]

I am proposing that when a gallery changes from public to private, it gets the extra characters added. I really think the best option is to only have the extra characters for private galleries. I think having the old links break would be okay as long it can be user controlled, kinda how smugmungous was rolled out. New images uploaded into a private gallery automagically get the extra chars, and then have an option to regenerate the image numbers by rotating/cropping/whatever. This would allow people with private galleries containing all of their site/theme graphics to copy them to a new private gallery and fix up their CSS with the new images.

-ScottThis was our original plan but when we started painting scenarios of all the images embedded in blogs and forums that could later break, we thought the support burden/customer frustration would be too great.

It's reasonably common for someone to load images into a gallery, post them to forums, and then make them private later. They don't have a concept that doing it would make their links break.

As it is, we have a very tough time with the option to turn off external links.

I wish I had a better answer for you.

Thanks,
Baldy

[Baldy]

I pretty much second everything he said below. Personally I would rather have a GUID or GUID-looking ID (e.g. D3B5A-1CD8A) than the current number with characters appended (e.g. 2355236_a6n3c8), as I think the former looks cleaner (or at least use a hyphen instead of an underscore if you do append something). But in the end, either way would work. I also second the ability to convert images/galleries to the new URLs/IDs "in place" instead of having to move them to another gallery then back or something like that.

Thanks!
BrianWe hashed this out at great length tonight as a result of your post. I went in feeling like a hyphen would be better than an underscore because underscores in links look like spaces.

But there are some issues. One is we have legacy URLs with -small and -large in them, which is also theoretically possible to generate with our keys. We'd have to jump through some hoops to get around this. But the bigger issue is our customers are constantly fetching album ID and image ID to use in various customization and slide show functions, not to mention purchasers of photos. They can read image and album IDs so much easier than GUIDs.

[asd]

One is we have legacy URLs with -small and -large in them, which is also theoretically possible to generate with our keys. We'd have to jump through some hoops to get around this.

Won't you have to do this for any scheme that involves random use of letters? I'm sure you'll need a filter so that one of George Carlin's 7 dirty words doesn't show up in an ID. If you can do that, you can add "small" and "large" to the list.

But the bigger issue is our customers are constantly fetching album ID and image ID to use in various customization and slide show functions, not to mention purchasers of photos. They can read image and album IDs so much easier than GUIDs.

If you're worried about readability, try breaking things up with a hyphen or two. Consider the following ID schemes:

280238554-M (today's ID)
280238554-M_D7xnO (Chris's proposal--today's ID plus a new key on the end)
D7xnO41juT-M (10 digit alphanumeric)
D7xnO-41juT-M (an extra hyphen..)
D7x-nO4-1juT-M (another extra hyphen..)

Both the appended key approach and the full alphanumeric approach will result in kinda-harder-to-write IDs, so I think folks will have to copy/paste more regardless. I'm personally not worried about site customization getting more difficult since I copy/paste IDs where I need them. But I don't heavily customize.

If you want to get fancy in the full-alphanumeric scheme, you'd store a non-hyphenated ID, display (and link) IDs hyphenated however you like, and strip hyphens from requests, so you can safely (links won't break) switch hyphenation schemes if you find that people really prefer one way of splitting over another. This starts to look like Google's dot scheme in Gmail (http://mail.google.com/support/bin/answer.py?answer=8158), where you can put dots wherever you want in your gmail address. And you're already parsing out the -M, -L, -600x480, etc, so you'd just need to expand that processing. OK, I'll stop the geek-out now.

[I Simonius]

Hahaha, we were talking about that because we'd like to offer three radio buttons in certain circumstances.

make em bigger! --oh that's not what you meant...:rolleyes

Well there's a convention that's already established that people would understand the https - "SECURE" - notion. Perhaps?

[I Simonius]

As it is, we have a very tough time with the option to turn off external links.



Can you explaina little why that is, for non techies like moi?

[I Simonius]

We hashed this out at great length tonight as a result of your post. I went in feeling like a hyphen would be better than an underscore because underscores in links look like spaces.

But there are some issues. One is we have legacy URLs with -small and -large in them, which is also theoretically possible to generate with our keys. We'd have to jump through some hoops to get around this. But the bigger issue is our customers are constantly fetching album ID and image ID to use in various customization and slide show functions, not to mention purchasers of photos. They can read image and album IDs so much easier than GUIDs.

It still sounds complicated to me, if I have undestood the problem correctly

Is the problem that people can guess the URLs? If so then surely it's much easier to have users themselves allocate a level of security to images they want protected rather than trying to make all images impossible to guess?

It seesm to me like you're taking ona burden that could just as easily be born by the users, with no penalty, provided they were given the tools (i.e. a new button)

[claudermilk]

I guess I'm not watching the same blogs as everyone else here, missed this whole issue.

After reading the 7 pages of debate, I'll weigh in with my 0.02. I like the concept that SM is moving forward with.

I also like the suggestions that this be applied when the gallery is set to private; to counter any ignorant customer issues (not an insult, just a state of being), have some kind of warning regarding the broken links issues display before this is done. That way people cannot claim ignorance--they were explicitly told they would be breaking existing links & it's up to the gallery owner to deal with it. That seems likea reasonable compromise to me.

As long as the URLs are already, I personally don't care if it's 5 or 6 characters appended, or if it's switched to a proper GUID format. I personally prefer to make the proper change and deal with the pain all at once when faced with this kind of update situation.

[jfriend]

On the terminology and security front, here are some previous dgrin threads on the topic that it may be worth reviewing:

When private isn't really private - April 2007 (http://www.dgrin.com/showthread.php?p=523396&highlight=unlisted+private#post523396)
Private vs. unlisted - Oct 2006 (http://www.dgrin.com/showthread.php?t=44384&highlight=unlisted+private)
People confused about private galleries - Sept 2006 (http://www.dgrin.com/showthread.php?t=43799&highlight=unlisted+private)
Guessable gallery numbers - Sept 2006 (http://www.dgrin.com/showthread.php?t=43651&highlight=unlisted+private)
Passworded images not requiring a password - May 2006 (http://www.dgrin.com/showthread.php?t=33818&highlight=unlisted+private)
Suggestion for "unlisted" galleries - March 2006 (http://www.dgrin.com/showthread.php?t=30938&highlight=unlisted+private)
In the past, I've been in favor of the term "unlisted" instead of "private". I'm not arguing that someone can't think of a better term, but it seems to avoid any implied (but not delivered security). The terms that I could think of are: "Unlisted", "Not shown on homepage", "Unlinked", "Unpublicized", "Segregated", "Solo", "Unattached".

[Nimai]

If you want to get fancy in the full-alphanumeric scheme, you'd store a non-hyphenated ID, display (and link) IDs hyphenated however you like, and strip hyphens from requests, so you can safely (links won't break) switch hyphenation schemes if you find that people really prefer one way of splitting over another. This starts to look like Google's dot scheme in Gmail (http://mail.google.com/support/bin/answer.py?answer=8158), where you can put dots wherever you want in your gmail address. And you're already parsing out the -M, -L, -600x480, etc, so you'd just need to expand that processing. OK, I'll stop the geek-out now. :thumb Geek is good.
This lets the ID be the shortest string of alpha-numeric characters, and can be as readable as one likes, using hyphens.
(I wonder if SmugMug's databases are using an INT for all these IDs currently... changing would be one heckuva migration!)

[Baldy]

changing would be one heckuva migration!*cough* :whew

Thanks for all the feedback. We read every post and debated many of them internally.

The status is we pretty much worked out a scheme last week that seemed to minimize unfriendliness as much as possible and we've spent a lot of time testing it on our test servers. Public and unlisted are the terms we're going to use.

We went with a key scheme instead of full GUIDs for simplicity.

We didn't push the big red button and go live at the end of last week in part because we wanted some review from security specialists. As it turns out, Don went to O'Reilly's foo camp last weekend and the talk there was all about (a) Microsoft's offer for Yahoo, and (b) SmugMug's privacy dilemma. Most people at foo felt the biggest problem was mismatched expectations and the ambiguity of the word privacy. No one was in favor of full GUIDs. Most felt the scheme we're trying to implement makes URLs pretty hard to guess but we should avoid claims about more than that.

There will be some variances from specifics of what you've suggested here, usually for scalability reasons. Sometimes it was that we didn't want the complexity of yet another thing to explain, or another gallery privacy option (medium privacy like it is now versus more advance privacy, for example).

The hard thing is a very large majority of our customers are opposed to this change. But in this case we feel the minority, the people who make the case for making URLs less guessable, have a strong point that we have to respond to. And inserting another privacy option between the existing one and passworded galleries adds more complexity to it all than just making URLs with 6 to 12 more digits for everyone.

The toughest thing is we're going to grandfather all images and galleries prior to this change so that the links to forums and blogs from private galleries don't break. If you move those images into other grandfathered galleries, they will still work. If you move them to new galleries, they break. Ouch. :cry That's nasty.

[asd]

*cough* :whew

Thanks for all the feedback. We read every post and debated many of them internally.

The status is we pretty much worked out a scheme last week that seemed to minimize unfriendliness as much as possible and we've spent a lot of time testing it on our test servers. Public and unlisted are the terms we're going to use.

We went with a key scheme instead of full GUIDs for simplicity.

We didn't push the big red button and go live at the end of last week in part because we wanted some review from security specialists. As it turns out, Don went to O'Reilly's foo camp last weekend and the talk there was all about (a) Microsoft's offer for Yahoo, and (b) SmugMug's privacy dilemma. Most people at foo felt the biggest problem was mismatched expectations and the ambiguity of the word privacy. No one was in favor of full GUIDs. Most felt the scheme we're trying to implement makes URLs pretty hard to guess but we should avoid claims about more than that.

There will be some variances from specifics of what you've suggested here, usually for scalability reasons. Sometimes it was that we didn't want the complexity of yet another thing to explain, or another gallery privacy option (medium privacy like it is now versus more advance privacy, for example).

The hard thing is a very large majority of our customers are opposed to this change. But in this case we feel the minority, the people who make the case for making URLs less guessable, have a strong point that we have to respond to. And inserting another privacy option between the existing one and passworded galleries adds more complexity to it all than just making URLs with 6 to 12 more digits for everyone.

The toughest thing is we're going to grandfather all images and galleries prior to this change so that the links to forums and blogs from private galleries don't break. If you move those images into other grandfathered galleries, they will still work. If you move them to new galleries, they break. Ouch. :cry That's nasty.

:thumb

It sounds like you've found a good compromise between increasing privacy without making the system too much harder for everyone. Kudos to Smugmug for the fast action on this and for keeping us updated!

[I Simonius]

If you move those images into other grandfathered galleries, they will still work. If you move them to new galleries, they break. Ouch. :cry That's nasty.

not ure what this means but hope it doesnt mean we can accidentally ( and therefore easily) move things into the wrong sort of gallery?

[Andy]

not ure what this means but hope it doesnt mean we can accidentally ( and therefore easily) move things into the wrong sort of gallery?
Accidentally? No, you'd know what you're doing. You must use the "Move Photos" tool to move stuff.

If you move an image to a NEW gallery, it'll have the new urls with keys. If any of those images were previously linked in a forum or blog, the url there would be busted on said forum or blog, until you edited that post with the new url.

If you don't move a photo, nothing would break.

[I Simonius]

Accidentally? No, you'd know what you're doing. You must use the "Move Photos" tool to move stuff.

If you move an image to a NEW gallery, it'll have the new urls with keys. If any of those images were previously linked in a forum or blog, the url there would be busted on said forum or blog, until you edited that post with the new url.

If you don't move a photo, nothing would break.

No I didn't mean 'accidentally' as in 'whops I tripped over my shoelace' I meant as in 'oops I forgot to lock the door''

i.e. Obviously 'move photos' requires a conscious move , but to find that moving photos killed links without realising it would be a problem: so; as long as I clearly understand that moving a previously linked image to a NEW gallery will kill its links, then I can take the appropriate action.


The danger comes in either forgetting , or .. er forgetting.

[Andy]

The danger comes in either forgetting , or .. er forgetting.
:lol3

'tis true - and we're constantly worrying about adding complexity to things :cry

[DJ-S1]

...- I'm very confident you folks will figure out the best solution for all concerned. :thumbMan, I love being proven right. Now where's that "patting myself on the back" smilie? :D

Sounds like a well-reasoned solution to me, good job guys! :clap

[george-1]

*cough* :whew

Thanks for all the feedback. We read every post and debated many of them internally.


That's the thing I like best about Smugmug, y'all listen to your clients.


The toughest thing is we're going to grandfather all images and galleries prior to this change so that the links to forums and blogs from private galleries don't break. If you move those images into other grandfathered galleries, they will still work. If you move them to new galleries, they break. Ouch. :cry That's nasty.


I really don't understand what all the uproar was about, I learned a long time ago that there is no privacy on the internet. I just want to put my photos up on a page that others can come look at, and link my photos for use in forum posts and such.

Smugmug is a photo sharing site, not a photo hiding site.

I trust Smugmug to do what's best.

Thanks

[olegos]

The hard thing is a very large majority of our customers are opposed to this change. But in this case we feel the minority, the people who make the case for making URLs less guessable, have a strong point that we have to respond to. I think you just need to realize that the majority of your customers are photographers, not security-conscious computer professionals. This will make going against the majority in issues like this one easier :wink

[jfriend]

I really don't understand what all the uproar was about, I learned a long time ago that there is no privacy on the internet. I just want to put my photos up on a page that others can come look at, and link my photos for use in forum posts and such.

Smugmug is a photo sharing site, not a photo hiding site.

You hit the nail on the head with this statement. Security works for a user when it delivers what that user is expecting it to do. It's as much about matching the user's perception as anything else. It works for you because it was delivering exactly what you expected of it (same for me by the way).

Unfortunately, because all users don't have the same understanding that you and I do and because some of the communication of what to expect from it was open to interpretation, many users had a different perception of what it was supposed to do. When it didn't deliver what they expected (even if their expectation was wrong), they felt like Smugmug security had failed.

Smugmug is taking steps to both change the description of what it does (to set a less ambiguous perception for what it should do) and to beef-up what security it actually delivers. The idea is to make sure that what it delivers always matches or exceeds what people think it's supposed to be delivering.

[olegos]

That's the thing I like best about Smugmug, y'all listen to your clients. I hate to rain on your parade, but I don't see much reason for kudos here. Apparently this issue has been brought to their attention several times before, such as here (http://www.dgrin.com/showthread.php?t=43651)more than a year ago, and they did nothing until external bloggers took them to task. Even now, their first instinct was to try to just talk it away.

I wish they implemented some of the simple things that keep getting asked for for years in the Feature Requests thread. My own top ones are virtual galleries and ftp uploads, and if not virtual galleries, then at least asking for a destination gallery when making a "2nd copy". Take this last one for example. It's a very easy and straight-forward change, I've seen it requested several times in addition to requesting it myself, and yet it's not there and I can't tell you how many hours it's wasted me: I go through a gallery, "Make 2nd copy" for each photo I want (very slow most of the time), go to Move Photos, manually pick duplicates from all the photos, and move them to the destination gallery. Then usually I need to navigate back to the source gallery and repeat the process. In addition to being slow, this process also breaks statistics (since I can't figure out how to pick the new copies and not the original ones), makes visitors see duplicates in the original gallery, and may even accidentally take a visitor to the new gallery (especially unfortunate if you happen to be copying photos from a public gallery to a private -- oops, unlisted one). I don't understand why company that prides itself on listening to customers ignores such simple requests, which also by the way would save its own resources (e.g. many people instead of going through what I've described would just re-upload, wasting bandwidth; and virtual galleries would save tons of storage space).

Sorry for venting here...

[olegos]

You hit the nail on the head with this statement. Security works for a user when it delivers what that user is expecting it to do. If a bank makes it clear that it can be hacked, would it be a good bank? Would you keep your money there?

[jfriend]

If a bank makes it clear that it can be hacked, would it be a good bank? Would you keep your money there?

When expectations are clear, customers are able to choose a service that meets their needs. In your bank example, people wouldn't choose that bank and the bank would either have to fix their issues or go out of business due to a lack of customers. But customers who did choose the bank would really have no reason to complain. The bank must have been offering something compelling (perhaps a high interest rate in exchange for more risk) so if the customers accept that risk with a proper expectation, then they really shouldn't have a reason to complain. Look at junk bonds. High rate of return, high risk. As long you people who buy them know what they're getting (perception matches reality), there's nothing wrong with that as a product offering and some people go for that tradeoff.

In my opinion, this particular privacy issue at Smugmug is more about mismatched expectations than anything else. The feature exactly as it exists today is a useful feature for customers who want a gallery that isn't listed on their home page. That's not really a security feature at all, it's a presentation feature that allows you to have galleries that don't show on your home page. Where things started to go wrong was when Smugmug labelled them as "private" and set an expectation that they really were private when, indeed, they didn't meet many people's expectations of what "private" should entail.

Of course, now that it's been this way for years, there are lots of customers who already have an expectation of some real privacy so Smumug now has to make changes to deliver more of that.

[Baldy]

Man, I love being proven right. Now where's that "patting myself on the back" smilie? :D

Sounds like a well-reasoned solution to me, good job guys! :clapThanks for the kind words! I'm holding my breath, however, because this is the opposite of most releases. Usually, you please the majority and disappoint a small number. This release is looking like the reverse, but hopefully we'll have added a layer of cumbersomeness that's small enough that it won't be too big an issue.

[wellman]

If a bank makes it clear that it can be hacked, would it be a good bank? Would you keep your money there?

No, but I don't share my money like I share my photos. :D (Sorry; couldn't resist...)

[jenweavernj]

When I tried to use one of the "new" type of links today in my blog through blogspot with google it told me that the URL was INVALID.

I tried and tried again but the new smugmug link would not work in the feature where you add a photo to the side of your blog using their "add photo" feature.

I'm not sure what it doesn't like about the new links but it never had a problem with the old smugmug links.

Any thoughts on this? Should I post this elsewhere?

[jenweavernj]

When I tried to use one of the "new" type of links today in my blog through blogspot with google it told me that the URL was INVALID.

I tried and tried again but the new smugmug link would not work in the feature where you add a photo to the side of your blog using their "add photo" feature.

I'm not sure what it doesn't like about the new links but it never had a problem with the old smugmug links.

Any thoughts on this? Should I post this elsewhere?

Same thing is happening with the DGRIN Forum. I wanted to change my Avatar so I used the URL feature rather than uploading from my own PC.

I went to "Share" and copied the link I wanted and pasted in into the field and got INVALIS URL.

Is this being looked into? Seems the links are not usable in situations like this.

[jfriend]

Same thing is happening with the DGRIN Forum. I wanted to change my Avatar so I used the URL feature rather than uploading from my own PC.

I went to "Share" and copied the link I wanted and pasted in into the field and got INVALIS URL.

Is this being looked into? Seems the links are not usable in situations like this.

Can you paste the link here so we can look at what you have because there's nothing invalid about them?

One possibility is that you're trying to use a gallery link where an image link (should end in .jpg) is what you need. Here's a link taken directly from the Share screen in one of your galleries:
http://www.jenweaverphotography.com/photos/245515131_uZQgs-M.jpg

Working fine here if you get the right link.

[Andy]

Same thing is happening with the DGRIN Forum. I wanted to change my Avatar so I used the URL feature rather than uploading from my own PC.

I went to "Share" and copied the link I wanted and pasted in into the field and got INVALIS URL.

Is this being looked into? Seems the links are not usable in situations like this.

If it works, linking an avatar for Dgrin (might be a forum bug, I'm not entirely sure...), you'd need to use a link like this:


http://www.moonriverphotography.com/photos/158548292_Nt9Fk-80x80.jpg


http://www.moonriverphotography.com/photos/158548292_Nt9Fk-80x80.jpg


EDIT: Linking of the avatar doesn't work (vbulletin / Dgrin issue). Upload it, that's fine. Has to be 80x80 or smaller, and 18kb or smaller.

[DavidTO]

I've got a question about the new keys.

I uploaded some new images today into an old, grandfathered gallery, and wanted to embed in a post. What I used to do was just copy the image number from the end of the URL, and then put it in the surrounding code, with the IMG tags, and the rest of the URL.

This time when I grabbed the image number, the images didn't link properly. I figured that the image number alone (without the key) would be good in a grandfathered gallery, but I guess not. I ended up going into the sharing window and grabbing the URL that way. It turned out the images did have keys on them.

I don't much care one way or the other about the keys, but I want to understand when and why they show up. Why weren't they showing up when I was viewing them in smugmug view in the gallery? What am I missing?

Here's a link to one of the images: http://davidrosenthal.smugmug.com/gallery/113654_pPm2c#252896954

This gallery is set to private, but it's an old gallery, created before the changes.

I think I'm just being stupid. That's the most likely explanation. :dunno

[jenweavernj]

If it works, linking an avatar for Dgrin (might be a forum bug, I'm not entirely sure...), you'd need to use a link like this:


http://www.moonriverphotography.com/photos/158548292_Nt9Fk-80x80.jpg


http://www.moonriverphotography.com/photos/158548292_Nt9Fk-80x80.jpg


EDIT: Linking of the avatar doesn't work (vbulletin / Dgrin issue). Upload it, that's fine. Has to be 80x80 or smaller, and 18kb or smaller.

I was using the .jpg URL link from the share feature... I'm totally fine with linking them in forums...that works perfectly...

I just wanted to let everyone know that it wasn't working for linking the URL for an avatar. I used the browse feature and uploaded it off the PC as Andy mentioned...

It seems it's not just a DGRIN issue since I can't use one of the direct links to add pics to the right side of my blogspot.com page either...I had to save them to the PC and then browse for them and load them that way.

Just wanted to put it out there because we may come accross this more when sites let you use a URL to load your photos. (I prefer using the URL because the share feature off our sites is sooo easy.)

[Andy]

I was using the .jpg URL link from the share feature... I'm totally fine with linking them in forums...that works perfectly...

I just wanted to let everyone know that it wasn't working for linking the URL for an avatar. I used the browse feature and uploaded it off the PC as Andy mentioned...

It seems it's not just a DGRIN issue since I can't use one of the direct links to add pics to the right side of my blogspot.com page either...I had to save them to the PC and then browse for them and load them that way.

Just wanted to put it out there because we may come accross this more when sites let you use a URL to load your photos. (I prefer using the URL because the share feature off our sites is sooo easy.)
Jen, the links are working perfectly in blogs, forums, anywhere really (except for Dgrin avatar).

Please list exact step by step what you are doing, including gallery links and the url link you are trying to embed. We can help you :thumb

[Andy]

I've got a question about the new keys.

I uploaded some new images today into an old, grandfathered gallery, and wanted to embed in a post. What I used to do was just copy the image number from the end of the URL, and then put it in the surrounding code, with the IMG tags, and the rest of the URL.

This time when I grabbed the image number, the images didn't link properly. I figured that the image number alone (without the key) would be good in a grandfathered gallery, but I guess not. I ended up going into the sharing window and grabbing the URL that way. It turned out the images did have keys on them.

I don't much care one way or the other about the keys, but I want to understand when and why they show up. Why weren't they showing up when I was viewing them in smugmug view in the gallery? What am I missing?

Here's a link to one of the images: http://davidrosenthal.smugmug.com/gallery/113654_pPm2c#252896954

This gallery is set to private, but it's an old gallery, created before the changes.

I think I'm just being stupid. That's the most likely explanation. :dunno
New image, post-Keys release, needs a key, even in the grandfathered gallery.

SO you'll need XXXXXXXX_KEY like this:

http://www.smugmug.com/photos/158548292_Nt9Fk-L.jpg

[com3]

i kinda liked it the way it was before... now the URL's are all long and look kinda tacky...

personally, i think it'd be great if the url's were coreespondant to the gallry names...

i.e., http://seppes.com/Motorcycles points to my motorcycles category... but what about http://seppes.com/Motorcycles/AFM pointing to my AFM galleries within the motorcycles category.

that'd be the hawtness.

[DavidTO]

New image, post-Keys release, needs a key, even in the grandfathered gallery.

SO you'll need XXXXXXXX_KEY like this:

http://www.smugmug.com/photos/158548292_Nt9Fk-L.jpg


But why doesn't this show in the URL? I'd like to have the ease of copying from the URL like before. Is there some other way I should access the image to get that key in the URL?

[jenweavernj]

Jen, the links are working perfectly in blogs, forums, anywhere really (except for Dgrin avatar).

Please list exact step by step what you are doing, including gallery links and the url link you are trying to embed. We can help you :thumb


I'm sorry, you must think I'm just a dummy...I guess I'm not explaining it correctly...


*with blogspot.com
*you go to customize - (to customize the side of your page)
you add a page element
*I chose the "picture" option - this adds pics down the side of your blog
*I use a URL for the photo...for example sake here is a URL I tested: http://jenweaverphotography.smugmug.com/photos/253080601_ujLNd-S.jpg

*I paste it in and I get:

22795

It always worked before and now it doesn't....kinda bummed because it's sooo much easier this way.


The links work in the actual blog posts that I write.
The links work in the forums I belong to.

Just not in "upload using a link" area of blogspot.com and Dgrin. Now these are the only 2 places I have tested....maybe others will have the same issue and report more instances.

[jfriend]

But why doesn't this show in the URL? I'd like to have the ease of copying from the URL like before. Is there some other way I should access the image to get that key in the URL?

Can you right click on the image and grab the whole image URL directly from that. It will have everything already in the URL (image ID and key). That's what I do.

[DavidTO]

Can you right click on the image and grab the whole image URL directly from that. It will have everything already in the URL (image ID and key). That's what I do.


Yeah, I could. But sometimes right click is disabled. I'm just so used to making my own URL from the photo number in the location bar up top, and I'm just surprised that the key isn't a part of it. I'm trying to figure out why that is, I'm probably just looking in the wrong place

[jerryr]

Hi the question I have is what is the variable for the key.
That is, if I want to add to my javascript:

urlToImage = webServer + "/photos/" + ImageID + "-L.jpg";

What is the Key variable ? I tried ImageKey and ImageKEY and no luck...

Thanks - jerryr

[Andy]

But why doesn't this show in the URL? I'd like to have the ease of copying from the URL like before. Is there some other way I should access the image to get that key in the URL?
You can put it in lightbox, or use the share button:
http://img.skitch.com/20080211-j7ber7h6eceyn3ggpe99ky2edt.jpg

[Andy]

I'm sorry, you must think I'm just a dummy...I guess I'm not explaining it correctly...


*with blogspot.com
*you go to customize - (to customize the side of your page)
you add a page element
*I chose the "picture" option - this adds pics down the side of your blog
*I use a URL for the photo...for example sake here is a URL I tested: http://jenweaverphotography.smugmug.com/photos/253080601_ujLNd-S.jpg

*I paste it in and I get:

22795

It always worked before and now it doesn't....kinda bummed because it's sooo much easier this way.


The links work in the actual blog posts that I write.
The links work in the forums I belong to.

Just not in "upload using a link" area of blogspot.com and Dgrin. Now these are the only 2 places I have tested....maybe others will have the same issue and report more instances.
Seems like blogger's form doesn't like the url for some reason - I can't say why, it's a valid url for sure - you've done it right.

[DrDavid]

I was wondering.... For a public gallery, where privacy doesn't ever matter.. Is the KEY still required to view the gallery?

For example, I make a new gallery with albumid=1234567 and the key is 12345.. If I link to the public gallery without the key, will it still work? or will it fail? Perhaps public galleries should work with or without the key, and if a gallery is MADE unlisted, the key should then be set/re-generated?

David

[Andy]

I was wondering.... For a public gallery, where privacy doesn't ever matter.. Is the KEY still required to view the gallery?

For example, I make a new gallery with albumid=1234567 and the key is 12345.. If I link to the public gallery without the key, will it still work? or will it fail? Perhaps public galleries should work with or without the key, and if a gallery is MADE unlisted, the key should then be set/re-generated?

DavidNew gallery, will need the gallery# and key. Use the link that we give you in the share page.

:thumb

[DrDavid]

Hi the question I have is what is the variable for the key.
That is, if I want to add to my javascript:

urlToImage = webServer + "/photos/" + ImageID + "-L.jpg";

What is the Key variable ? I tried ImageKey and ImageKEY and no luck...

Thanks - jerryr
I use this:

urlToImage = webServer + "/gallery/" + AlbumID + "_" + photoInfo[ImageID]['AlbumKey'] + "/1/" + ImageID + "/Large";

That creates a link to the single image page of what they ordered... I found it was more useful.... But, I think to get the Imagekey it's:


photoInfo[ImageID]['ImageKey']

[DrDavid]

New gallery, will need the gallery# and key. Use the link that we give you in the share page.

:thumb
That's a bit of a bummer.. I occassionally gave out URL's with the album ID written in (only 6/7 digits, so, no big deal).. Guess I'll be making lots of custom vanity URL's now. Not a big deal luckily. But, I'd still vote for PUBLIC galleries to not require a key--just make it optional.

David

[bwg]

I use this:

urlToImage = webServer + "/gallery/" + AlbumID + "_" + photoInfo[ImageID]['AlbumKey'] + "/1/" + ImageID + "/Large";

That creates a link to the single image page of what they ordered... I found it was more useful.... But, I think to get the Imagekey it's:


photoInfo[ImageID]['ImageKey']


That won't always be the case. For smugmug style, it will be there, but for other styles, use ImageKey.

Our javascript is a bit inconsistent at the moment, we're working on cleaning it up.

[DrDavid]

That won't always be the case. For smugmug style, it will be there, but for other styles, use ImageKey.

Our javascript is a bit inconsistent at the moment, we're working on cleaning it up.
I thought I saw Jerryr say that he tried to use ImageKey and it didn't work? Also, how about AlbumKey? Is there a better/consistent variable I can use? I'm using photoInfo[ImageID]['AlbumKey'] for that.... and photoInfo[ImageID]['ImageKey'] for the imagekey's.. You're saying that I should use only:

ImageKey

and

AlbumKey <-- I'm guessing here

??

David

[DrDavid]

That won't always be the case. For smugmug style, it will be there, but for other styles, use ImageKey.

Our javascript is a bit inconsistent at the moment, we're working on cleaning it up.
There is a bug in ImageKey... When I use image key, it only uses the imagekey of the FIRST image. AlbumKey works fine, but, ImageKey as a dynamic field to use in a script is not working.

photoInfo[ImageID]['ImageKey'] returns the correct key... ImageKey does not.

David

[bwg]

There is a bug in ImageKey... When I use image key, it only uses the imagekey of the FIRST image. AlbumKey works fine, but, ImageKey as a dynamic field to use in a script is not working.

photoInfo[ImageID]['ImageKey'] returns the correct key... ImageKey does not.

David


sorry, I must not have been clear. Use photoInfo[ImageID]['ImageKey'] for smugmug style, but ImageKey/AlbumKey for all other style.

[jerryr]

Ok - here is my test:
(Sorry no luck on the ImageKey; style = Traditional)


This gallery was created Sunday:
http://www.jrphotosandwebdesign.com/gallery/4311576_pq8kM/1/219253544_ZjyiW/Medium

This gallery was created back in the Fall:
http://www.jrphotosandwebdesign.com/gallery/3789668_MKjGR/1/218578211_NmZFD/Medium

Again, any help on obtaining the imageKey using the traditional or allthumbs style is greatly appreciated...


Here is my footer code:

<div id="testfooter1" align="center">
******** type="text/javascript">
document.write("The AlbumID and AlbumKey for the image is: ");
document.write(AlbumID + "_" + AlbumKey);

</********
</div>

<div id="testfooter2" align="center">
******** type="text/javascript">
document.write("The ImageID and ImageKey for the image is: ");
document.write(ImageID + "_" + ImageKey);

</********
</div>

[bwg]

Ok - here is my test:
(Sorry no luck on the ImageKey; style = Traditional)


This gallery was created Sunday:
http://www.jrphotosandwebdesign.com/gallery/4311576_pq8kM/1/219253544_ZjyiW/Medium

This gallery was created back in the Fall:
http://www.jrphotosandwebdesign.com/gallery/3789668_MKjGR/1/218578211_NmZFD/Medium

Again, any help on obtaining the imageKey using the traditional or allthumbs style is greatly appreciated...

Ah, thats not Traditional, thats SingleImage...but yeah my fault for not seeing what you were talking about.

ImageKey is indeed missing on that page. I'll make sure to add it for my next round of updates.

Sorry about that.

[jerryr]

Hi - Thanks a big :clap since I thought I was going crazy
Ok - need this asap (I am sure several others need it as well)

Thank you thank you :) jerryr

[GerryDavid]

Is it me, or does the 5 letteres keep changing in the link? Ive tried to link an image a few times now, and each time I go to get the url, the 5 letters at the end between the _ and the - keep changing. And then after a little while, the new link doesnt work anymore.

Is there an easy way to fix this? I miss the old way, I had no problems with it.

[Andy]

Is it me, or does the 5 letteres keep changing in the link? Ive tried to link an image a few times now, and each time I go to get the url, the 5 letters at the end between the _ and the - keep changing. And then after a little while, the new link doesnt work anymore.

Is there an easy way to fix this? I miss the old way, I had no problems with it.
Hi Gerry, they don't change. Try the share photos button, the links are easy to grab there...

help: http://www.smugmug.com/help/picture-sharing

[claudermilk]

Hey guys, just noticed the changes while working in a gallery last night. saw the "unlisted" flag on the galleries & checked the URLs, sure enough there was the security code. I'm happy to see the change & at least on the relatively simple linking I'm doing on my site it's all working fine.

I may just move & rebuild some of my private/unlisted galleries to ensure the new code is required even on older images.

[jerryr]

Ah, thats not Traditional, thats SingleImage...but yeah my fault for not seeing what you were talking about.

ImageKey is indeed missing on that page. I'll make sure to add it for my next round of updates.

Sorry about that.


thanks again for looking into this.
As a temporary fix, I am using the window.location function

- jerryr

[Markjay]

RE: turning off external links Baldy......

this problem presents itself in the Smugsearch. If you type in a search term, the results sometimes show image placeholders with NO image shown.
I'm guessing that is a result of someone turning off external links or, having removed the photo since it's upload?

BTW: this is a great discusssion and, I'm grateful to Smugmug for going out of their way to make our galleries feel as secure as they can be, while strking a balance against all the external linked images "out there".

Markjay

This was our original plan but when we started painting scenarios of all the images embedded in blogs and forums that could later break, we thought the support burden/customer frustration would be too great.

It's reasonably common for someone to load images into a gallery, post them to forums, and then make them private later. They don't have a concept that doing it would make their links break.

As it is, we have a very tough time with the option to turn off external links.

I wish I had a better answer for you.

Thanks,
Baldy

[Andy]

this problem presents itself in the Smugsearch. If you type in a search term, the results sometimes show image placeholders with NO image shown.
I'm guessing that is a result of someone turning off external links or, having removed the photo since it's upload?
Could be a variety of things - got a link to show us?

[brandofamily]

Ah, thats not Traditional, thats SingleImage...but yeah my fault for not seeing what you were talking about.

ImageKey is indeed missing on that page. I'll make sure to add it for my next round of updates.

Sorry about that.
When might that round take place?

[Andy]

When might that round take place?
When it does. Sorry Anthony, we can't & don't give dates. But rest assured, it's on the list to be addressed.

[brandofamily]

When it does. Sorry Anthony, we can't & don't give dates. But rest assured, it's on the list to be addressed.
I'm certain it's on the "to do list." But when my site is broken I can't rest very well... I guess I can only hope it's sooner than later....

[Andy]

I'm certain it's on the "to do list." But when my site is broken I can't rest very well... I guess I can only hope it's sooner than later....
Hi Anthony, your site isn't broken, a hack you used to do a very specific thing is not working anymore, as a result of changes we've made. Hacks are like that. I'm going out on a limb and say that there are very few, if any, other customers using that specific hack that you have that's broken. But we will get it done, I promise you that.

[brandofamily]

Hi Anthony, your site isn't broken, a hack you used to do a very specific thing is not working anymore, as a result of changes we've made. Hacks are like that. I'm going out on a limb and say that there are very few, if any, other customers using that specific hack that you have that's broken. But we will get it done, I promise you that.

I know SM is working on fixes to their new structure. I also know it is not possible to anticipate every glitch that will arise when changes are made. But if my site is not working as I intend it to then it's broken. Whether it's a hack that ceased working or not.
I'm sure SM is "on the case." I am at your mercy since I can not fix it, nor can any of the heros... I do not like being at someone else's mercy :(

[jfriend]

Hi Anthony, your site isn't broken, a hack you used to do a very specific thing is not working anymore, as a result of changes we've made. Hacks are like that. I'm going out on a limb and say that there are very few, if any, other customers using that specific hack that you have that's broken. But we will get it done, I promise you that.

Andy, this raises an interesting question for those who customize their site. How does one know what is a "supported customization" and what is a "hack" that might break at any time?

[Andy]

Andy, this raises an interesting question for those who customize their site. How does one know what is a "supported customization" and what is a "hack" that might break at any time?
If it's on http://www.smugmug.com/help/customize-faq.mg you can bet it's supported

If it's in the "Advanced FAQ" http://www.dgrin.com/showthread.php?t=52811 then there are cases where sometimes things might bust or need modification.

If it's a one-off or really obscure hack, well, patience is appreciated :thumb

[Markjay]

Example links

http://www.smugmug.com/keyword/all/sunflower#255491833
twelve total thumbnails... only TWO that actually appear, the rest are blank frames!

http://www.smugmug.com/keyword/all/flowers#256368645
see the 6th & 7th thumbnails-blank

http://www.smugmug.com/keyword/all/seashells#254285461
see the 9th thumbnail-blank!

Hope that illustrates this for you?

Anxiously awaiting your explanation... so I can learn




Could be a variety of things - got a link to show us?

[Andy]

Example links

http://www.smugmug.com/keyword/all/sunflower#255491833
twelve total thumbnails... only TWO that actually appear, the rest are blank frames!
http://img.skitch.com/20080219-gyue12gpccqj91j12hntwb2xdu.jpg

Mark, try clearing your browser's cache? I see all the thumbs there. Same for the other two links, we see 'em fine here.

[bwg]

thanks again for looking into this.
As a temporary fix, I am using the window.location function

- jerryrImageKey and ImageID are now there for all templates that have a main image (and they even accurately reflect what that main image is! bonus!)

[jerryr]

ImageKey and ImageID are now there for all templates that have a main image (and they even accurately reflect what that main image is! bonus!)

Awesome - thank you for the time and attention on this. My initial tests show success ! :) jerryr :clap :clap

[com3]

do some of the OLD URLs to images simply not work anymore? on the entire left side of my side, i tend to rotate through images on smugmug... while the thumbs (which are hotlinked) still work, the links to the images themselves aren't working... and they're simply dropping off in random order.

i checked them about 2 weeks ago, and all of em worked. yesterday, i noticed 2 of em didn't work anymore and when i clicked the links to the large images, it instead forwarded me to smugmug.com.

(on my 4theriders site)

here's one of the current thumbs that works as well as link to L that suddenly stopped working the other day, never changed the code...

http://seppes.com/photos/235342765-Ti.jpg (http://seppes.com/gallery/4042360/1/235342765/Large)

[jfriend]

do some of the OLD URLs to images simply not work anymore? on the entire left side of my side, i tend to rotate through images on smugmug... while the thumbs (which are hotlinked) still work, the links to the images themselves aren't working... and they're simply dropping off in random order.

i checked them about 2 weeks ago, and all of em worked. yesterday, i noticed 2 of em didn't work anymore and when i clicked the links to the large images, it instead forwarded me to smugmug.com.

(on my 4theriders site)

here's one of the current thumbs that works as well as link to L that suddenly stopped working the other day, never changed the code...

http://seppes.com/photos/235342765-Ti.jpg (http://seppes.com/gallery/4042360/1/235342765/Large)

I have a theory that external linking protection has been tightened up in the latest security changes to you should verify that external linking is allowed to any galleries that you want to use in this way.

[com3]

I have a theory that external linking protection has been tightened up in the latest security changes to you should verify that external linking is allowed to any galleries that you want to use in this way.


external linking is ALWAYS allowed in my galleries.

[Andy]

external linking is ALWAYS allowed in my galleries.
I clicked a bunch and all these links worked

http://www.seppes.com/gallery/2884013/1/155099783/Large

http://www.seppes.com/gallery/2547355/1/133943103/Large

http://www.seppes.com/gallery/2884013/1/155291869/Large

I could keep going...

[com3]

I clicked a bunch and all these links worked

http://www.seppes.com/gallery/2884013/1/155099783/Large

http://www.seppes.com/gallery/2547355/1/133943103/Large

http://www.seppes.com/gallery/2884013/1/155291869/Large

I could keep going...


yeah, not all of em work...that's why i'd asked about it...cause it's hit/miss (when they worked just fine before... i haven't changed any code). *shrugs* thanks for checking, andy!

EDIT// hehe... i just clicked to see which ones you'd checked... of course, you pick the hawtest of the hawties. :P