May 15, 2010 at 11:35 am
Comments posted to this topic are about the item Precious Ideas
May 15, 2010 at 6:39 pm
I don't believe people encrypt their stored procedures to keep anything proprietary secret because, as you've so very adequately noted, just about everything that can be done in SQL Server has been done already.
But I'll bring up the recent bouts with plagarizm that some of the articles on this fine forum have gone through on other sites... people are lazy and greedy. If they can steal something instead of building it themselves, they will. Encrypting code will at least make them jump through a hoop or two to support their "new" product. It will also keep the number of stupid user tricks in the form of code modifications to a minimum.
I personally don't like encrypted code either on the vendor or user ends, but I can see its merits.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2010 at 12:32 pm
I guess I'm just not sure that encrypting really helps prevent theft of ideas. And it makes it entirely likely that you'll deploy the wrong version of something sometime because you can't easily see what's there.
I still think it's a feature to be removed.
May 16, 2010 at 7:34 pm
Oh no... I understand what you're talking about and I wasn't talking about theft of "ideas"... I was talking about outright theft of code (just like plagarism) to actually start a business on or to charge money for. For example, I may have a great way of converting a large dataset like the national and international call system information (either from Telcordia or CCMI... all country codes, city codes, area codes, exchanges, distance info, LEC ownership, tariff info, etc, etc) into normalized tables. While I'm absolutely sure that I'm neither the first nor the best in the world to do such a thing, it does work well and I wouldn't want someone to just copy the code to start a new business with especially if they opened up as a competitor. If they didn't have such code stolen from the clear code our company built, maybe they couldn't find such code from some other source and never become a serious competitor.
As a side bar, I've run into a couple of competitors and worked for a couple of companies that have their own version of code to do the same thing. They'll never be serious competitors with my old company because it takes them 24 hours just to render phone bills for a lousy 90,000 customers and that DIDN'T include collecting the CDR's (call detail records). They also have an IT staff of a couple dozen not to mention the Billing and Finance staff to support it all.
The code I wrote (all of it DOS batch and T-SQL) would do everything from collecting the raw CDRs from multiple sources (FTP, Modem Download, AND a 3 reel physical tape change) to the final rendering of bills for 500,000 customers... in less than 6 hours... on an old 450Mhz P3 w/512 K of RAM... and we only had two people in IT... and we had a (i.e. ONE) part time CPA as our Billing and Finance department.
I agree... my code isn't a new idea but I really wouldn't want to share that code with anyone by accident if I installed that code at a customer site. Encryption can help in that area.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2010 at 12:25 am
I'm with Jeff on this one. I've written some pretty hair-raising stuff that I still suspect to this day might be a first, and liable for some pretty serious commercialisation one day (if I ever get a minute ... sigh). It's smart code, not big code.
Like Jeff, I think it's worth protecting from competitors, not customers. The main beef in the article you referenced was that the ISV's customers had their own IT sections who could not access the SPs to improve them, a situation which could not be further from the truth for MY customers.
On the other hand, if, like someone mentioned, the MSSQL encryption is so low powered that Redgate have built an automatic decryptor into SQL prompt, maybe we shouldn't even be bothering with this discussion.
Dr X
May 17, 2010 at 12:52 am
Not sure that SQLCLR helps here, there's always ILDASM to assist the exceptionally curious.
Even if you obfuscate your .NET code, or even put the real secret stuff in an unmanaged dll, if your code can really turn lead into gold, then someone will disassemble it. Assuming, of course, that your code is so clever that disassembly is faster than implementing something functionally equivalent from scratch.
IMV, this kind of thing has its place as a "defence" against customers, but not against (determined) competitors. If the fact that your code is obfuscated is a source of frustration to your customers, then there is a case to be made for reviewing this policy - if the dissatisfaction generated outweighs the benefits of obfuscating, then why bother? And why do your customers want to see your source code? Is your app not working as well as it should? I know I have used many third-party components over the years, without being the slightest bit interested in their inner workings, as long as they reliably do what they say on the tin.
May 17, 2010 at 1:49 am
If it was really encrypted it would be fine to keep it but as it isn't I can live without it.
Installing it at a customer site won't prevent them from reading the code using encryption. Competitors are more likely to get your code than customers even though it's encrypted. They have the skills to do it. What's the interest for the customer to "steal" your code?
To handle support when the customer has changed the code, which I'm sure you can figure out the first time they call, support just goes away and you start charging by the hour.
You buy a system because you don't want to do it yourself and not because you can't. I'd assume that it at least applies to the readers here...
May 17, 2010 at 3:06 am
I'm fairly indifferent really.
I'm not going to use an ISV if I have time and expertise, nor would I do the support.
If it performs bad its their problem, and being a hero to the business and fixing their code just means the business has less reason to kick them out the door while putting yourself on the line if something goes wrong.
From a competitor, if I know they do something better, then I know there is room for improvement and I can look at my own processes\design\code. If they were in the market first, then I probably have to do better to take business from them, not just as good.
To me, condoning the practice of stealing code would be a sympton of bigger issues in terms of risk taking and shortcutting.
But that said I would not be against of anyone in the practice of encrypting stored procedures to reduce business risk of code theft.
May 17, 2010 at 4:25 am
Jeff,
I agree with you and I believe that encryption keeps competitors just that.
Take Quest LiteSpeed for SQL Server as an example. It is evolved into one of the best backup, restore and Log Shipping application for SQL Server. The Failover and Failback process is very competent. Even MS internal version at SS-2008 cannot touch the maturity of LiteSpeed. Quest charges alot to support their product and the money goes into creating bug fixes and new features so your comment that everything that has been written for SQL Server already exist is only partially correct. Therefore, they should protect their T-SQL code for they have real money invested in this product and the product has commecial benefit and a future.
Just like the patent person who made the same comment over 70 years ago that everything that is worth inventing has already been invented was DEAD WRONG, so are similar comments here !
There will always be creative Developing DBA(s) who will build a better mouse trap and I have clearly been one of them.. Yes I have seen other ideas on various subject and then I have turned them around into some very interesting T-SQL code that I know hit the spot, which I have gladly shared with the concept originator and on other forums. However, since some of the code I have had to write is bizarre and potentially dangerous in the hands of a novice, I seriously considered encryption for certain code modules.
So from my experience encryption helps protect my private code as well as corporate property from thieves, who will either damage the original product or steal the intillectual property for commercial benefit. A real developer who wants to see the proprietary code can usually get a copy under a non-disclosure agreement, they just have to honest about their intent.
Hank Freeman
Senior Systems DBA/Developer Architect
Atlanta, GA
Hank Freeman
Senior SQL Server DBA / Data & Solutions Architect
hfreeman@msn.com
678-414-0090 (Personal Cell)
May 17, 2010 at 5:23 am
I think you have the wrong perspective here. My company has been encrypting all of their stored procs since the beginning. I am talking hundreds of stored procs. Some are your normal Crud procs, but I would guess about half are very complex procs that are core to the engine that makes our software do what it is suppose to.
Here is the rub. We have good intentioned DBA's, that want to figure things out themselves, that really have no business messing around with a system they know nothing about. Nor do they understand how it should work. So encryption just makes it that much harder for them to mess around. It isn't' that a DBA couldn't crack the encryption, because they could. It is just that since the code is encrypted it is just too much work to bother with, so the DBA moves on to other things that need to be done.
I think you have missed the real reason encryption bothers you and everyone else. It drives you nuts that you can't easily see some code. Honestly I think it is just prideful to assume you should be able to see something you really don't need to be messing with.
Your issue about not knowing which proc someone is running one, sounds like a source control issue not an encryption issue.
So for us encryption serves three purposes:
First make it hard enough so DBA's spend their time on something else other than looking at our code. Trust me you don't want to look at it, it is really complicated. It would just give you a headache, like you need another one of those.
Second to help us support our clients better. When our clients have a problem or a bug it isn't going to be because they were messing around with stored procs. We have to support them it would be a nightmare if we couldn't trust the db code was unchanged. I know you say just charge them more, but honestly have you ever had to trouble shoot a super complicated system? It is bad enough when you know the code you are starting with, it is much worse when someone messed around with something they don't understand and now expect you to fix it.
Finally, we do want to protect our product. Honestly even if we didn't encrypt our code it would be hard to duplicate what we do. If you don't know or understand the original business rules it is hard to make sense of the code. Still encryption isn't foolproof, but it does make it that much harder.
Anyway, I would suggest you hold your judgement on sql encryption until you have worked with it and seen the benefits first hand. It makes a difference at my company.
Ben
May 17, 2010 at 6:09 am
Only one thing wrong here... decrypting SPs or views is not very complicated and would be a scriptable task to perform on any database (I wouldn't recommend decrypting a live db though).
I can definately understand the need to protect your business stuff and for the customer this might be enough to prevent them from fiddling with the code. What it doesn't protect against is the fact that competitors can rip it all using the current encryption if they get their hands on a database.
For some reason, when reading the previous two posts I come to think of KISS. Seems like there is a tendency to make things overly complicated....
K
May 17, 2010 at 7:38 am
Kristian Ask (5/17/2010)
For some reason, when reading the previous two posts I come to think of KISS. Seems like there is a tendency to make things overly complicated....
Heh... and what would be that reason? Yes, I agree that MS encryption isn't the best so do you have a KISS method for making it simple?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2010 at 7:39 am
I have worked with encryption and the arguments you give just don't make sense.
If the software is unencrypted, you can easily run a hash against the code to see if things are changed. If DBAs want to look at it, why is it your job to stop them. They might learn something, or they might find a bug, or they might improve the code used in joins. In almost every third party system I've seen, the indexing is horrible. Plus, viewing the code doesn't change anything.
This doesn't protect you. The encryption is easily broken. You might claim it is, but it isn't. The reason Litespeed isn't copied is because of laws against copyright. If someone brings out a product, you can get an injunction against their code, ESPECIALLY if you can see it because it's not encrypted.
The reality is that you aren't providing protection from competitors. They have the resources and time to easily decrypt it.
For customers, you can just write this into future EULAs. Not current ones, but you tell them that support requires that they don't change a proc.
May 17, 2010 at 8:37 am
I can't follow some of the arguments on this thread...
Some say encryption is pointless because SQL Server encryption is easy to break - This is true but not an argument against encryption per se.
Some seem to be arguing that there is no value AT ALL in the design, development, and testing processes - like when you want to write code it magically arrives fully debugged and error checked so there is no point in acquiring someone elses work!
Really?
Tim
.
May 17, 2010 at 8:46 am
My argument is encryption of stored procedures isn't worth doing. It's a PIA and doesn't provide protection. It can be broken.
I see two arguments back.
- Customers mess with stored procs so vendors need it.
- Competitors can steal your code if you don't do this
I think both are invalid, for different reasons.
We are not talking about data encryption.
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply