Mendeley encrypts users' database after Zotero provides an importer
If I&#x27;m understanding things correctly from the reading (which, let&#x27;s be honest, that&#x27;s an assumption on its own), the tl;dr seems to be that Mendeley heard about an open source product working on a set of importers that would, potentially, result in Mendeley customers migrating to this free alternative[0].  To provide cover for this change, they invoked user security.<p>And hey, user security is a pretty good reason to encrypt a database, but if security were the <i>only</i> aim, they could have made the data accessible for export purposes (after all, it&#x27;s accessible for the <i>user</i> to read).<p>At this point in history I&#x27;m not even sure it&#x27;s worth going into all of the reasons this is a terrible thing to do on their part.  At <i>best</i>, they&#x27;ll scare off some users from migrating away briefly and buy themselves some time to figure out what they need to do to produce something that&#x27;s better than the competition they&#x27;re attempting thwart.  More likely, they&#x27;ll simply fail (quickly or slowly).  It&#x27;s that last point that <i>really</i> matters to me.  If I&#x27;m buying an application that I&#x27;m going to rely on, I want comfort that the company will continue to maintain the product -- or in the case of open-source, confidence that the product is still regularly maintained (or in languages&#x2F;frameworks that make it practical for me to maintain myself).<p><i>Aside</i> from the fact that I wouldn&#x27;t want that feature &#x27;as it has been designed, today&#x27;, I wouldn&#x27;t want to rely on a product that&#x27;s being designed by individuals who aren&#x27;t well versed in the perils that DRM-like behavior causes.  After all, that&#x27;s what this is -- it&#x27;s an attempt to keep the user from transforming their own data for the purposes of locking that customer into the product while attempting to position the lock-in as a security feature.  And it failed on both accounts, Zotero worked around the encryption (which means the bad guys can to) and if people looking for a product like this <i>care</i> about that capability, they&#x27;ll likely refine it to the point that it&#x27;s as capable encrypted as it is decrypted.<p>Every time I&#x27;ve been asked to implement a DRM solution I&#x27;ve either outright refused or paired it down so much that the &quot;R&quot; didn&#x27;t really exist.  They&#x27;re horribly complex to write, off the shelf solutions are already cracked and time would be <i>better spent</i> giving customers something they&#x27;re <i>willing</i> to pay for.  The thing that makes me roll my eyes every time I read one of these is &quot;there are still engineers out there who think this is a good idea?&quot;<p>I can&#x27;t wrap my head around what causes this kind of thinking -- it&#x27;s not a zero-sum game, there&#x27;s room for more than one product in the marketplace -- <i>even if one of them is free and open-source</i>.  Trying to beat the competition by sabotage rather than by making a better product doesn&#x27;t work ... at least not for very long.<p>[0] And they also do my least favorite &quot;other marketing thing&quot; -- &quot;Create a Free Account&quot; and no hint of what the thing costs in any obvious place.  So maybe this other product is free?  I doubt it -- Like most companies, I&#x27;m assuming they&#x27;re perfectly happy collecting your personal information for free (in order to send marketing to you to get you to <i>pay</i> for whatever <i>service</i> is tied to the <i>free</i> account).  It&#x27;s the little deceptive things that drive me crazy -- you didn&#x27;t trick me, you only managed to make me suspicious of your product.<p>[1] I&#x27;ve gotten lucky ... usually budget and time doesn&#x27;t allow for wasting energy on customer-hostile features that won&#x27;t achieve the ends they&#x27;re aiming for.  The only case where something &quot;DRM-like&quot; was in an application I wrote was to be the opposite of customer-hostile.  We had an app that provided information to users based on their permissions, determined by them logging in.  I pushed to make the automation (sending us the login information) opt-in, with manual provisioning options.  It worked well, since if they failed to true up after months of warnings, the application would deactivate (due to the size of the customers, <i>months of warning</i> was somewhere near a year and could <i>also</i> be disabled with a flag).