Re: Scope for self-destructing email?

[Matthias Merkel <[e-mail]>]

Well. The problem with a central authority is that it has to be trusted.

In case my company will serve as central authority we would provide public audits which everyone could use to verify we followed the rules.

In case some other organisation would serve as central authority I'd suggest to require it to provide these audits as well.

On Aug 16, 2017 6:50 AM, vaibhav singh <[e-mail]> wrote:

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