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