UI terminology for calculated validities

[Nicolai Josuttis]

Am 25.04.2014 19:43, Bernard Tyers schrieb/wrote:
> At the risk of being flamed, can I suggest asking the users what
> they think?
> 
> Nicolai, by the look of it you've carried out some user research.
> I guess so by the "real world" discussion you posted in a message.
> 
Well, the "users" I asked were just ordinary people in my family
(typical smart phone users).

The funny thing is, today I discussed this again with one.
The outcome was surprisingly a renaissance of the term "valid"
but in a slightly different sense.
Valid meaning "validated by me or other people I trust".

And the result was to provide three "trust model" options
in a mailer:

--------------------------------------------------------------
To send encrypted, accept
a) only keys validated/signed by me personally
b) only keys validated/signed by my or others I trust
c) all keys that are neither disabled nor expired nor revoked
---------------------------------------------------------------

With the following tooltips:

a) only keys validated/signed by me personally
  Tooltip:
      This option is provided to deal with the danger of faked keys,
      not trusting anybody else.
      Validated keys are keys either signed by you or
      signed by other people you trust.

b) only keys validated/signed by my or others I trust
  Tooltip:
      This option is provided to deal with the danger of faked keys,
      trusting other people you categorized as trustworthy.
      Validated keys are keys either signed by you or
      signed by other people you trust.

c) all keys that are neither disabled nor expired nor revoked
  Tooltip:
      This option forces encryption whenever you have
      a key that is not disabled by you or revoked/expired by the owner.
      Because these keys are not necessarily validated
      by you or people you trust, there is a risk
      that you use faked keys so that others than the
      requested receivers can read the content of the encrypted email.

Some of these policies would then be supported by GPG directly,
but I might have to implement one or two in enigmail directly:
a) This would allow only keys where the user locally signed the key
   with at least casual checking
   - Is there an option I can use to have this policy?
b) This would allow keys valid according to the WoT.
   As the current implementation seems only to check the first key
   for an email address, the workaround would have to be implemented
   in enigmail directly.
c) b) but also allow unknown.
   This would match --trust-model always

And:
We might even split option a) in:
a1) allow keys where I personally signed with casual verification
a2) allow keys where I personally signed with extensive verification

-- 
Nico