ASL Files — Source library
Public documentation snapshot: 2026-09-08
A shared link should never be the key.
Encrypted file storage where a link alone opens nothing, plus a password-protected way to send one file out.
A shared link should never be the key.
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
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. 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. 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. 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 ASL Files works, start to finish.
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. The key lives with the storage service alone. No application that stores files here ever receives it, and no application ever holds a readable copy. Someone who walks off with the disk, or with the index that lists what is on it, comes away with nothing they can open. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. There is also a native Android app, at version 1.0.0, for receiving a Secure Send without any account at all and keeping the received copy encrypted on the phone.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
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. Copy the storage, copy the index, and you still have nothing you can read. 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 MB. 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 Android app at version 1.0.0 lets a recipient collect a two-channel secure transfer with no account, no sign-up, and no organization membership. Paste the link, enter the password that came by another route, and the file lands on the phone. Before it sends anything the app refuses addresses that are not secure, that carry a password in the address, or that resolve to a private or local address.
On the phone, encrypted and under your control
Received files, their names, types, and fingerprints are encrypted on the device with a key held by the phone's own operating-system key store, in storage excluded from device backups. Copies leave only through the phone's own file picker, to a location you choose. The app asks for one permission, network access, and carries no advertising or analytics code. It also states plainly that deleting a local copy cannot promise a physical overwrite of the phone's storage.
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 carries no advertising code, no analytics code, and no long-lived key, and asks for exactly one permission.
Surfaces and status.
Status as of 2026-09-02. Deployed and verified over public HTTPS on 2026-07-31, running the 2026-08-14 release since, and that running release was inspected on the server itself on 2026-08-23 and reconciled into the source repository without changing anything live. Re-checked over public HTTPS on 2026-09-02: the health check answers OK, the Secure Send recipient page and its styling load correctly, an unknown or expired secure link returns the proper "no longer available" page, and a file request without a valid session is refused with 401. Transport security, framing, referrer, sniffing, and no-index headers were all present on that check. Four ASL products are connected with their own keys. The Android client is the newer and less mature surface: signed at 1.0.0 and accepted on two devices, but not publicly listed.
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-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 the running release was reconciled into the source repository with nothing live changed (no file, service, credential, index, stored file, or configuration touched), and a native Android client shipped at signed 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. It was accepted on an emulator and a physical Pixel 8 across receipt, upload, download, secure send, deletion, offline behaviour, and relaunch; the public store listing is still to come. The most recent change in the repository is dated.
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?
Pricing for ASL Files is not published. 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. Two limits shape the plan: 15 MB 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 service has been live since 2026-07-31 and four ASL products already store files in it. It carries seventeen automated checks over the parts that matter: encryption on disk, organization isolation, a link not being permission, tamper detection, deletion rules, and the backups. The change history is candid about defects that were found and fixed, including one that had made administrator deletion impossible. The Android app is the newer piece: signed, accepted on an emulator and a physical Pixel 8, and not on the public store listing yet.
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 MB. 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 a self-chosen password containing lower-case letters will not be accepted back. 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