[sz4kerto]

"In my previous blog, I revealed that Oura data is not end-to-end encrypted. That means that an Oura user's health data can be unscrambled at certain points as it travels from a person's ring, through their phone app, over the internet, and as it lands on Oura's servers."

Very strange -- it seems to be conflating end-to-end encryption with encryption-in-transit.

[munchler]

My understanding is that E2E encryption implies encryption in transit. The message is encrypted at the source and only decrypted at the destination, so it is encrypted everywhere in between.

[blueg3]

The term has kind of degraded, because people started marketing that "end-to-end encryption" is the "right" answer.

Encryption in transit means that network intermediates can't read the data. The two endpoints of the network communication can.

E2E encryption is more context-sensitive, and its context mostly comes from messaging. It means that the data is encrypted and that operational intermediates cannot read it. So in the context of messaging, the servers that run the messaging system cannot read the messages. Or, for an email, only the sender and recipient, not any of the intermediate email servers.

There's a big difference -- you can't really control or predict your network intermediates, but you can in theory know the operational intermediates. Whether something is E2E encrypted often depends on what intermediates you bring in to scope.

For example:

> That means that an Oura user's health data can be unscrambled at certain points as it travels from a person's ring, through their phone app, over the internet, and as it lands on Oura's servers.

If the ring uses Bluetooth to sync the data to your phone and the phone syncs data to the Oura servers, but the data is in the clear on your phone, then by this definition, it is not E2E encrypted. However, that's a pretty reasonable setup, depending on how the data on the phone is stored.

[lloeki]

> If the ring uses Bluetooth to sync the data to your phone and the phone syncs data to the Oura servers, but the data is in the clear on your phone, then by this definition, it is not E2E encrypted.

Yet another angle would be that both the phone and the ring are in one's material possession, whereas the cloud is someone else's computer, and to display a nice web UI it has to have the data unencrypted over there.

In that case, the cloud is the potentially untrusted intermediate between the data and one's eyeballs.

All of these are equally valid, it all depends on what is your threat model.

[fc417fc802]

> The term has kind of degraded

I have to disagree. It's the same thing that happened to terms such as open source. It's perfectly clear what it means but marketers intentionally attempt to mislead people for the sake of their own bottom line.

> but the data is in the clear on your phone, then by this definition, it is not E2E encrypted.

False. E2EE is centered on a given user. So long as the phone would be viewed as "yours" (ie inside your personal security boundary) by a reasonable person then it is clear that the data is E2E encrypted.

As the sibling comment notes the common issue is providing a web interface. It isn't so simple to have a remote server dish up a nice UI with lots of convenient functions while only decrypting the data on the client side. It can certainly be done but it requires developers that know what they're doing and management willing to budget for it.

[Ajedi32]

GP is saying E2E encryption implies encryption in transit, because by definition "in transit" is not an "end".

I would agree with your definition that E2E means "operational intermediates cannot read it", but I would define intermediaries as people/organizations, not as devices. If my phone can read my data from my ring, that's not an intermediary because it's my phone. If a cloud server can read the data, then that is an intermediary because it's not my cloud server.

[pseudosaid]

this is such a hacker news comment. expounding needlessly. e2e implies encryption at the source and endpoint which entails encryption along all transit paths. its not that deep. if its not encrypted at the source “ring”, then it cant be e2e. I get your semantics but its just a waste, as is my comment here.

[fc417fc802]

I don't see the conflation? The author makes it clear that the data is not E2EE. It does sound like it's encrypted in transit (this is table stakes for the past 20 years or so). I think that saying that the data gets "unscrambled at certain points as it travels" is a perfectly reasonable way to explain the practical difference between the two approaches to a nontechnical reader.

[close04]

Not very strange but E2EE is thrown around a lot and everyone interprets it differently. And in some cases the expectations are unrealistic.

Take a messenger app using a server as middleman. E2EE means only the 2 users get to see the content, not the middleman company server. For Oura there’s only a user and the company server and a lot of people assume Oura can’t read the data, like the Signal or WhatsApp servers can’t read the data because of E2EE. The marketing usually allows or encourages this misunderstanding.

If they claim E2EE though, the interface between the user and the service (the ring or at worst the app) should mandate the encryption and the data should be decrypted only at the other end on Oura’s servers. If at any point in between these 2 ends the data is decrypted then it’s not E2EE.

[u1hcw9nx]

There is no interpretation issue, some people are just confused.

Oura is not claiming E2EE and Oura is not E2EE. E2EE in the health apps would mean that Oura would not see the data. Only user could see the data in their app. Oura's privacy policy states that they do not sell your data, they limit internal access using strict safeguards (like pseudonymization, where your name is separated from your health stats), and they pledge to push back against overbroad government data requests.

Contrast Oura to Apple Health that is true E2EE. Only you and your trusted devices have the keys, Apple can't see the keys, and Apple has noting to give is it gets government request.

[fc417fc802]

> everyone interprets it differently.

No, they don't. You're spreading misinformation. If the service provider can see the data then it is not E2EE. There is no room for negotiation here. Let me be perfectly clear that any service provider that claims E2EE while having access to user data is committing blatant fraud.

That said, it does not appear that Oura ever claimed E2EE. The author is merely making it clear to the reader that this is not the case.

[Chaosvex]

Agreed. Weird to see a bunch of posts trying to argue that E2E doesn't imply that provider can't see the data, at rest or in transit.

[close04]

> Weird to see a bunch of posts trying to argue that E2E doesn't imply that provider can't see the data, at rest or in transit.

It's only weird for the people in that middle ground where they know "something" about it, but really not much at all. There are ways to get educated and at least acknowledge the misunderstandings but who has time for that [0].

E2E explicitly means from one end to another. Obviously when the provider is one of the ends, as sender or final recipient of the data, they can have access to the data and not violate the principle of E2EE. When the provider is just an intermediary they should not be able to decrypt the data because they are not one of the ends.

Some companies slap the E2EE sticker on their product even when it's meaningless because it makes the product sound more secure. Like when they were slapping "blockchain" on everything. Or "AI" and "agentic" these days. It means nothing, it's misleading, but not factually wrong.

[0] https://www.researchgate.net/publication/342621891_Improving...

[fc417fc802]

No, again, that is misinformation on your part. By your own logic every https connection qualifies as E2EE by virtue of traversing untrusted intermediaries as it crosses the public internet.

That obviously makes no sense as it renders the term entirely pointless. The entire reason for the term to exist is the difference from encryption in transit. It specifically means that one or more of the intended recipients (generally the service provider) do not have default access to the data.

The "meaningless" usage you describe is fraud seeing as it's an intentional attempt to deceive the consumer. It is factually wrong in the exact same way that slapping an open source label on something made available on github under a proprietary license is.

[close04]

> No, they don't. You're spreading misinformation.

You can confidently say that everyone is qualified enough and understands E2EE the same way you do? Is it magic or an LLM whispered in your ear?

Because by the nature of my job I talk every 2 days with someone who doesn't really understand what E2EE is, what it does and more importantly what it doesn't do. They learn from marketing materials nit from reading technical info, you know, like almost all users out there.

[iLoveOncall]

You are conflating end-to-end encryption with encryption at rest.

[ggm]

It also doesn't sound like its encrypted at rest. Perhaps each in-transit is held to be a unique e2e IP exchange?

[juggle-anyhow]

Encrypted at rest means something different. It means if you pull the hard drive out no one can decrypt it. Not that it is encrypted in the database.

[stavros]

Does encryption at rest actually do much? The percentage of attacks that were perpetrated by people getting physical access to a drive must approach zero.

[nicce]

Depends on what kind of data is in question. Backups and old incremential data can stay encrypted while disks are otherwise in use.

[stavros]

Hm yeah, I always think of encryption at rest as "the drive handles encryption itself", rather than "we encrypted these archives before we wrote them", but fair enough.

[literalAardvark]

Not necessarily the drive, but yeah, where standards mandate encryption at rest you need to have the files on the live disk encrypted.

Usually it's much less of a headache to luks/bitlocker/SED the whole drive so that you don't have to worry about swap files and logs

[zoogeny]

It generally has to do with risk models, especially in single tenant environments.

What I mean is, say I am a b2b service provider and I have a single database for some subset of my clients. That is, multiple clients data are held in the same database. There are many ways to do this but one way I have see is BYOK (Bring Your Own Key). You can have your clients give you secure access to a public/private key pair (e.g. through AWS secrets manager). Then you encrypt anything that gets written into the database using their key.

This means that if there is some security hole in your software that accidentally allows data to be exfiltrated from your servers (e.g. one malicious client sends API requests that allow for a query of data from another target client), the data the API returns will be encrypted using the target clients public/private key.

My own experience with security is that nothing is perfect and good security is like an onion. Encryption at rest isn't perfect and won't handle every possible malicious attack, but it is a layer in the broader strategy. The attacker has to both find a way to exfiltrate the data and trick the server into revealing the shared key. The idea being it is harder to do both than it may be to do either individually.

[alternatex]

I think it's also meant to protect from potential mistakes in handling of hard disk decommissioning which presumably is a common thing with data centers.

[SoftTalker]

Used to be, but e.g. where I work any decommissioned drive has to be DBANed (if it's spinning platters) or secure-erased (SSDs). If it can't be for some reason (e.g. it has failed) it needs to be physically destroyed. I would hope most data centers have similar policies in 2026, but that may be optimistic I guess.

[fcarraldo]

When the company that owns the physical hardware goes out of business, all of this stuff is moot.

[dmkolobov]

Unless the attacker is law enforcement.

[stavros]

Law enforcement will just get you to give them the keys.

[dmantis]

Law enforcement of another jurisdiction won't, but can try to snoop into the data.