Technically YES - but only for a brief moment, and we do not store it unencrypted. Read more about this under "Is TUArmor zero knowledge?". Your data is sent to us through an encrypted channel (SSL), and it is then prepared for storage by encrypting it using your optional secret on the server. After encryption the data is then saved in the database. If you used an optional secret, the data in our database is inaccessible without that secret. The same can be said for a key-me-please post, as those are basically secrets created from browser accessible data (IP address, user-agent string, etc) The same is true on the way back out. When the data is viewed, and the optional secret is supplied, we decrypt the data at the server and display it to the user over SSL. Again - we don't store this information unencrypted, but this does not meet the definition (in our opinion) for true zero-knowledge system.

Short answer - no, but we try to be. Let's look at what zero knowledge is. Zero knowledge means that the host never knows the unencrypted contents of the data being stored. The advantage of this (over just basic transmission encryption practices) is if the host server is comprised, the data it houses cannot be accessed without decrypting it first using a specific key (presumably not known by the host). In the case of TUArmor, the data is sent over SSL and then encrypted at the server level using a random key and stored in our database for a period no greater than 24 hours. If the user supplies an optional secret, then the encryption key is based around that secret and the data can only be decrypted with it being present. We don't store unencrypted data in our database (exceptions being some meta data - see "What data does TUArmor collect?"), but while it is in memory we could potentially peak into what was being posted. This is true for a lot of online sharing services. In reality, the only real way to be zero-knowledge is if the client handles all the encryption. TUArmor is still in beta, and if the interest exists, we will look at adding client side encryption/decryption to our roadmap.

NO! During the post creation process you are given a URL to expire the post early if you want. Once a post has been purged, it is gone and we cannot undelete that request.

NO! The keys for the admin URL are randomly generated and are NOT the same as your post url. If you lose it - we will NOT send it to you again.

While we were testing this internally, we liked the idea of an optional secret but realized in some cases it was more cumbersome to come up with something than to just ignore it. The key me please allows the recipient to determine how the text is stored. They can tie it to their user-agent string, ip address, or type in their own password. That is then formed into a one-way hash that needs to be recreated before the post can be decrypted. You can create as many key combinations as you want. The keys are also reusable. If you want to create a key for a user (say for example, based on IP address), then feel free to do that. That is an easy way to further lock-down a post without requiring a user to do anything special.

TUArmor is in beta. Which really means "we aren't quite sure we have all the bugs worked out yet".

No. We do not track IP information within our database. Our web servers and firewall do keep standard access logs, but we do not marry any connection information into our data storage or meta tables. At the moment, we do utilize Google Analytics on the home page to capture usage information as we baseline if this service has a future. This analytical information is currently not being collected when displaying stored information.

Surprisingly, very little. We have two main data classifications as it pertains to sharing and hosting uploaded text. The first is our data storage table. It contains the data key (what is randomly generated and used for your custom URL), the encrypted data (if an optional secret is provided, we cannot decrypt this data without it), and when the entry was created. In our meta table, we track any options submitted with your post. For example, we keep a view counter, an expiration date (max 24 hours, user customizable down to 1 hour), view limit, and a storage id. The storage id is NOT the same as the storage key (mentioned above). This is a simple seed value we use to connect the data sets together. This is important to understand as once the data has expired (either via time or view limits), we purge the encrypted data and the url key from our storage database. The meta data, however, is retained so we can monitor usage statistics and provide an admin screen for you to verify the data has been purged. Remember, our meta data is keyed using a simple seed integer that is of no value once they url key and encrypted data have been washed.

We don't.. and that is a problem for any sort of long term viability. In the future we hope to find ways to monetize this service through premium features.

The same team behind textuploader.com. It was proudly crafted in Austin, Texas, USA.

Textuploader.com is a popular text uploading service. However, there are no real privacy functions with that site. The developers for TUArmor wanted a simple site we could securely offload small snippets of code, data, or text that wasn't connected to any other service. For example, we can secure text by an optional secret, user-agent string, ip address or any combination thereof. We also don't have to worry about managing the text as it will never live past 24 hours, and any other trigger could expire it sooner (view count, etc)

You should! TUArmor is not a password management tool, a file repo, or a backup service. Those services are great and widely used (even by the TUArmor team). Those services also offer ways to securely share data. However, we always felt uncomfortable sharing data through these services as if you don't watch out you can be your own security worst nightmare. Ever started a share and forgot to turn it off? Yeah - it can stain some underpants pretty quickly when you realize your error. TUArmor is not connected to those services. The data stored on TUArmor is not backed up or stored for longer than 24 hours. If there is some sort of breach, your other services aren't in any danger.

We try to be. Our goal, however, is not really to be anonymous. Our goal is to simplify the transmission of small snippets of information quickly and securely. If you are expecting a Tor like experience, please don't. Running from the police? This isn't the service for you. We purposefully don't retain information or store it in a readable format for the exclusive purpose of peace of mind - not for obscurity from legal repercussions. Please don't abuse our service.

All traffic to the website is handled over SSL. After that, we encrypt the data using AES Rijndael 128. The encryption keys are assembled using the generated url keys and any supplied user secrets. If the user doesn't supply a secret, that would make it possible for someone to decrypt the hosted data if it had not been washed and they had access to the TUArmor storage database.

Any page view. Whether it be yours or someone else's. A page refresh also counts. If you create a post and limit it to one view, and then check the page to admire your handy work - that post will be expired for the next view.

Great! Send us your thoughts - in English - to [email protected] Not all requests will receive a response, but we do read them when received through the appropriate channels. If it is not in English, it will be deleted.