Share sensitive information without betting its future privacy on today’s cryptography. AshNote encrypts content in the browser and uses hybrid ML-KEM post-quantum protection against harvest-now, decrypt-later threats.
Built independently Product design · cryptographic architecture · frontend · backend · data lifecycle
Visit AshNote (opens in a new tab)
Overview
AshNote started with a problem I kept running into: products would call themselves secure, but the meaningful details were often somewhere behind the claim. Was the content actually encrypted before it left my browser? What could the service see? What was stored after I deleted something? Was some analytics or other network behavior quietly expanding the trust boundary?
I wanted a system where those answers were visible in the way the product actually worked.
AshNote encrypts sensitive content in the browser before it is sent. The server receives encrypted data rather than the readable secret, and the cryptographic flow can be inspected from the browser rather than requiring blind trust in a privacy statement.
Persistence is deliberately limited too. Smaller ephemeral payloads can remain in volatile memory instead of being written to durable storage at all. Larger files can use encrypted cloud storage when persistence is necessary, but remain encrypted outside the client.
The other half of the problem was usability.
It is easy to decide that sensitive information should move through a secure channel. It is much harder to convince another person to create an account, install software, learn a new workflow, or understand why any of that matters.
So AshNote works in both directions. You can send someone a secret, or generate a link that asks them for one. They open it, enter the sensitive information you requested, and submit it through the same encrypted flow.
The goal is to make the secure path the easy path.
Security architecture
AshNote is designed to reduce the amount of trust a user has to place in the service itself. The important decisions happen at the boundaries: before data leaves the browser, while it is stored, when it expires, and in the cryptography protecting it over time.
Sensitive content is encrypted in the browser before it is transmitted.
The service receives encrypted material rather than the readable secret or file, making the client-side encryption boundary something a technically inclined user can inspect rather than simply accept as a product claim.
AshNote combines classical cryptography with ML-KEM rather than replacing one with the other.
The classical component preserves confidence in mature cryptography today, while the post-quantum component is intended to protect captured ciphertext against future quantum attacks and the harvest-now, decrypt-later threat.
Smaller ephemeral payloads can remain in volatile memory instead of being written to durable object storage.
Larger files use encrypted cloud storage when persistence is necessary, allowing the storage strategy to change without requiring the service to receive the readable contents.
Security breaks down quickly when every participant has to understand the security model.
AshNote supports both sending and requesting sensitive information. A request link gives the other person a simple form for returning what was requested through the encrypted flow, without requiring them to adopt an entirely new workflow first.
Security boundaries
AshNote protects sensitive content before it leaves the browser and keeps the service from needing the readable payload in normal operation.
That does not make every part of the system trustworthy by definition. The security of the device, browser, delivered application code, authentication flow, and cryptographic implementation still matters.
AshNote makes these dependencies explicit instead of hiding them behind the word “encrypted.”
AshNote