ASL Files — Source library
Public documentation snapshot: 2026-10-17
Share files with access you control
ASL Files provides encrypted file sharing and storage with password-protected Secure Send links. Control access and link expiration, and review who holds the encryption keys before sharing a document.
Share files with access you control
A shared link should never be the key.
Share files with access you control
Encrypted file storage where a link alone opens nothing, plus a password-protected way to send one file out.
Share files with access you control
Built for: A solo therapist or small practice holding client documents that occasionally have to go to an attorney, a parent, or another clinician · An office manager who needs a departed staff member's files to still be deletable by somebody · A clerk or administrator storing records for one organization who must never be able to see another organization's · Anyone who has to send one sensitive document to one person outside the office, once, and have it stop working afterwards
Choose how to share an encrypted file
Keep internal access tied to the organization. An authorized session is required for a workspace download. A copied file address alone is not permission to read the stored document.
Choose how to share an encrypted file
Set the limits before sending outside the workspace. Secure Send uses a link and a separate password. Choose the expiration and allowed open count, and send the password through a different channel.
Choose how to share an encrypted file
Understand keys and early cancellation. The storage service holds the encryption key, so this is not end-to-end encryption. A sent link ends at its chosen limits; stopping it earlier requires deleting the file.
Choose how to share an encrypted file
Keep sensitive information out of filenames. The full explanation below covers live index metadata, recipient access, integrity checks and backups.
Choose how to share an encrypted file
Read the complete workflow · Explore all features · Read the questions and limitations
ASL Files exists because of this.
You have a document that should not travel casually. A custody evaluation. A signed lease. A resume with a home address on it. Somebody outside your office needs it, and the tools within reach are email and a link. So you attach the file, or you drop it in a share drive and paste the URL, and from that moment the document is exactly as private as everyone who ever sees that message.
ASL Files exists because of this.
Forward it once and it is out of your hands for good. The services that promise better usually stop halfway. "Encrypted at rest" often means the bytes are scrambled while the file name sits in plain text right beside them, and "Jane Doe custody evaluation.pdf" says most of what you were trying to hide without anyone opening anything.
ASL Files exists because of this.
A long, unguessable URL gets treated as the whole lock, so one accidental paste into the wrong thread hands over the document. Backups exist on paper and nobody has ever restored one. And when the person who uploaded a file leaves the practice, their documents sit there permanently, because the system only ever let the uploader delete them.
ASL Files exists because of this.
Then there is the other half of it. You rarely just need to store the file. You need to give it to one named person, one time, and have the door close behind them. Most storage tools answer that with a public link, an indefinite lifetime, and a shrug.
ASL Files exists because of this.
The backups were proven by an actual restore into a second running copy of the service, not by a backup job finishing without an error.
ASL Files exists because of this.
The nightly archive is encrypted as well as the files, so file names, which often disclose as much as the contents, are protected too.
ASL Files exists because of this.
Holding a download address is never enough, and the one place a browser cannot carry a session normally is narrowed to reading a single named file, never to writing.
ASL Files exists because of this.
A request that reaches across organizations gets "not found", not "not allowed", so it reveals nothing about what exists.
ASL Files exists because of this.
Sending a file safely to an outsider is part of the product, not a separate service to buy and wire up.
ASL Files exists because of this.
The storage service installs no third-party packages at all, so there is no outside supply chain sitting between your documents and the service that holds them.
ASL Files exists because of this.
The product's own change history, which we will show you, names real defects that were found and fixed, including one that had quietly made administrator deletion impossible, and corrects an earlier entry that overstated its own test coverage.
How encrypted file sharing works in ASL Files
ASL Files is the encrypted locker that sits behind the products you already use, and a way to hand a single file to somebody outside your organization. Every file is encrypted the moment it arrives, before it is written to storage, using AES-256-GCM.
How encrypted file sharing works in ASL Files
The key lives with the storage service alone. Applications do not receive the service encryption key, but an authorized download necessarily gives its recipient readable file contents. Stored blob contents are encrypted; filenames, types, owner labels, and sizes in the live service index are not.
How encrypted file sharing works in ASL Files
Keep sensitive information out of filenames. Every file belongs to exactly one organization and never leaves it. There is no cross-organization read anywhere in the product: not as a setting, not as an administrator override, not as a support path. If a request from one organization asks for another's file, the answer is "not found" rather than "not allowed", because "not allowed" would confirm the file exists.
How encrypted file sharing works in ASL Files
Holding a download address is not permission either. A valid, current session is required for every download, and the organization in that session has to own the file. A bare address that leaks out of a browser history, a proxy log, or a forwarded email is a dead end.
How encrypted file sharing works in ASL Files
Integrity is enforced on the way back out, twice over. The encryption itself carries an authentication tag, so a stored file that has been altered by anything at all fails to decrypt and the download refuses rather than handing back quietly corrupted bytes. On top of that, a file served into your own organization's workspace is compared against the fingerprint recorded when it was uploaded, and a mismatch is refused outright.
How encrypted file sharing works in ASL Files
That distinction matters most on the day it matters at all: a document that is wrong but plausible is far more dangerous than a download that visibly fails. Secure Send handles the outside recipient. You pick a file and get back two things that are meant to travel on two different channels: a link and a password.
How encrypted file sharing works in ASL Files
Email the link, read the password down the phone or send it by text. The recipient sees a plain page that tells them nothing at all until the password is right: not the file name, not the size, not who sent it, not when it expires.
How encrypted file sharing works in ASL Files
Get it right and the file downloads as a.zip that opens natively on Windows and macOS. You choose how long the link lives, from an hour up to thirty days, and how many times it may be opened, up to fifty; whichever limit is reached first ends it.
How encrypted file sharing works in ASL Files
You can take a generated ten-character password drawn from an alphabet with no look-alike characters, so it survives being read out loud, or set the password yourself so you can tell the recipient in advance, in which case use upper-case letters and digits, because the recipient page reads what is typed as upper case.
How encrypted file sharing works in ASL Files
Failed attempts and successful opens are both recorded. What the product will not do is take the link back: once a secure link is out, it ends at the expiry and open count you chose, and the way to stop it sooner is to delete the file.
How encrypted file sharing works in ASL Files
Deleting a file removes the stored copy and keeps the record that it existed and who removed it. Either the person who uploaded it or an organization administrator can do it, so a departed colleague's documents never become permanently stuck. Every night the whole store, index and file contents together, is snapshotted, encrypted under a separate key, and kept for fourteen nights.
How encrypted file sharing works in ASL Files
Encrypting the archive is the point rather than a formality: the archive is where file names would otherwise sit in the clear. That backup was proven the only way a backup can be proven, by uploading a real file through the live service, restoring the archive into a second, separate copy of the service, and downloading the file back byte for byte identical.
How encrypted file sharing works in ASL Files
A native Android app is coming. It receives a Secure Send without an account and keeps the received copy encrypted on the phone.
Everything in the current release.
The live service and the upcoming Android app are described separately below.
Encrypted before it reaches storage
Every file is encrypted with AES-256-GCM as it arrives, and only the encrypted form is ever written down. The key belongs to the storage service and is never handed to the applications that store files. The encrypted blobs do not expose their contents without the key. The live index still contains readable metadata such as filenames and sizes; the encrypted backup archive protects that index separately. This was checked on the live service, not only in automated tests: a real uploaded file was located in storage and confirmed to contain none of its own text.
The link is not the key
Knowing a download address gets you nothing. Every download also requires a live session that belongs to the organization owning that file, so a bare address in a browser history, a forwarded email, or a server log is a dead end. Where a browser genuinely cannot carry a session another way, a session can ride in the address itself for about an hour, and that path was deliberately narrowed to reading one specific named file, never to uploading, sending, or listing anything.
One organization, one wall
Files are visible only inside the organization that owns them. There is no cross-organization read path at all, and none was left disabled behind a flag for later. A request that reaches across returns "not found" rather than "not allowed", so an outsider cannot even confirm a file exists. An organization administrator has extra authority inside their own organization and none whatsoever outside it, and there is an automated check that holds them to it.
A tampered file refuses to open
The encryption carries its own authentication tag, so a stored file altered by a single byte cannot be decrypted and the download fails on every path rather than returning damaged content. Files served into your own organization's workspace are additionally compared against the fingerprint recorded at upload. Silently wrong data is worse than a loud refusal, particularly for a signed document or a clinical record, and there is an automated check that deliberately corrupts a stored file and confirms the refusal.
Secure Send: two channels, one file
Send a file to someone outside your organization without giving them an account. You get back a link and a password, and they are meant to travel separately: link by email, password by phone or text. The service never learns the recipient's address or phone number, and it does not send either half for you, so two-channel delivery only works if you actually use two channels. Whoever holds only one of the two has nothing.
Passwords a person can read out loud
A generated share password is ten characters drawn from a 32-character alphabet with the confusable ones removed, so there is no arguing over whether that was a zero or an O. You can also set the password yourself, which lets you tell the recipient what it will be before the link is even sent; it must be at least eight characters, and it should be upper-case letters and digits, because the recipient page reads what is typed as upper case.
Links that expire and stop working
You choose the lifetime, from one hour to thirty days, and the number of times the link may be opened, up to fifty. Whichever limit is reached first, the link is finished and cannot be revived. The page a late recipient sees says plainly that the link is no longer available and that a new one has to be issued, rather than leaving them guessing.
The recipient learns nothing until the password is right
Before the password is entered, the page shows no file name, no file size, no sender, no organization, and no expiry date. Wrong attempts are recorded against the share. The trade-off is deliberate and worth knowing: a recipient who comes back too late finds out only when the link stops working, so tell them the deadline when you send the password.
Deletion that still works after someone leaves
A file can be deleted by the person who uploaded it or by an organization administrator. That second path exists because of a real defect that was found and fixed: for a period, the administrator branch could never be true, which meant a departed colleague's documents were undeletable by anyone. Both paths now have their own automated checks, including one confirming an administrator still cannot reach outside their own organization.
A record of what happened
Uploads, downloads, deletions, secure links created, secure links opened, and failed password attempts are all written to a record the service only ever adds to, with who, what, and when. Deleting a file removes the stored contents and keeps the record that it existed and who removed it. That is deliberate: an audit trail with holes in it is not an audit trail. Reading that record back is an export we run for you, not a report screen you open.
Nightly encrypted backups, proven by restoring one
The index and the stored files are captured every night, encrypted under a separate key, and kept for fourteen nights. The archive is encrypted because the index holds file names and owner names, which disclose plenty on their own. The backup was validated by restoring it into a second, separate copy of the service and downloading a real file back byte for byte identical. A backup nobody has restored is a hope, not a backup.
Limits stated in advance, not discovered later
A single file can be up to 15 MiB. A listing returns the 200 most recent files, and there is no way to page further back than that today. File names are checked so that nothing can escape into another part of storage. These numbers are published rather than buried, so you can decide up front whether the product fits what you actually store.
Android app: receive without an account
The upcoming Android app lets a recipient collect a two-channel secure transfer without creating an account. Paste the HTTPS link and enter the password received through a different channel. The app rejects embedded credentials, private or local destination addresses, non-HTTPS connections, and nonstandard ports. Redirects, automatic network retries, and device HTTP proxies are disabled. An untrusted server is still an untrusted server.
On the phone, encrypted and under your control
Received bytes and metadata are encrypted with a key held by Android Keystore in no-backup app storage. Atomic writes preserve the earlier catalog if a replacement fails. A damaged catalog fails closed; the 100-file limit rejects a new save instead of silently dropping an older entry.
On the phone, encrypted and under your control
Export is an explicit choice through the Android file picker and may create a plaintext copy at the selected destination. The activity and dialogs restrict screenshots, unsaved secrets are cleared on backgrounding, and sensitive clipboard cleanup is best-effort. No ads, analytics SDK, broad storage permission, or background upload worker is included.
On the phone, encrypted and under your control
Local deletion is not a physical-flash-overwrite guarantee.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
The Android app requires network access but no broad storage or contacts permission. It carries no advertising SDK, analytics SDK, or long-lived server key. The generated app-private receiver permission is not a user data permission.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Files.
ASL Tickets
Files is the attachment store behind the ticketing engine, and the download addresses it produces are the exact shape Tickets already recognises. A file uploaded here can be referenced from a ticket or a comment straight away, so support conversations carry documents without a second storage system.
ASL Support
Support turns a message from someone with no account into a real tracked ticket. Alongside Files and Tickets it gives a product a support queue and encrypted attachments without building either.
ASL Vault
A copy of the key that unlocks the nightly archives is escrowed in the sealed credential store, so the archives survive the loss of the machine that wrote them. Vault is where a small organization keeps the handful of secrets that must outlive staff turnover.
ASL Therapy
A practice storing client documents gets encrypted storage, deletion that still works after a clinician leaves, and a password-protected way to send one record to an attorney or another provider.
ASL Municipal Utilities
Record storage for an office that must keep documents for one organization only, with an audit trail of who opened what and a safe way to hand a document to a resident or a contractor.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-09-20 The Android app gained ASL blue and navy styling, atomic encrypted local storage, integrity-checked tenant downloads, public-address validation at connection time, protected dialogs, and custom-password normalization for the deployed service.
Recent progress.
2026-08-14 the release now running lets the sender set the secure-link password themselves, so a therapist can read it to the recipient over the phone before the link is even sent, and delivers the file to recipients as a.zip that opens natively on Windows and macOS.
Recent progress.
2026-08-23 a native Android client reached version 1.0.0. It adds two-channel receipt with no account, an encrypted on-device library, export through the phone's own file picker, and an organization workspace that only ever holds a short-lived session and never a long-lived key.
Recent progress.
2026-09-02 the live service answers, unauthenticated file requests are still refused, and the expired-link page renders correctly.
Recent progress.
Pricing for ASL Files is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
What does it cost?
ASL Files is priced with the product it ships in. It runs as shared infrastructure behind other ASL products today, so what it costs you depends on which product you are buying and how much you store. Ask for a figure in writing before you commit, and ask what happens to it as your storage grows.
We already use a cloud drive. Why would we move?
For everyday working files, you probably would not, and we would rather say so. The gap that shows up in a small practice is narrower: the moment a document has to leave the building. A cloud drive answers that with a link, and a link that gets forwarded is a document that got forwarded. ASL Files never treats a link as permission, and Secure Send splits a handoff across two channels with an expiry and an open limit. If you never send anything sensitive outward, you have less to gain here.
Can you read our files?
The storage service can, because it holds the key that unlocks a file in order to serve it back to you. We will not tell you otherwise. What it means in practice is that a stolen disk, a stolen copy of the index, or a stolen nightly archive yields nothing readable, and that no application storing files here ever receives the key. If your requirement is that nobody at all can ever read the contents, you need end-to-end encryption between two people, and that is a different design.
How do we get our existing files in, and out again later?
Files go in one at a time through the product you use it from, so a move usually means bringing across the documents that actually still matter rather than everything you have ever kept. Coming out is the same shape: there is no bulk export button today, so a full extraction is a job somebody runs.
How do we get our existing files in, and out again later?
Two limits shape the plan: 15 MiB per file, and file names are stored as plain text, so anything confidential belongs inside the file rather than in its name. Tell us the volume and shape of what you have and we will tell you honestly how long it takes.
What happens to our files if we stop paying or stop using it?
You should get your files back in a form you can read without us, and you should get that promise in writing before you start, including how long the encrypted nightly archives are kept after an account ends. Fourteen nights of archives are retained during normal operation. Be aware there is no self-service export today, so an exit is a piece of work that has to be scheduled rather than a button you press. Any product that will not answer this question in writing is telling you something.
Is it actually ready, or are we the ones who find the problems?
The file service is live, and other ASL products use it every day to store, serve and secure-send files. The Android app is coming soon.
How is Secure Send different from emailing a password-protected zip?
A password-protected attachment lives in the recipient's mailbox forever and can be forwarded with the password sitting in the thread below it. Secure Send hands over a link that stops working on a schedule you set, or after a number of opens you set, and reveals nothing at all until the password is right. Failed attempts and successful opens are both recorded, so you can tell whether the file was ever collected. Two honest caveats: the delivered.zip itself is not password-protected once it lands, and a link cannot be cancelled early, so keep the lifetime short.
Can we cancel a secure link after we send it?
Not directly, and we would rather say that plainly than let you assume otherwise. A link ends when the time you set runs out or the open count you set is used up, whichever comes first. If you need it stopped sooner, deleting the file stops the link from delivering anything. In practice this means choosing the shortest lifetime and the fewest opens that will really work, rather than defaulting to the maximum.
Do you have backups, and has anyone actually restored one?
Yes, and yes. The index and the file contents are captured nightly, encrypted under a separate key, and kept for fourteen nights. The archive is encrypted because the index holds file names and owner names, which give away plenty by themselves. The restore was proven by uploading a real 40 KB file through the live service, restoring the archive into a second, separate copy of the service, and downloading the file back byte for byte identical.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
This is not end-to-end encryption. The storage service holds the key and can read a file in order to serve it. If your requirement is that nobody but the two ends can ever read the contents, this is not that product.
What should I know before I rely on it?
File names, types, and sizes are stored as ordinary text in the index, so a file name should never contain something confidential. The nightly archive is encrypted, so names are protected there, but not in the live index.
What should I know before I rely on it?
A single file can be up to 15 MiB. Video, disk images, and large data sets do not fit.
What should I know before I rely on it?
A listing returns the 200 most recent files and there is no way to page further back, so an organization that stores more than that cannot reach the older ones through the ordinary listing.
What should I know before I rely on it?
There is no bulk export and no bulk import. Files go in and come out one at a time, so a migration in either direction is a job somebody runs rather than a button.
What should I know before I rely on it?
A secure link cannot be cancelled once it has gone out. It stops at the expiry and the open count you chose, and nothing in the product pulls one back early. Deleting the file also stops it from being collected. Choose the shortest lifetime and the fewest opens you can live with.
What should I know before I rely on it?
A password you choose yourself must be at least eight characters, and should be upper-case letters and digits: the recipient page reads whatever is typed as upper case, so direct API callers must normalize self-chosen passwords consistently. Android 1.0.1 trims edge spaces and converts custom passwords to upper case before creating a transfer. Generated passwords are unaffected.
What should I know before I rely on it?
The delivered.zip is not itself password-protected. The password guards the page that hands over the file, not the archive afterwards. Once the recipient has it, they have an ordinary file.
What should I know before I rely on it?
The recipient page shows nothing at all before the password is entered, including nothing about when the link expires. That is deliberate, but it means a recipient who waits too long finds out only when the link stops working.
What should I know before I rely on it?
Files does not send the link or the password for you and never contacts the recipient, so two-channel delivery only works if you actually use two channels.
A shared link should never be the key.
Prefer email? contact@autosecurelogin.com
End-to-end encrypted file sharing or service-held keys: where ASL Files fits
ASL Files is for small offices, such as a solo therapy practice or a clerk keeping records for one organization, that need to share sensitive documents with one person outside the organization. Every stored file is encrypted with AES-256-GCM, and Secure Send gives you a link plus a separate password for the intended recipient, so you maintain control over how long the link works, from one hour to 30 days, and how many times it opens, up to 50.
End-to-end encrypted file sharing or service-held keys: where ASL Files fits
If you are comparing end-to-end encrypted file sharing with other options, one point matters before you choose a file sharing service. ASL Files is not end-to-end encrypted: the storage service holds the decryption key so it can return files to the people allowed to read them. If your rule is that nobody but the sender and the recipient may ever read the contents, you need a different design.
End-to-end encrypted file sharing or service-held keys: where ASL Files fits
Other plain limits: each file is limited to 15 MiB, file names stay readable in the live index, so keep sensitive data out of them, and a sent link cannot be cancelled early except by deleting the file.
Read the guide
Encrypted File Sharing: How to Send Files Securely
Read the guide
A practical guide that uses public, official sources and explains where this product fits and where it does not.
Before you choose a secure file sharing platform
Many services promise to share files securely. The promises sound alike, but the designs differ. Ask these questions before you trust one with a sensitive document.
Before you choose a secure file sharing platform
Who holds the key? With end-to-end encrypted file sharing, only the sender and the recipient can read the file. Other designs let the service read it so it can serve it back. Ask who, besides your recipient, could end up accessing your file.
Before you choose a secure file sharing platform
Is a link enough? If anyone holding the link can download the file, one forwarded email is a leak.
Before you choose a secure file sharing platform
Can you limit time and opens? A link that never expires stays a risk.
Before you choose a secure file sharing platform
What happens after the download? Ask how protected files stay once they reach the recipient.
Before you choose a secure file sharing platform
How do you get everything out? Ask about export before you upload.
Before you choose a secure file sharing platform
If a document does leak, the FTC’s guide to responding to data breaches explains the first steps for a business.
How ASL Files answers these questions
The storage service holds the key, so ASL Files is not end-to-end encryption. A link alone opens nothing. A workspace download needs a valid session from the organization that owns the file. Secure Send gives you a link and a separate password. You deliver them yourself, on two channels, because ASL Files never contacts the recipient. The recipient does not need an account. Failed password attempts and opens are recorded.
How ASL Files answers these questions
Know the limits too. Once downloaded, the delivered .zip is an ordinary file with no password. There is no bulk export, so moving everything out is a job someone runs. ASL Files has no dashboard of its own. It works behind other ASL products and is priced with the product it ships in.