secure-transmit is a file transmission service that allows you to transmit data of any size, from anyone you like, to anyone you like. You can prove that the data was only transmitted to the people you designated. You can prove that the transmission completed. You can prove that the correct data was transmitted. You can attach detailed, personalized instructions telling your correspondents what you would like them to do. All of your data and metadata is only accessible to you and the people with whom you intend to share it. No client side infrastructure needs to be installed on any of the correspondents’ machines. You don't need a subscription, an account, or a long term relationship with secure-transmit to use the service.

Electronic communications occur every day. But occasionally, you need to transmit data of some significance for a particular task. Perhaps you are transmitting your financial records to your accountant, or sensitive legal documents to your lawyer, or complicated design documents to your vendor. Transmissions are communications that have consequences, should the information being transmitted go astray or awry. They require some combination of the following attributes: There is a lot of data to be transmitted. It is essential that the data be secure in transmission. It is crucial that the data not be accessed by anyone other than the desired correspondent. The data being transmitted needs attached instructions, explanations or warnings. Feedback on the state of the transmission is required. After the data is transmitted, proof of the transmission is required. secure-transmit is designed to satisfy the requirements of data transmission. For most people, data transmissions occur infrequently. This means that the user community for data transmission infrastructure within any organization is large, but diffuse. Almost everyone needs to transmit data occasionally. Almost no-one needs to transmit data daily. Most market alternatives or improvised solutions do not fit this use case well.

You should consider secure-transmit: When you need to occasionally or intermittently send or receive data with a changing collection of people, and you don’t want to manage another user account or subscription service to accomplish these communications When you need to be certain with whom you're corresponding When you need to be sure that nobody else can intercept your data in transit, including employees of the transmission service you're using When you need to keep records of what was sent and received secure-transmit is for securely transmitting a well defined packet (even very large in size) of data between a well defined set of correspondents, for a well defined purpose, and keeping track of what was sent from whom, to whom, and when.

When you define a transmission, you name the correspondents who will exchange data in the transmission. You will be required to define for each correspondent the proofs of their identity, including yourself. At a minimum, a correspondent must have an email address, but they can also be required to demonstrate that they control a phone number (voice or text), on which they will receive one time security codes. In addition, a correspondent can be associated with a public key, and to prove their identity they will be required to demonstrate that they possess the private key paired with their public key. Finally, a password can be attached to a transmission, and all correspondents must be able to demonstrate their knowledge of the password as a further proof of identity.

When you define a transmission, you provide proofs of identity for all correspondents, including you. secure-transmit requires that you click on a link and provide your proof(s) of identity before alerting any of your correspondents of the transmission. Your proof(s) of identity are shared with all of your correspondents, as well as the assurance that secure-transmit has verified them all (email, and optionally, phone, private key, and password). Your correspondents should recognize your proof(s) of identity, and if they do not, they can feel free to check them (by sending an email or calling a phone number), or totally disregard your transmission as being untrustworthy.

When data is uploaded for transmission, it is stored in an AWS S3 directory, encrypted with keys that are not stored by AWS. (The AWS storage mechanism is called Server Side Encryption, with Client Side Keys). The unencrypted file is never stored in the file system or memory of any server, and the decryption keys are inaccessible to secure-transmit without information held only by the correspondents. Furthermore, when the transmission is defined, you can specify a geographic region where the encrypted data will reside, which is sometimes required by various regulations. Finally, when the transmission is defined, you will be required to define a file retention period, after which the data being transmitted will be automatically deleted. If you like, by selecting the gear on the Transmission screen, you can request notification by text or email when this deletion occurs.

The metadata associated with a transmission define the proofs of identity of all correspondents, and any instructions to be shared with correspondents. In addition, all activity associated with a transmission are logged, to allow the sponsor of the transmission to know that their data was correctly received. All of this data is stored in secure-transmit's internal database, but it is stored in such a manner that it is not accessible to secure-transmit without keys held only by the correspondents. Every record in secure-transmit's internal database is encrypted with its own key. The keys are not held by secure-transmit, but instead are held by the correspondents. In the course of the transmission, when files are uploaded or downloaded by correspondents, each of these actions requires the correspondent to pass a key to secure-transmit, and secure-transmit will use this key to locate and decrypt the correct record. Only then will be metadata associated with the transmission in question be revealed to secure-transmit, so that it can perform the actions necessary to make the transmission happen. Furthermore, when the transmission is defined, a records retention period can be defined. When this period expires, all of the records associated with the transmission will be deleted. Because of the structure of secure-transmit's internal database, it is impossible for secure-transmit to know what transmissions are in flight, or to know what customers are being served at any time. Because of the requirement that every record have its own decryption key, a single decryption of a record in secure-transmit's database can reveal data about only ONE transmission. secure-transmit cannot leak a list of user account names and data, because it has no list of user accounts. In fact, secure-transmit does not have user accounts as most systems implement them.

secure-transmit doesn't require a user account, and doesn't have subscriptions, as previously mentioned. secure-transmit can be used in an entirely ad hoc manner, where the sponsor pays for each transmission individually. If a user or organization anticipates lots of transmissions, there is a flexible mechanism for allowing a bulk purchase to be used by a purchaser who can define a set of transmission sponsors. At the moment, secure-transmit allows user to try the service for small transmissions (<10MB). Larger transmissions cost money, and a transmission cannot be initiated without payment having been arranged. It is possible to pay for a single transmission. A transmission whose total data to be transmitted is less than 1GB costs $3 USD, a transmission whose total data to be transmitted is less than 5GB costs $5 USD, and a transmission whose total data to be transmitted is less than 20GB costs $10 USD. Data is accounted when it is delivered to the recipient(s). If there are 5 recipients, each downloading 1GB, this is a 5GB transmission. If a transmission racks up downloads larger than what was paid, or if a free transmission exceeds its 10MB allotment, downloads will be suspended until the funding is increased. If you expect to have a recurring need for transmissions, it is cheaper and easier to pay secure-transmit a lump sum which can be used to fund a large number of transmissions. This model should be thought of like charging up a transit card and using it to ride the subway a bunch of times, or paying into an EZPass account and riding the turnpike as much as you want. Each transmission debits a balance in a tab, and when the money is used up, the tab will stop working, or the user can pay more money into the account. Like a subway card, the tab should be thought of as a token that gives access to funding, rather than a user identity. There are two different kinds of tabs - Basic and Enhanced. You can open a Basic Tab with a deposit of $35 USD. When you open the tab, it will create a passphrase associated with your proof(s) of identity. When you want to fund a transmission, you provide the passphrase, and the charges associated with the transmission will be debited from the tab. Only someone who can provide your proof(s) of identity can use your passphrase. A Basic Tab allows you to grant the ability to use the tab to two other identities. This grant is known as a User Proxy, and each of the User Proxies of a Basic Tab will be associated with a single identity and will have its own passphrase. This is designed for a small office, or a family, to share access to the Basic Tab. An Enhanced Tab can be opened with a deposit of $250 USD or more. Enhanced Tabs are designed for use by a mid to large organizations. To grant access to the tab to many employees, the Enhanced Tab is not limited in its number of proxies. Conceivably you could grant an individual User Proxy to each employee you would like to give access to the tab. Alternatively, there is another type of proxy available to the Enhanced Tab to simplify management of a large group of employees. A Domain Proxy associates a passphrase with an email domain. Any person whose proofs of identity connect to a specified domain will be able to use the proxy. When you check the tab records it will reference all charges against the account by proxy and by sponsor, so charges can be ascribed to the sponsor who generated them. Enhanced Tabs can also limit the use of a proxy to a specified number of transmissions, a specified maximum expenditure, or a specified lifespan. When you create a Basic or Enhanced Tab you will be able to access an interface that allows you to grant or retract access through the proxies associated with your tab.. The proxy mechanism allows the person who funded the tab to maintain their own set of authorized users without requiring any assistance from secure-transmit. The charges from secure-transmit do not scale in any way by the number of users accessing the account. Charges are based only on number of transmissions and the amount of data transmitted.