Forum Moderators: buckworks
We did the a/b split test to "prove" it was of value to us. While that showed us on paper that it was worth it we can see by the sheer volume of orders post implementation that it was worth it.
and when the salesman gave me the line:
if you had the cure for cancer, wouldn't you share it with everybody - i just hung up.
i don't in any way dispute their claims, on the other hand i've had a site freeze on me because the page was waiting for the mcAfee server to serve the 'safe' symbol - more than once, but then again maybe they have sorted that issue out by now.
I may test it on other industry sites though. Ask them about their 30 day guarantee. They said that if I didn't see an increase in conversion rates, I could cancel and get a full refund if I did so in less than 30 days.
[informationweek.com...]
We did it more for the recogonized seal and increased conversions. Unfortunatly we do not have conversion data yet because our market has taken a dip recently with all the stuff going on in the economy so it is hard to guage increased conversions because of the seal when order volume is generally dropping due to the economy.
We still said no.
Someday we will use photoshop to make an official looking seal.
Seriously, if your site already shows trust by having a 800 number, physical address, SSL logo, etc; you don't need all these expensive feel good trust seals.
Design your site right, and you won't need to buy trust.
I used to be dead set against Secure Seals, especially that old Hacker Safe logo. I even used to write against them, along the thoughts that it probably encouraged hackers.
Though I bet that the new McAfee Secure seal probably does increase conversions by a small amount, I think that a 12% increase in sales MUST be well above the norm - but if that's true than we could see a six figure increase in sales. That makes the initial investment seem very minimal.
What have others seen through split testing? 1%, 3%, 5%?
Therefore they can never catch errors that are generated on the server end when certain parameters are passed and target the specific web application or shopping cart. At the same time, attackers, when they deploy bots checking for vulnerabilities, are way more effective because they check software versions, server versions and other stuff like modules deployed with popular shopping carts.
End result is, these tools may do more damage, if a merchant ignores some basic facts and totally rely upon them. Facts like upgrading the server software, shopping cart code, etc. For some shopping carts, there are dedicated tools that check for weaknesses and can give you information on flaws from the server end.
Also lots of the errors reported from tools like hackersafe, refer to the host exclusively and not to the shopping cart code. If you're on a dedicated server you may be able to add the patches and get around it. But if you are on a virtual or shared host, good luck convincing the host to do upgrades.
To give you an example, if your shopping cart s/w was using a variable $xyz, that was not exposed with the reviews form you mentioned and within the script you were doing something like
$xyz = $_GET['xyz'] followed by a dbase update, then those tools do not see anything. In other words a million things can happen on the server end for a request and the hackersafe won't have a clue because nothing will be send back by the server. However an attacker knows about the script specifics.
So it's best to keep your web s/w fully updated from the vendor and monitor the modules you have integrated, if any, for updates.
As I mentioned unless you're on a dedicated server, you don't have much choice but to either use the server s/w the host sets up for you or change hosts. There are separate issues that can happen from the PHP, MySQL, Apache, etc versions and different from the shopping cart s/w.
I agree it is best, not even best but critical to keep your s/w updated with the vendor.
I am not on a dedicated server, but when mcafee has found server specifics my host has updated the server within days to help keep my site PCI compliant.
how would an attacker know of the script specifics?
Once this is determined he can get the source code of the application and now he knows the weaknesses between different versions of the s/w (btw these are documented by the vendor). So if your reviews script has a problem is not even necessary to figure out what additional module the site has on.
Also many of the popular carts are open source so the code is widely available as well as the various modules or plugins. For closed source carts, it's a bit harder to acquire the code but it's still possible. Or he can visit sites like secunia where it contains a vulnerability database and then he starts applying the various documented hacks at every level. Server s/w, application, cpanel etc. Because if he knows the site he knows the host, may also know the server version etc from the headers.
Unless you have developed your own custom cart in which case yea it can be quite secure from the application point.
So in my opinion it is way more important to keep the s/w updated, than relying on some other tool that operates at the html level to figure things out.
