Security Best Practices link

Cloud Share is designed to be secure by default, but the security of any transfer ultimately depends on how you use it. Follow these practices to ensure your transfers remain private and tamper-proof.

Share the secret through a separate secure channel link

The tunnel URL and the secret token together are the keys to your transfer. Never send them together through an insecure channel.

✅ Do:

• Share the secret via Signal, WhatsApp, or another end-to-end encrypted messenger
• Read it aloud over a phone or video call
• Send it via an encrypted email (PGP/S-MIME)
• Use a password manager’s secure sharing feature

❌ Don’t:

• Include the secret in the same email or chat message as the tunnel URL
• Post either the URL or secret in a public Slack channel, GitHub issue, or document
• Send it as plaintext in a regular email

⚠️ Warning: Anyone who has both the tunnel URL and the secret can receive all queued items, including ones you haven’t sent yet. Treat the secret like a password.

Stop the sender after the transfer is complete link

The sender’s tunnel stays active and the secret remains valid for as long as the process is running. Once your recipient has received everything they need:

1. Stop the sender with Ctrl+C
2. Confirm the terminal session has exited

Stopping the sender:

• Closes the Dev Tunnel (the URL immediately becomes unreachable)
• Invalidates the secret
• Clears all queued items from memory

  # The sender runs until you press Ctrl+C
cloud-share-sender
# ... transfer completes ...
^C   # Stop the sender
  

Use cloud-share for one-time transfers link

Cloud Share is designed for ephemeral, one-time transfers — not as a persistent file server. Each sender run generates a new secret, and the queue is not persisted to disk.

✅ Intended use:

• “I need to send you this file right now”
• One-off sharing between two machines you control
• Transferring credentials or secrets to a new machine during setup

❌ Not intended for:

• Leaving the sender running indefinitely as a file server
• Sharing files with many recipients over an extended period
• Replacing a proper file-sharing or document management system

Use a zip password for sensitive files link

When sharing particularly sensitive files (private keys, certificates, credential files, financial documents), use the Zip Bundle feature with a password:

1. Use the Zip Bundle tab instead of the File tab
2. Enter a strong password in the zip password field
3. Share the zip password with your recipient via a different channel than the secret token

This provides double encryption:

• AES-256-GCM encrypts the zip during transport (keyed to session secret)
• AES-256 encrypts the zip entries themselves (keyed to your password)

Even if someone recovers the decrypted zip bundle, they cannot access the files without the password.

⚠️ Warning: If you forget the zip password, the files cannot be recovered. The password is not stored anywhere in the system.

Understand where the secret appears link

The secret token appears in:

• The sender’s terminal output (startup banner)
• HTTPS query parameters on every API call (?secret=<token>)

The secret is protected in transit by HTTPS/TLS. The query parameter is encrypted by the TLS layer — it is not visible to network observers between the sender and the Dev Tunnel relay.

However, the secret may appear in:

• Shell history if passed via --secret flag: use --secret carefully in scripts
• Server-side logs if verbose logging is enabled
• Browser history/dev tools on the sender machine

For most use cases this is acceptable. If you are in a highly sensitive environment:

• Avoid using --secret as a command-line flag; use the interactive prompt instead
• Clear the receiver’s saved session file after the transfer

Rotate the secret by restarting the sender link

If you suspect the secret has been compromised (e.g. accidentally shared in a chat), simply restart the sender:

  # Ctrl+C to stop
^C

# Start again — new secret generated automatically
cloud-share-sender
  

A new secret is generated on every start. The old URL and secret are immediately invalid.

Understand the token scope and lifetime link

Clear saved receiver session data if needed link

The receiver saves the last-used URL and secret to receiver-session.json. If you are on a shared machine or want to ensure no trace of the session remains after a transfer:

  # Windows
del "%USERPROFILE%\AppData\CloudShare\receiver-session.json"

# macOS / Linux
rm ~/AppData/CloudShare/receiver-session.json
  

ℹ️ Info: The saved secret in receiver-session.json is the secret from the previous session — it is already invalid because that sender has stopped. However, you may still want to clear it for hygiene purposes on shared machines.

DevTunnels authentication link

The sender authenticates with Microsoft Dev Tunnels using your Microsoft or GitHub account. This login is saved to preferences.json. To revoke it:

  cloud-share-sender --reset
  

This clears the saved OAuth tokens and forces re-authentication on the next run. You can also revoke the DevTunnels app’s access from your Microsoft or GitHub account settings.