Forums › Help & support › AxCrypt Portable – truly standalone? › Reply To: AxCrypt Portable – truly standalone?
Hello Hjalmar,
What can I say? Thanks! Lots of very good and relevant thoughts and notes. Some are on our issue list, some will soon be ;-)
One thing surprised me – you say there’s lots of dead and unused code? Could you point me in the general direction, I try very hard to get rid of dead code as soon as it’s dead. One thing you may not be aware of is that while the Windows desktop and the core libraries are open source, we also use the core libraries in our mobile apps, our soon to be released Mac app as well as on the server side ( https://account.axcrypt.net/ ). So, if the methods are public, they may be used by other code that is not part of the axcrypt-net repository.
The plan is to separate the core libraries into a published SDK nuget package once the most intense development phase is over. But for now, when we have no less than 5 platforms rapidly moving forward using the core libraries, it’s just so much more convenient to include it as a source dependency.
Also, about the ease of cheating with the Premium status, it’s a known situation and conscious decision although we will do a few minor changes in the near future where it at least requires you to hack the source. It’s hard to make strong DRM with open source like this. In the end there will always be a place in the code where the policy is applied, and where someone can hack it away. With or without the source, but it’s of course so much easier with the source. We could obfuscate and do sneaky things, but it just doesn’t make sense for us. If someone really wants to hack the source to get at the Premium features – so be it. There’s still quite a bit of things that are outside of this, which includes the mobile apps and the server-based features (of course if you want to be always offline, none of that makes much sense to use anyway). I could even consider making Premium the default in always offline mode!
As for always offline causing an OfflineApiException I seem to recall that’s just how it’s implemented. Normally, if a connection to the server fails, we throw an OfflineApiException. If we’re always offline, we do the same but before even trying, causing the rest of the code to see no difference between “unplugged”, “server down” and “always offline”.
In any case, the level of your comments indicates I’d like to talk to you. Please PM me via support att axcrypt dott net if you will. I gather you and your employer values privacy to a great degree, and I’ll be happy to respect that of course.