DEV Community

Super Funicular
Super Funicular

Posted on

Ring's "Throw Away the Key" Encryption Is a Custody Change, Not a Cryptography One

On 26 August 2026, Amazon's Ring announced TAKE — Throw Away the Key Encryption — which the company says "will become the default encryption for all Ring customers worldwide when fully rolled out." It rolls out in phases starting in September. TechCrunch reported the same day that the scheme uses rotating keys held temporarily in the cloud, released to Ring only to power features the user has enabled, and deleted afterward — within 24 hours, per TechCrunch's account. End-to-end encryption remains available as an opt-in setting.

Let me say the fair thing first, because it's true and it matters: this is a real improvement, and Ring deserves credit for it.

Default beats opt-in. Almost nobody changes defaults, so a privacy control that ships off is a privacy control most people never get. Ring's own blog notes E2EE has been available since 2021 — five years of an option that, by construction, protected only the users who went looking for it. Making the stronger setting the default is the single highest-leverage privacy change a consumer product can make. They also built on Messaging Layer Security, a published IETF standard rather than a proprietary scheme, and shipped a white paper describing it. That is how you want a vendor to behave.

So this isn't a "gotcha" post. It's a post about what the announcement actually changes, and what it structurally can't.

The question was never "is it encrypted"

Your Ring video was already encrypted. Ring says so plainly: "Your Ring videos are already encrypted when they travel to the cloud and while they are stored at rest." Transport encryption and encryption-at-rest have been table stakes in this category for years.

What TAKE changes is key custody — who holds a copy of the key that undoes the encryption, and for how long.

Here's Ring's own description of the mechanism:

"A copy of the keys is temporarily held inside a secure enclave within the cloud; think of it as a sealed vault that can only provide Ring access to the key under strict, limited conditions. Ring can only receive access to power the intelligent features that you have active on your account, and then throws away and deletes the keys."

Read that clause again: to power the intelligent features that you have active on your account.

That sentence is the whole architecture. Your key-exposure surface is exactly proportional to how many cloud features you leave switched on. Smart Alerts needs to see the frame to tell a person from a parcel. Video search needs to see the frame to index it. Every cloud-side capability is, definitionally, a moment where something other than your device has plaintext.

Ring is not hiding this. Their E2EE section states the tradeoff outright: with end-to-end encryption enabled, "Shared Users and cloud-based features are not available." That's an honest disclosure, and it's the same tradeoff every cloud camera makes.

What TAKE genuinely innovates is making that tradeoff continuous instead of binary. Before, you chose all-cloud or all-private. Now you choose a dosage. That's useful. It's also a different thing from removing the tradeoff.

The handyman analogy is more revealing than it looks

Ring reaches for a lovely metaphor:

"You might give a spare to a close friend or family member you trust completely. And if a handyman needs to fix your sink, you lend them a key only for as long as the job takes, then get it back."

It's a good analogy — and notice what it concedes. In the metaphor, the handyman really does hold your key. The safety comes from duration and intent, not from impossibility. You are trusting that the key comes back, that nobody copied it while it was out, and that the job was what you were told it was.

That's not a knock on Ring specifically. It's the honest description of what any recoverable, feature-serving key architecture buys you. The second tell is the recovery story: TechCrunch reports that if you lose your devices, you can recover your keys by standing near your Ring cameras, or via "a passphrase, cloud-based backups, another approved device, or passkeys." A key that can be recovered from cloud backup is a key the cloud can, under some conditions, reconstitute. Every consumer product makes some version of this compromise, because the alternative — lose your phone, lose your footage forever — is a support nightmare that most users would hate.

So the honest framing is: TAKE narrows the window. It does not remove the window. And "how wide is the window" is a fundamentally different security property from "there is no window."

Where we sit, and why it's a different question rather than a better answer

I build Background Camera RemoteStream, an Android app that turns a phone into a camera that records with the screen off and streams to a device you already own.

The architecture is deliberately dumber. Footage is stored locally on the device. Live viewing runs over your own network. YouTube Live streaming, if you use it, goes to your channel with your stream key. There is no account to create, because there is no server holding anything that would need one.

I want to be precise about what that does and doesn't buy you, because overclaiming here would be exactly the sin I'm describing.

What it buys: there is no vendor-held key, because there is no vendor-side copy of your video for a key to protect. The question "how long does Super Funicular hold a copy of your key?" has no denominator. Not "24 hours" — undefined. You cannot leak what you never received, and you cannot be compelled to hand over what you don't have.

What it costs, honestly: no cloud-side smart alerts. No server-side video search across months of footage. No frictionless sharing link you can text to a neighbour. If your phone dies with local-only footage on it and no backup, that footage is gone — the same brutal tradeoff Ring's E2EE mode carries, which is precisely why they made it opt-in. Cloud features are genuinely useful, and pretending otherwise is marketing, not engineering.

The point isn't that local-first is universally better. It's that these are different questions. Ring is optimising how briefly a third party holds your key. A local-first tool removes the third party from the diagram entirely, and pays for that in features. Which one you want depends honestly on whether you'd rather have package detection or an architecture with nothing in the middle.

The takeaway for anyone evaluating a camera

When a vendor announces an encryption upgrade, three questions cut through the marketing:

  1. Who can decrypt this, and under what conditions? "Encrypted" alone answers nothing — encrypted to whom is the whole question.
  2. Which features require plaintext? That list is your exposure surface. If it grows, so does the surface, regardless of the encryption scheme.
  3. What happens if I lose every device? If the answer is "you can recover," some recoverable path exists, and that path is part of your threat model.

Ring answered all three publicly and in specific terms, which is more than most of this industry does. Ask their competitors the same three questions and see how many can answer as clearly.


Background Camera RemoteStream — local-first background camera and YouTube Live streaming for Android. No cloud storage, no account required. More at superfunicular.com.

Sources: Amazon — Ring introduces TAKE (26 Aug 2026) · TechCrunch — Ring introduces a new encryption standard (26 Aug 2026)

Top comments (0)