Wed, 21 Jun 2000 10:34:26 +0200
Content-Type: text/plain; charset=us-ascii
On Wed, Jun 21, 2000 at 08:24:42AM +0200, Werner Koch wrote:
> On Tue, 20 Jun 2000, Jan-Oliver Wagner wrote:
> > a) Keyring management and the management of files management are largely
> > different tasks. They should be divided into separate tools.=20
> Agreed - however it should also work as a standalone tool.
That would make one standalone tool for the file management, basically=20
reimplementing a filebrowser again to be really useful. But you are
right we might need it as an interim solution.
> > Note that this might be very difficult in practice.
(This was related to writing plug-in for the filebrowsers on major
platforms.) But the design concept has to be there. Maybe filebrowser
developers will help if they know in detail what functionality they have
> > b) The keyring management dialog should transparently show
> > all important information in one window.=20
> Not all - Did you read the Whitten report on the PGP GUI. =20
> One important thing is still missing: An option (which is enabled by
> default) to suppress most information - the standard mode; the other
> information should only be shown in expert mode.
True. May I should have written: Only the (most) important information.
But it should show it at once, the way it is done now with all the
windows is very cumbersome from a usability perspective.
> > 6. Show a nice counter/clock to give a visual impression on the
> > remaining time of passphrase validity.
> I don't understand this. There is no such concept of a passphrase
Maybe time of passphrase in memory would be the right expression.
If people start using encryption a lot, they do not want to enter their
passphrase each single time they operate. So we should think about a
place on where to store the passphrase. As we cannot assure secure
connections between plug-ins(MUA and filebrowser) and the main gpa,
each of these applications might need to hold a passphrase for a certain
time. This situation still needs more thinking and engineering.
> > d) Help for novice users:
> All are very important.
> > So what can we do in the next few days?
> I don't know - I will be away from all computing equipment from
> tomorrow to Monday morning.
We all are on the testing crew, too.
> > trust levels:
> > Unknown
> > don't trust
> > trust marginally
> > fully trust
> Please don't mix up the trust level and the key validity:
> I prefer to say "assigned owner trust" for the 4 leveles you give.
> They are parameters needed to calcualte the validity of a key - the
> answer on the question "how far do you trust the owner of this key to
> correctly sign other keys and whether she understands all the
> implications" [quite long question and not easy for the user].
> For the calculated validity (sometimes also called trut in GnuPG :-()
> there should be only 2 values:
> o Key is valid
> o Key is NOT valid
This is the best concept.
One fundamentally flaw is, that people need to learn about
the trust concept. Otherwise they will not be able to use GPG in a
useful manner in the future. This is a main concept. We cannot hide it
completly. Maybe we should go with at least three different=20
possibilities so that user start top think about what happens.
We probably do not have time to fully integrate this within the few days
to LinuxTag. So we should add something like color or simple icons
to the owner trust levels and key validity.
> The use of the term "valid" has been proposed by some folks who
> regulary do courses on PGP and this should make it much easier for a
> user to understand what this mesag is about (who understands what:
> "The key is marginally trusted"? - replace it by the key is NOT
Professional Service around Free Software (intevation.net) =
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (SunOS)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----