"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 3 hours ago | parent | next [-]

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 2 hours ago | parent [-]

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 2 hours ago \| parent \| next [-]
		> 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 an hour ago \| parent \| prev \| next [-]
		> 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.
	▲	pseudosaid 28 minutes ago \| parent \| prev [-]
		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 44 minutes ago | parent | prev | next [-]

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.

▲

ggm 4 hours ago | parent | prev | next [-]

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 4 hours ago | parent [-]

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 2 hours ago | parent [-]

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 2 hours ago | parent | next [-]

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

▲

stavros 2 hours ago | parent [-]

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 2 hours ago \| parent [-]
		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

▲

alternatex 2 hours ago | parent | prev | next [-]

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 an hour ago \| parent [-]
		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.

▲

dmkolobov 2 hours ago | parent | prev [-]

Unless the attacker is law enforcement.

▲

stavros 2 hours ago | parent [-]

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

	▲	dmantis an hour ago \| parent [-]
		Law enforcement of another jurisdiction won't, but can try to snoop into the data.

▲

iLoveOncall 3 hours ago | parent | prev | next [-]

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

▲

close04 2 hours ago | parent | prev [-]

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 8 minutes ago \| parent \| next [-]
		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 an hour ago \| parent \| prev [-]
		> 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.