Change in SmugMug URLs for better privacy

135

Comments

  • BaldyBaldy Registered Users, Super Moderators Posts: 2,853 moderator
    edited January 31, 2008
    scwalter wrote:
    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.
  • brianbbrianb Registered Users Posts: 96 Big grins
    edited January 31, 2008
    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
    asd wrote:
    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.
  • scwalterscwalter Registered Users Posts: 417 Major grins
    edited January 31, 2008
    Baldy wrote:
    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
    Scott Walter Photography
    scwalter.smugmug.com
  • BaldyBaldy Registered Users, Super Moderators Posts: 2,853 moderator
    edited January 31, 2008
    scwalter wrote:
    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 wish I had a better answer for you.

    Thanks,
    Baldy
  • BaldyBaldy Registered Users, Super Moderators Posts: 2,853 moderator
    edited February 1, 2008
    brianb wrote:
    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.
  • asdasd Registered Users Posts: 115 Major grins
    edited February 1, 2008
    Baldy wrote:
    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.
    Baldy wrote:
    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.
  • I SimoniusI Simonius Registered Users Posts: 1,034 Major grins
    edited February 1, 2008
    Baldy wrote:
    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...rolleyes1.gif

    Well there's a convention that's already established that people would understand the https - "SECURE" - notion. Perhaps?
    Veni-Vidi-Snappii
    ...pics..
  • I SimoniusI Simonius Registered Users Posts: 1,034 Major grins
    edited February 1, 2008
    Baldy wrote:

    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?
    Veni-Vidi-Snappii
    ...pics..
  • I SimoniusI Simonius Registered Users Posts: 1,034 Major grins
    edited February 1, 2008
    Baldy wrote:
    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)
    Veni-Vidi-Snappii
    ...pics..
  • claudermilkclaudermilk Registered Users Posts: 2,756 Major grins
    edited February 1, 2008
    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.
  • jfriendjfriend Registered Users Posts: 8,097 Major grins
    edited February 1, 2008
    On the terminology and security front, here are some previous dgrin threads on the topic that it may be worth reviewing: 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".
    --John
    HomepagePopular
    JFriend's javascript customizationsSecrets for getting fast answers on Dgrin
    Always include a link to your site when posting a question
  • NimaiNimai Registered Users Posts: 564 Major grins
    edited February 2, 2008
    asd wrote:
    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.
    thumb.gif 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!)
  • BaldyBaldy Registered Users, Super Moderators Posts: 2,853 moderator
    edited February 5, 2008
    Nimai wrote:
    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.
  • asdasd Registered Users Posts: 115 Major grins
    edited February 5, 2008
    Baldy wrote:
    *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.gif

    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 SimoniusI Simonius Registered Users Posts: 1,034 Major grins
    edited February 5, 2008
    Baldy wrote:
    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?
    Veni-Vidi-Snappii
    ...pics..
  • AndyAndy Registered Users Posts: 50,016 Major grins
    edited February 5, 2008
    I Simonius wrote:
    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 SimoniusI Simonius Registered Users Posts: 1,034 Major grins
    edited February 5, 2008
    Andy wrote:
    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.
    Veni-Vidi-Snappii
    ...pics..
  • AndyAndy Registered Users Posts: 50,016 Major grins
    edited February 5, 2008
    I Simonius wrote:
    The danger comes in either forgetting , or .. er forgetting.
    lol3.gif

    'tis true - and we're constantly worrying about adding complexity to things :cry
  • DJ-S1DJ-S1 Registered Users Posts: 2,303 Major grins
    edited February 5, 2008
    DJ-S1 wrote:
    ...- I'm very confident you folks will figure out the best solution for all concerned. thumb.gif
    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! clap.gif
  • george-1george-1 Registered Users Posts: 48 Big grins
    edited February 5, 2008
    Baldy wrote:
    *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.

    Baldy wrote:
    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
  • olegosolegos Registered Users Posts: 93 Big grins
    edited February 6, 2008
    Baldy wrote:
    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 mwink.gif
  • jfriendjfriend Registered Users Posts: 8,097 Major grins
    edited February 6, 2008
    george-1 wrote:
    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.
    --John
    HomepagePopular
    JFriend's javascript customizationsSecrets for getting fast answers on Dgrin
    Always include a link to your site when posting a question
  • olegosolegos Registered Users Posts: 93 Big grins
    edited February 6, 2008
    george-1 wrote:
    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).

    Sorry for venting here...
  • olegosolegos Registered Users Posts: 93 Big grins
    edited February 6, 2008
    jfriend wrote:
    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?
  • jfriendjfriend Registered Users Posts: 8,097 Major grins
    edited February 6, 2008
    olegos wrote:
    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.
    --John
    HomepagePopular
    JFriend's javascript customizationsSecrets for getting fast answers on Dgrin
    Always include a link to your site when posting a question
  • BaldyBaldy Registered Users, Super Moderators Posts: 2,853 moderator
    edited February 6, 2008
    DJ-S1 wrote:
    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! clap.gif
    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.
  • wellmanwellman Registered Users Posts: 961 Major grins
    edited February 6, 2008
    olegos wrote:
    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...)
  • jenweavernjjenweavernj Registered Users Posts: 133 Major grins
    edited February 9, 2008
    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?
    Jen Rinaldi

    Nikon D90 & D80 DSLR| Nikon 18-200mm VR | Nikon 70-300 VR |Nikon 105mm f/2.8 MICRO LENS | Nikon 50mm f/1.4 |Tokina 12-24 | Nikon SB800 | Minolta X700 SLR | Minolta 50mm | Minolta 35-105mm

    The goal is not to change your subjects, but for the subject to change the photographer. ~Author Unknown
  • jenweavernjjenweavernj Registered Users Posts: 133 Major grins
    edited February 10, 2008
    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.
    Jen Rinaldi

    Nikon D90 & D80 DSLR| Nikon 18-200mm VR | Nikon 70-300 VR |Nikon 105mm f/2.8 MICRO LENS | Nikon 50mm f/1.4 |Tokina 12-24 | Nikon SB800 | Minolta X700 SLR | Minolta 50mm | Minolta 35-105mm

    The goal is not to change your subjects, but for the subject to change the photographer. ~Author Unknown
  • jfriendjfriend Registered Users Posts: 8,097 Major grins
    edited February 10, 2008
    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:
    245515131_uZQgs-M.jpg

    Working fine here if you get the right link.
    --John
    HomepagePopular
    JFriend's javascript customizationsSecrets for getting fast answers on Dgrin
    Always include a link to your site when posting a question
Sign In or Register to comment.