Kirill Abrams

Founder & CEO of Messenger - building privacy-first communication and cryptographic infrastructure at global scale.

[Kirill Abrams @KirillAbrams]

Some messages are valuable because of what they reveal years later.

Simple example: a contract negotiation, a political conversation, a medical message, or a source conversation may not matter to an attacker today. It may matter in five years. If someone records encrypted traffic now and better decryption tools arrive later, the attack was already started.

In UmbrellaX I want new high value chats to use hybrid protection: a classical path plus a post quantum path. The point is not to claim that quantum computers can break everything tomorrow. The point is to avoid designing only for today's attacker when messages may have a long shelf life.

Hybrid also reduces dependence on one assumption. If one side fails later, the other side still has to fail too.

The threat this closes is store now, decrypt later collection against conversations that remain sensitive for years.

[Kirill Abrams @KirillAbrams]

The app build is part of the security model.

Everyday example: a bank can have a strong vault, but if someone swaps the banking app on your phone for a lookalike, the vault story does not help much. The user is now talking to the wrong client.

For UmbrellaX I want sensitive protocol paths to know which client build is asking. Release identity, signed update manifests, reproducible builds, and strict build claims matter because the server side should not treat every random binary as the real app.

This is not about blind trust in the company. It is about making the release chain auditable and harder to silently replace. A private messenger has to protect the path from source to binary, not only the message after it is typed.

The threat this closes is malicious update, fake client, or downgraded build becoming the user interface for private secrets.

[Kirill Abrams @KirillAbrams]

In the most sensitive mode, I do not want one relay to see both ends of a connection.

Simple example: if one taxi driver picks you up at home and drops you at a private meeting, the driver knows both endpoints. If one driver takes you to a busy station and another takes you onward, each sees less of the story.

UmbrellaX supersecret routing is designed around splitting the view. One hop can see the user side and the next relay. Another hop can see the previous relay and the destination side. No single relay should get the whole picture by design.

This is not a magic invisibility cloak. Timing correlation is still hard against a very strong observer. But it prevents the simplest relay from becoming a complete relationship sensor.

The threat this closes is IP plus relationship exposure at one network point.

[Kirill Abrams @KirillAbrams]

A push notification should knock, not gossip.

Everyday example: your phone is on the table and the lock screen lights up. Even without the message text, the alert can reveal the sender, group, timing, and that something urgent is happening.

In UmbrellaX I want push to carry as little meaning as possible. A push can tell the device to check its mailbox. It should not carry message text, group names, clear sender identity, or useful conversation context. For very sensitive mode, polling with timing noise may be safer than rich push.

This is less flashy than smart notifications. It is also more honest for a privacy product.

The threat this closes is lock screen leakage and push provider metadata. The notification should wake the app, not describe the private room.

[Kirill Abrams @KirillAbrams]

Encrypted messages can still leave a delivery trail.

Simple example: the letter is sealed, but the post office keeps a clean notebook that says Alice wrote Bob at 10:04 every night. Many investigations would start with the notebook, not the letter.

In UmbrellaX I want delivery to use blind mailbox style routing. The server should move encrypted packets without learning the human meaning of sender, recipient, chat, or group from easy fields like URL paths and readable identifiers. Routing material should be opaque, short lived, and kept out of permanent personal logs.

This does not defeat a global observer who sees everything. I will not make that claim. It does remove the simplest mistake: building our own readable phone bill for private messages.

The threat this closes is who talked to whom metadata stored by the service itself.

[Kirill Abrams @KirillAbrams]

A profile is not decoration. It is data.

Everyday example: a display photo, nickname, short bio, and status can be enough to identify someone, copy them, or build a list of who belongs to which community. Many products treat that as harmless because it makes the app feel social.

In UmbrellaX I want profile fields to be optional and private by default. Nickname, bio, and avatar should live in an encrypted padded envelope unless the user clearly chooses to make something public. The server should not get a clean directory of faces and descriptions by default.

Public profiles can exist. They should be a choice, not the price of opening the app.

The threat this closes is profile scraping, impersonation, and identity mapping from fields people did not think were sensitive.

[Kirill Abrams @KirillAbrams]

Backups can quietly destroy a privacy model.

Simple example: you lock a diary in a safe, then your phone automatically copies the diary into a cloud backup. The safe still works. The copy is the problem.

In UmbrellaX, the vault, media cache, sensitive logs, and crash artifacts should be excluded from platform backups before sensitive access is allowed. If the platform cannot prove the exclusion state, the safer answer is to fail closed for private vault access.

This is the kind of boring edge that matters. A messenger can have excellent encryption and still leak through backup systems nobody looked at carefully.

The threat this closes is cloud backup extraction. If someone cannot open the phone but can obtain a platform backup, the private vault should not be waiting there in a recoverable form.

[Kirill Abrams @KirillAbrams]

Where history is stored matters as much as how it is encrypted.

Everyday example: if a warehouse labels boxes with "Alice and Bob private chat from March", the boxes reveal a lot even before anyone opens them. The label becomes metadata.

In UmbrellaX, recoverable history should be stored as encrypted body records with boring routes and no human readable relationship in the path. The storage layer should not learn that a blob belongs to a named chat, a named person, or a specific social relationship. It should move opaque records, not keep a directory of private life.

This does not solve all traffic analysis. It removes the self inflicted version where our own storage names the thing we promised to protect.

The threat this closes is history metadata in logs, paths, object names, and storage indexes. Encryption should not be surrounded by labels that tell the story anyway.

[Kirill Abrams @KirillAbrams]

@lightsilver323 Not Selling https://t.co/JPinJpwa3l

[Kirill Abrams @KirillAbrams]

Recovering your account and recovering old history are not the same job.

Simple example: replacing a lost bank card should not automatically open a storage unit with every old receipt, letter, and diary page you ever kept. Access to the identity and access to the archive should be separate decisions.

In UmbrellaX I want account recovery and cloud history recovery split. One path proves you are allowed to regain the account. Another path unlocks only the archive material the user chose to make recoverable. The history phrase should not add devices, change identity, or sign account operations.

This lets people choose different privacy levels for different chats. Some history can be recoverable. Some can be delivery only. Some can be secret and gone if lost.

The threat this closes is recovery overreach. One recovery secret should not become a universal skeleton key.

[Kirill Abrams @KirillAbrams]

A photo or video is also code risk.

Everyday example: someone sends you a gift box. The outside says "photo", but inside there can be sharp pieces. Media files are parsed by complex decoders. Complex decoders have bugs. That is why opening a file should not happen in the same place that holds the vault keys.

In UmbrellaX, I want media opened through a sandboxed runner with tight limits. The decoder should get the file it needs, not the whole app state. If a malicious image or video attacks the parser, it should not get a direct path to chat keys, vault scopes, or account material.

This is not glamorous, but it is practical. Many real attacks start with a file that looks normal.

The threat this closes is malicious media escape from decoder bugs into the private core of the app.

[Kirill Abrams @KirillAbrams]

A media file should not share the fate of the whole chat key.

Simple example: you put every photo in a box that uses the same key as your apartment. If that apartment key leaks, every old box is open too. It is better when each box has its own random key and the apartment only stores a wrapped permission to open it.

In UmbrellaX, media should use random per file keys. A chat scope can open the wrapper for a file key, but the file key itself is not just a simple formula from the chat key. If a media wrapper is destroyed, the encrypted file should become useless noise.

This matters for deletion, forwarding, storage compromise, and old media caches.

The threat this closes is recoverable deleted media. Deleting a message should not leave a file that can be revived because the same broad key still exists somewhere.

[Kirill Abrams @KirillAbrams]

Accessibility is important, but it is also powerful access.

Everyday example: giving someone a microphone to help you hear better is useful. Giving that microphone to every room in the house is different. On a phone, accessibility services can read screen content, observe focus, automate taps, and understand the interface.

In UmbrellaX I want the most sensitive mode to draw a hard boundary. The private surface should avoid normal text fields and broad accessibility exposure. For users who need larger text, stronger contrast, or simpler controls, I want to build those controls inside the app rather than letting a system wide service read the transcript.

This is a real tradeoff, and I do not want to hide it. The private mode may give up some convenience.

The threat this closes is another app or compromised service becoming a second reader of private chats.

[Kirill Abrams @KirillAbrams]

A screen can leak through more than screenshots.

Simple example: a note on your desk can be copied by a camera, but it can also be copied by someone who reads the document title, the selected text, or the preview shown by another tool. On phones, normal text fields create many helpful side channels.

For UmbrellaX private views, I want sensitive messages rendered as controlled frames instead of normal selectable text fields. The text still becomes pixels. I am not claiming otherwise. But the operating system should not receive a neat text object that other services can select, read, index, or preview.

This makes some features harder. Copy, selection, system translate, and universal search are convenient. They are also extra readers.

The threat this closes is text extraction through UI services, overlays, screen readers, and system indexing paths.

[Kirill Abrams @KirillAbrams]

I do not like sensitive text sitting in memory as one clean string.

Everyday example: if you write a secret on one large sheet of paper, anyone who sees the sheet gets the whole thing. If you process it as small pieces and shred each piece after use, there is less to steal at one moment.

In UmbrellaX, sensitive input should move through small slots instead of becoming a normal long lived text buffer. The app can process symbols, encrypt or wrap them early, drain them in chunks, and wipe pending input quickly. The UI should not keep a perfect copy just because it is easy for developers.

This is not about pretending the device never sees what you type. It does. The point is to reduce how long and how cleanly it exists.

The threat this closes is input buffer recovery from memory, crash dumps, debug tools, or compromised UI layers.

[Kirill Abrams @KirillAbrams]

A private PIN should not travel through every helpful input feature on the phone.

Simple example: you whisper a door code to a friend, but you do it through a loudspeaker because the loudspeaker is convenient. That is how system input can feel in sensitive places. It may involve suggestions, learning, dictation, extensions, clipboard behavior, and accessibility hooks.

In UmbrellaX, PIN entry and sensitive vault input should use an in app keyboard. The goal is to avoid normal text fields and system keyboard paths for the most sensitive material. The app handles symbols directly and keeps the path narrow.

This is not because every keyboard is evil. It is because private input should not depend on every keyboard setting, extension, and cloud learning path being perfect.

The threat this closes is keyboard, clipboard, dictation, and input extension leakage.

[Kirill Abrams @KirillAbrams]

RAM is not a safe just because it disappears when power is gone.

Simple example: if you are cooking and leave every ingredient measured and labeled on the table, anyone who walks in can understand the recipe. If the table only has small unlabeled pieces that change often, the picture is harder to steal.

In UmbrellaX I do not want live secrets to sit in memory as neat, long lived values. The design uses split live labels, narrow session objects, zeroization, and short windows. The app should avoid keeping a clean master secret ready for any layer that asks.

I am not pretending software can beat a powerful attacker who freezes the whole process at the perfect moment. But I can make normal memory capture less useful and shorten the opportunity.

The threat this closes is secret recovery from RAM after compromise, crash, debugger attach, or live device capture.

[Kirill Abrams @KirillAbrams]

Access should expire quickly by default.

Everyday example: a delivery code for your building should work for one delivery, not for the next three months. Long lived permission is convenient until someone copies it.

In UmbrellaX, vault access is meant to use short lived capabilities. A capability should say what it opens, for whom, for which scope, under which server time window. When the window ends, the app should request a fresh one instead of quietly reusing old permission.

This costs a little more protocol work. I think the tradeoff is worth it because real devices are messy. They have crashes, background states, screenshots, logs, and malware.

The threat this closes is stolen live permission reuse. If an attacker captures one temporary access object, I want it to die fast and open only a narrow place.

[Kirill Abrams @KirillAbrams]

I do not want raw keys crossing the mobile app boundary like normal strings.

Simple example: a restaurant can give the waiter a sealed order number, or it can hand him the safe combination on a napkin. Both may deliver the meal. Only one keeps the kitchen safe.

UmbrellaX uses Rust for sensitive protocol work. The mobile layer should receive handles, fixed wire objects, and narrow results, not raw secrets it can accidentally log, stringify, keep in memory, or pass into a crash report. The app can ask the core to perform an operation without owning the secret itself.

This does not make bugs impossible. It makes the dangerous path smaller. Fewer layers get to touch the material that matters.

The threat this closes is key leakage across app layers. A messenger should not lose secrets because a UI layer treated them like ordinary text.

[Kirill Abrams @KirillAbrams]

Ciphertext should know where it belongs.

Everyday example: a boarding pass for Dubai to London should not work as a hotel key. Both are pieces of data. Both may have valid looking codes. But each code only makes sense in its own context.

In UmbrellaX I want encrypted capsules to bind the account, chat, scope, message type, content type, epoch, and purpose into what gets authenticated. That way, a valid encrypted object from one place cannot be copied into another place and accepted as if it belonged there.

This is one of those details users should never have to think about. But if we skip it, attackers get room to play with confusion.

The threat this closes is copy and paste ciphertext attacks. Strong encryption is not enough if encrypted pieces can be moved between contexts and still look valid.