Home
Up

At 03:06 PM 6/22/99 -0400, you wrote:

>I got a call from the projct manager for arcview a few days later - I think his name is rich turner. He asked that I stop distributing the program, suggesting it was illegal.

Unenforceable threat. But it still costs money to defend even frivolous lawsuits.

>the developer who wrote the code took it especially hard

You can guess how I feel about that.

>This article was written after the above incident, so I toned down the esri part a bit.

I was wondering.

>I wonder why is still has not been fixed - it may be very difficult.

I can assure you it is not. I'll wager that a good programmer could fix that mess within a day--at least to the point of making something that is not so transparent.

>With the advent of the Internet, I think encryption is very difficult to implement - all of the schemes for all of the major products have been broken and many vendors are selling the decryption tools.

With a small market like the ArcView one, if you make decryption hard, the vendors would have to charge quite a lot for the tool. That alone is a good barrier.

>I dont think avenue is high-powered enough to contain any serious secrets either.

You are not the first to echo this thought. There's a flaw in it, though. One person requested that I decrypt some files to be found on ESRI's web page. I asked her which ones. So I took a look. It turns out the ESRI page is just a link to a private developer's site. Their avx file contains a lot of code that is simply modified from ESRI scripts, borrowed from other well-known Avenue coders, etc. But the remainder was essentially Avenue translations of some pretty sophisticated algorithms, fully attributed with references to textbooks. Not a single secret in it. Nevertheless, it would take someone a lot of work to recreate that package on their own. The result is pretty impressive. No wonder they encrypted it. The moral is that developers don't have to have "serious secrets" to protect. They are just trying to protect their many arduous hours of debugging, design, and interface development. In some contrary sense, the less "high-powered" an applications development system is, the greater the need to protect code, because it's so much harder to write good code! (By the way, I did not send that person the decrypted files. I sent her the authors' names and e-mail addresses they put in the header comments.)

>He was considering selling a decryption prouct.

That must occur to everyone. I would much rather get the encryption improved, which I sense is your objective, too.

>It is interesting to note that most of that article has become true - there is now massive piracy of GIS applications and datasets on the web

One issue concerns the extent to which the encryption strength affords any protection against this piracy. I have been assuming that it does. No, that's not quite it: I think what dismayed me the most was the patent falsity of the ESRI claims about the encryption.

>I have received some requests for the program which I dont distribute anymore.

I have thought that one through. You don't want to get involved in deciding who is legitimate and who is not. That makes you part of their problem.

>Anyways, I have had my go-around with this, if you could try and keep references to me as few as possible, I would appreciate it.

Having had a small taste of this, I will gladly honor your request. I did send a reference to your web site to one or two people; I can't unsend that. I have had a link to your page from my web page since this afternoon. That link is disappearing right away. Thanks so much for the history.

sorry to have to write to you personally, but I accidently deleted and could not retrieve yesterdays ARCVIEW-L DIGEST where you mentioned being able to unencrypt scripts.

Would it be possible to be sent the script you have written, or be directed to where I may find it on the web.

Interested to hear that you have decrypted the avenue scripts. If ESRI are not going to provide a fix have you got any ideas on how to decrypt scripts securely.

Well that's a bit of a worry isn't it?! Have you had any sort of response from ESRI? Are they taking the problem seriously? Moreover, have you (or ESRI...as if!) come up with a way of REALLY encrytping scripts? I am sure there are a lot of commercial ArcView developers out there who would be very interested to know. Good luck in your crusade!

>If ESRI are not going to provide a fix have you got any ideas on how to decrypt scripts securely.

I have been thinking hard about that one because I have evidence that ESRI has known of the problem for many generations of ArcView but has not changed the "encryption" at all. Look for a SUM in a few days.

>Have you had any sort of response from ESRI?

No. But their moderator did let me post the message.

>Are they taking the problem seriously?

I have good evidence they are not.

>Moreover, have you (or ESRI...as if!) come up with a way of REALLY encrytping scripts?

There are some issues here. Look for a SUM in a few days.

>Good luck in your crusade!

More of a quixotic adventure than a crusade, I think...

Thank you very much for your reply. First of all I must apologize about the language I used. You probably noticed, that English is not my mothertongue - maybe I was a not very polite.. Sorry

I disagree with your point - and I am not ignorant about the possibility of hacking the encryption. As I wrote I am aware, that it might not be very tricky and some people might do it. There will always be someone who hacks the encryption, regardless of how good the encryption is.

But my point is a little different. See - I want to do a small business with some commercial ArcView-Extension written in Avenue. How can I sell anything, if there is a script on the ESRI homepage which makes my investment worthless with a fingertip??

Many potential customers believe that the encryption is good, so they don't even try to hack it and pay some $ for a good software. But if they don't believe in the encryption, or if they even have a script which removes the encryption they very likely will 'steel' my code and my ideas and this particular market is gone for me and many other people.

That's why I don't like your idea of publishing your findings.

I would be glad if you would change your mind, mabe get directly in touch with ESRI and tell them how bad their encryption is and get them to improve their code in this way.

Thank you very much for your understanding

[NB: Respondent 24 and Respondent 16 are the same person, using a different e-mail address at various times.]

sorry i had to head off early yesterday...

View.MCP would be very handy... thanks

actually i have been in touch with Hooge and he was very friendly and interested in what i was doing but i'm afraid he is pretty slow to reply and i had temporarily given up on him, but i take your point and i will try approaching him again...

At 02:31 PM 6/23/92 +0200, you wrote:

>The most important result of your discovery is that instead of creating useful applications now we (including you) must spent a lot of time trying to protect our code.

Actually, I have stopped spending the time protecting mine. I commented out the script-encryption calls in my extension creation code and have started to distribute unencrypted applications to my clients. It saves me time.

I now have reliable information that almost exactly the same announcement I made last weekend was made on ArcView-L three years ago. That person (who wishes not to be identified) also published working decryption code. Pressure from ESRI (according to him) caused him to withdraw that code.

ArcView has been through three major revisions since then. The "encryption" method has not changed.

You should be writing to ESRI, not me.

At 04:44 PM 6/23/99 +0200, you wrote:

>You probably noticed, that English is not my mothertongue - maybe I was a not very polite.

I discounted that because I am sympathetic, having lived and worked in countries where I had to speak languages with which I am uncomfortable. You are doing very well at expressing yourself--almost too well.

>There will always be someone who hacks the encryption, regardless of how good the encryption is.

This is true, but there are limits. ESRI makes explicit representations about the quality of their encryption. These representations are false and ESRI knows they are false. This is dishonest, fraudulent, and damaging to me and all other developers and vendors. What also offended me at the time of my message, and still offends me greatly, is how ridiculously simple the "encryption" is. There is almost no simpler way to do it. The extreme naivete of the method is breathtaking.

>How can I sell anything, if there is a script on the ESRI homepage which makes my investment worthless with a fingertip??

I am genuinely interested in knowing--without being informed of the confidential details, of course--how the ready availability of decryption software renders your investment worthless. This is merely a request: you do not have to prove yourself; it is the mere possibility that my proposed action could harm you that gives me pause and causes me to refrain from posting the script. I would just like to understand your point of view better.

>Many potential customers believe that the encryption is good, so they don't even try to hack it

Very true. However, what burns me up is that the encryption is SO bad that the belief in the goodness of the encryption is shaken the instant you glance at an encrypted script. Try it yourself. Hint: EVERY true encryption scheme produces random-looking output. Look at a group of encrypted scripts from any one of your projects or extensions. I promise you there will be obvious patterns.

>they very likely will 'steel' my code and my ideas and this particular market is gone for me and many other people.

One person, with whom I had an extended discussion, suggested that one important issue in the air is the nature of the vendor-client relationship. Is it really true the relationship is so poor that vendors automatically suppose their clients will steal their code and resell it?

> get directly in touch with ESRI and tell them how bad their encryption is and get them to improve their code in this way.

This was done three years ago. ArcView has been through three major revisions since. The "encryption" method has not changed. As I quoted in my original posting, the claims for the encryption method ("irreversible", etc.) have not changed. Would you care to predict my chances of success when ESRI will not even respond to clearly documented bug reports I have sent in the past?

As an Avenue programmer who has given much code away, this news was somewhat surprising. I've also produced several applications while working in the private sector that were encrypted to protect our product AS WELL AS protecting our consumers from themselves.

Having considered all sides, I think you should still release your extension. ESRI needs to be made responsible for it's lack of robust production code. I'm now concerned about the security of AML applications that I had distributed as encrypted -- if Avenue can be decrypted, what is to make me believe my AMLs are secure.

I've always believed that ESRI would use an algorithm for encryption that isn't reversible for it's engines. Now that you disproved this, I'm going to start looking at the technology to learn if the AMLs are at risk too.

At 11:28 AM 6/24/99 -0400, you wrote:

>Having considered all sides, I think you should still release your extension. ESRI needs to be made responsible for it's lack of robust production code.

I am very sympathetic. This was a major motivation for my original posting. The counter argument, which I am hearing from several developers, is that releasing the extension punishes them, not ESRI. That is why I am currently holding back and pondering the best course of action.

By the way, it turns out I am treading a path that was followed by another three years ago. He published his code, but succumbed to ESRI pressure to withdraw it (according to him). He is sick of the business and does not want his name used.

Maybe the best path is for developers and business partners all to hammer on ESRI to shape up. They have had three years and three major ArcView revisions to clean up their act. Continuing to deceive us with assertions that the encryption is "irreversible," etc., is dishonest and fraudulent.

>I'm going to start looking at the technology to learn if the AMLs are at risk too.

I am very sorry to inform you that AMLs are at the same risk. I don't use Arc/Info or have access to it, so this information is second-hand. To verify it, create some AMLs that have long strings of constant characters and encrypt them. You will see the patterns instantly. That is the heart of my problem: I would not mind ESRI using weak encryption provided it were not so obvious that it is weak. The other clues are that (a) encrypted AML strings are padded (with blanks, I think) to have lengths that are multiples of five; (b) encrypted AML strings may be written out using C escape sequences to replace newlines, carriage returns, and end-of-file characters (all of which can appear as encrypted values); (c) there are minor bugs in the encryption process that cause some exceptions to this behavior.

After reading your explanation of the Vigenere method of encryption, I was able to crack the AV encryption in "a few minutes" as you said. The key was to think of it as a positional Ascii displacement scheme.

Now I am in the dilemma of wondering whether anyone but a cryptology expert or enthusiast would have known about this had you not published your explanation. I suppose it could have occurred to someone bright even without the explanation...I think my competitors could have easily gone years before they would have thought to look though -- now they have a reason. This is a problem that probably only the COM-based AV 4.0 will fix.

I saw an ArcView-L posting where you stated that it was possible to decrypt a script. It so happens that I could really use this ability. I guess I suffered from brain gas lately and encrypted a few scripts that I really do not wish to re-write.

Could you forward the script you mentioned so I could try to decrypt my blunder? I use unable to locate on the ESRI or your website.

Has ESRI accepted you script to decrypt scripts? If not, have you placed it on your web page? I am curious as to what happens here. I was talking with a developer from the D.C. area yesterday and he said that this happened before & ESRI said they would basically sue the person if they distributed the script.

[NB: Respondent 28 and Respondent 26 are the same person.]

At 08:09 AM 6/25/99 -0400, you wrote: > I guess I suffered from brain gas lately and encrypted a few scripts that I really do not wish to re-write. Could you forward the script you mentioned so I could try to decrypt my blunder?

I will be posting a more detailed sum on ArcView-L soon. Many apologies for being unable to carry out my promise of releasing the software. It hurts to be unable to do that.

At 08:14 AM 6/25/99 -0400, you wrote:

>Has ESRI accepted you script to decrypt scripts? If not, have you placed it on your web page? I am curious as to what happens here. I was talking with a developer from the D.C. area yesterday and he said that this happened before & ESRI said they would basically sue the person if they distributed the script.

No and no. I have corresponded with the person (or one of the persons--this incident may have happened more than once) involved and what you say accords with his story, except he just referred to it as a bit of ESRI arm-twisting, not a threat to sue. He also heard from a European developer who apparently went through the same process with ESRI in Europe.

A threat of a lawsuit would have to be taken seriously but, I believe, is ultimately not legitimate and would not be successful. I have the resources to defend such a suit, so that's not the issue. Rather, many developers have written me alleging that releasing the decryption script (actually an extension) would cause them great harm. As an ethical matter, then, I cannot act unless those allegations can be dispelled. I fully intend to discuss this matter in some depth in a SUM to the ArcView-L list.

I am truly embarrassed not to be able to post the script at this time. I hope a compromise will be possible. Stay tuned. Thanks for the good wishes.

At 11:56 AM 6/23/99 -0700, you wrote:

>View.MCP would be very handy... thanks

Are you saying you would like to see Avenue code that could be used to implement View.MCP? As far as I can tell from having experimented with the extension, this script simply produces the convex hull of a theme of points. If this is true, you can find Convex Hull scripts on the ESRI page--search for "Convex Hull". I can also provide you an extremely simple algorithm (far simpler than the one actually used by View.MCP) implemented in Avenue.

please excuse my late reply - I am moving my home and office since last weeks tuesday - so there is not much time left for business, email etc.

I find our discussion very interesting and I greatly appreciate that you try to understand my point. I must admit that I start understanding your point of view....

Especially I begin to understand your point with ESRI, they don't seem to bother about the quality of the encryption. I completely agree with you on this.

But on the other hand most of the AV users are not aware of this problem. And this is good - for most people the world is how they believe it is - and not how it really is. If you understand what I mean.

About the customers:

In the market I am active in, there are many technical people who know something about software. And they are very interested to get a piece of code from somewhere or from a friend and modify it or make some own product out of it.

And this is where I have a problem when somebody can have a look at my encrypted scripts using e.g. your script, downloaded from the ESRI homepage.

So once again, I would greatly appreciate if you don't put your script on the ESRI homepage.

Respondents 1-10    Respondents 11-19    Respondents 28-33    ArcView Encryption

ColorRamp, Memorized Calculations, Rotate, Sample, XSect, and Tissot  are  trademarks of Quantitative Decisions.  All other products mentioned are registered trademarks or trademarks of their respective companies.

Questions or problems regarding this web site should be directed to webmaster@quantdec.com.
Copyright © 2000-2002 Quantitative Decisions.  All rights reserved.
Last modified: Monday July 01, 2002.