I guess when you compete with other companies, sometimes the easiest way to do so is to spread false information about your competitors. In the industry, this is known as FUD: Fear, Uncertainty and Doubt.

One of our potential customers was kind enough to forward us some FUD they received from a competitor. It was good for a laugh, so I will share it with you below. The only problem I see with this tactic is that it just may work if someone is inclined to blindy accept somebody else’s statements as fact. But hey, that is how the world works.

> I saw your note about SmartFile. I think they have some great features,
> and the price is great.

Thanks! Well, at least things start out civil enough.

> I’d only caution you, if you’re going to use this for law firms, that their
> security is almost non-existent and you can only beef it up a bit with their
> optional fob/key.

Hmm, we’re starting to move into the FUD realm. We happen to have many law firms using our product. We put a lot of effort into ensuring our customer’s data is safe in our system.

And it is totally true that you can increase the security of our system greatly by using our optional SmartKey. Two-factor authentication of this form is not without it’s flaws, but overall provides a boon for security.

> They only use assignable passwords and their system allows you to create
> passwords with as little as 3-bit protection. They also store passwords in
> an accessible database, and they can be retrieved by an admin. Not best
> practices.

OK, yes, our system allows you to assign your own passwords. I think that is pretty standard. This allows you to choose your own level of security.

Here I can wax philosophical and point out that the last time I checked, a pistol aimed at a foot would indeed fire. Also, I am pretty sure they have not yet finished installing the handrails on the north face of Everest. My point is that we provide the means of securing your data, but if you want to use the password ‘123’ who are we to stop you?

However, I am a bit confused as to what 3-bit protection is. Our bytes are 8 bits like everybody else’s.

And that last statement about storing passwords in an accessible database is patently false. We like our passwords hashed with a bit of salt thank you very much!

> Their API does not protect the password on pass-through well.

Huh? As far as I know, we don’t yet offer an API to the public. Look for our new API and API documentation in our next release! I can assure you that it will protect your password as completely as possible.

> There’s no proxy file system to protect file access; the application is
> running on the same server(s) as the files are stored on. You’re pretty
> much looking at your files when you view them in their interface.

I will choose to take this as a compliment, be it never so false. I can only laugh at the idea that our customer data is stored directly on our webservers. That would be a fairly difficult architecture to maintain. Our customer data is stored on a dedicated storage server farm and accessed through a custom data access layer. This ensures that you see your data and only your data. However, we apparently did our job well if “You’re pretty much looking at your files when you view them in our interface.”

> The only other negative I know about them is there are file/mime types
> that won’t upload to their sites. I’m not sure why if they’re using octet
> streaming to transfer files (they should all be binary to them, even
> portable dir files) but they could be reading files in line-by-line, vs.
> byte-by-byte. But that’s only a guess and it’s highly unlikely. Non-adobe
> PDFs would corrupt about 20% of the time using a line-by-line read in as
> would XML files. it could also be the java applets and Flash components
> required to be installed on the local CPU in order to upload. I believe
> there are mime type limitations with client-side uploads. Many of their
> features are client-side and dependent on config/app integrity on the
> local CPU.

I guess I don’t really understand this statement. Our file uploads are handled using either regular HTTP multipart-form POST or a Flash component. The Flash component uses the ActionScript FileStream class for performing the upload. If there are problems with these standard methods of performing uploads, I guess we should contact the IETF and Adobe.

On the other hand, if anybody’s files are being corrupted in our system, please let us know, we will get right onto fixing that issue. As of today, nobody has reported any such problem to us.

In conclusion, I have to thank this unknown contributor for giving me something to blog about. Further, it validates all of our hard work when others throw sticks and stones at us.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on RedditBuffer this pagePrint this pageEmail this to someone

Related Posts

Related Topics & Tags: General Information

About Brian Dowden

I am the Director of Client Services at SmartFile. My job is to make sure customers are happy with the SmartFile Web App and continue to use it. I am also responsible for being awesome 100% of the time. So far my record is flawless.

Leave a Reply

Your email address will not be published. Required fields are marked *