1 files changed, 2 insertions, 2 deletions

diff --git a/content/entry/re-dkim-show-your-privates.md b/content/entry/re-dkim-show-your-privates.md
index 3aac7b1..ef9a2ee 100644
--- a/content/entry/re-dkim-show-your-privates.md
+++ b/content/entry/re-dkim-show-your-privates.md
@@ -14,8 +14,8 @@ As Ryan notes in their blog post though, email deniability probably won't protec
 
 The Session team's blog post, "[Session Protocol: Technical implementation details](https://www.getsession.org/blog/session-protocol-technical-information)", says more or less the same in the context of their own private messaging protocol:
 
-> "As previously mentioned, cryptographic deniability is often something that is largely ignored by the court system and the media. If contextual information can be provided around screenshots, this is often enough to lead to a conviction or personal damages, regardless of the presence or absence of cryptographic deniability. 
-> 
+> "As previously mentioned, cryptographic deniability is often something that is largely ignored by the court system and the media. If contextual information can be provided around screenshots, this is often enough to lead to a conviction or personal damages, regardless of the presence or absence of cryptographic deniability.
+>
 > Instead of designing a cryptographic protection, Session will add the ability to edit other users’ messages locally, thus providing a way to completely forge conversations. Since signatures are deleted after messages are received, there will be no way to prove whether a screenshot of a conversation is real or edited, diminishing the value of screenshots as evidence."
 
 Programmers could still change the Session source code to save the message signatures anyways, but I highly doubt anyone is doing this. By contrast, email servers *do* retain email signatures even after emails are already validated. So there's more of a concern for email being cryptographically undeniable than Session Private Messenger.