-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/04/2014 00:12, Nicolai Josuttis wrote: > > > Am 20.04.2014 21:38, Philip Jackson schrieb/wrote: >> Hi Nicolai, > >> I've downloaded and installed the 1.7a1pre-test version. Patrick's link >> shouldn't just be clicked on though. Firefox downloaded it and tried to >> install and then rejected it as 'not being suitable for Firefox' and then >> presumably deleted it (because I couldn't find it in the downloads >> directory). > >> However, one question : in the preferences/sending tab, how do your new >> options cohabit with the second check box item 'Always trust people's >> valid keys' ? > > >> Does that option cancel your 3 options for full, marginal, unknown trust >> levels? > > No, it's the other way round: Currently the options don't affect each other > (which might be wrong). > > That is: - I can select to auto send encrypted emails to people for which > the keys have unknown trust although "always trust" is NOT selected. - I > was thinking about some alternatives, though. One is that if not "always > trust all keys" is selected I disable the last (two) options. That would be > a visual feedback for what you asked. - Another is that the > auto-send-options only ask whether to send encrypted if all keys are known > and "trusted" and what "trusted" means is derived from the "always trust > all keys" option".
In any case, I think the display of your new options at the same time as the second check box item (Always trust people's valid keys) presents a confusing display. A display logic should be decided that prevents them both being displayed at the same time. > In any case I am not sure whether the whole approach I programmed is > good/intuitive. So allow me to explain some details of the current > implementation: > > - Option "always trust all keys" is enabling or disabling the option > --trust-model always This is documented in the GPG manual as: >> Skip key validation and assume that used keys are always fully > trusted. >> You generally won't use this unless you are using some external > validation scheme. >> This option also suppresses the "[uncertain]" tag printed with > signature checks when there is no evidence that the user ID is bound to the > key. Sounds pretty dangerous (but is often selected). see below - > > - My options affect whether and how the Key Validity and Owner Trust > columns of the key management are considered. For example, if I need > marginal trust, both columns have at least to have that level. (Note that > validity/trust is sorted according to: - disabled/revoked/expired - > explicit mistrust - unknown trust - marginal trust - full/ultimate trust ) > "auto send encrypted" would never happen with keys being in the first two > groups. No option should change that IMO. For the other three groups, I > have provided the three auto-send-enc-options. > > However, now we have different trust models (one by GPG and one by the key > manager) THis also can be confusing. On the other hand, dealing with what > is defined in the key management dialog can be more intuitive than dealing > with the rules of the web of trust. > > Consider for a moment we would have no recipient rules and people don't > know the rules of the web of trust. The simple approach for the novice > either would be: a) You can disable auto encrypt. Then you have your > general default about whether to encrypt which you can change for each > mail. b) You can select to auto encrypt if all keys are known (ignoring the > trust level, but not mistrust or revoke/expired). This is like selecting > "always trust all keys" (and as dangerous) The question of 'dangerous' puzzles me somewhat. Where is the danger in trusting a key ? You are implying that one should not encrypt to a person whose key is untrusted - whether in the sense of its validity or of its owner's trust. There could be danger to some people in the mere act of being seen, by an observer, to be using encryption and in those circumstances, the trustworthiness of the owner or the key would be irrelevant. But even if the key validity has been fully ascertained, and the owner is 'fully trusted' in the sense that applies to the web of trust, one would have to consider the nature of the material (secrets) being written in the message - - and here again, the gpg trustworthiness of the owner and the key validity are not the most relevant factors. What is more relevant are the personal qualities of the owner - will he betray you ?, is he a stooge planted by the enemy/competitor? These are not questions that gpg web of trust or key validity can answer. My thoughts are that the more emails that can be encrypted, the better. A higher volume of encrypted mails provides a better safety screen for all so it is better to 'trust all keys' and to be extremely careful what you write if you do not "know" the recipient. > c) You can select to auto encrypt only if keys are known AND you have > declared some trust. In my implementation you can either require at least > either marginal or full trust. > > The current approach I implemented gives you this principle, with the > behavior that for b) and c) "always trust all keys" doesn't matter. If I > give "always trust all keys" a semantics here, the effect would be to let > c) and b) behave the same if "always trust all keys" is enabled. May be > that's more intuitive. Especially if I disable the last two options when > "always trust all keys" is selected. > > But is all might be too complicated ... (for novices or experts or both?). > Hmmm, questions over questions ... As I wrote: I am not sure. Opinions > please. > > Nico It seems to risk becoming overcomplicated to the point where an operating manual needs to be attached to the software. And we all know that operating manuals are never read and understood correctly - that's where the classic response to a query came from - RTFM ! , because people don't. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTVFLoAAoJECa9UAojVDpjPrUH/0q6hdaVeX0idDhS3kWPqmZC 7xWokpFJqRdrewc7tB+pdxVaFbvOzVr9lgQmN0OnF7EbdbnTuMLNR4D54xGGF1MQ h1KZpRgGWZ8lYLcReQSGc+np0GjU5GBksaHLfJ+Wk5uc4FdL1BmpMRD0aFhDOuGN Bs2kGN7gpOTje8XHx5bZ8hTeWkZ6PVGvPzGP5VxFm3dELsM0/i05Ypswfxf1CZib /+ukhBQXbkzkBe68uf5vGv6alGFWm+Aswgqkegfo51GgZ09DIVwSYSnnEU+jo+XF dUlQqqnPJu4xDAEAwZtbg8MmS19N7vOLkoNke9XsUCLuX5xhAm2YJsUva1DXwpM= =2Nzp -----END PGP SIGNATURE-----
0x23543A63.asc
Description: application/pgp-keys
_______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
