Forums Community some suggestions for AxCrypt

This topic contains 19 replies, has 2 voices, and was last updated by  Barkeley 7 years, 10 months ago.

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
    Posts
  • #2277 Reply

    Svante
    Spectator

    Hello,

    I am currently using 2.0.1343.0 beta portable.

    Here are some suggestions:
    1. please give us an option that when AxCrypt is minimized it does NOT pop up system notification. It’s very annoying and, really, useless
    2. I noticed that since 2.0.1343, the close button (X, at the top right of window)minimizes AxCrypt instead of closing it. please give us option so the “close button” does close/exit AxCrypt, like the older versions did
    3. please also offer an option that AxCrypt can automatically close itself after some idle time (i.e., user has not accessed any files encrypted by AxCrypt). It’s “close”/”exit”, not “minimize” the application window.

    thanks.

    #2278 Reply

    Svante
    Spectator

    Hello,

    Thank you so much for your input! Some quick thoughts in response.

    1 – System notification when minimized. It’s a standard procedure, however, it should probably only be done the first time, not every time. We’ll fix that. Thanks!

    2 – The close button (X) minimized instead of closes. Also standard for this type of application. You can always really close it by using File | Exit. We’ll also be adding a context menu to the minimized version where you can really close it.

    3 – Idle time close. Yes, it’s a relatively frequently requested feature. Coming soon!

    Once again, thanks!

    #3557 Reply

    Raphael DEMETTRE

    Hi,

    Encrypt to .exe files is really missing on version 2, it was a great feature on 1.x.

    I understand that you would prefer that we use the “key sharing” feature instead but I can’t require any downloading and web registering for most of the recipient of my encrypted file. This could be blocked by their IT managers too.

    So I’ll stay on version 1.7

    thank you,

    #3558 Reply

    Svante
    Spectator

    Hello Raphael,

    The reason for excluding encrypt to .exe is actually not to do with the “key sharing” feature, it’s due to executable attachments usually being blocked, so the feature as little use.

    But, if you are sending the files, you should of course use the “key sharing” feature instead of having the problem of managing and communicating many different passwords to others.

    With version 2 – you can actually use the full-featured standalone portable to send with the encrypted files, so there’s little difference with version 1. You’ll still have the executable blocked usually, so you can also include a download link.

    #3559 Reply

    Sputnik

    Hi Svante !

    You always bring back the same reason for not offering the encrypt to .exe functionality : these .exe attachments are supposedly being usually blocked.

    But curiously, of all the people who would like to see back this functionality no one has ever complained about such a blockade. It seems that this functionality doesn’t show any problem for these people but, on the contrary, represent an ideal way of transmitting crypted files that works very well.

    Your affirmation is thus more hypothetical than based on the actual reality.

    Why would you not give people what they ask for and if they have a blockade problem with these attachments, it will be their problem, not yours.

    If there were to be an eventual blockade problem, there is anyway the possible solution to put the crypted file in an archive before sending it.

    #3560 Reply

    Svante
    Spectator

    Hello Sputnik!

    Well, it’s good that I’m consistent, right?

    The thing is I get quite a bit of support from people who do have problems with the feature and it getting blocked. So it’s a kind of “damned if I do, damned if I don’t”-situation.

    But, as I have mentioned, we’re thinking of bringing it back “by popular demand” ;-) That’s one of the things with these forums, that we get an idea about what people want.

    The self-decrypting files, does not actually harm security for the content but there are other issues to consider as well. One known use of self-decrypting AxCrypt files is to slip malware past virus checks (just like encrypted .zip files are used). In order to bring the feature back, we’ll also have to add some safe-guards against that too.

    #3561 Reply

    Sputnik

    Hi Svante !

    I understand that you have to concentrate yourself on the new Premium version, the one which will bring the bread and the butter on the table, that’s OK for me and also for most people here, I think.

    I understand that you are ready to supply support to the free version, at least for all the functionalities that are common to both versions. Solving a problem on the free version concerning a function that equally exists in the Premium version is equivalent to solving the problem for the Premium version. As more people will use the free version, more you will have the chance to discover possible bugs because of the number of users.

    The encrypt to .exe functionality would only exists in the free version and you don’t want to put much time in solving problems of .exe blockade as there would be no positive impact for the Premium version. I understand that perfectly.

    But you could make it clear that this encrypt to .exe functionality is supplied as is and that it comes with no support at all in case of blockade or any other issue for which you would decide to offer no support.

    I think that doing so you would satisfy a majority of free version users and the people who would not be happy because they don’t get any support in a case of blockade would maybe represent only a minority.

    Thus, you would certainly have a great amount of v1.7 users that would turn to v2, helping you to find all the bugs that probably exist in the code and helping you to find new ideas.

    I repeat here what I have already said in another comment in a different topic : you are better to get the maximum of v1.7 users to switch to v2.

    You see that I can also be consistent… :-)

    #3590 Reply

    Svante
    Spectator

    Hi Sputnik!

    Actually, the motivation for removing the self-decrypting option was not connected to Free vs. Premium as such. I just didn’t (and still don’t) think that it has sufficient merit.

    That it’s not just to re-introduce it does have some connection to Free vs. Premium in the sense that we’re still very resource-constrained, so there’s a natural limit to what can be done in a given amount of time. If I had limitless resources, I would probably just add it back, since it would then be easier to do so than to defend the (still in my mind correct) decision to not include it in the first place.

    Another similar issue that went the other way is AES-128 vs. AES-256. For the vast majority of encryption users (not just AxCrypt) in the world, there’s absolutely no difference in achieved security. However, AES-256 is very much in demand, and it does not hurt (anymore – it used to due to performance reasons) so there it is!

    #3592 Reply

    Sputnik

    Hi Svante !

    Never forget that for a large part of AxCrypt’s users, what is important is not what YOU think but what THEY think, even if you are absolutely sure to be right.

    In fact, those who actually disagree with you would maybe do the opposite if there was not any Premium version and that AxCrypt was entirely free, because maybe the bad idea for them is not more the new way of transmitting crypted files than the fact that they have to pay for this while it was and is still free in the old version with the encrypt to .exe functionality.

    If it would take a long before you re-introduce the encrypt to .exe functonality, if you ever re-introduce it, I think that this is not a great problem because v1.7 is still working good and maybe so for a couple of years to come, so it leaves to you a great amount of time ahead of you to do the change.

    But I don’t think that the people who really feel the need for such a functionality will switch to v2 because there is no way for them actually, with this version, to send crypted files to others free of any cost.

    One problem for you here is that you risk to loose the contact with those who will decide to stay with v1.7 : it is possible that many of them will not come on your new website on a regular basis just to check if the requested functionality have been added or not and they will maybe not come in great number in the actual forum to report bugs in the new version that they will not be using and they will not also bring new ideas for this new version.

    From another point of view I want to say here that I am not telling people what to do, I think that everybody is mature enough to decide by himself what he’s going to do. I am just saying what I think is the real situation for many users and I am aware that I may deceive myself on this or on anything else.

    #3594 Reply

    Svante
    Spectator

    Thanks Sputnik,

    We appreciate your input. And, I mostly agree that it’s not what I think, but what you think that mostly matters. Except when it comes to actual security. AxCrypt will never add features just because it makes some users feel secure, unless the feature actually does add some security or at least does not lead people to think it’s more secure than it is.

    That’s why I brought up the AES-256 example – that’s there because a lot of users want it. Not because I want it.

    I think you’re bringing up an important point too which is separate from the “encrypt to .exe” function. That’s sharing between users. Your text made me think that maybe I’ll add a function so users can add secondary, or “sharing” passwords to their files for that particular purpose.

    I’ve added a proposal to our issue list with that feature. You can follow progress here: https://bitbucket.org/axantum/axcrypt-net/issues/131/add-sharing-password .

    #3597 Reply

    Sputnik

    Hi again, Svante !

    Quote : “And, I mostly agree that it’s not what I think, but what you think that mostly matters.”

    In fact I was not telling that what matters is what “I” think, but what “THEY”, the requesters of the encrypt to .exe functionality, think. Maybe I should have made clear from the beginning that I have never used this special functionality and that all what I try to do is to clarify the situation of all those who have asked for the re-introduction of this functionality in v2.

    Concerning the introduction of secondary or “sharing” passwords, this would maybe be interesting, but as long as this new functionality would be free of any charge.

    This could satisfy a couple of those who request the reintroduction of the encrypt to .exe functionality, specially those who mainly like this functionality because it is free.

    But I think that there are other users who like this functionality not just because it is free but maybe because it is the most handy for those who receive the crypted file : they have nothing else to do than double click on the file and to enter the password to open up the file, no software to download and/or to install.

    However, I agree with you that it is maybe not the ideal way to proceed because the sender of the such crypted .exe file have to tell the password to the sharee and this password can’t be revealed in an email because it is not safe at all : the most secure way to reveal the password to the sharee is by a direct contact with him and sometimes it is not very convenient. I understand that the way to share crypted files through the actual Premium version is maybe the easiest one, but you have to pay for this service and many people are not ready for this.

    Another point here is that the person to who someone will send a crypted file will eventually be someone who will have himself to send back another crypted file to the original sender as an answer to the first sent crypted file. In this particular case an encrypted .exe file is not really needed because both of the correspondents need to have AxCrypt to be installed on their computer in order to encrypt the file they want to share.

    Finally, I think that those asking for the re-introduction of the encrypt to .exe functionality should clarify better their thought on this matter and explain clearly why they think it is a must and you, Svante, I think that you should modify the actual v2 so to allow users to send crypted files freely to others.

    If the way the crypted files are shared in the actual Premium version is really the easiest one and the most secure as you say, the people who share this opinion will surely accept to pay for such an optimized service. I personally do think that this Premium version is what the companies should look for.

    Maybe some people will think that it is difficult to know exactly what is my real thought on this subject because I may say things that will appear as contradictory from time to time : these people are right because I do not consider that the thought should be static, but should always be treated as a work in progress till all the possibilities have been carefully studied. I don’t anymore trust people who have a fixed and static thought and who are not able to question their own positions.

    I was not saying this specifically for you, Svante, but for everyone, including myself.

    #3598 Reply

    Svante
    Spectator

    Hi Sputnik,

    I should have been clearer. When I wrote “…you think/want…” I did not mean you Sputnik, I meant someone else, any/many/all AxCrypt users. What you called “they”. So, we are saying the same thing here.

    The shared password feature would be free. Needs some thought, but it could be a good idea actually.

    Thanks!

    #3744 Reply

    Barkeley

    I understand all is a matter of priority in development and I would personally give the priority to an android version, so much convergence and share between computers and android devices are growing fast.

    I would stress however how much those exe files have their own advantage apart from sharing.

    At a moment when I’m still confused with using version 2 and before making the step from 1.7 on my other computers, I’m glad I can still open those exe files no matter which version I have… or not yet.

    For encrypted archive you don’t use on a daily basis it is nice to think it may still work the day you will need them while the software is no more available (or gone to a full paying version :) )

    I am glad to have some of those “exe” files still running after few years when the software is no more available, even if it is not about encryption.

    #3748 Reply

    Svante
    Spectator

    Hello Barkeley,

    We agree – mobile is our highest priority for the next development.

    As for self-decrypting, there are just so many disadvantages. I really think that having a self-contained, stand-alone, fully-featured executable is much better, and fills the same function. We’ll be ensuring that it can run well without any server or internet access too, for that reason among many.

    #3765 Reply

    Barkeley

    I’m glad you are giving an android version some priority.

    I’m not sure about what you call “self-contained, stand-alone, fully-featured executable” comparing to the exe files version 1.7 could produce.

    I am (was! ) glad to have on an USB key, attached to my key ring,  some personal (sensitive) info in a 1.7 ver exe file.

    Travelling (even if I travel with a laptop, which may crash or get stolen…) I knew I could open it to any host computer without having to install AxCrypt on the said computer.

    Host doesn’t mean “systematically hostile”!! It could be at friends’ or public computer in an hotel or cybercafé where you take standard precaution not to let any trace, without installing or registering anything.  This doesn’t mean zero risks at all but is fine when used in emergency.  Actually less risky than losing your ring key with a cristal clear file on it.

    Any equivalent with ver 2 would be appreciated.

    regards.

     

     

     

Viewing 15 posts - 1 through 15 (of 20 total)
Reply To: some suggestions for AxCrypt
Your information: