UI terminology for calculated validities

[Hauke Laging]

Am Do 01.05.2014, 23:48:08 schrieb Daniel Kahn Gillmor:

> We're talking about building infrastructure here.  That means that (by
> definition) we're making choices for some people who will never know
> the details of the infrastructure.

That is correct. But there are two groups of decisions:

a) how to do it

b) whether it can be done at all or not


> The greater the complexity of the infrastructure, the more fragile it
> is,

That may be true but there is a level of complexity below which the 
infrastructure (of a complex problem) becomes useless. That is about the 
current state of the WoT.

Crypto is about protecting information. The level of required protection 
depends on the (kind of) information. In order to decide whether a key 
is suitable to protect a certain data you mandatorily need certain 
information about the key. Most of which cannot be taken from the 
certificate. That is not an opinion but a simple but broadly ignored 
fact. Ignored in order to protect the users from too much complexity...


> And infrastructure which supports social graph publication is
> inherently more leaky than infrastructure which declines to define a
> way to do so.

That is correct. But there is a difference between "supports" and 
"enforces".


> I know you and i disagree on this Hauke; it's not the first time.

Disagreements are not a problem per se. It's perfectly OK to disagree on 
the recommendation whether to publish such information or not. And it is 
OK to debate how to present (or hide) this information to the user (e.g. 
via ‑‑expert in gpg or "expert settings" in some GUIs).


> i want to ensure that we don't
> make it easy for users to do things without thinking that might be
> harmful in the future.

That is a noble intention and I don't doubt it. But if ensuring turns 
into disabling then a line is crossed.

In my courses I tell the crypto newbies to forget the WoT. Not forever 
but until they have a firm understanding of the technology. That is a 
useful way. Crippling the technology isn't.


> If i was designing a road in a mountainous region, i'd want to build
> the road with guard rails too, even though some people might prefer
> to drive off the edge.

That would probably be a good idea if there is only one road. In 
contrast to rather expensive mountain roads we can build a second road 
more or less for free. I guess there wouldn't be a concensus that the 
better road should not be built just because some unqualified driver 
might use it though he has been told not to do so. If somebody 
deliberately endangers himself – so be it. That possibility is no reason 
to prevent those users with a brain from improving their situation.


> I *still* haven't heard
> an argument that makes sense to me for why the added complexity of
> certificate signing policies and certification levels are things that
> will help users use these tools.

I repeat myself:

Crypto is about protecting information. The level of required protection 
depends on the (kind of) information. In order to decide whether a key 
is suitable to protect a certain data you mandatorily need certain 
information about the key. Most of which cannot be taken from the 
certificate. That is not an opinion but a simple but broadly ignored 
fact. Ignored in order to protect the users from too much complexity...

"help users use these tools" not in the sense of "making the current use 
easier" but in the sense of "using the tools for applications which are 
today not (or hardly) possible".


> The added complexity hurts rather than helps adoption and use.

Added complexity would not even affect unqualified users (if well 
implemented).


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140502/a87ef380/attachment-0001.sig>