Changeover, send an email and move on, that's what I'd do Really - it's not the end of the world, as I see it. So long as you have contact info on your new site, people that have an old link that doesn't work, will just contact you. HECK, you can even make your own Jfriend 404 page, that includes a one-line apology, and asks them to either: search, or write you.
It wouldn't be a 404 though, would it? The link would work but there would be no custom domain at the front so therefore the hypothetical js would not work.
That's the way we see it too, because you get to take advantage of smugmug.com's high SEO ranking and you get to add to it by adding relevant content, which benefits us all, SmugMug and other photographers.
So that would be a downside of driving more people to custom hostnames, but if we can't deploy JavaScript in the way you want on smugmug.com, that would be an unfortunate side effect.
No downside there (for me anyway). I've turned off everything I can for SEO and all the other "find me" type stuff. Andy has (several times) accused me of being "too locked down". SmugMug's two greatest benefits for me (until now) were it's top notch customer service and it ultimately flexible customization options if you were willing to "do the heavy lifting".
Most of my photos are for schools. Customers get direct links and don't want random people finding the pictures so I do my best to honor that desire. I've used some of the JS "hacks" to provide additional pseudo-security (weak, but effective against lookie-loos) that would go away with the lack of JS support under the "new" system.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Huhhh? It's not a hack to redirect your own site to your own Smugmug-registered custom domain. Where in the heck is the security issue with that?
Hmmm, we seem to be misunderstanding each other or talking past each other, or something.
If I missed some context along the way, I apologize and have a true confession: when you or anyone launches into the benefits of JavaScript I skim over it because we all know and mostly agree on the benefits and I'm pressed for time. But if we're like Wordpress and can't figure a way to deploy it then it doesn't matter how compelling the benefits. So my mission is to seek information about how to deploy it in a responsible way.
One problem is most people really knowledgeable about it aren't willing to talk about it on a public forum because they feel that's irresponsible.
There is a way that you and I talked about over email to deploy it on both SmugMug and custom domains, and that's the Wordpress and Apple Appstore models where we review it and if it gets approved we distribute it. But you seemed very tepid about it. I had a few other conversations that spanned both extremes: one was very excited and thought it was the perfect solution. They are developers. A couple others...hmmm, how do I say?...Rage might be the word. I took it as a no.
Hi John, there's not an ounce of disrespect here - only what I perceive to be a possible solution. I'm sorry you took it all the wrong way. This I think is part of the issue, you and many others get way wrapped up in stuff.... If SM can do your FR, safely, I bet they will (have you lodged it on http://feedback.smugmug.com)?
Well, yeah I'm wrapped up in things. Duh. The site I've invested a lot in has, at least for now, abandoned me and obviously doesn't prioritize some things I care about enough to have released new SM with them. Maybe they will move that direction, maybe they won't. Now, they also want to break all my existing links by making it so I can't use JS on my current domain and forcing me to a new domain and you're over here telling me that I'm just making too big a deal about things and I should get over it. Well, I think that's down right disrespectful and I don't think you should do that to anyone.
I'm just trying to decide when is the straw that broke the camel's back. For now, I think I'll just need to leave dgrin for awhile because it isn't very enjoyable to be here. I'm obviously swimming against the tide so maybe I should find a tide that's going my direction.
Hmmm, we seem to be misunderstanding each other or talking past each other, or something.
If I missed some context along the way, I apologize and have a true confession: when you or anyone launches into the benefits of JavaScript I skim over it because we all know and mostly agree on the benefits and I'm pressed for time. But if we're like Wordpress and can't figure a way to deploy it then it doesn't matter how compelling the benefits. So my mission is to seek information about how to deploy it in a responsible way.
One problem is most people really knowledgeable about it aren't willing to talk about it on a public forum because they feel that's irresponsible.
There is a way that you and I talked about over email to deploy it on both SmugMug and custom domains, and that's the Wordpress and Apple Appstore models where we review it and if it gets approved we distribute it. But you seemed very tepid about it. I had a few other conversations that spanned both extremes: one was very excited and thought it was the perfect solution. They are developers. A couple others...hmmm, how do I say?...Rage might be the word. I took it as a no.
All I was asking for here was that if you're going to force people to custom domains in order to use JS that you offer them an option to auto-redirect from their xxx.smugmug.com domain to their custom domain (preserving path) so that all their existing links out on the web would land on the fully functioning custom domain rather than the only partially functional xxx.smugmug.com domain that doesn't have functioning JS. Seems like a simple way to lessen the pain of forcing customers to change to a custom domain. It might even help get all former SEO moved to the custom domain too.
That's all I'm trying to add to this discussion at the moment and I'm feeling thoroughly beat up (not by you) just trying to make that point. I'm obviously swimming against the tide here. I need a vacation from dgrin and even thinking about the future of my Smugmug site. You know how to reach me on email if you want my opinion on anything.
I think SmugMug's security problem with JavaScript is this: They currently use a *.smugmug.com-wide session cookie. That means that if I log on as n-sherlock.smugmug.com, then visit someotherguy.smugmug.com, my browser will continue to include my session cookie along with any request made to someotherguy.smugmug.com. If someotherguy can write arbitrary JavaScript, then they can write a script that causes my browser to send a request to a SmugMug API on their domain of their choosing. That request will include my session cookie which is basically my authorisation to perform the action as my account.
Your web browser only allows pages on someotherguy.smugmug.com to access URLs that exist inside precisely someotherguy.smugmug.com, this is called the Same-Origin Policy and is the basis of JavaScript security. So someotherguy can't cause my web browser to make a request to "n-sherlock.smugmug.com" or even "smugmug.com". However, if any SmugMug APIs exist which allow the parameters of the URL to decide which website the operation will actually modify (instead of checking the domain name in the URL, which the Same-Origin Policy won't let you fake), someotherguy could send a request to someotherguy.smugmug.com, which will include my session cookie, to modify *my* SmugMug website.
I don't see what is currently stopping SmugMug from using the domain name provided in the URL to validate the origin of the request: if an API is called on http://someotherguy.smugmug.com/, even if a cookie is passed showing that the caller is logged on as n-sherlock, it should not allow any APIs to run that would modify n-sherlock's website. If SmugMug's API was made safe in this way, I don't think there would be much security argument against allowing arbitrary JavaScript to be run.
For example, I can't think of a legitimate reason for any of the customiser APIs to be callable from off-domain sites. And yet, when I was logged on as n-sherlock.smugmug.com, by visiting chickensmoothie.smugmug.com, chickensmoothie.smugmug.com was able to use custom JavaScript to call customiser APIs of its choosing, which resulted in creating a brand new page with content it determined on my n-sherlock.smugmug.com site. (To simulate the ability to add custom JavaScript to the page, I pasted it in manually using Web Developer).
so..... whats the way forward? Can Smugmug give us a steer on when they'd like to have made a decision? hoping to have it wrapped up by say Christmas/end of year?
Changeover, send an email and move on, that's what I'd do Really - it's not the end of the world, as I see it. So long as you have contact info on your new site, people that have an old link that doesn't work, will just contact you. HECK, you can even make your own Jfriend 404 page, that includes a one-line apology, and asks them to either: search, or write you.
I dunno - I guess I think it differently. I have hundreds of Events links out there from over the years - I've consolidated those old galleries into another gallery. On the off-chance that someone wants a photo from a bar mitzvah I shot in 2009, well, they'll get a page that says contact me and I'll help them
I dunno - I guess I think it differently. I have hundreds of Events links out there from over the years - I've consolidated those old galleries into another gallery. On the off-chance that someone wants a photo from a bar mitzvah I shot in 2009, well, they'll get a page that says contact me and I'll help them
Andy,
I think that mostly people worry about a situation when links that they have posted on some social media site (or similar) might be picked up by search engines, evaluated by the search engine's algorithm and down-ranked as being dead thus affecting the overall SEO of the site. Do you think this is a possbility and, perhaps, the reason why some people are upset about it?
On the other hand, I personally believe, that a good structured website needs no links to be handed out at all. I believe that the only information potential visitors need is your domain name address. From there, from the landing/home page the navigation should be easy enough to point and direct visitors to the desired destination in the least amount of clicks.
Andy,
I think that mostly people worry about a situation when links that they have posted on some social media site (or similar) might be picked up by search engines, evaluated by the search engine's algorithm and down-ranked as being dead thus affecting the overall SEO of the site. Do you think this is a possbility and, perhaps, the reason why some people are upset about it?
There are people who are concerned about what's changing and have expressed their concerns. Telling someone to get over it and move on isn't addressing their concern-whether what you want them to do is the right thing or not.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
There are people who are concerned about what's changing and have expressed their concerns. Telling someone to get over it and move on isn't addressing their concern-whether what you want them to do is the right thing or not.
Bingo! Given Andy's former role at SM, I'm amazed that this is lost on him.
Bingo! Given Andy's former role at SM, I'm amazed that this is lost on him.
I don't think it's at all lost on him. I think Baldy said something along the lines that for 95% of their customers, what is available today works. He also suggested that a larger number of customers are choosing a truly customized site-which is way up vs their first offering. These two things are one of the biggest reasons I would suggest that most people 'jump in the water's fine'-again, most people would be fine with that recommendation. So what Andy's suggesting isn't all that bad for most people.
However, there is still some percentage who rely on that truly customizable nature of the old SmugMug. My interpretation of what Baldy said was they heard that requirement loud and clear and they are working on a way to bring some (maybe not all) of that back in a way that satisfies SmugMug's requirements too.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
I don't think it's at all lost on him. I think Baldy said something along the lines that for 95% of their customers, what is available today works. He also suggested that a larger number of customers are choosing a truly customized site-which is way up vs their first offering. These two things are one of the biggest reasons I would suggest that most people 'jump in the water's fine'-again, most people would be fine with that recommendation. So what Andy's suggesting isn't all that bad for most people.
However, there is still some percentage who rely on that truly customizable nature of the old SmugMug. My interpretation of what Baldy said was they heard that requirement loud and clear and they are working on a way to bring some (maybe not all) of that back in a way that satisfies SmugMug's requirements too.
What Andy is saying is very straight forward. 'Some things have changed including old links. So here's the new link to foo gallery, enjoy the new site.' Or 'Here's the main URL. Please navigate to the gallery of your choosing.' What is so difficult with this and why would this suggestion be so offensive? The new SM is like an entirely new site now, really. Instead, if someone decides to switch hosts because they're just fed up with all this change then guess what? All links change anyway.
The above is not the main issue at all IMO. The biggest problem is that there is a huge paradigm shift for the legacy customizer folks who made the old, very outdated SM model work for them with tremendous self-brewed scaffolding systems.
In the new SM the majority of us who used those work arounds do not need them any longer. Most do not *need* full JS customization, no questions asked anymore. There are some who have a good business case such as for self-fulfillment, paypal, international currency support, etc... But maybe some of these things don't align fully with SM's business model. All that customization and freedom comes with a cost which SM has incurred for years.
Some will leave for various reasons. Can everyone be made happy and accommodated? It would be nice, but may not very practical. I think a model with JS review prior to deployment is a pretty darn good middle ground. But of course this is short of instant deploy and unbridled freedoms which is still desired by some. I just don't see that as reasonable or a good SM business model or policy going forward. But that's simply my opinion after working in the industry for quite some time. If someone wants unbridled freedoms that typically comes at either a very high price (e.g. photoshelter) or a fully customized site on their own host providing 100% freedom at a cost. The later requires quite a bit of time to setup, maintain, update, etc...
The above is not the main issue at all IMO. The biggest problem is that there is a huge paradigm shift for the legacy customizer folks who made the old, very outdated SM model work for them with tremendous self-brewed scaffolding systems.
It is a huge shift and I think it's better to recognize that than to ignore it.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
What Andy is saying is very straight forward. 'Some things have changed including old links. So here's the new link to foo gallery, enjoy the new site.' Or 'Here's the main URL. Please navigate to the gallery of your choosing.' What is so difficult with this and why would this suggestion be so offensive? The new SM is like an entirely new site now, really. Instead, if.... ..... If someone wants unbridled freedoms.... setup, maintain, update, etc...
I don't quite understand where you're saying people would put some kind of statement like those in your first sentences. Do you mean they'd (folks like John, etc.) place statements like that on one page (homepage?) or a bunch of gallery pages, or where? I mean, there's no way to practically email out some kind of statements to customers / clients going way back. And a lot of people having to place such statements all over their sites sounds quite ugly, when they've had elegant sites going on for them. Also, the links placed all over the web in the past would be going to a lot of different pages on one's site, not just one spot. But maybe I'm just not understanding. I simply don't see anything wrong or unwarranted or surprising in John's request of SmugMug (basically that SmugMug take the responsibility of not ruining all his former traffic if SmugMug ends up forcing everyone to a custom domain in order to use Javascript, since SmugMug is continuing to say how fantastic all the New Stuff is & that everyone can Customize to their hearts' content) There's no reason SmugMug couldn't find a simple way to take care of this for folks if they decide we need custom domains for JS. If they can't, it begs the question, "why not?" If the engineers & designers can't handle creating ideas for stuff that simple... why are they there?
At any rate, there's been a great lack of acknowledgement that people have immensely differing needs for their sites (and that they really can't/don't want to lose what they've been already told they're paying for.) Yes, it has been quite offensive. Sure, there are plenty of Smug gurus (or past ones!) and others around here who have a small-ish Smug site that shows some small fraction of their work; their sites look pretty & they probably sell some stuff, spend limited amounts of time with their actual site or using all its tools, and keep it rather straightforward-Smug-ish. Maybe they've done a bit of customizing. And then many of them probably have numerous other outlets for their work (even other sites)... and since many of them are working full-time at SmugMug, they may not be depending on their photography income. And sure, plenty of us aren't. However, many are, & there's an entire realm of Smuggers going the whole gamut in several widely varied directions from that simple kind of site. Their sites are a whole different animal. Mine is one. It's clear that the functions of my site (as a person with a humongous family that uses my site & a crazy-range of interests) are barely related to the functions of, say, MBonocore's site. I have no problem with how he wants to use his site. But I need mine for a whole lot of purposes that he clearly doesn't need his for. And I have a right to be mad when I find a broken slideshow on a business site, supposed to be running from my pages, but borked due to the rollout & I'm not properly informed that'll happen. Maybe if I had a basic site, OK. But I have a Pro site for such reasons.
Paying customers who really do have a need for their site to be a much different animal for them than one of the Smug guru's sites is to that guru.... they are understandably ticked and indignant when others are almost scoffing at the ways they need to be able to use their site. It's just... not right. It's condescending and shows that a great lack of time was taken before the roll-out in simply looking around to see what long-term customers have been already doing with their sites for eons. And all the feigned shock at long-term customers being upset about losing so much is getting extremely tiresome. So are the sentiments from SmugMug that we should all have more trust that a bunch of this stuff will get implemented.... somehow...sometime. When you look at the things that have never been even answered or fixed let alone implemented, it really & truly does put you between a rock & a hard place. Do you trust? Do you save what you've got & try to fix stuff on your own? Do you move away from the place you've poured all that hard work into?
I don't need unlimited freedoms, and I don't even have a problem with PBolchover's suggestion that Andy thought was so awful. Or if we need custom domains for JS, fine. (That's if there's a real reason for it, & so far, no one up above has really explained why that's so much more "safe" or whatever). If they wanna give JS more freely to some customizers & only allow the rest to use those snippets, fine (if a bunch more customizers like John were approved). All I want is to be able to have (at the very least) the things work that worked before, and a way to install things that SmugMug won't get around to forever or hasn't yet thought of, as long as it's "safe". I wanna be able to fix stuff that's just ugly design or non-functional. (like captions presently divorced from photos) But I don't want to see people run over, ignored, abandoned, scoffed at, or treated as secondary citizens when they bring up intelligent points, ask good questions, and ask for explanations of why something is suddenly deemed unsafe. That needs to stop, and folks who've given so much to this site & company need to be treated as the treasures that they really are. I doubt SmugMug would've even continued to exist without some of them. Security is a fine thing. But overly-zealous security, especially if its purpose is not clearly defined, just kills the human spirit.
Basically, if you can write any JavaScript code you like, you can automatically ruin the SmugMug site of anybody who visits your SmugMug site, assuming that they are logged in. This is bad news.
It's easier to fix that hole if custom domains are used, since browser security helps contain things.
Basically, if you can write any JavaScript code you like, you can automatically ruin the SmugMug site of anybody who visits your SmugMug site, assuming that they are logged in. This is bad news.
It's easier to fix that hole if custom domains are used, since browser security helps contain things.
I saw that, but you also said how they could fix that risk already....?
Yes, I believe that they could create a fix for that at the moment. However, fixing and retesting all those APIs would be a large project. It'd be a huge investment of developer time for a feature that only a tiny fraction of their customer-base is going to use, and from what I can tell they're already hoping to eliminate ad-hoc JavaScript development.
They'll probably take the direction of manually reviewing and approving JavaScript customisations instead, which would be significantly less work than fixing the security.
I don't quite understand where you're saying people would put some kind of statement like those in your first sentences. Do you mean they'd (folks like John, etc.) place statements like that on one page (homepage?) or a bunch of gallery pages, or where? I mean, there's no way to practically email out some kind of statements to customers / clients going way back. And a lot of people having to place such statements all over their sites sounds quite ugly, when they've had elegant sites going on for them. Also, the links placed all over the web in the past would be going to a lot of different pages on one's site, not just one spot. But maybe I'm just not understanding. I simply don't see anything wrong or unwarranted or surprising in John's request of SmugMug (basically that SmugMug take the responsibility of not ruining all his former traffic if SmugMug ends up forcing everyone to a custom domain in order to use Javascript, since SmugMug is continuing to say how fantastic all the New Stuff is & that everyone can Customize to their hearts' content) There's no reason SmugMug couldn't find a simple way to take care of this for folks if they decide we need custom domains for JS. If they can't, it begs the question, "why not?" If the engineers & designers can't handle creating ideas for stuff that simple... why are they there?
...
All I'm saying is a photographer could easily send out a message to his/her clients explaining this. Won't that be required anyway if some move on to another host? Its not like photographers never communicate with their customers, friends, family, etc... or do not have a contact list to address such changes.
Security is something which is *very* important for all SM customers even if at times it limits the freedoms of some. Not fully understanding all the reasons why does not invalidate its significance. Some of those were already described. But going into more detail in a public place like this is a bad idea. If you or anyone else really wants to know 'more' of the whys beyond what was already stated I suggest using email rather than this forum to satisfy those curiosities.
Living with 'approved' scripts would work for the vast majority of customers IMO. Those requiring more will find another place with greater freedoms or simply build their own site. Then there are no limits except those which are self-imposed.
It's a standing joke in our house that one day we'll hire a burglar to ransack our eldest daughter's bedroom, in the sure and certain knowledge that it'll be tidier after than before.
With that in mind, forgive me for being so blunt, but is SmugMug concerned that somebody might hack into its system and actually FIX IT?
Haha nope, it's not that kind of vulnerability, fortunately (it basically only affects site viewers, not the server.)
Anyway, if someone wanted to go to all that development effort, they'd probably be better served filling out a job application so they can get paid for it!
All I'm saying is a photographer could easily send out a message to his/her clients explaining this. Won't that be required anyway if some move on to another host?....
Living with 'approved' scripts would work for the vast majority of customers IMO. Those requiring more will find another place with greater freedoms or simply build their own site. Then there are no limits except those which are self-imposed.
Sure, if someone moved, they'd have to do what they could to recover their biz & all. But sending out messages to hundreds (no, probably thousands if we're talking about school team parents, etc.) of clients would certainly not be "easy", & the point is that SmugMuggers paying the higher costs for Pro sites etc. shouldn't be socked with that responsibility since they haven't created the problem! Isn't the mess with the Uppercase & Lowercase links kind of enough already?! Not to even mention the wacky-ness of all the completely lost passwords that SmugMug unwisely & arrogantly didn't bother to warn anyone about! It's just... enough already! If it would be easy for you to send out all these changes to all of your clients, then you have a whole different type of client than a lot of Smug site owners have.
First of all, emails change all the time. Secondly, you may have never had email addresses in the first place! Thirdly, you may have lots of printed info or links posted where the potential clients / interested parties can get hold of them. Fourthly, try getting the current generation to pay attention to an email about such a mundane thing. No matter what solution the site-owner him/herself has to do, it's not gonna be easy. And it's going to rob gazillions of people of lots of hours they should not have to spend-- This is SmugMug's responsibility and no one else's! In these past couple years leading up to the big roll-out, they were only touting the changes as fabulous, not giving any peons like me heads-up that a bunch of links & all would end up obsolete. And they evidently didn't even give much of a heads-up to customizers and others who've given thousands of hours to SmugMug answering questions & walking people through all kinds of issues not limited to customization... for years. Even if they had much heads-up, they're sure not getting the time of day now except maybe Fastline; it's like... oh well, too bad for you. Honestly, I can't stand it.
I don't want to minimize security, and of course it's important. But if it involves throwing the baby out with the bathwater, it's not worthwhile; it's sort of like SmugMug just getting in the way of itself. I mean, if you throw out the good stuff in order to protect something, and now what you have to protect is way down-graded from what you had before it was "secure"... what's the point? I don't hear anyone stating why HTML or CSS is so much safer than JS, or why you couldn't simply be unable to add any JS w/o certain log-ins or authorizations. Other sites (even if not photo-related) seem to find safe ways to do this. If they made all their users track down former clients & all that in order to improve their safety (instead of providing re-directs or whatever it took) then shame on them.
The other thing that really ticks me off about this JS thing is that we keep getting asked to make more lists of what we want! I've been around here a long time, seen what people ask for, posted about this several times already, and every post seems to be virtually ignored by those up above who are asking. I'll find one of the posts (again) & link it, but for Pete's sake-- must we wear people out even more?? Just, please, please, please... go to John's list of JS Customizations in the sticky & just start working down the list. It's very clear, very impeccably written, beautifully illustrated. And the slideshow with its own thread; virtually everyone wants it, because it's simply gorgeous. It's obvious (or should be) to anyone with a customized site which 10 things or so are wanted the most. Just start. Why must they waste more of our time, time which has already been given up? People have already stated their needs loud & clear for years now & have already been using all 30 items for years now. Half the stuff should've already been built into the great new site, if anyone had been listening with even one ear....especially if they were even considering getting rid of JS. It's excruciating to have to keep repeating this again & again.
Agreed with JFriends that taking leave away from dgrin is a good thing as I have done so, even just as a reader. Heck, I don't even look at my own site.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ whoALSE => Allen
One form of time travel is thru Captured Moments
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
My interest is in having a site where I can enhance it or solve issues in it myself without waiting for SM to do something. That's why I've been a SM customer all these years in the first place. I would have left long ago without JS customization because the pace of SM feature development was glacial and they only did a small percentage of the things I wanted.
So, it's all fine for SM to quickly implement as many features at they can that currently require JS (there is a separate thread discussing that already) and that will make some people happier, but I'm interested in a site where I can create things on my own when Smugmug isn't interested in creating it or is taking forever to create it or when I just want to fix something now that's bugging me about my site.
If it becomes clear that SM has changed their audience target and is no longer interested in supporting that general purpose JS customization capability, then I will go find a different solution that does. For me, this is as much an issue about being able to solve my own issues or enhancements in the future as it is about known features right now.
There's a paradox here that has generated some insightful posts on dgrin over the past year. If we can figure out how to deploy JavaScript securely, we collectively have to learn from our past and figure out this issue too.
When there are thousands of different JavaScripts installed in the way they were in the past, development does become glacial because we end up with the installed base problem others have mentioned. But when we're free of having to engineer around them, we can introduce things like WuFoo form support very quickly.
That was a big factor in facebook being able to crush Myspace, because they had freedom to innovate quickly. With thousands of JavaScript installs, our engineers become increasingly handcuffed, our QA guys can never guarantee a change won't break someone, and some photographers get a nasty surprise when they're out on a shoot and we make some change that breaks a JavaScript install we didn't know about.
Several improvements over the past two years were engineered to completion, rolled out, and then rolled back because of this issue, and it has stopped dozens of improvements from beginning because someone would point out that we couldn't do that or it would disrupt someone's customization.
With thousands of JavaScript installs, our engineers become increasingly handcuffed, our QA guys can never guarantee a change won't break someone.
With all due respect, Baldy, your QA guys can't guarantee any changes won't break something even without JavaScript. Many recent "fixes" have made things better for some but worse for others.
There's a paradox here that has generated some insightful posts on dgrin over the past year. If we can figure out how to deploy JavaScript securely, we collectively have to learn from our past and figure out this issue too.
When there are thousands of different JavaScripts installed in the way they were in the past, development does become glacial because we end up with the installed base problem others have mentioned. But when we're free of having to engineer around them, we can introduce things like WuFoo form support very quickly.
That was a big factor in facebook being able to crush Myspace, because they had freedom to innovate quickly. With thousands of JavaScript installs, our engineers become increasingly handcuffed, our QA guys can never guarantee a change won't break someone, and some photographers get a nasty surprise when they're out on a shoot and we make some change that breaks a JavaScript install we didn't know about.
Several improvements over the past two years were engineered to completion, rolled out, and then rolled back because of this issue, and it has stopped dozens of improvements from beginning because someone would point out that we couldn't do that or it would disrupt someone's customization.
This makes so much sense to me, a software engineer. Its software 101.
I think the real problem is not so much that you want to follow smarter, best practices going forward. It's more that you unknowingly opened Pandora's box many, many years ago. And now it's hard, especially for some, to close it. I have to admit it was fun being able to instantly upload scripts and see them take effect immediately. However in the real software world engineers don't even have that privilege with production releases.
1. First the new feature needs to be approved. Does it meet the current business goals and requirements?
2. Is it the best approach to accomplish the companies goals?
3. Does it mesh with the current architecture? Is there a better or preferred method to handle the same thing?
4. Does it break anything else currently or potentially with future development plans (e.g. maintainable, scalable, loosely coupled, etc...)?
5. Is it secure?
6. Has it been tested on all platforms with all browsers and their various versions?
Unfortunately all of this is meaningless to most customers because all they see is the functionalitythey want. They either have it or they don't. So they look at our discussions of security and best SW practices as excuses rather the real world of IT we live in daily. Was it a mistake to open that box way back when? Maybe, I don't know. It seemed cool for us customers at the time... But for SM over the years obviously not so much. IMO, going back there makes no sense and would be a bad decision architecturally speaking for all the reasons mentioned as well as difficult lessons learned. But maybe we can find a middle ground with some SM oversight which works for most customers?
All I was asking for here was that if you're going to force people to custom domains in order to use JS that you offer them an option to auto-redirect from their xxx.smugmug.com domain to their custom domain (preserving path) so that all their existing links out on the web would land on the fully functioning custom domain rather than the only partially functional xxx.smugmug.com domain that doesn't have functioning JS. Seems like a simple way to lessen the pain of forcing customers to change to a custom domain. It might even help get all former SEO moved to the custom domain too.
That's all I'm trying to add to this discussion at the moment and I'm feeling thoroughly beat up (not by you) just trying to make that point. I'm obviously swimming against the tide here. I need a vacation from dgrin and even thinking about the future of my Smugmug site. You know how to reach me on email if you want my opinion on anything.
Yes, I heard you on that point and it's very valid. I started investigating the issue and yes, we should be able to make it do that but there is a sometime-in-the-future change to keep in mind. It's inevitable that we'll have to go to a https sign-in, and when you think through all the practical issues (there are many) what it means is you'll have to sign in on a smugmug.com domain and we'll have to provide a way for you to get to it without confusing everyone. To see your JavaScript as a user would, you'll have to have another browser open to your own domain.
This change will create many threads of rage but it's the way the net is going and eventually, we'll have to as well.
Comments
It wouldn't be a 404 though, would it? The link would work but there would be no custom domain at the front so therefore the hypothetical js would not work.
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
No downside there (for me anyway). I've turned off everything I can for SEO and all the other "find me" type stuff. Andy has (several times) accused me of being "too locked down". SmugMug's two greatest benefits for me (until now) were it's top notch customer service and it ultimately flexible customization options if you were willing to "do the heavy lifting".
Most of my photos are for schools. Customers get direct links and don't want random people finding the pictures so I do my best to honor that desire. I've used some of the JS "hacks" to provide additional pseudo-security (weak, but effective against lookie-loos) that would go away with the lack of JS support under the "new" system.
If I missed some context along the way, I apologize and have a true confession: when you or anyone launches into the benefits of JavaScript I skim over it because we all know and mostly agree on the benefits and I'm pressed for time. But if we're like Wordpress and can't figure a way to deploy it then it doesn't matter how compelling the benefits. So my mission is to seek information about how to deploy it in a responsible way.
One problem is most people really knowledgeable about it aren't willing to talk about it on a public forum because they feel that's irresponsible.
There is a way that you and I talked about over email to deploy it on both SmugMug and custom domains, and that's the Wordpress and Apple Appstore models where we review it and if it gets approved we distribute it. But you seemed very tepid about it. I had a few other conversations that spanned both extremes: one was very excited and thought it was the perfect solution. They are developers. A couple others...hmmm, how do I say?...Rage might be the word. I took it as a no.
I'm just trying to decide when is the straw that broke the camel's back. For now, I think I'll just need to leave dgrin for awhile because it isn't very enjoyable to be here. I'm obviously swimming against the tide so maybe I should find a tide that's going my direction.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
That's all I'm trying to add to this discussion at the moment and I'm feeling thoroughly beat up (not by you) just trying to make that point. I'm obviously swimming against the tide here. I need a vacation from dgrin and even thinking about the future of my Smugmug site. You know how to reach me on email if you want my opinion on anything.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Your web browser only allows pages on someotherguy.smugmug.com to access URLs that exist inside precisely someotherguy.smugmug.com, this is called the Same-Origin Policy and is the basis of JavaScript security. So someotherguy can't cause my web browser to make a request to "n-sherlock.smugmug.com" or even "smugmug.com". However, if any SmugMug APIs exist which allow the parameters of the URL to decide which website the operation will actually modify (instead of checking the domain name in the URL, which the Same-Origin Policy won't let you fake), someotherguy could send a request to someotherguy.smugmug.com, which will include my session cookie, to modify *my* SmugMug website.
I don't see what is currently stopping SmugMug from using the domain name provided in the URL to validate the origin of the request: if an API is called on http://someotherguy.smugmug.com/, even if a cookie is passed showing that the caller is logged on as n-sherlock, it should not allow any APIs to run that would modify n-sherlock's website. If SmugMug's API was made safe in this way, I don't think there would be much security argument against allowing arbitrary JavaScript to be run.
For example, I can't think of a legitimate reason for any of the customiser APIs to be callable from off-domain sites. And yet, when I was logged on as n-sherlock.smugmug.com, by visiting chickensmoothie.smugmug.com, chickensmoothie.smugmug.com was able to use custom JavaScript to call customiser APIs of its choosing, which resulted in creating a brand new page with content it determined on my n-sherlock.smugmug.com site. (To simulate the ability to add custom JavaScript to the page, I pasted it in manually using Web Developer).
Please check out my gallery of customisations for the New SmugMug, more to come!
Wow...
I dunno - I guess I think it differently. I have hundreds of Events links out there from over the years - I've consolidated those old galleries into another gallery. On the off-chance that someone wants a photo from a bar mitzvah I shot in 2009, well, they'll get a page that says contact me and I'll help them
Portfolio • Workshops • Facebook • Twitter
Andy,
I think that mostly people worry about a situation when links that they have posted on some social media site (or similar) might be picked up by search engines, evaluated by the search engine's algorithm and down-ranked as being dead thus affecting the overall SEO of the site. Do you think this is a possbility and, perhaps, the reason why some people are upset about it?
On the other hand, I personally believe, that a good structured website needs no links to be handed out at all. I believe that the only information potential visitors need is your domain name address. From there, from the landing/home page the navigation should be easy enough to point and direct visitors to the desired destination in the least amount of clicks.
There are people who are concerned about what's changing and have expressed their concerns. Telling someone to get over it and move on isn't addressing their concern-whether what you want them to do is the right thing or not.
Bingo! Given Andy's former role at SM, I'm amazed that this is lost on him.
However, there is still some percentage who rely on that truly customizable nature of the old SmugMug. My interpretation of what Baldy said was they heard that requirement loud and clear and they are working on a way to bring some (maybe not all) of that back in a way that satisfies SmugMug's requirements too.
What Andy is saying is very straight forward. 'Some things have changed including old links. So here's the new link to foo gallery, enjoy the new site.' Or 'Here's the main URL. Please navigate to the gallery of your choosing.' What is so difficult with this and why would this suggestion be so offensive?
The above is not the main issue at all IMO. The biggest problem is that there is a huge paradigm shift for the legacy customizer folks who made the old, very outdated SM model work for them with tremendous self-brewed scaffolding systems.
In the new SM the majority of us who used those work arounds do not need them any longer. Most do not *need* full JS customization, no questions asked anymore. There are some who have a good business case such as for self-fulfillment, paypal, international currency support, etc... But maybe some of these things don't align fully with SM's business model. All that customization and freedom comes with a cost which SM has incurred for years.
Some will leave for various reasons. Can everyone be made happy and accommodated? It would be nice, but may not very practical. I think a model with JS review prior to deployment is a pretty darn good middle ground. But of course this is short of instant deploy and unbridled freedoms which is still desired by some. I just don't see that as reasonable or a good SM business model or policy going forward. But that's simply my opinion after working in the industry for quite some time. If someone wants unbridled freedoms that typically comes at either a very high price (e.g. photoshelter) or a fully customized site on their own host providing 100% freedom at a cost. The later requires quite a bit of time to setup, maintain, update, etc...
My Smugmug Gallery
It is a huge shift and I think it's better to recognize that than to ignore it.
At any rate, there's been a great lack of acknowledgement that people have immensely differing needs for their sites (and that they really can't/don't want to lose what they've been already told they're paying for.) Yes, it has been quite offensive. Sure, there are plenty of Smug gurus (or past ones!) and others around here who have a small-ish Smug site that shows some small fraction of their work; their sites look pretty & they probably sell some stuff, spend limited amounts of time with their actual site or using all its tools, and keep it rather straightforward-Smug-ish. Maybe they've done a bit of customizing. And then many of them probably have numerous other outlets for their work (even other sites)... and since many of them are working full-time at SmugMug, they may not be depending on their photography income. And sure, plenty of us aren't. However, many are, & there's an entire realm of Smuggers going the whole gamut in several widely varied directions from that simple kind of site. Their sites are a whole different animal. Mine is one. It's clear that the functions of my site (as a person with a humongous family that uses my site & a crazy-range of interests) are barely related to the functions of, say, MBonocore's site. I have no problem with how he wants to use his site. But I need mine for a whole lot of purposes that he clearly doesn't need his for. And I have a right to be mad when I find a broken slideshow on a business site, supposed to be running from my pages, but borked due to the rollout & I'm not properly informed that'll happen. Maybe if I had a basic site, OK. But I have a Pro site for such reasons.
Paying customers who really do have a need for their site to be a much different animal for them than one of the Smug guru's sites is to that guru.... they are understandably ticked and indignant when others are almost scoffing at the ways they need to be able to use their site. It's just... not right. It's condescending and shows that a great lack of time was taken before the roll-out in simply looking around to see what long-term customers have been already doing with their sites for eons. And all the feigned shock at long-term customers being upset about losing so much is getting extremely tiresome. So are the sentiments from SmugMug that we should all have more trust that a bunch of this stuff will get implemented.... somehow...sometime. When you look at the things that have never been even answered or fixed let alone implemented, it really & truly does put you between a rock & a hard place. Do you trust? Do you save what you've got & try to fix stuff on your own? Do you move away from the place you've poured all that hard work into?
I don't need unlimited freedoms, and I don't even have a problem with PBolchover's suggestion that Andy thought was so awful. Or if we need custom domains for JS, fine. (That's if there's a real reason for it, & so far, no one up above has really explained why that's so much more "safe" or whatever). If they wanna give JS more freely to some customizers & only allow the rest to use those snippets, fine (if a bunch more customizers like John were approved). All I want is to be able to have (at the very least) the things work that worked before, and a way to install things that SmugMug won't get around to forever or hasn't yet thought of, as long as it's "safe". I wanna be able to fix stuff that's just ugly design or non-functional. (like captions presently divorced from photos) But I don't want to see people run over, ignored, abandoned, scoffed at, or treated as secondary citizens when they bring up intelligent points, ask good questions, and ask for explanations of why something is suddenly deemed unsafe. That needs to stop, and folks who've given so much to this site & company need to be treated as the treasures that they really are. I doubt SmugMug would've even continued to exist without some of them. Security is a fine thing. But overly-zealous security, especially if its purpose is not clearly defined, just kills the human spirit.
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
http://dgrin.com/showpost.php?p=1901370&postcount=517
Basically, if you can write any JavaScript code you like, you can automatically ruin the SmugMug site of anybody who visits your SmugMug site, assuming that they are logged in. This is bad news.
It's easier to fix that hole if custom domains are used, since browser security helps contain things.
Please check out my gallery of customisations for the New SmugMug, more to come!
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
They'll probably take the direction of manually reviewing and approving JavaScript customisations instead, which would be significantly less work than fixing the security.
Please check out my gallery of customisations for the New SmugMug, more to come!
All I'm saying is a photographer could easily send out a message to his/her clients explaining this. Won't that be required anyway if some move on to another host? Its not like photographers never communicate with their customers, friends, family, etc... or do not have a contact list to address such changes.
Security is something which is *very* important for all SM customers even if at times it limits the freedoms of some. Not fully understanding all the reasons why does not invalidate its significance. Some of those were already described. But going into more detail in a public place like this is a bad idea. If you or anyone else really wants to know 'more' of the whys beyond what was already stated I suggest using email rather than this forum to satisfy those curiosities.
Living with 'approved' scripts would work for the vast majority of customers IMO. Those requiring more will find another place with greater freedoms or simply build their own site. Then there are no limits except those which are self-imposed.
My Smugmug Gallery
are they:
- already existing but aren't working right now
- hypothetically available about some point in the future
- shortly being rolled out
Thanks.
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
With that in mind, forgive me for being so blunt, but is SmugMug concerned that somebody might hack into its system and actually FIX IT?
Anyway, if someone wanted to go to all that development effort, they'd probably be better served filling out a job application so they can get paid for it!
Please check out my gallery of customisations for the New SmugMug, more to come!
Sure, if someone moved, they'd have to do what they could to recover their biz & all. But sending out messages to hundreds (no, probably thousands if we're talking about school team parents, etc.) of clients would certainly not be "easy", & the point is that SmugMuggers paying the higher costs for Pro sites etc. shouldn't be socked with that responsibility since they haven't created the problem! Isn't the mess with the Uppercase & Lowercase links kind of enough already?! Not to even mention the wacky-ness of all the completely lost passwords that SmugMug unwisely & arrogantly didn't bother to warn anyone about! It's just... enough already! If it would be easy for you to send out all these changes to all of your clients, then you have a whole different type of client than a lot of Smug site owners have.
First of all, emails change all the time. Secondly, you may have never had email addresses in the first place! Thirdly, you may have lots of printed info or links posted where the potential clients / interested parties can get hold of them. Fourthly, try getting the current generation to pay attention to an email about such a mundane thing. No matter what solution the site-owner him/herself has to do, it's not gonna be easy. And it's going to rob gazillions of people of lots of hours they should not have to spend-- This is SmugMug's responsibility and no one else's! In these past couple years leading up to the big roll-out, they were only touting the changes as fabulous, not giving any peons like me heads-up that a bunch of links & all would end up obsolete. And they evidently didn't even give much of a heads-up to customizers and others who've given thousands of hours to SmugMug answering questions & walking people through all kinds of issues not limited to customization... for years. Even if they had much heads-up, they're sure not getting the time of day now except maybe Fastline; it's like... oh well, too bad for you. Honestly, I can't stand it.
I don't want to minimize security, and of course it's important. But if it involves throwing the baby out with the bathwater, it's not worthwhile; it's sort of like SmugMug just getting in the way of itself. I mean, if you throw out the good stuff in order to protect something, and now what you have to protect is way down-graded from what you had before it was "secure"... what's the point? I don't hear anyone stating why HTML or CSS is so much safer than JS, or why you couldn't simply be unable to add any JS w/o certain log-ins or authorizations. Other sites (even if not photo-related) seem to find safe ways to do this. If they made all their users track down former clients & all that in order to improve their safety (instead of providing re-directs or whatever it took) then shame on them.
The other thing that really ticks me off about this JS thing is that we keep getting asked to make more lists of what we want! I've been around here a long time, seen what people ask for, posted about this several times already, and every post seems to be virtually ignored by those up above who are asking. I'll find one of the posts (again) & link it, but for Pete's sake-- must we wear people out even more?? Just, please, please, please... go to John's list of JS Customizations in the sticky & just start working down the list. It's very clear, very impeccably written, beautifully illustrated. And the slideshow with its own thread; virtually everyone wants it, because it's simply gorgeous. It's obvious (or should be) to anyone with a customized site which 10 things or so are wanted the most. Just start. Why must they waste more of our time, time which has already been given up? People have already stated their needs loud & clear for years now & have already been using all 30 items for years now. Half the stuff should've already been built into the great new site, if anyone had been listening with even one ear....especially if they were even considering getting rid of JS. It's excruciating to have to keep repeating this again & again.
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
Agreed with JFriends that taking leave away from dgrin is a good thing as I have done so, even just as a reader. Heck, I don't even look at my own site.
whoALSE => Allen
One form of time travel is thru Captured Moments
When there are thousands of different JavaScripts installed in the way they were in the past, development does become glacial because we end up with the installed base problem others have mentioned. But when we're free of having to engineer around them, we can introduce things like WuFoo form support very quickly.
That was a big factor in facebook being able to crush Myspace, because they had freedom to innovate quickly. With thousands of JavaScript installs, our engineers become increasingly handcuffed, our QA guys can never guarantee a change won't break someone, and some photographers get a nasty surprise when they're out on a shoot and we make some change that breaks a JavaScript install we didn't know about.
Several improvements over the past two years were engineered to completion, rolled out, and then rolled back because of this issue, and it has stopped dozens of improvements from beginning because someone would point out that we couldn't do that or it would disrupt someone's customization.
With all due respect, Baldy, your QA guys can't guarantee any changes won't break something even without JavaScript. Many recent "fixes" have made things better for some but worse for others.
This makes so much sense to me, a software engineer. Its software 101.
I think the real problem is not so much that you want to follow smarter, best practices going forward. It's more that you unknowingly opened Pandora's box many, many years ago. And now it's hard, especially for some, to close it. I have to admit it was fun being able to instantly upload scripts and see them take effect immediately. However in the real software world engineers don't even have that privilege with production releases.
1. First the new feature needs to be approved. Does it meet the current business goals and requirements?
2. Is it the best approach to accomplish the companies goals?
3. Does it mesh with the current architecture? Is there a better or preferred method to handle the same thing?
4. Does it break anything else currently or potentially with future development plans (e.g. maintainable, scalable, loosely coupled, etc...)?
5. Is it secure?
6. Has it been tested on all platforms with all browsers and their various versions?
Unfortunately all of this is meaningless to most customers because all they see is the functionality they want. They either have it or they don't. So they look at our discussions of security and best SW practices as excuses rather the real world of IT we live in daily. Was it a mistake to open that box way back when? Maybe, I don't know. It seemed cool for us customers at the time... But for SM over the years obviously not so much. IMO, going back there makes no sense and would be a bad decision architecturally speaking for all the reasons mentioned as well as difficult lessons learned. But maybe we can find a middle ground with some SM oversight which works for most customers?
My Smugmug Gallery
This change will create many threads of rage but it's the way the net is going and eventually, we'll have to as well.