GPA development

Bernhard Reiter
Wed, 21 Jun 2000 10:34:26 +0200

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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 to provide.
> > 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
> validity.
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
> valid).
Bernhard --=20 Professional Service around Free Software ( = =20 The FreeGIS Project ( Association for a Free Informational Infrastructure ( --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (SunOS) Comment: For info see iEYEARECAAYFAjlQfhAACgkQh9ag3dpKERb4GwCgyskBkavHGFuQY8mJHtyeAeqa TloAniL/Jhb//mWX9cpsYKoBm6PBozKQ =J/Mp -----END PGP SIGNATURE----- --8X7/QrJGcKSMr1RN--