On Tue, Aug 15, 2017 at 9:50 PM, vaibhav singh <vaibhavsinghacads@xxxxxxxxx> wrote:
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?
I think there are two potential lines of development here, though I confess I am skeptical of the value of either.
The first is providing a facility that declares a particular message to be automatically overcome by events at a particular time, leaving it completely up to the recipient how to process the message based on that metadata. There are simple message types (today's weather, lunch availability, etc.) that could be thus set to be marked OBE when no longer relevant. Some clients might choose to auto-delete them or auto-archive them when the time is reached, but this would be because of their preferred handling and not a guarantee to the sender that the sender's intent is being honored. A message header like OBE-At: could be registered provisionally without much hassle, and you could see if it saw implementation and use.
The second is a trickier question: is it possible to construct a message such that it is cryptographically non-repudiable within a set time frame but repudiable thereafter? I think the answer to this is yes, but it relies on a carefully crafted interaction among the use of limited validity certificates, requirements to confirm validity with a CA, and CA behavior. You could deploy that in a limited environment, in other words, and see if it was useful enough to make the behavior standard. It's less clear to me, though, why it would be useful. The one scenario I can construct is financial, as part of the flow for placing a time limited order, but the flow seems strictly worse that a simpler flow that includes the time limit for the order within a message which is permanently non-repudiable.
regards,
Ted