Re: Scope for self-destructing email?

[vaibhav singh <[e-mail]>]

On Tue, Aug 15, 2017 at 8:42 AM, joel jaeggli <[e-mail]> wrote:

> On 8/14/17 12:01, vaibhav singh wrote:
> > Hi,
> >
> > As some of you may already know, General Data Protection Regulation
> > (GDPR), about to be enforced in the EU within months, and calls for
> > strict regulations for Right to rectify communications, Right to be
> > forgotten , Pseudonymisation and Data portability.
> >
> > 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).
> >
> > 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 order that you have some assurance that the demands provided at the
> input side are honored on the receipt side you need effectively
> end-to-end control over the system, that is the sender, receiver, and
> any intermediate hops are part of the same administrative domain such
> that any control imposed is actually implemented. That might be
> practical for an email system but not generally for the email system.
>
>
>
>
We found an archived thread of a similar proposal for XMPP being made in
XMPP Standards list as well. There were a couple of neat outcomes from that
discussion, which I would like to present here as well.

There were a couple of improvements/compromises we were thinking:

1.) The popular opinion is that this will be unenforceable on the client;
we can actually drop the idea of clients being forced to clean up those
messages altogether. Our initial plan to propose this was to let the sender
of the email decide whether he wants to store his emails on the server or
not; that would be what we will be focusing on then.

2.) Matthias suggested a way to implement feature discovery for this:

*Have a central list (possibly mentioned in the documentation of this) of
IPs and domains that really support this feature (a central registry that
maintains the list would test if it really works; I'd offer that my company
can do this but that would have to be decided by the public). If a SMTP
server advertises the feature and it is on the list send the mail without
any warnings, if it advertises it but is not on the list warn the user that
the server might potentionally fake the ability to do this. If it does not
advertise the feature but is on the list warn the user that the server may
not have the ability. If it neither is on the list nor advertise the
feature ask the user if they want to send the email without
self-destruction enabled.*

This seems to work for me. Any problems which could come up with having a
central authority for this feature?

3.) We may have to assume that the sender and receiver of the mail are
trusted; this would mean that the mail may have to be encrypted prior to
sending:

*Encryption would allow you to establish a level of trust with the
recipient. I.e. you encrypt the message and mark it for ‘self destruct’.
You then have to trust the recipient to destroy it (but at least you don’t
have to trust every server along the way). This gives you some level of
reassurance that the message will be destroyed, assuming the recipient is
trustworthy (and runs trustworthy clients).*

4.) A really boiled down version of ephemeral mails could just mark the
mail "outdated" if the information provided in the mail is not expected to
hold good after some time, instead of actually expunging the mail.



*why not try to accommodate both realitys and define a feature which is
called "Invalidation of Messages" or similar instead of "Destructible
Messages". The goal of this feature should be to mark messages in a way,
that the client somehow can mark the message as "not being relevant
anymore" or something like that. So it could still be displayed but grayed
out for example telling the receiver that the message can be ignored.
Additionally there could then be added an attribute "deletionrequest" which
can be set for clients which really want to have destructible messages like
Signal does.*

Any thoughts?

-- 

Regards,
Vaibhav Singh