One Time Share (1ts.dev)

The service allows sending self-destructing messages.

It can be useful when you want to share content-sensitive information in a conversation with someone, and you don't want this information to persist there after being read.

Disclaimer

Disclaimer of Warranties and Limitation of Liability

This service is provided "as is" and without warranties of any kind, either express or implied. No representations or warranties are made regarding the operation or availability of the service, the accuracy or completeness of the information provided herein, or the reliability of any service descriptions. The contents of this page are not legally binding and may be subject to change without notice.

The provider expressly disclaims any and all liability for damages arising out of or in connection with the use of this service or the information provided, including but not limited to direct, indirect, incidental, punitive, and consequential damages. Users assume full responsibility for their use of the service and any information obtained through it.

The important parts first

Don't send any context to your secret information in your 1ts's

OK:

Hi, can you unlock my PC so I can remote-login into it, my login is User123, my pin is here: [link to 1ts]

Not OK:

Hi, can you unlock my PC so I can remote-login into it, I've sent you all the instructions how to do it here: [link to 1ts]

Why:

If someone gets the link before the intended recipient or the content of it is leaked in any other way, then you would want the leaked data to be as abstract and untraceable as possible.

If you have a separate trusted end-to-end encrypted messenger with your recipient, prefer using it over 1ts

The example above but even better:

Hi, can you unlock my PC so I can remote-login into it, my login is User123, I've sent you my pin in our encrypted chat in Telegram.

Unfortunately, this is not always possible, that's why this service exists.

Telegram is used as an example, you choose what you trust.

Use end-to-end encrypted communication to send any information you don't want to disclose publicly

This is not only relevant to 1ts, but if you care about your information, use end-to-end encrypted messengers. As of 2024, most messengers and means of online communication are not end-to-end encrypted.

If your conversation is not end-to-end encrypted, all your messages can be read by the service provider and leaked to malicious users. Not only that, but the messages can be modified without you knowing (e.g. in theory while your message is being delivered someone who has access to your conversation can intercept the 1ts link, read it, create a new link, and give it to your recipient).

Don't share your private keys

Never share your private keys or their recovery codes over the internet, not with 1ts not even with end-to-end encrypted messengers.

Also avoid sharing access passwords and similar information, if you absolutely need to do so, change them quickly after.

What can this server do?

• The messages that you send over 1ts.dev can be accessed by the link only once
• The message is removed from the server even before it receives the recipient
• The message will be removed after the time you've chosen if it is not read by that time
• After the message is removed the service doesn't track whether the message even existed
• You can additionally encrypt your message using a password

What information does the service store?

• The message (encrypted)
• The expiry time of the message
• The token associated with the message
• A flag to indicate whether the message is password protected or not

How is encryption used?

The service uses multiple layers of encryption to ensure that the content of the message is not exposed to unintended readers:

• TLS Encryption: TLS is used to encrypt communication between the server and the clients.
  Protects: It secures all meta-data, such as the token for accessing the message, the expiry date, and whether the message is password-protected.
  From whom: It ensures that anyone who might intercept the communication between you and the server (or between the recipient and the server) cannot read this data.
• Browser-side Encryption: All messages are encrypted in the browser before being sent to the server. The encryption key is embedded in the shared link, which the recipient uses to decrypt the message in their browser. This key never reaches the server, even when the link is accessed to retrieve the message. AES-128 with GCM is used for encryption.
  Protects: The contents of the message.
  From whom: This ensures that even authorized (or unauthorized) users who have access to the server cannot read the contents of the stored messages.
• Optional Password Encryption: Messages can be additionally encrypted with a password before being encrypted for sending. AES-128 with GCM is used for the encryption, and PBKDF2 with 600000 iterations of SHA-256 (using a 128-bit salt from the AES-128 key from the above point) provides basic protection against brute-force attacks on the password.
  Protects: The contents of the message.
  From whom: This step ensures that if the link is intercepted before the recipient accesses it, the interceptor cannot access the contents without the password.
  Note: If you send both the link and the password in the same message, anyone who can read the link will also be able to read the password. In that case, adding password encryption doesn't make the message any more secure.

What are the limitations?

• Since the message is removed from the server before sending it to the recipient, delivery is not guaranteed. If the recipient has a poor internet connection, the message may not be delivered and would need to be resent.
• The service does not differentiate between read, expired, and non-existing messages.
• Only text messages are supported.
• To avoid spam and overuse, there is a strict limit on how often messages can be created, and this limit is shared among all users.
• The size of the message is restricted.
• The maximum possible message storage time is 30 days.