<div>My two penny worth....</div><div><br></div><div>Personalised unlock keys that are without robust user authentication are a species of deception.</div><div><br></div><div>David<caret></caret></div><div><br></div><div id="protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile</div></div> <div><br></div><div><br></div>On Thu, Oct 31, 2019 at 14:48, Jaak Ristioja &lt;<a href="mailto:jaak@ristioja.ee" class="">jaak@ristioja.ee</a>&gt; wrote:<blockquote class="protonmail_quote" type="cite">  On 31.10.19 01:30, Troy A. Griffitts wrote:<br>&gt; Thank you for pointing out one problematic input condition which passes<br>&gt; the validation checks already in the code.<br>&gt;<br>&gt; Your statement that there is no validation on input is incorrect.&nbsp; There<br>&gt; is validation on input.&nbsp; You found one case which passed those<br>&gt; validation checks.&nbsp; An additional check has been added to handle your<br>&gt; case of passing an empty personalization prefix to the depersonalization<br>&gt; mechanism.<br>&gt;<br>&gt; We appreciate your reporting of this unvalidated scenario.&nbsp; If you find<br>&gt; additional strings which cause issues, please continue to provide feedback.<br><br>I believe the function should no longer crash (except when it runs out<br>of memory and throws an exception). If the size of the input string and<br>the parsed segments were bound, one could rewrite the entire function<br>without any memory allocations.<br><br>&gt; Regarding the publisher's reason for requesting personalized unlock<br>&gt; codes, in their mind, a user is less likely to share their unlock code<br>&gt; if it is, e.g.,<br>&gt;<br>&gt; RISTIOJAJA2019-wEt-lum-UIw-GlQN<br>&gt;<br>&gt; They know it does not provide any additional software protection.<br>&gt;<br>&gt; I agree with their reasoning that it is a disincentive to share one's<br>&gt; unlock key if the origin of that shared key can be traced back to a user.<br>&gt;<br>&gt; Hope this makes sense,<br><br><br>Yes, thank you Troy! That was my only conjecture as well. But it is a<br>really weak disincentive, because one can easily just de-personalize<br>"RISTIOJAJA2019-wEt-lum-UIw-GlQN" to "abc-123-def" and share that, or<br>even share DeutscheBibelgesellschaftPrivat-NvM-y0K-vbU-arWR or<br>TroyGriffitts2019-UWV-IOO-iYY-LBVM if one wants to shift the blame.<br><br><br>J<br><br>_______________________________________________<br>sword-devel mailing list: sword-devel@crosswire.org<br>http://www.crosswire.org/mailman/listinfo/sword-devel<br>Instructions to unsubscribe/change your settings at above page</blockquote><div><br></div><div><br></div>