It was only a decade or so ago that "End-To-End Encryption" began to mean something other than "encrypted in transit".
E2EE now means something wildly different in the context of messaging applications and the like (since like 2014) so this is more of an outdated way of saying "no one is getting your poop pictures between your toilet and us".
It also feels like it would never make sense for this to be "E2EE encrypted" in the modern sense of the term as the "end user recipient" of the message is the service provider (Kohler) itself. "Encrypted in Transit" and "Encrypted at Rest" is about as good as you're going to get here IMO as the service provider is going to have to have access to the keys, so E2EE in a product like this is kind of impossible if you're not doing the processing on the device.
I wonder if they encrypt it and then send it over TLS or if they're just relying on TLS as the client->server encryption. Restated, I wonder how deep in their stack the encrypted blob goes before it's decrypted.
> It was only a decade or so ago that "End-To-End Encryption" began to mean something other than "encrypted in transit".
No, before that it was simply not a term, except in some obscure radio protocol (and even there someone competent in cryptography would probably not have chosen that term)
> E2EE now means something wildly different in the context of messaging applications and the like (since like 2014) so this is more of an outdated way of saying "no one is getting your poop pictures between your toilet and us".
The outdated way was saying "Military-grade 128-bit encryption", no one really used the E2EE term before it got the current meaning
> I wonder if they encrypt it and then send it over TLS or if they're just relying on TLS as the client->server encryption. Restated, I wonder how deep in their stack the encrypted blob goes before it's decrypted.
Some homemade encryption added on top of TLS is very unlikely to increase the security of the system