Re: Scope for self-destructing email?

[Dave Cridland <[e-mail]>]

On 14 August 2017 at 20:01, vaibhav singh <[e-mail]> wrote:
> With regards to this, me and my friends were thinking about the idea of a
> self-destructing email, wherein the sender will mark the mail to be
> destroyed (expunged from the server) once the receiver(s) have finished
> reading it/after a time period chosen by the sender.
>
> Another enhancement to this idea was a notification which will be sent from
> some (Exploding email RFC) compliant MUA, in case the receiver refuses to
> delete the email from the client. (I know Snapchat is a poor example here,
> but they apparently send notifications to the originator of the snap in case
> any receiver tries to capture the screenshot of the snap. This is, in
> theory, what we are trying to do here).
>

It's pretty much unenforceable. It is, however, theoretically possible
to build a mechanism to request the later deletion of a message using
MSGTRACK (RFC 3885) as a basis - but that's likely to be merely a
means to let others know you made an error rather than a real way to
delete a message.

> I would also like to know about things (working groups, internet drafts etc)
> which are being done to enforce GDPR to
> email and Instant Messaging especially.

In Instant Messaging, things are slightly different.

Because there's an online, synchronous communications path, then
protocols like XMPP can use "Perfect Forward Secrecy" techniques to
limit access to the original message, and protocols such as OTR, "The
Signal Protocol", and OMEMO all deliberately prevent non-repudiation
post-facto.

Therefore after a conversation, it is difficult to decrypt the
messages (you'd need to persistently store ephemeral keys) and
impossible to strictly prove that the message as captured was not
simply a forged log (although since computer logs are usually
admissible evidence, this is of debatable use).

In terms of Pseudonymity, XMPP builds this into chatrooms (XEP-0045)
and is making this slightly better in its replacement, MIX (XEP-0369).

However, all of these still boil down to keeping honest users honest -
the GDPR applies to people and organisations, and not to computer
systems per se. It means we (system and protocol developers) are
required to consider these use-cases to remain relevant, certainly,
but the actual compliance to these laws is a matter for the end user.

Dave.