When everyone's sales slip due to the down economy, companies (and individual sales reps) are desperate to make their numbers.  How are they doing it?  By trying to jack up maintenance costs, in some cases by more than 100%!  It's way more than isolated incidents; all our maintenance renewals coming up are meeting with hugely inflated quotes.  And not fly-by-night companies either, I don't want to name names but let's just say I am confident everyone out there has heard of all of them.

So protect yourself.  In your dealings with your supplier reps, start making it clear way ahead of time that your economic situation sucks too and you certainly expect that there's a price freeze in place.  Don't put up with it either - they know they're going to make plenty of money off all the goons they send quotes to who will just rubber-stamp it and send it on so they can return to ESPNZone (I'm looking at you, State of Texas).  If you put up enough resistance they'll go looking for easier pickings, just like those mean ol' wolves do.    We had one outfit that wanted to jack up our maintenance cost by $125k a year, but luckily our IT director is a firm lady who has no problems with browbeating a sales rep until he cries.  In the end, we let them have a 5% increase because we ended up feeling sorry for them.

And have a backup plan.  If they really do have you over a barrel, then you're low on leverage - you can try offering reference calls, presenting at conferences, and other handy non-cash incentives to them.  But when it comes down to it, you need to be able to walk away from them.  And to do this you need to plan ahead.  There are very few things that there's only one of.  Have multiple suppliers lined up, and have a plan to change hardware or software if you have to.  Also look into open source, or third party support - even if it's "not as good," these days you have to decide how much good is worth how much money.

Now don't get me wrong, we like to partner with our suppliers and treat them friendly.  Win-win and all that.  But good fences build good neighbors, and there's nothing friendly about showing up and saying  "Hey, your operations will grind to a halt without our product, so stick 'em up and give me double this year!"

Be advised, that gleam in Bob the Sales Rep's eyes will be a little hungrier than usual these days, and he's gotta eat one of God's little forest creatures to live.  Just make sure it's not you.

Jeremiah started off with a brief introduction on what clickjacking is.  In a nutshell, it's when you visit a malicious website and the attacker is able to take control of the links that your browser visits.  The problem affects all of the different browsers except something like lynx.  The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you.  It's a fundamental flaw with the way your browser works and cannot be fixed with a simple patch.  With this exploit, once you're on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.  "A normal user wouldn't have any idea of what is going on.  People in this audience may see something a little different from what they would expect and you would definitely see the results in the page's source code."  Ebay, for example, would be vulnerable to this since you could embed javascript into the web page, although, javascript is not required to exploit this.  "It makes it easier in many ways, but you do not need it."  Use lynx to protect yourself and don't do dynamic anything.  You can "sort of" fill out forms and things like that.  The exploit requires DHTML.  Not letting yourself be framed (framebusting code) will prevent cross-domain clickjacking, but an attacker can still force you to click any links on their page.  Each click by the user equals a clickjacking click so something like a flash game is perfect bait. The issue and fix will probably be originally released on http://ihackcharities.org.

My Analysis: It sounds like the exploit basically creates a frame that is hidden underneath the main content frame that a user is seeing.  The main content could be a flash game or any sort of incentive to keep a user clicking.  All of the clicks that the user is making are used to click on content in the hidden frame. Again, just my speculation based on the information provided by RSnake and Jeremiah above.

Here's some things to keep in mind when selecting a SaaS vendor, laced with real life horror stories from our experiences.

1.  Performance/Availability.  Set a hard performance/availability SLA in the contract.  Many vendors won't even have an SLA clause, or they'll have one that says "99.9% uptime!" without any remedy clause for what if they don't hit that.  You want a clear SLA with a clear measurement method and clear "money back" if they don't hit it.  We use a 2 second global performance SLA as measured by a Keynote Global 35 monitor.  But the SLA isn't the whole story - you are counting on these people to accomplish your goals.

True story.  We did an implementation with a new SaaS supplier.  Everything looked fine but the team had not done performance testing.  With only a week to go live, they finally loaded in a full set of data into the system and saw performance that was horrible, clearly in the ~30 second page load time even in the US (much worse internationally).  But it isn't as simple as "Oh, you're not hitting the SLA, goodbye..."  We have months of time invested in this supplier.

2.  Privacy policy.  Make sure you know what they're going to do with your user data they collect and make sure that matches what your privacy policy says.  We're international and so have to abide by a fairly restrictive EU-compliant privacy policy.  Many SaaS vendors don't know what exactly that entails, and so can run you afoul - remember, you're legally responsible for your site whether you've outsourced parts of it or not.

3.  Security.  One, if you have compliance concerns like PCI etc. you need to make sure they're complaint as well, and certified as such by an auditor (don't take "Oh, yeah, we're PCI complaint" at anyone's word).  Two, you are almost certainly going to have to exchange user credentials, so a user can log in across you site and the SaaS site with the same login, and the "right ways" to do this, like SAML, are supported by about one tenth of one percent of SaaS vendors.  You need to carefully review how you're going to do it to avoid security problems.

4.  Contingency plan.  Companies go out of business, or the relationship between them degrades.  You have to have a plan in place for when your SaaS vendor dies, gets bought by HP and has their price quadrupled,or you decide you hate each other, or the cost isn't what you anticipated (see point 5 below).   You need some of this in your contract - in any event, you get your data andif they are dying, a perpetual license to their software.  (If you're really lucky it's one of these firms that has a software package and an ASP version both.)

True story.  Our ni.com forums were hosted for many years by a company called QUIQ.  In the big bubble bust, they went down and had the revenooers show up to unplug them.   We were very lucky in that they were interested in helping us despite their own problems, and that we had bad ass technical folks on staff.  We paid to have a QUIQ engineer come down and load up their forum software on our systems (and this wasn't a bundled software solution, it was their internal-only stuff) and transition our data over.  We then supported this as our forum solution for a couple years, often having to take measures like decompiling the Java to make changes.   But that was better than being dead in the water.  Now with our new forums vendor, we do things like get regular backups of our data, gateway the forum to NNTP, etc.

5.  Cost.  SaaS vendors almost universally charge you by usage.  Which is "fair" - but the Internet is a wild place.  What about when that new Chinese experimental spider (soso, you suck!) decides to grant you a couple hundred thousand extra page views one day?  You get stuck with the bill.  Corporations have to be able to budget for their expenditures, and there is risk in thsi business model that one time events and/or unexpected growth will fundamentally alter your cost and ROI structure.

There are several potential mitigations here.  One is to get a SaaS vendor that implements throttling, so you can meter back untoward amounts of traffic.  Another is to have specific payment scales that mitigate this- you want to avoid "cell phone" type plans that give you a certain amount and then an abusive overuse charge like the plague.  Look for plans like ISPs, where you pay for the 90th percentile peak of traffic, for example.  Or have a prepay agreement, and/or specify what kinds of traffic you'll pay for.  (On many Internet sites, spiders account for 30% or so of the traffic and thus the expense.)

6.  Quality.  Do a pilot/proof of concept.  DO ONE!!!  A SaaS vendor is not yet a commodity in most areas.  You are getting as deep in bed with them as if you bought hardware and software and in house programming.  Don't sign the contract until you have seen it work for you.  Build deliverables and payment schedule into the contract - "You get 1/3 upon requirement completion, 1/3 upon signoff of a test version, and 1/3 upon go live" is popular.  We have one purchasing agent who likes to push "Sign the contract, and have a 30 day 'out' clause if things don't go well."  But this ignores the deep investment into even a SaaS vendor (and the fact that most implementations aren't fully baked in 30 days).  As a result, we have several business units even now signing up with ASPs without doing a formal pilot, and every one of them will come to regret it bitterly.  Only the rich and the idiotic buy a car without a test drive and a mechanic checkup.  Any SaaS solution will be much more expensive than any car.

None of this is to say that SaaS is bad or should be avoided.  But it needs to be evaluated just like any other solution.  Is the 5 year TCO really better than in house, not just the first year cost?  And does it really do what you need - functionality wise, but also in the areas of performance, security, and these other areas which make your functionality meaningful to the users?  If you can't answer these questions, you are betting a lot of money and your reputation on an untried horse.  Find out the answers.