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
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 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.
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.
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.
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
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 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
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.
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, 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.
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)
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.
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".
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, 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.
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!)
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.
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.
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!
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?
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.
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.
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.
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
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.
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 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).
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.
Man, I love being proven right. Now where's that "patting myself on the back" smilie?
Sounds like a well-reasoned solution to me, good job guys!
Thanks 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.
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?
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.
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:
Comments
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.
Thanks!
Brian
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
scwalter.smugmug.com
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
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.
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.
If you're worried about readability, try breaking things up with a hyphen or two. Consider the following ID schemes:
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, 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.
make em bigger! --oh that's not what you meant...
Well there's a convention that's already established that people would understand the https - "SECURE" - notion. Perhaps?
...pics..
Can you explaina little why that is, for non techies like moi?
...pics..
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)
...pics..
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.
http://www.chrislaudermilkphoto.com/
- When private isn't really private - April 2007
- Private vs. unlisted - Oct 2006
- People confused about private galleries - Sept 2006
- Guessable gallery numbers - Sept 2006
- Passworded images not requiring a password - May 2006
- Suggestion for "unlisted" galleries - March 2006
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".Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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!)
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.
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!
not ure what this means but hope it doesnt mean we can accidentally ( and therefore easily) move things into the wrong sort of gallery?
...pics..
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.
Portfolio • Workshops • Facebook • Twitter
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.
...pics..
'tis true - and we're constantly worrying about adding complexity to things :cry
Portfolio • Workshops • Facebook • Twitter
Sounds like a well-reasoned solution to me, good job guys!
That's the thing I like best about Smugmug, y'all listen to your clients.
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
http://george-1.smugmug.com
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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...
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
No, but I don't share my money like I share my photos.
Swim for Them | WellmanHouse.net | AlbumFetcher | SmugShowBuilder
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?
The goal is not to change your subjects, but for the subject to change the photographer. ~Author Unknown
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.
The goal is not to change your subjects, but for the subject to change the photographer. ~Author Unknown
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:
Working fine here if you get the right link.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question