Session Protocol: Technical implementation details
&gt; <i>In practice, cryptographic deniability is often disregarded when it comes to court cases or media reporting.</i><p>That&#x27;s because implementers fail to follow through.<p>The signal <i>protocol</i> enables deniability, but the signal <i>application</i> does not. For a communication app to deliver actual deniability it needs <i>at least</i> to provide the ability to add, remove, and edit messages locally, with timestamps and everything. That edit feature must be easy to use, and easy to find. Ideally, it would be advertised when you first use the app. It must be crystal clear to any judge that screenshots from this app is no better than &quot;he said, she said&quot;.<p>For offline protocols where messages stay online for a long period of time (file encryption, and Signal to a lesser extent), we should also have an easy way to forge messages to oneself. With protocols from the Noise framework, this is easy to implement. From a user&#x27;s perspective, we just need a &quot;forge false message to self&quot; button, where you specify the &quot;fake sender&quot;. Only then can encrypted files be reduced to a &quot;he said, she said&quot; situation.<p>Cryptographic deniability is not enough. We need <i>plausible</i> deniability, and that can only be achieved when (i) forgeries are easy, and (ii) everybody knows it.