[SvanteSpectator]

Hello Mike,

Not quite, quite yet…. We just started the internal beta this week. We’re planning going public with the beta within a week or two.

[SvanteSpectator]

Hello kz and Captain Quirk,

I wouldn’t be quite so empathic, but I wish it was so simple…

I’m not going to make really long post about this, although I could. But there are many issues that need to be thought out, and then implemented in code and described in text. This means we need to spend time on it. This means we need to spend money on it.

– You don’t really want a one-off purchase. If we fix a bug, that’s important to you the month after, you want a free upgrade. How long should free upgrades be included? After this time, how should the upgrade offer look like? If we implement a new feature, you might also want to upgrade. Should we separate bug-fix-releases and so-called feature-releases? You know the major / minor update “scam” many software companies with the license model use… “We need more revenue, let’s increase the major version digit and make people pay again…” – Parallels is a good example of this. They also make it mandatory by tying the software to a given version of Mac OS X, so if you upgrade the OS, you must update Parallels.

– You may not want our server features, but you do want us to maintain the application. Should we offer an optional maintenance subscription?

– Should we have a trial mode? Should we discontinue the free version, and just have one-off or subscription? Should we discontinue the subscription model entirely? How do we handle all the current subscriptions when they expire? Do we need to refund those that have subscribed for years, or just offer a free transfer to a perpetual license? Should they just be left out and have to purchase a one-off?

– How should the license be delivered, and using what technology? How hard do we need to make it thwart cheaters? Remember, it’s an open source product… Can we depend on the Internet for license delivery? If not, how do we implement license entry in an air gapped situation?

– Sometimes it does not work as you want or think it should. Should free support be included in the one-off? Should we offer an optional support plan?

– If you change your mind, and want a subscription instead, because you find we actually have something you want. How should that upgrade / transfer look like? The reverse is of course also possible, you want to stop subscribing but purchase the one-off. How should that offer and transfer look like?

– Should the one-off be valid for all your devices? One, two? For the mobile apps? If not, they too need to implement all this. The soon to come Mac version? Should we have bundles?

– How do we explain all of the above to you and the other users? How do we provide information so you can make an informed decision about going with the Free, with the Premium subscription, or with the purchased License? What languages do we need to support this information in? Every text change in the software currently triggers about 10 translations, every text change on the content web about 2-3 translations.

All of the above, once decided, actually leads to a number of non-trivial development tasks that need programmer time to be allocated, change and addition to documentation and lots of updates and additions to the content web site. Time and money that would then be spent on this rather than making the application more stable and even greater with more awesome features, capabilities, and platform support.

I wish it was as simple as just saying:

“Yeah, let’s offer a one-off price without server access @ €40. Done. Now everyone is happy.”

But it’s not.

Now we have a fairly simple model: We offer a very useful and complete utility at the one-off price of zero. We also have a simple, easy to understand and predictable subscription at the approximate half cost of what comparable commercial alternatives cost with the license model (and these competitors also charge for updates at various points in time etc).

Believe it or not – this is the short post on this question. In reality it’s much more complicated.

All this being said, if we do get time/resources available and figure out a way to answer all of the above and more with good and well-defined answers, we may indeed offer something in the future.

[SvanteSpectator]

Hello Anonymous,

Please upgrade AxCrypt, that’s a really old version, and try again. You’ll find the latest at https://forum.axcrypt.net/ .

[SvanteSpectator]

Hello Anonymous,

If you please can provide more information about your problem, and if you can send a screenshot explaining where the problem is it is the best.

How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .

[SvanteSpectator]

Hello Dean

If you please can provide more information about your problem, and if you can send a screenshot explaining where the problem is it is the best.

How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .

[SvanteSpectator]

Hello Hjalmar,

Thanks again for your input. Yes, the SSL/TLS issue is frequently debated and many distrust it for the reasons you describe, and with reference to various conspiracy theories.

I like your idea of using AxCrypt to encrypt the password as it is sent to the server, we’re actively trying to make the analysis as simple as possible, and that entails using / relying on as few mechanisms as possible. We’ve already discussed various ways of strengthening the protocol, including making a zero knowledge variant. (The problem with that is that some other things become less convenient. But that’s a longer discussion.)

The problem that will have to be investigated is just how robust such a large HTTP header is in practice. For it to be a relatively “simple” fit, I’d like to continue using basic authentication, and this entails sending the password in a HTTP header. A minimum AxCrypt file right now weighs in at about 5K, this can probably be reduced a little by extending AxCrypt to support a file-less format (that’s useful for other situations as well, such as AxCrypt-encrypting pure text etc), thus reducing the amount of headers etc, and perhaps even skipping the redundant headers in the trailer. But then it has to be Base-64 encoded, so it grows again. In the end the header will probably be on the order of 4K. To be honest, I just don’t know how will this will work. A mitigating factor is that it’s still inside a SSL/TLS connection so it should not be affected by intermediate stuff.

Still, I like it. Even better, it can be added without any problem for existing clients. The server can easily distinguish between the cases.

See:

https://bitbucket.org/axantum/axcrypt-net/issues/276/filter-out-components-from-the-user-email

https://bitbucket.org/axantum/axcrypt-net/issues/277/implement-file-less-axcrypt-encryption

https://bitbucket.org/axantum/axcrypt-net/issues/278/investigate-and-possibly-implement-axcrypt

Thanks!

[SvanteSpectator]

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.

[SvanteSpectator]

Hjalmar,

If you want to be really sure – download the source and compile it locally, then you can inspect every line of code to ensure it does exactly what it should.

[SvanteSpectator]

Hjalmar,

If you want to be really sure – download the source and compile it locally, then you can inspect every line of code to ensure it does exactly what it should.

[SvanteSpectator]

Hello Dwight,

I’m sorry you’re unhappy, but the simple fact is that writing new code in order to convert files back from version 2 in order to use an unsupported version 1 software, is simply not a a priority ;-) We’d much rather put the effort in making you happy with version 2, which we already feel is a huge improvement – but it can of course get better!

However, we do publish all the source code, so you could roll your own if you think the community would appreciate it.

Also, from what you’ve described, I don’t think you’ve actually converted all your 300 files to v2, have you? My suggestion was to have the portable version on hand, whenever you need it. v1 will tell you if the file is too new to open, i.e. a v2 file.

Wayne, for the other way around – converting from v1 to v2, we have that in the program. You don’t have to open each file in order to auto-convert.

[SvanteSpectator]

Hello Hjalmar,

The signature and the hash is correct. We’ve now updated the list of hashes to include the new version as well. Sorry about that.

The portable version stores temporary and configuration files in %localappdata%\AxCrypt but that’s all. If you run in it in ‘always offline’ it will always be offline.

It does not ever need Internet if you run in it ‘always offline’, and does not store anything in the registry.

[SvanteSpectator]

Ok… You do need to re-boot often after installing. It should tell you this, but many just close it and ignore it. Did you reboot after the first install?

[SvanteSpectator]

Hello Christian,

You can deploy AxCrypt using group policy in various ways, either by way of the setup.exe, or by extracting the .msi setup packages that are contained in it.

However, once installed, AxCrypt will ask for the email to use and then the user will go through the registration process with confirming the email and setting the password to use.

We will soon start development of business related features, and in this situation an administrator can invite users and also waive the need to confirm the email. The user will still have to type in the correct email address and set the password though.

We are very interested in developing as streamlined procedures as possible. Can you perhaps describe your scenario, and how you’d like it to work and we can discuss it perhaps arriving at a good solution for all?

[SvanteSpectator]

Hello Dwight,

Thanks for your input!

Files encrypted with v2 are not possible to open with v1. Files opened with v2 with the auto-convert option enabled (default) will be in v2 format. However, the easiest way if you insist on reverting to the unsupported v1, is to uninstall v2, install v1 and then download the standalone v2 which will enable you to decrypt v2-encrypted files as you need to in order to re-encrypt them with v1.

I’ve been a developer for almost 40 years, and I love to debate the pros and cons of all things, because things change! AxCrypt did not evolve at all for 15+ years. The world did though, and now it’s way past time to get things up to date again, which includes new views on passwords and local vs. remote storage (aka cloud).

Here’s my input to the single vs. multiple password debate: http://www.axcrypt.net/blog/use-of-different-passwords/ .

 

[SvanteSpectator]

Hello Kent,

The key sharing function embeds the shared key into the file. The file must thus first be key shared with the recipient, then sent or file shared. Please note that AxCrypt does not share or send the actual file. To see a quick instructional video explaining how to use key sharing, please view https://www.youtube.com/watch?v=9z3KOZD-Yks .

[Author]

Posts