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