<br>I would guess that in most cases the process of getting the unlock key would include either an email or some "keep this safe" instruction.<br>Suppose someone pays for a module, and then deletes it (I guess by mistake), and then wants it back again. Are they likely to find it stashed away in the properties file?
<br>Maybe we should simply add a note of our own during module delete "Keep this key safe".<br><br>Joe.<br><br><div><span class="gmail_quote">On 7/21/06, <b class="gmail_sendername">DM Smith</b> <<a href="mailto:dmsmith555@yahoo.com">
dmsmith555@yahoo.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Please provide feedback:<br><br>Within the last few months and over the course of the near future we are
<br>seeing locked modules coming available (NET, NASB, ...). In each of the<br>cases the publisher will be selling the unlock key. In some cases the<br>publisher will be hosting the module on their website.<br><br>In BibleDesktop, when a module is locked it is shown with a small lock
<br>overlay icon in the Book Installer. When the user selects a locked<br>module, the "Install" button is greyed out. This leaves the user with<br>manually downloading the module, unzipping it in the correct location,
<br>finding the module's conf and editing it, entering the unlock key.<br><br>I would like to change this so that at a minimum, the user can download<br>and install the module. Further, ideally the application should allow
<br>the user to enter the unlock key at download time and also later. The<br>key would then be checked for validity*. I'm kinda working against a<br>deadline of the next SWORD CD being created. It would be nice to get<br>
this done before the CD is mastered. So at a minimum, instructions<br>should be given to the user to manually insert the unlock key.<br><br>The unlock key represents an asset that the user owns. I am wondering<br>where and how we should store the unlock key. In order to maximize
<br>sharing with other SWORD applications it needs to be in the module's<br>conf. I'm wondering if it should be double stored in a file that is not<br>deleted when the module is deleted? (A simple properties file should<br>
suffice.)<br><br>*WRT a unlock key validity check there has been much discussion on<br>sword-devel on how this should be done.<br><br>The best solution was to change the locking process to encode a random<br>sequence of bytes in two known locations in the module before
<br>enciphering. Then a check would to have been to decipher the module and<br>compare the random sequence at the beginning and the end. If they<br>matched the key was valid. This solution is not be used because it was<br>
deemed as being too intrusive. (There are locked module already created<br>that would have to be relocked.)<br><br>So this leaves us with guessing. Turns out that we can guess fairly<br>well. There are certain characters that should not be in a module,
<br>namely most 7-bit ASCII unprintable, control characters. If any of these<br>control characters are found any deciphered chunk of text, then the<br>unlock key is bad. The accuracy of the test increases with the length
<br>of the text being deciphered. (The fundamental nature of the cipher<br>algorithm is that of a random byte generator, seeded with the unlock key<br>and all input prior to the current byte.)<br>_______________________________________________
<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel
</a><br></blockquote></div><br>