I definitely understand where you are coming from, and your two scenarios are discussed almost daily, from what I even hear, and I don't even work in the main suite. All I can tell you is where we are at today, and I have said that many times before. I know it is not what you are looking for at this very moment, but that is all I can tell you at this very moment.
Thanks - I know I come across frustrated, because I really really am frustrated. I don't know whether I'll end up having one months notice to dump SM and move to Zenfolio, or whether I'll only be up for dozens of hours rebuilding my site on SM at some stage.
I think that's the key frustration - even with all the best will in the world, at the moment it's TOTALLY UNCLEAR as to whether SM will ever support what I need for my site, and if it will support it continuously (through the legacy site remaining usable until the capability is delivered on the new site)
Until those unknowns are cleared up, I will remain upset with Smugmug for proposing to remove important functionality from the service offering.
How about asking the bosses if there's any chance they can make a clearer statement about these please? How about updating us on these topics? I note my bumps in the feature request topic asking for updates have been ignored.
Thanks - I know I come across frustrated, because I really really am frustrated. I don't know whether I'll end up having one months notice to dump SM and move to Zenfolio, or whether I'll only be up for dozens of hours rebuilding my site on SM at some stage.
I think that's the key frustration - even with all the best will in the world, at the moment it's TOTALLY UNCLEAR as to whether SM will ever support what I need for my site, and if it will support it continuously (through the legacy site remaining usable until the capability is delivered on the new site)
Until those unknowns are cleared up, I will remain upset with Smugmug for proposing to remove important functionality from the service offering.
How about asking the bosses if there's any chance they can make a clearer statement about these please? How about updating us on these topics? I note my bumps in the feature request topic asking for updates have been ignored.
Cheers - N
No problem. I understand, and you can always vent to me...that's what I am here for. I know this consumes alot of time upstairs, so I promise you when we have more information about the future of JS, Baldy will personally come in and make it known.
I envision that no javascript will be allowed on individual sites but held in a sandbox. The "one copy"
of each script would be kept up to date for everyone. Users would then be able to call a script and only
supply the parameters.
It would be up to each developer to supply their script for approval and keep updates current.
Well, I sure as hell don't have access to any JS on customized sites. I guess SM is only allowing special people to customize sites now, and since Don hates me, I'm out in the cold.
No worries though; SM is dying -- and spending money to customize SM is like throwing your money down the drain.
I always thought that the wherewithal for complete, unfettered, customization was the whole point of Smugmug. That's certainly why I signed up. I always thought I was paying Smugmug to simply host and provide functionality to display my photos as the foundation of a website that I could design and modify to my heart's content. Eliminating one of the core tools of website design and modification definitely seems like a dramatic change in priorities.
I get it that there's been a support overhead for Smugmug when it comes to javascript. But beyond supporting the embedded design functionality of Smugmug-hosted websites, I've never expected Smugmug to be responsible for how badly I fubar my website using tools that are above and beyond those explicitly provided (as opposed to, allowed) by Smugmug. The Smug hero help with javascript, CSS, etc., has always been appreciated, but I've never construed it to be obligatory. I've only ever bothered Smugmug support with problems related to core functionality. For everything else, there is Dgrin and the wonderful, amazing volunteers such as jfriend, Allen, and so many others.
That seems like a very reasonable line of demarcation for what Smugmug's help desk should be expected to support.
But now it appears that under this new regime of drastically limiting customization, my website will become much more a Smugmug site and much less my site. That's not what I signed up for.
I'm not a Javascript expert, but I guess that the following type of situation is what they're trying to avoid:
Imagine a virus which automatically checks whether you have a smugmug site and, if you do, and are logged in, then it silently adds Javascript to your site which triggers all viewers of your site to do some action which makes them infected by the virus.
Smugmug can't even prevent this by asking for your password, because a decent virus will contain a keylogger which can capture your smugmug password. (And this is might be just one of many ways in which the virus might spread.)
Now, there are probably ways in which Smugmug can check javascript for viruses and/or block certain risky types of traffic. However, I get the impression that there might have been some recent incident (perhaps on some other website, or perhaps announced in some security conference) which has made Smugmug put their original plans to allow Javascript on hold until they can assess the situation.
However, I do think that there must be some type of compromise. My suggestion would be to allow a "Javascript Guru" privilege to a limited users, who can submit custom-made javascript to Smugmug. Once they have worked out the bugs in their own pages, these gurus could then have the option to submit these snippets to a Smugmug library of these "user code snippets" which non-Gurus could add to their pages. Registered customisers might have the option of creating their own snippets which could be applied to pages that they customise (not sure how the business model would work...)
wow, after being away for a few days it was interesting to read all that above:) I do not even know which side to lean toward: frustrated customers or poor Michael Bonocore who has to suffer here.
On one hand I am very much frastraded (as I stated in some other threads) about the removal of JS. I agree with many and with John (jfriend) - there is no way for anyone to list all the feature we want/need. We simply do not know. That is what the programming language (JS) is here for. I want to be able to address MY needs as they come when they come and not pay Fastline for something I can easily do.
At the same time, being in the software development industry and understanding not only pure development portion of it but also a management part of the whole thing - I can see the dilemma a business (SmugMug) is presented with. Michael, you keep asking to list features? ok. I want two right now:
1) ability to make side bars sliding (as on my website, you know what I am talking about.) I doubt you can easily duplicate the full functionality of my sliding side bar... but even simple, single sliding sidebar would be ok for now.
2) content block (or whatever the internal name is) to type the name of the folder, gallery, page and be redirected to it. The same as on Fastline template in the Client section.
Please, move the above two request in whatever place they need to be. But I have a terrible feeling that at the end JS will not be here in SM anymore and these features will not be implemented as well. Why do I have this feeling? Because I think that SM is simply changing business model. I hope I am wrong. I honestly feel bad for Michael B. who is thrown here to defend the SMugMug reputation and provide whatever support he is allowed to. People, please realize - regardless how much we all vent out here and "scream" - Michael will NOT tell you "yes" or "no". I am glad he tells us anything:)
Imagine a virus which automatically checks whether you have a smugmug site and, if you do, and are logged in, then it silently adds Javascript to your site which triggers all viewers of your site to do some action which makes them infected by the virus.
I really, really don't think that anybody would bother to write a virus like that to target such a miniscule portion of the Web. It'd be a complete waste of time. Posting links to people's Facebook walls would give a much better rate of return, given that the chance of any random computer being logged into Facebook is many orders of magnitude higher than being logged onto SmugMug.
Not to mention the fact that SmugMug supporting JavaScript doesn't really make that situation any worse. All a virus would have to do is add a link to the page "click here to view my price list" which leads to an infected PDF, no JS required. I don't think this possibility factors into SmugMug's risk planning at all.
I imagine one of their big concerns is developers' servers that are hosting JS which is embedded into SmugMug sites being subverted, which could have easily happened on Old SmugMug. If you hotlinked to a developer's copy of a JS customisation using a <script> tag, then an attacker only needs to breach that developer's server to simultaneously hit every SmugMug page that uses that JavaScript customisation. The attacker could then do things like make the Checkout button redirect to their own form which just sends the credit card details straight to them (the browser's address bar would reveal this deception, but only to very keen-eyed users).
A curated customisation repository basically avoids this issue, but requires a large development effort on the part of SmugMug to create, so it definitely won't be just around the corner.
I think the best solution to this, would to be able to have your JavaScript approved before it is made 'live'. You could code your own script in a 'JavaScript' content block, and when you click live, the code is submitted to a small team which checks the script is not harmful in any way (which is almost all cases will not be).
Really, what are the reasons for removing JavaScript. Malicious code? Implement the above or a 'Report Site' button? Your users removing your copyright at the bottom? Check my site, I've already manipulated it (well removed it, and added my own). Your SmugMug Heros don't want to handle support tickets for JavaScript? Just make it an 'Unsupported' feature in SmugMug, and refer them to these forums to get help of fellow SmugMuggers like Dave mentioned. I can't really think of others to hand. It doesn't make sense to remove it.
The reason I stuck with SmugMug is customization. If there is no good customisation, why should I stay with them?
- Dan, Studying At College To Enter Science or Programming Field.
I think since launch we have proved we are able to turn feature requests around quickly, and that we really do want to. It's up to you whether you trust us or not, but i think that we have shown that we are listening.
Hi Michael, Smugmug have also already demonstrated that what are simple fixes, like adding Google+ +1s (http://www.dgrin.com/showthread.php?t=237601) . can also easily fall by the wayside if they're not deemed important enough. Its two lines of code for us to add in Javascript. (just my particular pet peeve, I'm sure that we all have stuff we'd like to bump up the list of changes, and I'm not suggesting this should be priority 1)
I don't doubt Smugmug's sincerity, I do doubt their ability to quickly react to changing needs of their clients compared to them being able to add the thing themselves.
Its great that the new smugmug infrastructure can speed up feature request implementation. However, having previously measured feature request implementation in years, I'm not confident that even now the smugmug team are able to implement requests quickly enough to meet our needs, and look forward to the time when I'm once again able to just add the code myself.
I think the best solution to this, would to be able to have your JavaScript approved before it is made 'live'. You could code your own script in a 'JavaScript' content block, and when you click live, the code is submitted to a small team which checks the script is not harmful in any way
I'd take a moderated javascript box (assuming its not madly restirctive, and either pre-moderated, or preferably post-moderated); a few written guidelines as to what is and isn't acceptable in javascript would probably be easy to follow by most, and might give us a better idea of what Smugmug's issues with JS are.
Additionally, as a counter-offer to "tell us what you'd like to use Javascript for", can I suggest that you extend the javascript authorised customers to include some of the javascript experts on here, like jfriend, and see if there are issues with the code they'd like to add to their site. I'd also suggest that seeing what people actually use it for is probably more accurate than asking people to list what they would use it for.....
I have two very specific issues for the new SmugMug, which is why I'm still on the legacy mode.
1) Full screen slideshow on homepage - Self explanatory. I loved the one I currently have on my legacy site (http://www.RacingHistorian.com) - and want it back.
2) Google Adsense Ads - I use to make almost enough off my Adsense ads in my footer to pay for my SmugMug account. Without javascript, I cannot run it on my site.
If I have missed solutions to these two issues, I apologize - but would love to know where to find the information if it is available.
I'm not a Javascript expert, but I guess that the following type of situation is what they're trying to avoid:
Imagine a virus which automatically checks whether you have a smugmug site and, if you do, and are logged in, then it silently adds Javascript to your site which triggers all viewers of your site to do some action which makes them infected by the virus.
Smugmug can't even prevent this by asking for your password, because a decent virus will contain a keylogger which can capture your smugmug password. (And this is might be just one of many ways in which the virus might spread.)
Now, there are probably ways in which Smugmug can check javascript for viruses and/or block certain risky types of traffic. However, I get the impression that there might have been some recent incident (perhaps on some other website, or perhaps announced in some security conference) which has made Smugmug put their original plans to allow Javascript on hold until they can assess the situation.
However, I do think that there must be some type of compromise. My suggestion would be to allow a "Javascript Guru" privilege to a limited users, who can submit custom-made javascript to Smugmug. Once they have worked out the bugs in their own pages, these gurus could then have the option to submit these snippets to a Smugmug library of these "user code snippets" which non-Gurus could add to their pages. Registered customisers might have the option of creating their own snippets which could be applied to pages that they customise (not sure how the business model would work...)
Wouldn't a mandatory captcha (a challenge requiring human understanding) prevent automated attempts to stuff javascript into your site even if the virus knew your password?
Wouldn't a mandatory captcha (a challenge requiring human understanding) prevent automated attempts to stuff javascript into your site even if the virus knew your password?
That is precisely what I wondered. And/or some other straightforward security ideas that others have mentioned... I mean, surely there is something. It seems to me, after reading these forums for the past several weeks & paying lots of attention to words from the powers-that-be, that what happened along with the huge site-change is an overly-zealous worry about security. I can appreciate the thought they've given it, & am surely not going to assume there's any ill-will behind it-- I do think SmugMug powers want to keep their site and ours safe. However, a lot of it reminds me of the very over-kill our country has done in these years post-911... overkill in certain areas I mean, while simply overlooking easier, cheaper, & more effective security methods that don't ruin freedom & forward-thinking ingenuity & exploration. It feels like we've been handcuffed or imprisoned in some ways in our own sites, & been told we may be a danger to ourselves. (same case as too often in our country also these days; it's the wrong people/places that are targeted as security issues. Example: I have to stand in long lines at the P.O. because I'm no longer allowed to put my own postage on anything over a pound since heavier packages/more stamps may be dangerous. I myself can think of many better solutions than this!)
I don't want to over-simplify or be naive. I just think that if SmugMug really wants to, & really cares about us the way it should by now, the powers-that-be would give its most creative forces the go-ahead to look for better & less-hampering security methods that wouldn't suddenly remove so much capability from its users and viewers. The whole thing where even site owners can't see passwords, and barely anyone can use Javascript, even the experts such as yourself... surely there are creative thinkers there who could work their way through security concerns & figure out real solutions? If not, I have to ask why, why, why? If they're getting all this influx of newbies, surely they'd have the $$$ to hire a few whiz-bang creative-idea people if they don't have 'em? Otherwise: how will a site with such a dearth of creativity move into the future, if it cannot even find better solutions for these relatively small issues...
My view is it's a very good sign that Fastline has JavaScript and everyone should be encouraged that it means what I said: we're going to work out the kinks with a few understanding customizers first. If you didn't see them with JavaScript and I were in your shoes, I'd take that as a bad sign that things aren't progressing.
Our goal is to make it available beyond the customizers, but we have to do it responsibly. Fastline is helping us work out a reasonable approach but there are many things we haven't solved, such whether we can deploy it for users without their own custom domains. We probably can't.
it's in our interest to enable it if we can because some greater number of customers benefit from the work people like Fastline and jfriend can do. And some of those customers are very high volume in terms of sales.
I'm not a Javascript expert, but I guess that the following type of situation is what they're trying to avoid:
Imagine a virus which automatically checks whether you have a smugmug site and, if you do, and are logged in, then it silently adds Javascript to your site which triggers all viewers of your site to do some action which makes them infected by the virus.
Smugmug can't even prevent this by asking for your password, because a decent virus will contain a keylogger which can capture your smugmug password. (And this is might be just one of many ways in which the virus might spread.)
Now, there are probably ways in which Smugmug can check javascript for viruses and/or block certain risky types of traffic. However, I get the impression that there might have been some recent incident (perhaps on some other website, or perhaps announced in some security conference) which has made Smugmug put their original plans to allow Javascript on hold until they can assess the situation.
However, I do think that there must be some type of compromise. My suggestion would be to allow a "Javascript Guru" privilege to a limited users, who can submit custom-made javascript to Smugmug. Once they have worked out the bugs in their own pages, these gurus could then have the option to submit these snippets to a Smugmug library of these "user code snippets" which non-Gurus could add to their pages. Registered customisers might have the option of creating their own snippets which could be applied to pages that they customise (not sure how the business model would work...)
I haven't delved into this thread, but Andy referred me to this post and it's the most informed thing I've heard so far on this forum.
We chose Fastline because they understand JavaScript security and they would let us review their code.
I can tell you very honestly what the situation is:
- Of course we'd love to deploy JavaScript.
- Several people are threatening to sue me for not including it.
- But more people would threaten to sue me if we included it and there was a security breach.
- No one that we've met has yet been able to come up with a solution to deploy it responsibly, except for PBolchover, which is to employ the method used by WordPress successfully: institute an approval process and include some JavaScript snippets that pass the approval process.
- I've talked to several of you and the interest level in that is low except among the customizers.
I have two very specific issues for the new SmugMug, which is why I'm still on the legacy mode.
1) Full screen slideshow on homepage - Self explanatory. I loved the one I currently have on my legacy site (http://www.RacingHistorian.com) - and want it back.
2) Google Adsense Ads - I use to make almost enough off my Adsense ads in my footer to pay for my SmugMug account. Without javascript, I cannot run it on my site.
If I have missed solutions to these two issues, I apologize - but would love to know where to find the information if it is available.
Thank You.
Thanks, Hylander. The full screen slideshow is in test and my understanding is it has at least one known bug. I don't know how long it will take to fix or how much other testing it still needs, I'm sorry to say, but usually being in test for awhile and being down to one known bug is a good sign.
For Adsense, we're thinking about the best way to do this but have not begun work. We have many very large household-name accounts such as newspapers who depend on Adsense, so this is something we'd love to solve if we can. These sites have IT departments who know the perils of JavaScript security so they'd vastly prefer we built an Adsense app into new SmugMug like we did with WuFoo forms, but we have not scoped it. I'm sorry I don't have more info for you yet.
For Adsense, we're thinking about the best way to do this but have not begun work. We have many very large household-name accounts such as newspapers who depend on Adsense, so this is something we'd love to solve if we can. These sites have IT departments who know the perils of JavaScript security so they'd vastly prefer we built an Adsense app into new SmugMug like we did with WuFoo forms, but we have not scoped it. I'm sorry I don't have more info for you yet.
I'm the one who posted the Adsense block request, and continue to bump that thread for a response.
I am the first to admit I know very little about the risks of JavaScript... BUT... I really fail to see what the risk is with allowing an Adsense block. As far as I can tell, there is no Javascript within the ad code you put on the site. It passes a few simple parameters (Publisher ID, Ad slot ID, width, height) and a LINK to the .js file, which is hosted by Google. Could you not just whitelist that URL? Seriously, if you're worried about malicious code getting into Google's own Adsense system... well, most of the net is screwed if that happens.
This is the entirety of what is added for Adsense (with IDs removed). What danger am I missing?
I
- I've talked to several of you and the interest level in that is low except among the customizers.
The interest is low vs having full javascript.
I suspect if it was that or nothing, it might be a different story.
wrt the dangers of custom javascript - if its such a disaster waiting to happen, can those on legacy sites expect its impending removal too?
- No one that we've met has yet been able to come up with a solution to deploy it responsibly, except for PBolchover, which is to employ the method used by WordPress successfully: institute an approval process and include some JavaScript snippets that pass the approval process.
'responsibly' is very subjective, but if that's the view, I cannot see how Smugmug can say they are still contemplating alternative 'irresponsible' approaches.
I am the first to admit I know very little about the risks of JavaScript... BUT... I really fail to see what the risk is with allowing an Adsense block.
I agree. I'm not sure what hurdles Smugmug would have with this code. Box to type in the parameters, job done. Adding the *ability* to add Adsense is definitely not difficult. The only thing holding it up is a will by Smugmug, either for 'security reasons', which as some of the most used Javascript on the web, must be pretty spurious, or for more political reasons. Can we expect the same tortured process for every javascript feature we request?
Its easy stuff like this, used on millions of websites, is proving to be a struggle, that gives me little confidence that a "let us know what you want and we'll add it for you" model is doomed for anything but failure.
- Several people are threatening to sue me for not including it.
- But more people would threaten to sue me if we included it and there was a security breach.
It's your product, your company, you are the business owner and you control what you want or don't want to offer! I hope people can learn to respect that. That would be childish to sue you for not including javascript in your product:) But you can, and most likely, will be be sued for violating 15 U.S.C. Section 52. Penalties and injunctions in Sec 53, 54, 55.
I agree. I'm not sure what hurdles Smugmug would have with this code. Box to type in the parameters, job done. Adding the *ability* to add Adsense is definitely not difficult. The only thing holding it up is a will by Smugmug, either for 'security reasons', which as some of the most used Javascript on the web, must be pretty spurious, or for more political reasons. Can we expect the same tortured process for every javascript feature we request?
Its easy stuff like this, used on millions of websites, is proving to be a struggle, that gives me little confidence that a "let us know what you want and we'll add it for you" model is doomed for anything but failure.
That is exactly my concern. Hearing things like "we want to, but have not yet begun work" on something like Adsense, which really should take ONE developer a few minutes to implement. And if allowing Adsense to be run is a security risk, then I guess that means millions of very popular websites are at risk of being hacked... give me a break, seriously.
In a perfect world, us asking for things to be implemented by SM would be fine. In the real world, where new feature additions to SM have historically been measured in YEARS, it's not practical. Again, Adsense would take minutes. Talking about company IT departments, and their concerns about Adsense security, makes me think A) someone has no idea what they are talking about or are just making excuses not to implement a VERY simple feature request.
In the meantime I am losing large amounts of income I have always relied on. Thanks a lot SM. If you can't do Adsense, I don't see why anyone should ever expect you to add anything. It doesn't get easier.
... which really should take ONE developer a few minutes to implement...
Sir - I'd fire a developer who told me it will take him a few minutes to implement something into production, along with his manager who would allow this to happen:) Failure to plan is a plan to fail.
Sir - I'd fire a developer who told me it will take him a few minutes to implement something into production, along with his manager who would allow this to happen:) Failure to plan is a plan to fail.
Whatever. You know very well what point I was making. This is a very simple thing to do. If it's being portrayed as hard, then I/we have very little hope of ever seeing JS-based feature requests be added in a timely manner.
Thanks, Hylander. The full screen slideshow is in test and my understanding is it has at least one known bug. I don't know how long it will take to fix or how much other testing it still needs, I'm sorry to say, but usually being in test for awhile and being down to one known bug is a good sign.
For Adsense, we're thinking about the best way to do this but have not begun work. We have many very large household-name accounts such as newspapers who depend on Adsense, so this is something we'd love to solve if we can. These sites have IT departments who know the perils of JavaScript security so they'd vastly prefer we built an Adsense app into new SmugMug like we did with WuFoo forms, but we have not scoped it. I'm sorry I don't have more info for you yet.
Thank you for responding, and hopefully the slideshow will be ready "soon"
As for the second issue with Adsense, if it's true you have these large customers who rely and depend on it, shouldn't this have been something you have "scoped" and/or planned for BEFORE the launch of the new system? I'm really glad I didn't launch my "new" site by being dazzled with the pretty new interface without first thoroughly exploring all the options and discovering all the limitations compared to the old system. For something along the lines of Adsense, I have no problem if it were 'built in' like the WuFoo forms - as long as it's there to be used and implemented on our sites. I'm sure you all have your plates more than full with requests of the new system, but I do hope you begin looking at this shortly.
Similar to Adsense, PayPal / Self-fulfillment options are being used on countless sites throughout the web also.
With PayPal being in the $$$ business wouldn't they be pretty vigilant about their operations regarding JS.
Now I'm far from Johnny Technology as it were, but with this seemingly urgent concern over JS security now being manifested how is it that SmugMug could have somehow managed to not have a single issue up to now???
Bearing in mind any of us could have added virtually anything in the JS options we so desired over like the last... what is it now...like about10 years or so???
What am I missing?
Either way I'm willing to accept that danger is lurking just around every corner and for the greater good SmugMug will in fact protect us all.
But the thought that some of these can and should be implemented in the methods being proposed already is encouraging enough for me to stick around - I just can't / won't unveil without some sort of PayPal option available...
how is it that SmugMug could have somehow managed to not have a single issue up to now???
Bearing in mind any of us could have added virtually anything in the JS options we so desired over like the last... what is it now...like about10 years or so???
What am I missing?
And, for those not switched over from legacy, still can add anything in the jS options. I wonder if the Smugmug lawyer team have been looking for something to do since the patent wars and have come up with this 'if you don't do x you'll be sued' list...
The "Advanced Customizers" will have access to do JavaScript applications, but you and I will not. As of now, though, SM hasn't turned them on to do it for clients. We'll have to sit tight a bit into this roll out and see what happens
Who said they couldn't? They've been running custom JavaScript components on their sites since literally day one of New SmugMug.
So are others. The guy who hacked the collage gallery on old smugmug has a version running on new smugmug. Note that his collage layout actually makes images large enough to be visible and has reasonable line breaks. In other words, it doesn't suck, unlike the current smugmug implementation: http://www.sherlockphotography.org/Other/Montage-thumbnails-example/n-FzQnB
He can probably fix the width between photos too, because he controls the layout. We can't do that. We can adjust the gallery thumb spacing, but nothing about the gallery itself.
Haha, that's my site. The difference is that SmugMug provides the support for Fastline to do it, and it only works on my site due to a dodgy hack.
I did a side-by-side comparison, and my layout actually ends up being almost identical to the SmugMug one, except I always finish the gallery with a nicely filled row instead of SmugMug nearly always ending on 1 or 2 photos left over. A lot of the difference is due to the fact that I'm willing to crop photos to make them fit better, which allows for more evenly-sized rows (though if you add borders to your own photos, that will make them look terrible).
Comments
Thanks - I know I come across frustrated, because I really really am frustrated. I don't know whether I'll end up having one months notice to dump SM and move to Zenfolio, or whether I'll only be up for dozens of hours rebuilding my site on SM at some stage.
I think that's the key frustration - even with all the best will in the world, at the moment it's TOTALLY UNCLEAR as to whether SM will ever support what I need for my site, and if it will support it continuously (through the legacy site remaining usable until the capability is delivered on the new site)
Until those unknowns are cleared up, I will remain upset with Smugmug for proposing to remove important functionality from the service offering.
How about asking the bosses if there's any chance they can make a clearer statement about these please? How about updating us on these topics? I note my bumps in the feature request topic asking for updates have been ignored.
Cheers - N
http://www.nzsnaps.com (talkiet.smugmug.com)
No problem. I understand, and you can always vent to me...that's what I am here for. I know this consumes alot of time upstairs, so I promise you when we have more information about the future of JS, Baldy will personally come in and make it known.
Facebook
Google+
Twitter
Photo Blog
Well, I sure as hell don't have access to any JS on customized sites. I guess SM is only allowing special people to customize sites now, and since Don hates me, I'm out in the cold.
No worries though; SM is dying -- and spending money to customize SM is like throwing your money down the drain.
Twitter: @WolfSnap
Facebook: http://www.facebook.com/WolfSnapDesigns
SmugMug & Wordpress Customization - WolfSnap.com | Custom Domains
I get it that there's been a support overhead for Smugmug when it comes to javascript. But beyond supporting the embedded design functionality of Smugmug-hosted websites, I've never expected Smugmug to be responsible for how badly I fubar my website using tools that are above and beyond those explicitly provided (as opposed to, allowed) by Smugmug. The Smug hero help with javascript, CSS, etc., has always been appreciated, but I've never construed it to be obligatory. I've only ever bothered Smugmug support with problems related to core functionality. For everything else, there is Dgrin and the wonderful, amazing volunteers such as jfriend, Allen, and so many others.
That seems like a very reasonable line of demarcation for what Smugmug's help desk should be expected to support.
But now it appears that under this new regime of drastically limiting customization, my website will become much more a Smugmug site and much less my site. That's not what I signed up for.
- Dave
www.djdigitaldave.net
Imagine a virus which automatically checks whether you have a smugmug site and, if you do, and are logged in, then it silently adds Javascript to your site which triggers all viewers of your site to do some action which makes them infected by the virus.
Smugmug can't even prevent this by asking for your password, because a decent virus will contain a keylogger which can capture your smugmug password. (And this is might be just one of many ways in which the virus might spread.)
Now, there are probably ways in which Smugmug can check javascript for viruses and/or block certain risky types of traffic. However, I get the impression that there might have been some recent incident (perhaps on some other website, or perhaps announced in some security conference) which has made Smugmug put their original plans to allow Javascript on hold until they can assess the situation.
However, I do think that there must be some type of compromise. My suggestion would be to allow a "Javascript Guru" privilege to a limited users, who can submit custom-made javascript to Smugmug. Once they have worked out the bugs in their own pages, these gurus could then have the option to submit these snippets to a Smugmug library of these "user code snippets" which non-Gurus could add to their pages. Registered customisers might have the option of creating their own snippets which could be applied to pages that they customise (not sure how the business model would work...)
On one hand I am very much frastraded (as I stated in some other threads) about the removal of JS. I agree with many and with John (jfriend) - there is no way for anyone to list all the feature we want/need. We simply do not know. That is what the programming language (JS) is here for. I want to be able to address MY needs as they come when they come and not pay Fastline for something I can easily do.
At the same time, being in the software development industry and understanding not only pure development portion of it but also a management part of the whole thing - I can see the dilemma a business (SmugMug) is presented with. Michael, you keep asking to list features? ok. I want two right now:
1) ability to make side bars sliding (as on my website, you know what I am talking about.) I doubt you can easily duplicate the full functionality of my sliding side bar... but even simple, single sliding sidebar would be ok for now.
2) content block (or whatever the internal name is) to type the name of the folder, gallery, page and be redirected to it. The same as on Fastline template in the Client section.
Please, move the above two request in whatever place they need to be. But I have a terrible feeling that at the end JS will not be here in SM anymore and these features will not be implemented as well. Why do I have this feeling? Because I think that SM is simply changing business model. I hope I am wrong. I honestly feel bad for Michael B. who is thrown here to defend the SMugMug reputation and provide whatever support he is allowed to. People, please realize - regardless how much we all vent out here and "scream" - Michael will NOT tell you "yes" or "no". I am glad he tells us anything:)
I really, really don't think that anybody would bother to write a virus like that to target such a miniscule portion of the Web. It'd be a complete waste of time. Posting links to people's Facebook walls would give a much better rate of return, given that the chance of any random computer being logged into Facebook is many orders of magnitude higher than being logged onto SmugMug.
Not to mention the fact that SmugMug supporting JavaScript doesn't really make that situation any worse. All a virus would have to do is add a link to the page "click here to view my price list" which leads to an infected PDF, no JS required. I don't think this possibility factors into SmugMug's risk planning at all.
I imagine one of their big concerns is developers' servers that are hosting JS which is embedded into SmugMug sites being subverted, which could have easily happened on Old SmugMug. If you hotlinked to a developer's copy of a JS customisation using a <script> tag, then an attacker only needs to breach that developer's server to simultaneously hit every SmugMug page that uses that JavaScript customisation. The attacker could then do things like make the Checkout button redirect to their own form which just sends the credit card details straight to them (the browser's address bar would reveal this deception, but only to very keen-eyed users).
A curated customisation repository basically avoids this issue, but requires a large development effort on the part of SmugMug to create, so it definitely won't be just around the corner.
Please check out my gallery of customisations for the New SmugMug, more to come!
Really, what are the reasons for removing JavaScript. Malicious code? Implement the above or a 'Report Site' button? Your users removing your copyright at the bottom? Check my site, I've already manipulated it (well removed it, and added my own). Your SmugMug Heros don't want to handle support tickets for JavaScript? Just make it an 'Unsupported' feature in SmugMug, and refer them to these forums to get help of fellow SmugMuggers like Dave mentioned. I can't really think of others to hand. It doesn't make sense to remove it.
The reason I stuck with SmugMug is customization. If there is no good customisation, why should I stay with them?
Mel Jones Photography Ltd.
School and Nursery Photographer working in Blackpool and Lancashire, UK.
Google+ Page / Local | Facebook Page
Hi Michael, Smugmug have also already demonstrated that what are simple fixes, like adding Google+ +1s (http://www.dgrin.com/showthread.php?t=237601) . can also easily fall by the wayside if they're not deemed important enough. Its two lines of code for us to add in Javascript. (just my particular pet peeve, I'm sure that we all have stuff we'd like to bump up the list of changes, and I'm not suggesting this should be priority 1)
I don't doubt Smugmug's sincerity, I do doubt their ability to quickly react to changing needs of their clients compared to them being able to add the thing themselves.
Its great that the new smugmug infrastructure can speed up feature request implementation. However, having previously measured feature request implementation in years, I'm not confident that even now the smugmug team are able to implement requests quickly enough to meet our needs, and look forward to the time when I'm once again able to just add the code myself.
I'd take a moderated javascript box (assuming its not madly restirctive, and either pre-moderated, or preferably post-moderated); a few written guidelines as to what is and isn't acceptable in javascript would probably be easy to follow by most, and might give us a better idea of what Smugmug's issues with JS are.
Additionally, as a counter-offer to "tell us what you'd like to use Javascript for", can I suggest that you extend the javascript authorised customers to include some of the javascript experts on here, like jfriend, and see if there are issues with the code they'd like to add to their site. I'd also suggest that seeing what people actually use it for is probably more accurate than asking people to list what they would use it for.....
1) Full screen slideshow on homepage - Self explanatory. I loved the one I currently have on my legacy site (http://www.RacingHistorian.com) - and want it back.
2) Google Adsense Ads - I use to make almost enough off my Adsense ads in my footer to pay for my SmugMug account. Without javascript, I cannot run it on my site.
If I have missed solutions to these two issues, I apologize - but would love to know where to find the information if it is available.
Thank You.
Hustedia.com
Husted Visuals
The Racing Historian
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 don't want to over-simplify or be naive. I just think that if SmugMug really wants to, & really cares about us the way it should by now, the powers-that-be would give its most creative forces the go-ahead to look for better & less-hampering security methods that wouldn't suddenly remove so much capability from its users and viewers. The whole thing where even site owners can't see passwords, and barely anyone can use Javascript, even the experts such as yourself... surely there are creative thinkers there who could work their way through security concerns & figure out real solutions? If not, I have to ask why, why, why? If they're getting all this influx of newbies, surely they'd have the $$$ to hire a few whiz-bang creative-idea people if they don't have 'em? Otherwise: how will a site with such a dearth of creativity move into the future, if it cannot even find better solutions for these relatively small issues...
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
We chose Fastline because they understand JavaScript security and they would let us review their code.
I can tell you very honestly what the situation is:
- Of course we'd love to deploy JavaScript.
- Several people are threatening to sue me for not including it.
- But more people would threaten to sue me if we included it and there was a security breach.
- No one that we've met has yet been able to come up with a solution to deploy it responsibly, except for PBolchover, which is to employ the method used by WordPress successfully: institute an approval process and include some JavaScript snippets that pass the approval process.
- I've talked to several of you and the interest level in that is low except among the customizers.
For Adsense, we're thinking about the best way to do this but have not begun work. We have many very large household-name accounts such as newspapers who depend on Adsense, so this is something we'd love to solve if we can. These sites have IT departments who know the perils of JavaScript security so they'd vastly prefer we built an Adsense app into new SmugMug like we did with WuFoo forms, but we have not scoped it. I'm sorry I don't have more info for you yet.
I'm the one who posted the Adsense block request, and continue to bump that thread for a response.
I am the first to admit I know very little about the risks of JavaScript... BUT... I really fail to see what the risk is with allowing an Adsense block. As far as I can tell, there is no Javascript within the ad code you put on the site. It passes a few simple parameters (Publisher ID, Ad slot ID, width, height) and a LINK to the .js file, which is hosted by Google. Could you not just whitelist that URL? Seriously, if you're worried about malicious code getting into Google's own Adsense system... well, most of the net is screwed if that happens.
This is the entirety of what is added for Adsense (with IDs removed). What danger am I missing?
The interest is low vs having full javascript.
I suspect if it was that or nothing, it might be a different story.
wrt the dangers of custom javascript - if its such a disaster waiting to happen, can those on legacy sites expect its impending removal too?
'responsibly' is very subjective, but if that's the view, I cannot see how Smugmug can say they are still contemplating alternative 'irresponsible' approaches.
I agree. I'm not sure what hurdles Smugmug would have with this code. Box to type in the parameters, job done. Adding the *ability* to add Adsense is definitely not difficult. The only thing holding it up is a will by Smugmug, either for 'security reasons', which as some of the most used Javascript on the web, must be pretty spurious, or for more political reasons. Can we expect the same tortured process for every javascript feature we request?
Its easy stuff like this, used on millions of websites, is proving to be a struggle, that gives me little confidence that a "let us know what you want and we'll add it for you" model is doomed for anything but failure.
It's your product, your company, you are the business owner and you control what you want or don't want to offer! I hope people can learn to respect that. That would be childish to sue you for not including javascript in your product:) But you can, and most likely, will be be sued for violating 15 U.S.C. Section 52. Penalties and injunctions in Sec 53, 54, 55.
That is exactly my concern. Hearing things like "we want to, but have not yet begun work" on something like Adsense, which really should take ONE developer a few minutes to implement. And if allowing Adsense to be run is a security risk, then I guess that means millions of very popular websites are at risk of being hacked... give me a break, seriously.
In a perfect world, us asking for things to be implemented by SM would be fine. In the real world, where new feature additions to SM have historically been measured in YEARS, it's not practical. Again, Adsense would take minutes. Talking about company IT departments, and their concerns about Adsense security, makes me think A) someone has no idea what they are talking about or
In the meantime I am losing large amounts of income I have always relied on. Thanks a lot SM. If you can't do Adsense, I don't see why anyone should ever expect you to add anything. It doesn't get easier.
Sir - I'd fire a developer who told me it will take him a few minutes to implement something into production, along with his manager who would allow this to happen:) Failure to plan is a plan to fail.
Whatever. You know very well what point I was making. This is a very simple thing to do. If it's being portrayed as hard, then I/we have very little hope of ever seeing JS-based feature requests be added in a timely manner.
Thank you for responding, and hopefully the slideshow will be ready "soon"
As for the second issue with Adsense, if it's true you have these large customers who rely and depend on it, shouldn't this have been something you have "scoped" and/or planned for BEFORE the launch of the new system?
Thanks again for your time.
Hustedia.com
Husted Visuals
The Racing Historian
With PayPal being in the $$$ business wouldn't they be pretty vigilant about their operations regarding JS.
Now I'm far from Johnny Technology as it were, but with this seemingly urgent concern over JS security now being manifested how is it that SmugMug could have somehow managed to not have a single issue up to now???
Bearing in mind any of us could have added virtually anything in the JS options we so desired over like the last... what is it now...like about10 years or so???
What am I missing?
Either way I'm willing to accept that danger is lurking just around every corner and for the greater good SmugMug will in fact protect us all.
But the thought that some of these can and should be implemented in the methods being proposed already is encouraging enough for me to stick around - I just can't / won't unveil without some sort of PayPal option available...
Member: ASMP; EP; NPPA; CPS
And, for those not switched over from legacy, still can add anything in the jS options. I wonder if the Smugmug lawyer team have been looking for something to do since the patent wars and have come up with this 'if you don't do x you'll be sued' list...
It looks like they can now.....
ref http://www.billmccarroll.com/
Please check out my gallery of customisations for the New SmugMug, more to come!
So are others. The guy who hacked the collage gallery on old smugmug has a version running on new smugmug. Note that his collage layout actually makes images large enough to be visible and has reasonable line breaks. In other words, it doesn't suck, unlike the current smugmug implementation: http://www.sherlockphotography.org/Other/Montage-thumbnails-example/n-FzQnB
He can probably fix the width between photos too, because he controls the layout. We can't do that. We can adjust the gallery thumb spacing, but nothing about the gallery itself.
I did a side-by-side comparison, and my layout actually ends up being almost identical to the SmugMug one, except I always finish the gallery with a nicely filled row instead of SmugMug nearly always ending on 1 or 2 photos left over. A lot of the difference is due to the fact that I'm willing to crop photos to make them fit better, which allows for more evenly-sized rows (though if you add borders to your own photos, that will make them look terrible).
Please check out my gallery of customisations for the New SmugMug, more to come!