Self destructing messages with ziti

Ziti Overlay
1

I thought to ask if anyone has any ideas on how to go about implementing a self destructing message with ziti.

Here are some of the specs:

  • you need to be enrolled in the network to access it
  • once you access it, you will have a time limit to view it
  • you cannot download the file, only view it
  • once the time limit is up, the message is destroyed.

I want this to be more than a messaging app… as it will need to support the use of xls and doc formats natively. I am sure this can be done with some special type of platform.

In relation to the destroying of the content, I was thinking of a one time use token… that could be linked to an authenticator application. Hence, one the token expires, the file decryption no longer works… which then triggers some type of deep data cleanse

This use case has some really interesting applications… even if I can deliver only 25% of this capability with ziti

Keen for your thoughts, comments and feedback.

2

You’d need to code an implementation of the management REST API. The OpenAPI v2 spec is built in to the API itself at https://${CONTROLLER_URL}/edge/management/v1/docs.

You could code a flow that waits for a timestamp to arrive before revoking access to a particular application. You would probably implement this as an update to a “service policy” that grants the access, or by removing an identity role attribute that confers the access that you wish to revoke.

The most immediate and simple form of this would be a shell script that calls the ziti edge update identity command with the necessary options to drop the identity role that grants the access.

1 Like
3

To me this sounds more like an application Layer more than a ziti layer issue. There are many programs out there that sort of do this. Also known as a ticketing service. I used one ages ago called dl. That allowed you to load a file up to it, and it would email the recipient. You could expire the file based on time, downloads etc.

I would think this would be an application delivered over a ziti network if you only want ziti enrolled clients (ie known users) to access. If you are thinking a general user service then I would not use ziti. Reason being setting up mTLS for mutual authentication is beyond most peoples threshold.

You could interrogate ziti for a user list and then send an email out a unique email to the user with an access code to access that content one-time or however any times you want them too.

Could the system host many different files at the same time that a user could get to one time? If they do, then dropping the identity access to the service would mean they would need to get all the files at once or otherwise would be dropped access. Also, when would you remove the access token - being that ziti is really cool and drops access within seconds. If it was a web page and you hit it and then it drops access, you won’t be able to get the file. If you delayed the removal of the identity for a few minutes, then they could download the file more than once, or if they go to the page and get shoulder tapped or equivalent before they download and the identity gets removed then they cannot fulfill the request. Having an application control when and how also allows auditing on who and when they get the file/message no matter how long it took them.

Just my thoughts

1 Like
4

Very interesting feedback… thanks for your comments.