MacCTC Wish List
Last updated Sunday 21st February 1999.
This is the MacCTC wish list page. This lists improvements that have
been suggested for the MacCTC application. These are classified accordingly
to how likely there are to be incorporated. Please send in
your
suggestions.
Have done (but not yet released)
The following are done in the development version, so will automatically
be included in the next release.
-
Busy indication
-
When working on a long task (e.g. generating a key), MacCTC now displays
a snipping cursor.
Will Do
The following changes will definitely be done as soon as time/effort is
available.
-
Support for Remailers
-
Allow the user to send via N-remailers with the application automatically
doing allow the encryptions and (if asked to) randomly selecting the remailers.
-
Automatic key collection
-
Automatically generate mail to request keys from a key-server. The processing
of replies should already be automatic.
-
Generate and read password encryption "key blocks"
-
These are blocks added to password encrypted block to tell the decrypting
program what algorithm is used for generating the key from the password,
and the encryption algorithm. Currently CTC neither generates nor reads
these.
Might Do
The following changes might be done. However it is not clear if there value
as features will ever justify the effort involved. This may either because
they are difficult, or because I am dubious of their value or a combination
of the two.
-
Enable Apple Menu while Preferences panel is open
-
The only reason this is might do is that I am not sure why this
isn't happening. If and when I work out how to do it I will. Strictly I
have management to enable the menu, just it doesn't do anything if there
is a MacCTC modal dialog up.
-
Record and respect 'preferred algorithms'
-
This is actually quite complex to do properly, and especially to sensibly
present the choices to the user. It is very simple with one recipient,
you use the first algorithm listed that you can. It is reasonably simple
with two recipients, you either do or don't have an overlap of preferred
algorithms. If you do you use one of the common algorithms. If you don't
you warn the user, and generate two separate messages instead of a single
one decryptable by both.
However with three of more you may be into the problem of different
ways of partitioning the users into several messages. In practice there
will have to be some sort of compromise between being general and being
implementable at reasonable effort.
Won't Do
These are changes that I will never make. Either because I don't think
they are worth the effort, or that I don't think the facilities is worth
having. This does not mean that they won't be done. However if they are
someone else will have to do the work. (If you are set on having one of
these, you may have to do it yourself.)
-
Encrypt to self
-
This is a feature of PGP-classic that I consider to be a Bad Idea®.
I will be writing a whole page on this an related issues presently.
-
Implement Key-Recovery
-
Key-Recovery Keys are a 'feature' of PGP5 and later. This is not so much
a Bad Idea®, as treason. OpenPGP does not implement this, nor
will CTC. CTC now discards any key that is recorded as being for this purpose.
webmaster@bifroest.demon.co.uk
