<p dir="ltr"><br>
> Usability is about putting user goals first, period.  If your users do<br>
> not need a thing to accomplish their goals, you do not force it on<br>
> them.  Now, your users don't always know what they need, I hear you<br>
> exclaiming.  That's true.  However, if you want to suggest this, it<br>
> can't be your ego saying "me big cryptographer, me tell users what<br>
> really matter", which is frankly most of what I've heard here.  You<br>
> need evidence.  You need field experience.  You need testing.  And<br>
> then you need to explain what you've done to your users so they can<br>
> take it into account.<br>
><br>
> This isn't (just) about deniability.  This is about the entire process<br>
> of security design and the failure of this community to engage in it,<br>
> as indicated by the continued treatment of deniability as a<br>
> first-class property and the arguments presented for it.</p>
<p dir="ltr">But why are you repeatedly dismissing the value of deniability if usability is the focus? </p>
<p dir="ltr">If you want to be as constructive as possible, try to help us figure out what is reasonable to expect from an end user (how much are they willing to learn before using it for security critical tasks?), and how to build interfaces and systems that can match those assumptions being made. </p>
<p dir="ltr">IMHO lack of deniability (permanent provable authencity) is the greater deviation from standard expectations. There's a design philosophy of "least surprise". It is definitely applicable here. The consequences of deniability won't be surprising, the consequences of provable authencity for a lifetime of online activity would be. </p>