Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Precious Ideas Expand / Collapse
Author
Message
Posted Saturday, May 15, 2010 11:35 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
Comments posted to this topic are about the item Precious Ideas






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #922513
Posted Saturday, May 15, 2010 6:39 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 1:53 PM
Points: 35,366, Visits: 31,905
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #922554
Posted Sunday, May 16, 2010 12:31 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #922626
Posted Sunday, May 16, 2010 7:34 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 1:53 PM
Points: 35,366, Visits: 31,905
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #922693
Posted Monday, May 17, 2010 12:25 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 6:00 PM
Points: 76, Visits: 381
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
Post #922720
Posted Monday, May 17, 2010 12:52 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, October 1, 2014 9:31 AM
Points: 28, Visits: 380
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.
Post #922726
Posted Monday, May 17, 2010 1:49 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 12:21 PM
Points: 53, Visits: 251
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...
Post #922742
Posted Monday, May 17, 2010 3:06 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 5:12 AM
Points: 36, Visits: 397
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.
Post #922761
Posted Monday, May 17, 2010 4:25 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, October 16, 2014 10:22 AM
Points: 10, Visits: 35
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
CCFGC – Senior SQL Server DBA/Architect
hafreeman@coca-cola.com
678-414-0090 (Personal Cell)
Post #922789
Posted Monday, May 17, 2010 5:23 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 1:17 PM
Points: 1,862, Visits: 481
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
Post #922814
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse