We have taken swi5t to a new level. Based on the same technology used by swi5t, we have launched MakeSends, a secure file transfer service.
It's simple: You pick a file to transmit, type the recipients' email addresses, and an encryption password.
MakeSends then encrypts the file for you using your password, uploads the encrypted file onto the internet, and notifies the recipients by email. The recipients click on the link in the email, and type the password you share with them.
Files are encrypted before being uploaded, and decrypted in your friend's web browser after being downloaded. The confidentiality of your documents is therefore guaranteed even if hackers intercept the email, or the encrypted document.
As opposed to swi5t, you do not need to install any software on your computer. Try it for free at www.makesends.com.
When starting swi5t for the first time, you may see a message from your firewall or internet security suite asking you if you want to allow swi5t to access the internet. You are seeing this message when swi5t checks for new versions.
With version 1.7, we added an automatic update check to swi5t to keep you posted when new versions appear. We recommend you to allow swi5t to do this check, and to update swi5t whenever a new version appears. New versions not only add features, but may also improve the security or fix bugs.
For the techies among us: when starting swi5t, it makes a request to
to check for news and updates. If that page has changed, it is displayed on the screen.
Swi5t never transmits your passwords or documents to the internet, and works fine without internet access.
The new swi5t 1.8 is online. Besides bug fixes and small improvements, we have added the possibility to upload the encrypted HTML file directly onto a FTP server. This comes in handy for users who want to share their documents through an FTP drive.
Do you like the new version? Are you awaiting more features? Share your feedback with us.
We are putting our files and data, sometimes private and confidential, on the internet via emails, websites, and cloud services. Our data is being surveyed by governments or businesses or even by individuals with malicious intent.
Encrypting our data is perhaps the safest way to protect it from unwanted access. But encryption only provides the desired safety if it is used correctly:
Using HTTPS, the data is encrypted between your web browser and the server only. The server decrypts the data to store or process it. This leaves plenty of possibilities for potential hackers.
In some cases, the data is re-encrypted by the server for storage. That does not add a lot of security, since the encryption keys are stored on the server (or unfar from it) as well. This is akin to locking a door but leaving the keys behind. The protection is minimal and cannot be verified by the user.
End-to-end encryption therefore remains the only secure option.
HTTPS is widely used across the internet, and touted as the secure version of HTTP. In contrast to HTTP, data remains encrypted for the transmission between server and client. However, HTTPS has several weaknesses, allowing surveillance agencies to readily decrypt your HTTPS transmissions.
First, HTTPS allows for different encryption algorithms, some of which are outdated and known to be weak. Which algorithm is being used is negociated between your web browser and the server when a connection is established. Web browsers are pretty lean about that: if the server does not support any of the strong algorithms, they content themselves with a weak encryption algorithm - without asking or telling you. While most servers nowadays are configured to use strong algorithms, it is not easy for you to check (or enforce) that.
Weak encryption can be broken in real-time with readily available tools.
Second, HTTPS relies on a hierarchic certificate scheme. Certificates are issued by VeriSign, StartSSL, and many others, and used to check the identity of the server. Whenever you connect to DropBox, for instance, you want to make sure that you are talking to a DropBox server, and not to a hacker pretending to be DropBox. To prove that, the server signs his reply with a (private) key, and sends the corresponding certificate to your browser, which then checks the signature, as well as the validity and trustworthyness of the certificate.
That scheme is simple and strong – technically. In practice, however, there are two severe issues:
According to a recent study1 by Facebook, about 0.2 % of all HTTPS connections use a forged certificates.