Slack's Block Kit video blocks load any web page the sender chooses and render it inside an iframe with no runtime content check beyond an HTTP 2xx response. That sounds like a footnote in Slack's documentation. It is not. It is a covert computation channel living inside a chat platform used by millions of workplaces, and a security researcher spent months turning the quirk into a working end-to-end encrypted (e2ee) messaging system that the Slack server cannot read. The build is the proof. The pattern is the story.
The project, called e2ee-slack, runs the entire cryptography stack inside the iframe Slack itself loads. Keypair creation, passphrase-protected private key decryption, encryption, signing, and decryption all happen in the user's browser, using openpgpjs, a library maintained by Proton. The Slack server sees only ciphertext.
The mechanism works like this. A user types the slash command /e2ee send, picks recipients in a Slack modal, and composes a message. Slack's server stores a small slug in a key-value database holding the user's encrypted private key plus the recipients' public keys. When a recipient opens the resulting message, Slack renders the video block, the iframe loads, the client pulls the encrypted key from the slug, prompts the recipient for the sender's passphrase, decrypts the private key locally, and unwraps the message. Only the encrypted blob ever leaves the browser. The Slack server, by the design of the build, never sees a decrypted key.
The author of the proof of concept describes it as a hack that "does not fully comply" with Slack's documented design constraints for the video block. That phrasing matters. The Block Kit video-block reference lays out constraints on the iframe, and the author's testing suggests those constraints are not enforced at the render layer. Treating this as a CVE-class bug overstates the disclosure. The honest read is that the video-block surface was modeled as a passive media embed, not as a hostile-content execution environment, and the platform has not been retrofitted for the second case.
A signal that Slack's own engineers thought of the embed as a media surface: video blocks cannot appear in ephemeral messages, a restriction the author calls undocumented. The fact that ephemeral surfaces were excluded from the embed path reads less like a security boundary and more like a product call that landed before the security team modeled the iframe as a general-purpose browser.
The pattern, not the Slack instance, is what a reader who uses other tools should take away. Slack is not the only collaboration surface where a user-controlled iframe renders inside a platform server. Notion embeds, Figma plugin iframes, VS Code webviews, and any other SaaS tool that hosts third-party web content inside a platform-authenticated shell functions the same way at the architectural level. Some of these platforms have leaned into the model. Discord Activities and Telegram Mini Apps both support fully featured embedded apps as a first-class product. Slack has not.
The e2ee build the researcher published is not a Slack alternative. It is a research artifact, useful for understanding what the embed surface actually permits. The threat model it satisfies is workplace privacy from employer and workspace-admin surveillance: an admin who controls the Slack workspace cannot read message contents because the keys never reach a server they control. That is a narrower guarantee than journalist-grade or state-adversary e2ee, and the article the author wrote does not claim otherwise.
What Slack does next is the watch item. The author has not framed the work as a coordinated disclosure, and the build remains a public repository. If Slack responds, the response will be the next data point, not the first. Until then, the iframe-as-channel pattern is the throughline, and every embed-capable SaaS tool a reader uses at work is the same shape.