5 ms·

"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

"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.

ggm 4mo ago
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 4mo ago
  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 4mo ago
    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 4mo ago
      Depends on what kind of data is in question. Backups and old incremential data can stay encrypted while disks are otherwise in use.
      - stavros 4mo ago
        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 4mo ago
        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 4mo ago
      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 4mo ago
        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 4mo ago
        When the company that owns the physical hardware goes out of business, all of this stuff is moot.
    - dmkolobov 4mo ago
      Unless the attacker is law enforcement.
      - stavros 4mo ago
        Law enforcement will just get you to give them the keys.
        dmantis 4mo ago
        Law enforcement of another jurisdiction won't, but can try to snoop into the data.
    - zoogeny 4mo ago
      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.
munchler 4mo ago
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 4mo ago
  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 4mo ago
    > 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 4mo ago
iLoveOncall 4mo ago
You are conflating end-to-end encryption with encryption at rest.
close04 4mo ago
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.
- fc417fc802 4mo ago
  > 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 4mo ago
    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 4mo ago
      > 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_Non-Experts%27_Understanding_of_End-to-End_Encryption_An_Exploratory_Study https://www.researchgate.net/publication/342621891_Improving...
fc417fc802 4mo ago
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 4mo ago

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 4mo ago
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 4mo ago
  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 4mo ago
    Depends on what kind of data is in question. Backups and old incremential data can stay encrypted while disks are otherwise in use.
    - stavros 4mo ago
      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 4mo ago
        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 4mo ago
    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 4mo ago
      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 4mo ago
        When the company that owns the physical hardware goes out of business, all of this stuff is moot.
  - dmkolobov 4mo ago
    Unless the attacker is law enforcement.
    - stavros 4mo ago
      Law enforcement will just get you to give them the keys.
      - dmantis 4mo ago
        Law enforcement of another jurisdiction won't, but can try to snoop into the data.
  - zoogeny 4mo ago
    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.

munchler 4mo ago

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 4mo ago
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 4mo ago
  > 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 4mo ago

iLoveOncall 4mo ago

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

close04 4mo ago

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.

fc417fc802 4mo ago
> 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 4mo ago
  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 4mo ago
    > 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_Non-Experts%27_Understanding_of_End-to-End_Encryption_An_Exploratory_Study https://www.researchgate.net/publication/342621891_Improving...

fc417fc802 4mo ago

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.