DonationCoder.com Software > fSekrit

LATEST VERSION: fSekrit 1.40 shrinkwrapped!

<< < (3/9) > >>

MerleOne:
Hi,
I am starting to use it on a regular basis and I have a few suggestions/observations/questions :
1/ When a text has been saved in read-only, could it be possible to turn r/w on again, without creating a new file
2/ Would it be possible to enter a unique password at the beginning of a session so that files created next are all saved with the same password, which would reduce input errors.
3/ When typing the password at save time, could it be possible to un-hide the password (optionally)
4/ Is the support of "rich text" doable a in future version ?

Great tools as it is, but I feel this would improve my user experience even more...

Edited :
5/ Also, when I open a read-only note, select new, the new file is still read-only, so it's impossible to enter text.

f0dder:
1) I've been considering this, but don't really know - the original request for read-only actually wanted it to be even more restrictive than it is. Which use-case leads to enabling and then disabling read-only mode?

2) You can already achieve this by choosing "Save As"... I could do a "don't clear passphrase on file->new" option, which would be easy for current version of fSekrit. However, it would be more intuitive for file->new to open a new fSekrit editor window, rather than the current method of just clearing the contents. If/when that is added, the cache feature would require passing the passphrase on the commandline (or some more complicated IPC method), which I don't really feel like doing. Commandline is a security risk, other IPC method is too much code overhead for too little win. I'll ponder a bit about this.

3) yep, and it's something I've wanted to add. Next version will have copy/paste disabled on the passphrase dialogs, but an "unmask password" checkbox (which will obviously clear whatever you've already typed when you unhide).

4) should be, considering I'm using a RichEdit control :) - actually I'm currently specifying explicitly that I only want pure text on edit->paste, it'd be less code to acched rich formatted text. I do not plan on adding rich editing features to fSekrit, but pasting from an external document should be doable.

MerleOne:
Thanks for you reply and this info.

The use case about read-only -> read/write is the following.

I open a new fsekrit window, import some text by dragndrop, save it as readonly, then I realize I want to modify something.  Too late !

f0dder:
That use-case sounds fair enough, but then we'll also have to consider why you enable read-only... as I interpret the original request, it was to avoid "tampering" with the encrypted notes. To achieve general "protect me against my fumble-finger saving", you could set the +R attribute on your file.

But let's have a discussion about this :). And if you have anything to say about the other four points (or anything else), let me know - I'm open for comments.

MerleOne:
About the +R attribute, I thought at first it was equivalent to the 'read-only' feature and was looking for this attribute to be set (I never read the manual!).

Lifting the 'read-only' atttribute makes sense when you want to update the content of a note easily but not inadvertedly.  If fsekrit could ask for the password when doing it, it would avoid accidental change of the note content and still give some flexibility ?

Regarding hide/unhide password , I understand the temptation for erasing but it would only enhance security in a not indispensable way.  If you're in an "open" environnement, with some eyes behind you, you just don't leave your PC and don't unhide the password.  I would keep the two input zones, without erasing, but simply unhidden.  This would solve the important problem of Caps lock or numlock being activated and a different password being typed than the one you want, especially if you also remove copy/paste.

Navigation

[0] Message Index

[#] Next page

[*] Previous page