Am I understanding correctly that the other end of this is a rear end?

It doesn't "imply", it outright states that. Their server isn't the end, it's the middle. They're not "breaking the spirit" or something, what they are doing is called lying.

Of course, only authorized users could see the data, but that was a different compliance line item.

There are numerous benefits. For one, it will make people aware where their data goes when they set up the device.

https://youtube.com/watch?v=DJklHwoYgBQ

This sounds like the marketing department came up with this "market opportunity" and then some poor team at Kohler was asked to make it real.

No doubt there is health data to be had in waste products (it was used extensively during covid to figure out community-wide infection rates) but that used physical samples that were then analyzed. Trying to figure out if someone has a UTI, or pathogenic poop from a webcam image ... it is hopeless.

You wouldn't want that cheap tat miring up the clean lines of your throne.

* https://www.bbc.com/news/articles/cjd07dprln9o

https://images.ctfassets.net/veq5rt4lbvkn/2bpiwr3gYoRPnXqB8e...

And people who are being treated for gut issues can pay for their $600 medical toilet with HSA or insurance

Honestly, that this camera toilet exists is not a WTF for me. If my doctor needs to track changes to my stool, I certainly don’t want to have to hover over the bowl with my phone out. Please, just have the toilet take the picture.

That’s not end-to-end encryption. By that logic HN, and any other website over HTTPS is E2E encrypted.

For normal people E2EE means privacy, and that's why some company tries to sneak the term in products where it makes no sense.

It's "of course" for very knowledgeable people, normal people just assume that it means guaranteed privacy

Anyway a chemical or biological sensor in the bowl might be more useful.

Optical could be useful if it's doing spectrographic analysis: the color of poo and urine is sometimes informative.

- Deviation in consistency/texture/color/etc.

- Obvious signs related to the above (eg: diarrhea, dehydration, blood in stool).

Ultimately though, you can get the same results by just looking down yourself and being curious if things look off...

tldr: this feels like literal internet-of-shit IoT stuff.

But the linked privacy policy talks about making anonymous (aka de-identified) bulk data sets and using them for "lawful business purposes" (aka anything they want that's not illegal).

Bank data is never E2EE because the bank needs to see it. If banks call it E2EE they are misusing the term. E2EE for financial transactions would look like e.g. ZCash.

Well it could be processed on-device.

edit: also, what the hell, YouTube? they've got this new link shorter at https://youtu.be/DJklHwoYgBQ that they really want you to use, that forces you to use the browser to watch it instead of the app? so weird.

https://shop.digitalcourage.de/digitalcourage-und-ccc-aufkle...

I was under the impression that large companies use proxies so they can do deep packet inspection.

PS: you are right of course.

"[D]epending upon ambient tempertures and user age" is probably more accurate.

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

And yes, if my doctor wanted me to collect that info, I’d vastly rather buy a smart toilet and let it do the dirty work. That is, assuming it was actually secure.

It's misunderstood.

In the begining it's used to describe chat apps, your chat message are delivered in a secure way.

But later some marketers try to use it as a "transport channel" for client-server interactions.

And oh dear, that’s all too realistic. Imagine responding to the job posting and finding out these are the images you’ll be classifying.

(aside from the fact that people don't seem to know/remember WhatsApp backs up to google drive)

Code that then gets access to the end-to-end encryption keys ... so you're not safe from state actors, you're not safe from police, you're not safe from the authors of the code and you're not safe from anyone who has physical access to your phone.

https://news.ycombinator.com/item?id=45908891

Doing on device compute is probably expensive and would prohibit such a product based on the economics but ITS A GENITAL CAM

That being said, the person you're replying to seems to be saying that "the server" is always an "intended" end, which is wrong.

> no one really used the E2EE term before it got the current meaning

It most certainly was a term and no it wasn't simply limited to "some obscure radio protocol".

1994: https://ieeexplore.ieee.org/abstract/document/363791

1984: https://dl.acm.org/doi/pdf/10.1145/357401.357402

1978: https://apps.dtic.mil/sti/tr/pdf/ADA059221.pdf

> Some homemade encryption added on top of TLS is very unlikely to increase the security of the system

"Some homemade encryption" is not what I was suggesting at all. E.g. encrypted-at-the-source (client side) AWS files are still sent over TLS as an encrypted blob within an encrypted blob but remain encrypted past the TLS boundary.

An ADA toilet at Home Depot is $300 so even the price isn’t that outrageous, honestly. It’s a unique niche product so it’s gonna be a little bit pricey.

I don’t know, it just feels a bit gauche to make jokes about a medical device. Nobody’s buying this unless they need it, and if they need it then best of luck to them.

Not in my experience, except by very few

> But later some marketers try to use it as a "transport channel" for client-server interactions.

Some, still few enough to not make the term confusing, for what I can tell

They once shipped a backdoor in their macOS app. It was noticed and called out and they refused to remove it. It took Apple blacklisting it for Zoom to finally take action.

https://telegram.org/faq?setln=en#q-so-how-do-you-encrypt-da...

It shouldn't be any harder than e2ee chatting with any other user. It's just instead of the other end chatting using a keyboard as an input they chat using a language model to type the messages. Of course like any other e2ee solution, the person you are talking to also has access to your messages as that's the whole point, being able to talk to them.

I can't blame most people for calling TLS "E2EE", even some folks in industry, but it's not great for a company to advertise that you offer X if the meaning of X has shifted so drastically in the last decade.

Then you can incorporate this into a "health care product" and charge insurance companies insane rates on personal toilet cameras.

They need to analyse the data; adding layers of encryption, thus, could only improve security if the keys for the inner encryptions are better protected than the server's TLS private key.

Which would honestly, actually, likely to be the case, but it would probably be a modest improvement

I addressed the other two at https://news.ycombinator.com/item?id=46132220 .

You did show that the term was already used, but in the current meaning

If you continue to have GI issues anyways, perhaps due to genetic causes, then what is constant surveillance of the situation -- at $7,200/year -- going to improve?

If you promise end-to-end encryption, and later it turns out your employees have been reading my chat transcripts...

That's not given in any of those examples. In the case of ChatGPT and this toilet sensor e2ee is almost equivalent to 'we use https'. But nowadays everybody uses https, so it does not sound as good in marketing.

That's pretty wild

The reason that a different term had to be invented was that some centralized messaging system defined itself as "encrypted" when it begun to use TLS.

It would have been stupid to pick a term commonly used for TLS to differentiate yourself from TLS

RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949

     $ end-to-end encryption
      (I) Continuous protection of data that flows between two points in
      a network, effected by encrypting data when it leaves its source,
      keeping it encrypted while it passes through any intermediate
      computers (such as routers), and decrypting it only when it
      arrives at the intended final destination. (See: wiretapping.
      Compare: link encryption.)

      Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS,
      SILS, SSH, SSL, TLS.

      Tutorial: When two points are separated by multiple communication
      links that are connected by one or more intermediate relays, end-
      to-end encryption enables the source and destination systems to
      protect their communications without depending on the intermediate
      systems to provide the protection.

Each day after 50, your line and bobbers get a little closer to the pond.

Are we talking about 2 different things here?

That paper is about PKI-based session setup for End-End which is the ancestor of SSL/TLS. It even mentions a CAE which is effectively a CA and it does a synchronous handshake to establish a symmetric key. It's very clearly about transport layer security from end to end.

It's not about User-User E2EE (akin to Signal) and shares very little other than that data is encrypted from point A to point B.

My ISP who delivers these chat messages.

And honestly, E2EE's strict definition (messages between user 1 and user 2 cannot be decrypted by message platform)... Is unambiguously possible for chatGPT. It's just utterly pointless when user2 happens to also be the message platform.

If you message support for $chat_platform (if there is such a thing) do you expect them to be unable to read the messages?

It's still a disingenuous use of the term. And, if TFA is anything like multiple other providers, it's going to be "oh, the video is E2EE. But the 5fps ,non-sensitive' 512*512px preview isn't."

Otherwise, you have two instances of encryption with decryption in the middle; that can't logically be called end-to-end encryption, I never heard it called so, and hopefully it never was.

Papers in academia and the greater industry[2] also referred to it in this way at the time.

Stack Overflow has plenty of examples of folks calling it "end to end encryption" and you can start to see the time period after the Signal protocol and WhatsApp implemented it that the term started to take on a much wider meaning[4]

This also came up a lot in the context of games that rolled out client side encryption for packets on the way to the server. Folks would run MITM applications on their computer to intercept game packets coming out of the client and back from the server. Clever mechanisms were setup for key management and key exchange[3].

[0] as SSL became more common lots of tooling broke at the network level around packet inspection, routing, caching, etc. As well as engineers "having fun" on Friday nights looking at what folks were looking at.

[1] Stack Overflow's security section has references from that era

[2] "Encrypting the internet" (2010) - https://dl.acm.org/doi/10.1145/1851275.1851200

[3] Habbo Hotel's prime and generator being hidden in one of the dynamic images fetched from the server as well as their DH mechanism comes to mind.

[4] Jabber/XMPP however used E2EE in the more modern sense around that time as they were exploring going beyond TLS and having true E2EE.

While you are technically correct in a network topology sense (where the "ends" are the TCP connection points), that definition has been obsolete in consumer privacy contexts for a decade now due to "true" E2EE encryption.

If we use your definition, then Gmail, Facebook, and Amazon are all "End-to-End Encrypted" because the traffic is encrypted between my client and their server. But we don't call them E2EE because the service provider holds the keys and can see the data.

In 2025, when a company claims a camera product is "E2EE", a consumer interprets that to mean "Zero Knowledge". I.e. the provider cannot see the video feeds. If Kohler holds the keys to analyze the data, that is Encryption in Transit, not E2EE. Even though in an older sense (which is what my original comment was saying), it was "End to End Encrypted" because the two ends were defined as Client and Server and not Client to Client (e.g. FB Messenger User1 and FB Messenger User2).

This is what it takes to make a financial transaction E2EE. I'm not saying that banks could or should do this. I'm just saying that their systems do not qualify as E2EE unless they do. It's not ambiguous.

If the provider controls one of the ends then the feds can instruct them to tap that end and nobody is any the wiser.

The best you can do is either to run the inference in an outside jurisdiction (hard for large scale AI), or to attempt a warrant canary.

I assume you mean impossible, and in either case that’s not quite accurate. The “end” is a specific AI model you wished to communicate with, not the platform. You’re suggesting they are one and the same, but they are not and Google proves that with their own secure LLM offering.

But I’m 100% with you on it being a disingenuous use.

Granted, it's a marketing piece trying to sell a product, but still.

That may or may not be the case. TLS is always terminated at a load balancer that uses TLS but it's still common to use HTTP within datacenters. So it may not be E2EE and it's a meaningful security feature.

This is basically the whole thrust of Apple's Private Cloud Compute architecture. It is possible to build a system that prevents user2 from reading the chats, but it's not clear that most companies want to work within those restrictions.

> If you message support for $chat_platform (if there is such a thing) do you expect them to be unable to read the messages?

If they marketed it as end-to-end encrypted? 100%, unambiguously, yes. And certainly not without I, as the user, granting them access permissions to do so.

My understanding is that banks, at least in the US, need to have fairly extensive knowledge relating to all transfers of money, both for fraud handling and for non-fraud (money laundering, etc). A transaction they can't know anything about other than "transfer X money to some recipient you can't know anything about" just doesn't seem realistic with the regulations involved.

Plus, even "transfer X money to some recipient you can't know anything about" is a message that you're sending _to_ the bank, that they have to be able to decode and read. And, presumably, you'd encrypt that message and expect the bank to decrypt it.

Honestly, I don't understand what argument is that you're not sending a message TO the bank, and they need to be able to read it in order to act on it, and they need to decrypt it to read it. The bank is the target of the message, they are one of the "ends" in E2EE.

I feel like I need an "Explain this like I'm 5", because clearly you believe differently than me... and I don't understand _how_ it can be otherwise.

It seems ridiculous to use the term "national security letter" as opposed to "subpoena" in this context, there is no relevant distinction between the two when it comes to this subject. A pointless distraction.

> You can't encrypt away a legal obligation.

Of course you can't. But a subpoena (or a NSL, which is a subpoena) can only mandate you to provide information which you have within your control. It can not mandate you to procure information which you do not have within your control.

If you implement e2ee, customer chats are not within your control. There is no way to breach that with a subpoena. A subpoena can not force you to implement a backdoor or disable e2ee.

I'm not familiar with the referenced Google secure LLM, but offhand- if it's TEE based- Google would be publishing auditable/signed images and Intel/AMD would be the third party Attesting that's whats actually running. TEEs are way out of my expertise though, and there's a ton of places and ways for it to break down.

You can easily find these references in the literature, often comparing link encryption with end-to-end encryption. Some of the earliest papers outlining the plans for SSL in the 90s (Analysis of the SSL 3.0 Protocol) are based on this exact foundation from the 80s (End-To-End Arguments in System Design).

Hell, you can even go back to 1978 and see MITRE discussing this exact thing in "Limitations of end-to-end encryption in secure computer networks".

That said, it might not be impossible to implement some enforcement of AML-like rules with zero-knowledge proofs. What's possible with advanced cryptography is not at all intuitive. But banks profit from their middleman position and surely wouldn't be interested in disintermediating themselves. Neither would crypto people be interested in adding AML. So I don't expect anyone to try. This fact still doesn't make existing middleman banks qualify as E2EE.

That's an argument that their payment service is not end-to-end encrypted, not an argument that you can simply redefine the ends and say that it is.

The problem with AI platforms is that they are also a party to the communication, therefore they can indeed be forced to reveal chats, and therefore it's not e2ee because defining e2ee that way would render the term without distinction.

1. "End-To-End Arguments in System Design" (https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...) argues that it's appropriate to perform various functions at the high-level, application, ends, rather than for example leaving encryption to devices external to the hosts.

It's really a stretch to affirm that it considers "end-to-end encryption" a proper term for transport, client-server encryption.

Actually, I'd say that transport-level, origin-server -> server-destination encryption is precisely one of the things that the paper would not consider end-to-end.

2. "Analysis of the SSL 3.0 Protocol" (https://www.schneier.com/wp-content/uploads/2011/09/paper-ss...):

  a. it doesn't "outline the plans for ssl", it's an analysis of its third version???
  
  b. It doesn't reference "End-To-End Arguments in System Design" anywhere, and doesn't even contain the expression "end-to-end"

Its usage of end-to-end encryption is defined in the paper that's being criticized (https://dl.acm.org/doi/pdf/10.1145/1499799.1499812): «The term end to-end encryption refers to data being enciphered at the source and remaining unintelligible until it deciphered at its final destination.»

> Honestly, I don't understand what argument is that you're not sending a message TO the bank, and they need to be able to read it in order to act on it, and they need to decrypt it to read it. The bank is the target of the message, they are one of the "ends" in E2EE.

That's the part that I'm confused on.

You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:

> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."

This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.

The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.

re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).

The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.

---

RFC 4949 from 2007 (Internet Security Glossary) is quite explicit on this: https://datatracker.ietf.org/doc/html/rfc4949

> $ end-to-end encryption

> (I) Continuous protection of data that flows between two points in

> a network, effected by encrypting data when it leaves its source,

> keeping it encrypted while it passes through any intermediate

> computers (such as routers), and decrypting it only when it

> arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)

>

> Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, *SSL, TLS*.

>

> Tutorial: When two points are separated by multiple communication

> links that are connected by one or more intermediate relays, end-

> to-end encryption enables the source and destination systems to

> protect their communications without depending on the intermediate

> systems to provide the protection.

---

RFC 1455 from 1993 (32 years ago) also uses the term in the IP/Host context: https://pike.lysator.liu.se/docs/ietf/rfc/14/rfc1455.xml

> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.

---

Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.

You might just as well say that E2EE messaging is impossible because you are sending a message "to" Signal, and they need to read it in order to act on it.

I don't understand why you cited it at all; I didn't read it carefully, but I didn't find anything relevant to the discussion.

---

RFC4949 might indeed support your point; it says intended final destination, though: while SSL is listed among the examples, does that include the "SSL-server-SSL" of a non-E2EE messaging system?

I think there's a good chance that it doesn't, in the intentions of the RFC's authors.

---

> This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination"

The disagreement is on whether in a user-server-user system, encrypting the two user-server sides was ever considered sufficient to call it an end-to-end encrypted system.

I think it wasn't, and to my recollection, luckily, no one ever tried to call it that.

Keep in mind that it used to be rare both to use any kind of encryption, and to go through an intermediary server for real-time, one-to-one communication.

It's only when centralized messaging systems begun to use SSL that the possibility of confusion arose.

They should just never have called themselves encrypted, in my opinion; encrypting the traffic was sure a big improvement, but I'd only call a messaging system encrypted if no decryption occurs before reaching the recipient

---

> The definition of "End" has simply shifted from the Machine to the User.

The ends are actually machines in the current definition too, it's not like people decrypt stuff by hand ;)

---

You sure proved that E2EE was a term already in use, anyhow (although I don't think too widely)

I'm telling the bank "I want you to give $5 of my money to Bob". I'm not asking them to pass a message to Bob. The entire message is the instructions for the bank to give the $5 to Bob. The bank MUST be able to read that message in order to follow the directions. There's nothing to "leave encrypted" to treat the bank as a non-end of the E2EE.

You could presumably hide who Bob is by making it some kind of anonymous account thing... but that _still_ wouldn't leave any message encrypted. Because all of the information needs to have been decrypted for the bank to act on it.

For the Signal analogy to apply, there would need to be some message going to Bob. And there isn't... other than "We're giving you this $5 for OP", all of which is information in the original message that the bank needs to act on it.