So basically their marketing-department is abusing a security term in order to sound good, as opposed to a software flaw.
They're claiming "end to end" encryption, which usually implies the service is unable to spy on individual users that are communicating to one-another over an individualized channel.
However in this case there are no other users, and their server is one of the "ends" doing the communicating, which is... perhaps not a literal contradiction in terms, but certainly breaking the spirit of the phrase.
This is an incredibly common misuse of the term e2ee. I think at this point we need a new word because you have a coin flip's chance of actually getting what you think when a company describes their product this way.
End-to-end encryption doesn't mean anything where it is semi-validly used. It's used on phones, where you as a user (or company) don't control what code executes. For example, WhatsApp was end-to-end encrypted. Well, it doesn't actually provide security because with either physical access to the phone or if you have if you can use the app store to "upgrade" the app, you can upload code to the phone. You can upload an apk that replaces the WhatsApp app. It even still uploads the messages to a central server so you can get those messages from Meta, then get the key from the phone some time later or earlier and use the key to decrypt it when the message is already erased from the phone.
(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.
There was a discussion here on hn about OpenAI and it's privacy. Same confusion about e2ee. Users thinking e2ee is possible when you chat with an ai agent.
>Users thinking e2ee is possible when you chat with an ai agent.
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 do not think this matches anyones' mental model of what "end-to-end encrypted" for a conversation between me and what is ostensibly my own computer should look like.
If you promise end-to-end encryption, and later it turns out your employees have been reading my chat transcripts...
If you have an E2EE chat with McDonalds, you shouldn't be surprised that McDonalds employees can read the messages you've sent that account. When messaging accounts controlled by businesses then the business can see those messages.
I'm not sure how you can call chatgpt "ostensibly my own computer" when it's primarily a website.
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."
> it's primarily a website … unambiguously possible[sic] for chatGPT … happens to also be the message platform
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.
No, No typo- the problem with ChatGPT is the third party that would would be Attesting that's how it works, is just the 2nd party.
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.
> 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.
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.
Yeah of course, technically that is true. Still when talking about e2ee in any context it implies to the non technical user: The company providing the service cannot read what I am writing.
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.
Yes but National Security Letters make that pointless. You can't encrypt away a legal obligation. The point of e2ee is that a provider can say to the feds "this is all the information we have", and removing the e2ee would be noticed by security researchers.
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.
> Yes but National Security Letters make that pointless
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.
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.
I would say Telegram is communicating their level of encryption pretty good ("client-to-client" and "client-to-server" is a good way to avoid the ambiguity of e2e).
The problem is that you have to trust that they'll stay that way, and we have no way of proving that the app that runs on your phone comes from the same source that they publish.
It's not incredibly common, there's sure a lot of companies that try to misuse it, but the average person (even non technical) still interprets it in the correct way
I think part of the problem is that prior to WhatsApp's E2EE implementation in like 2014, TLS was very often called "End to End Encryption" as the ends were Client and Server/Service Provider. It got redefined and now the new usage is way more popular than the old one.
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.
I’m pushing back on that one. I’ve been running websites since the ‘90s, and I’ve never heard E2EE used that way until very recently by vendors who, bluntly, want to lie about it.
It was pretty common to call client-side encryption/SSL "end to end encryption" among network engineers who were analyzing data flowing through their networks[0] as well as those who were implementing SSL/TLS into their applications[1]. The ends were the client and the server and the data was encrypted "end to end". The goal at that time was to prevent MITM snooping/attacks which were highly prevalent at the time.
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
At least in some circles, the real meaning of "end-to-end encryption" was being addressed. For example, in the field of credit card processing, here's an article from 2009 which talks about how people back then were misusing the term: https://web.archive.org/web/20090927092231/http://informatio...
Granted, it's a marketing piece trying to sell a product, but still.
I wasn't a network engineer, but to my recollection "end-to-end encryption" was only used occasionally, probably by people not too knowledgeable in cryptography
Well respectfully your recollection is missing lots of references by people that were "knowledgeable in cryptography".
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".
With three citations I was about to give in, and accept that my experience might have been limited, but then I checked those citations and... are you trolling? Or were those given you by an llm?
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.
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"
3. "Limitations of end-to-end encryption in secure computer networks" is mostly concerned with warning about side-channels, that they can be used to disseminate information despite encryption.
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.»
I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.
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.
> 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.
> I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make
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)
The two endpoints of the communication with Kohler's app are the client and the server. In WhatsApp's E2EE implementation the endpoints are two client devices. Both are valid meanings of E2EE. You're defining that "end to end" means the server cannot access it but that's simply not what it means.
The modern usage of E2EE definitely means that "the server cannot access it". That's the meat of this entire discussion.
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).
> 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.
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.
No term will stop marketers from lying. If users see one as being the more secure one, marketers will use it. Unless they get sued for false advertising.
> However in this case there are no other users, and their server is one of the "ends" doing the communicating, which is... perhaps not a literal contradiction in terms, but certainly breaking the spirit of the phrase.
Am I understanding correctly that the other end of this is a rear end?
> They're claiming "end to end" encryption, which usually implies the service is unable to spy on individual users that are communicating to one-another over an individualized channel.
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.
This is exactly what E2EE means. I used to work at a bank, and our data was E2EE, and we had to certify that it was E2EE - from the person paying, through the networks, through the DNS and Load balancers, until it got to the servers. Only at the servers could it be unencrypted and a (authoried) human could look at it.
Of course, only authorized users could see the data, but that was a different compliance line item.
No, E2EE doesn't mean it's encrypted until the service provider decrypts it. E2EE means the service provider is unable to decrypt it. What you are describing is encryption in transit (and possibly at rest).
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.
I would argue it depends on context. E2EE means it's encrypted until the "target" receives it. For a messaging protocol, it's the intended recipient of the message. For what the person you're replying is discussing, the intended recipient IS the bank.
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, it doesn't depend on context. The intended recipient of a financial transaction is not the bank. The intended recipient is the party you're trying to pay. It is possible for financial transactions to be E2EE and completely indecipherable by anyone but the two parties of the transaction. Crypto like ZCash can do it. Banks cannot.
Can you expand on this a bit. It was my understanding that you're telling the bank to pay the vendor (from your money/credit). In that case, the bank certainly needs to know about the transaction... so it can make the payment.
I suggest researching how ZCash uses zero-knowledge proofs to allow paying money from your balance to another person's balance without any middleman like a bank being able to decrypt your transaction, while still allowing everyone to verify that important invariants are maintained, such as not allowing you to spend more money than you have.
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.
Doesn't the anonymous-ness of crypto/zcash make it impossible for the bank to handle fraud (reversing of charges and such)?
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.
> 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.
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'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.
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.
While what you're saying makes sense, it's not the normal use of the term - in fact, the term 'end to end encryption' was basically coined to differentiate user-to-user encryption (through an intermediary service that can't decrypt the message) from the regular case (user to service encryption) that you're talking about!
$ 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.
There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :D
Nah. You have no reasonable expectation that the bank itself can’t access your financial records. Anyone reading Kohler’s lies would have every expectation that the Internet of Poopcam screenshots are theirs and theirs alone.
Anyone reading that is misunderstanding what E2EE means. As the article says, that's client-side encryption. Kohler isn't lying, people are confusing two different security features.
They're also claiming regulatory requirements as features. At least consumers might be able to sue in addition to several governments when it turns out to be a bunch of crap.
Sounds like the crappiest data source for AI training yet.
But in all seriousness, of course they can access the data. Otherwise who else would process it to give any health results back? I don't think encryption in transit is relevant to privacy concerns because the concerns are about such data being tied to you at all, in any way. At the same time, yes, this could product valuable health information.
Their better bet would be to allow full anonymity, so even if there is a leak (yeah, the puns write themselves), there is never a connection between this data and your person.
If there's anything circa five dozen wannabe-techbro blogposts have taught me, it's that if you wait for a product that's worthy of shipping, you're never gonna ship.
Imagine the collective brainpower that could be used to help solve the world's ills, and instead decided, no, what we need is a camera pointed at your asshole which we feed into an AI-powered SaaS we can then sell to you for a subscription. This industry is finished.
I watched a teardown of it and the truly bizarre thing was that the build quality was actually amazing. Machined out of a huge block of aluminum, really big bearings, etc.
This is downstream from the notion that companies need to have infinite growth forever. Of course, that's not possible, so this is the end stages of that: wealth trickles up while the, well... you can guess what's trickling down.
Ironically, "Trickle-Down Economics" was phrased in a circa-1900 political cartoon as "The horse eats the grain, and then trickles it down to the sparrow on the barn floor." I'll let you picture the image.
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.
The problem is genuinely the misleading nature of the phrase "end to end" and the lack of a better alternative. HTTPS is "end to end". There should be some new word for "decryptable only by the user".
> Kohler Health’s homepage, the page for the Kohler Health App, and a support page all use the term “end-to-end encryption” to describe the protection the app provides for data. Many media outlets included the claim in their articles covering the launch of the product.
When companies first wanted to sell things over the Web, a concern I heard a lot was that consumers would be afraid of getting ripped off somehow. So companies started emphasizing prominently how the customer was protected with n bits of encryption. As if this solved the problem. It did not, but people were confused by confident buzzwords.
(I was reminded of this, because I actually saw a modern Web site touting that prominently just last week, like maybe they were working from a 30 year-old Dotcom Marketing for Dummies book, and it was still not very applicable to the concern.)
Some marketers lie, or don't care what the truth is. They want success, and bonuses, and promotions. And, really, a toilet company possibly getting class-action sued for a feces camera that behaves in an unexpected way, that attorneys would have to convince a judge was misrepresented, and then quantify the unclear harm, and finally settle, several years later, for lawyers' fees and a $10 off coupon for the latest model Voyeur Toilet 3000... isn't on the radar of the marketers.
You pay someone in a developing nation $1.00 per day to look at thousands of photos of shit. Like, how do people think Facebook moderation and semantic labeling happen? Cheap labor in places with no labor laws. It was ever thus.
I meant that they train their system on pictures where they have the underlying medical data. Their system might still be total crap (teehee), but I'm guessing that they at least try to make it predictive/generalized.
Here we are 35 years after the invention of the web browser, and now browser fingerprinting is an exact science. [1] I'm guessing 35 years from now toilet bowl fingerprinting will be an exact science. Claims of "de-identified and/or anonymized data" are reckless and naive.
Kohler can "de-identify [the user’s] data for lawful purposes." I mean exactly how would that ever be justified? "Hey, we see a man-sized log in the bowl. There's only supposed to be women there. The perp must be in that house!!!"
That is very strangely worded, to a degree they I wonder if maybe the wordsmithing was outsourced to either an ai or someone who didn't do English very well. Or if it's meant to be confusing.
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).
So basically some idiot company connected toilets with cameras to the internet claiming the media collected of peoples "ends" was end to end encrypted. Except, it wasn't.
These compromised toilets could be easily used to exfiltrate compromising videos of exfiltrations.
?? I got very confused from the start of this article because it is clear that Kohler is one end of the communication from how the product is described and marketed. They’re just stating the data is encrypted between the device and them.
The old adage is "garbage in, garbage out". s/garbage/feces/g
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.
People who have clinical gut issues need to track this kind of thing
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.
You know, obvious humor potential aside, that’s a great point. Fewer people would laugh about a pee analyzer: “Oh, it can tell if you’re dehydrated, or in ketosis, or whatever? Makes sense!” I can imagine how this could gather similar types of information.
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.
Yeah I hate to kill the party but if you can’t imagine a need for this product, consider yourself blessed. GI issues are not pleasant.
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.
It's the idea of buying it that's nonsensical. I'm not sure how you could realistically use this thing long term. Someone has to sort through the data, spot trends, and offer competent advice. Presumably once you have your diet under control then there is no further need of this bowl level analysis.
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?
Our crypto cookies implement end-to-end encryption by creating a digest of the input morsels and securing their transit between the front end and the back end. Be warned, certain failure modes can result in over-encryption or return of partially-encrypted ciphertext to the sender.
It would be naive to assume they couldn't access the data from a technical perspective. I think anyone in here would think so. The problem is regular customers who aren't technical and don't have much choice but to trust claims by the seller - these are the real victims here.
I feel End-to-end is over marketed. Yes it protects your data from transmission pipes, but data on both your "ends" can be easily controlled and duplicated. Your picture on your device can be accessed by 3rd party, so does your data on the server.
Everything in our lives is connected to the internet, so why not our toilets? Take a tour of Smart Pipe, the hot new tech startup that turns your waste into valuable information and fun social connectivity.
At least it is still optional. Imagine a world where cameras came preinstalled, and your toilet would phone home like your SmartTV and there was no way out of it.
I remember a sign in our dorm bathroom that read, “toilet cam is for research purposes only”. It was a joke, but always got a nice reaction from new people in the building.
But they actually sell this?! And want to charge me for it!?
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
> 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.
> "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.
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
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.
To be clear, SSL/TLS and other transport protocols can absolutely be considered end-to-end encryption, if they're established between the two real interlocutors.
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.
I honestly cannot believe this device exists. I'm living in the absolute weirdest timeline that I could have never imagined. Imagine being an engineer working on this particular ring of the torment nexus.
Years ago, a friend and I were kicking around startup ideas. We weren't coming up with anything good, so we flipped it and decided to come up with the worst/dumbest idea possible. We landed on a social media site dedicated to poop (this was back when social media sites were all the rage). People could upload pictures of their poop, discuss poop, share "best poop" stories, and so on. We never actually built anything, realizing it was just a joke, a total waste of time. ... Fast forward to 2025: For $600-plus-monthly-subscription, we'll take pictures of your poop!
BTW, someone please tell me that there is/was a social media site dedicated to poop, and the founder got rich from it. I need that today.
So basically their marketing-department is abusing a security term in order to sound good, as opposed to a software flaw.
They're claiming "end to end" encryption, which usually implies the service is unable to spy on individual users that are communicating to one-another over an individualized channel.
However in this case there are no other users, and their server is one of the "ends" doing the communicating, which is... perhaps not a literal contradiction in terms, but certainly breaking the spirit of the phrase.
This is an incredibly common misuse of the term e2ee. I think at this point we need a new word because you have a coin flip's chance of actually getting what you think when a company describes their product this way.
Any new term you come up with, will end up being misused by marketers.
End-to-end encryption doesn't mean anything where it is semi-validly used. It's used on phones, where you as a user (or company) don't control what code executes. For example, WhatsApp was end-to-end encrypted. Well, it doesn't actually provide security because with either physical access to the phone or if you have if you can use the app store to "upgrade" the app, you can upload code to the phone. You can upload an apk that replaces the WhatsApp app. It even still uploads the messages to a central server so you can get those messages from Meta, then get the key from the phone some time later or earlier and use the key to decrypt it when the message is already erased from the phone.
(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.
Yes, the government can also just implant tiny cameras in your eyeballs and just record everything you see anyway, so you’re not safe.
I have never seen "e2ee" abused this way personally.
There was a discussion here on hn about OpenAI and it's privacy. Same confusion about e2ee. Users thinking e2ee is possible when you chat with an ai agent.
https://news.ycombinator.com/item?id=45908891
>Users thinking e2ee is possible when you chat with an ai agent.
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 do not think this matches anyones' mental model of what "end-to-end encrypted" for a conversation between me and what is ostensibly my own computer should look like.
If you promise end-to-end encryption, and later it turns out your employees have been reading my chat transcripts...
If you have an E2EE chat with McDonalds, you shouldn't be surprised that McDonalds employees can read the messages you've sent that account. When messaging accounts controlled by businesses then the business can see those messages.
I'm not sure how you can call chatgpt "ostensibly my own computer" when it's primarily a website.
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."
> it's primarily a website … unambiguously possible[sic] for chatGPT … happens to also be the message platform
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.
No, No typo- the problem with ChatGPT is the third party that would would be Attesting that's how it works, is just the 2nd party.
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.
> 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.
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.
Not all messages. The message you sent to support- the answer is implicitly "of course they can read them."
Yeah of course, technically that is true. Still when talking about e2ee in any context it implies to the non technical user: The company providing the service cannot read what I am writing.
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.
e2ee implies that there is a third party who can't read the messages. If you are chatting with an AI, who is the third party?
>who is the third party?
My ISP who delivers these chat messages.
Ideally, both OpenAI employees and the 3-letter agencies?
Yes but National Security Letters make that pointless. You can't encrypt away a legal obligation. The point of e2ee is that a provider can say to the feds "this is all the information we have", and removing the e2ee would be noticed by security researchers.
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.
> Yes but National Security Letters make that pointless
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 saw a YouTube video claim similar levels of privacy are possible using trusted computing.
Zoom also did this once
They don't care about security at all.
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.
They also paid me something around 100 dollars in settlement for this
I believe they now have a proper e2ee mode which disables all the cloud powered features, no?
They aquihired (and gutted) keybase for this, but I have a doubt that their "reimplementation" is actually E2EE.
Whatsapp, Signal, Telegram, iCloud
I would say Telegram is communicating their level of encryption pretty good ("client-to-client" and "client-to-server" is a good way to avoid the ambiguity of e2e).
https://telegram.org/faq?setln=en#q-so-how-do-you-encrypt-da...
Please cite where Signal is not e2ee.
The problem is that you have to trust that they'll stay that way, and we have no way of proving that the app that runs on your phone comes from the same source that they publish.
That's a completely different problem than marketers co-opting the term "end-to-end encryption".
It's not incredibly common, there's sure a lot of companies that try to misuse it, but the average person (even non technical) still interprets it in the correct way
“In transit encryption”
Creating a new term for the less secure definition doesn't work, as they'll just continue to call it E2EE encrypted.
I think part of the problem is that prior to WhatsApp's E2EE implementation in like 2014, TLS was very often called "End to End Encryption" as the ends were Client and Server/Service Provider. It got redefined and now the new usage is way more popular than the old one.
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.
I’m pushing back on that one. I’ve been running websites since the ‘90s, and I’ve never heard E2EE used that way until very recently by vendors who, bluntly, want to lie about it.
It was pretty common to call client-side encryption/SSL "end to end encryption" among network engineers who were analyzing data flowing through their networks[0] as well as those who were implementing SSL/TLS into their applications[1]. The ends were the client and the server and the data was encrypted "end to end". The goal at that time was to prevent MITM snooping/attacks which were highly prevalent at the time.
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.
At least in some circles, the real meaning of "end-to-end encryption" was being addressed. For example, in the field of credit card processing, here's an article from 2009 which talks about how people back then were misusing the term: https://web.archive.org/web/20090927092231/http://informatio...
Granted, it's a marketing piece trying to sell a product, but still.
I wasn't a network engineer, but to my recollection "end-to-end encryption" was only used occasionally, probably by people not too knowledgeable in cryptography
Well respectfully your recollection is missing lots of references by people that were "knowledgeable in cryptography".
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".
With three citations I was about to give in, and accept that my experience might have been limited, but then I checked those citations and... are you trolling? Or were those given you by an llm?
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...):
3. "Limitations of end-to-end encryption in secure computer networks" is mostly concerned with warning about side-channels, that they can be used to disseminate information despite encryption.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.»
I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.
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.
> I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make
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)
> prior to WhatsApp's E2EE implementation in like 2014, TLS was very often called "End to End Encryption"
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
The two endpoints of the communication with Kohler's app are the client and the server. In WhatsApp's E2EE implementation the endpoints are two client devices. Both are valid meanings of E2EE. You're defining that "end to end" means the server cannot access it but that's simply not what it means.
The modern usage of E2EE definitely means that "the server cannot access it". That's the meat of this entire discussion.
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).
> 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.
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.
No term will stop marketers from lying. If users see one as being the more secure one, marketers will use it. Unless they get sued for false advertising.
I despise how often that’s used. “Do you have end to end encryption?” “Sure! We use TLS for everything, and KMS for at-rest.” “So… no?”
> However in this case there are no other users, and their server is one of the "ends" doing the communicating, which is... perhaps not a literal contradiction in terms, but certainly breaking the spirit of the phrase.
Am I understanding correctly that the other end of this is a rear end?
Every front end needs a rear end. So, yes.
While they’re taking one “end” much less literally than usual, they are taking the other “end” much more literally…
> They're claiming "end to end" encryption, which usually implies the service is unable to spy on individual users that are communicating to one-another over an individualized channel.
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.
What is the other “end”?
This is exactly what E2EE means. I used to work at a bank, and our data was E2EE, and we had to certify that it was E2EE - from the person paying, through the networks, through the DNS and Load balancers, until it got to the servers. Only at the servers could it be unencrypted and a (authoried) human could look at it.
Of course, only authorized users could see the data, but that was a different compliance line item.
No, E2EE doesn't mean it's encrypted until the service provider decrypts it. E2EE means the service provider is unable to decrypt it. What you are describing is encryption in transit (and possibly at rest).
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.
I would argue it depends on context. E2EE means it's encrypted until the "target" receives it. For a messaging protocol, it's the intended recipient of the message. For what the person you're replying is discussing, the intended recipient IS the bank.
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, it doesn't depend on context. The intended recipient of a financial transaction is not the bank. The intended recipient is the party you're trying to pay. It is possible for financial transactions to be E2EE and completely indecipherable by anyone but the two parties of the transaction. Crypto like ZCash can do it. Banks cannot.
Can you expand on this a bit. It was my understanding that you're telling the bank to pay the vendor (from your money/credit). In that case, the bank certainly needs to know about the transaction... so it can make the payment.
Are we talking about 2 different things here?
I suggest researching how ZCash uses zero-knowledge proofs to allow paying money from your balance to another person's balance without any middleman like a bank being able to decrypt your transaction, while still allowing everyone to verify that important invariants are maintained, such as not allowing you to spend more money than you have.
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.
Doesn't the anonymous-ness of crypto/zcash make it impossible for the bank to handle fraud (reversing of charges and such)?
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.
Yes, banks have a bunch of regulations which means they can't run an end-to-end encrypted payment service.
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.
Can you speak to this part?
> 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.
That's an implementation detail of the bank.
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'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.
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.
While what you're saying makes sense, it's not the normal use of the term - in fact, the term 'end to end encryption' was basically coined to differentiate user-to-user encryption (through an intermediary service that can't decrypt the message) from the regular case (user to service encryption) that you're talking about!
It wasn't coined, it was reused. It historically meant things that were encrypted from the client to the server, e.g. SSH, SSL, TLS, etc.
RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949
There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :DNah. You have no reasonable expectation that the bank itself can’t access your financial records. Anyone reading Kohler’s lies would have every expectation that the Internet of Poopcam screenshots are theirs and theirs alone.
Anyone reading that is misunderstanding what E2EE means. As the article says, that's client-side encryption. Kohler isn't lying, people are confusing two different security features.
That is an uncommon interpretation that’s far different than the usual meaning.
They're also claiming regulatory requirements as features. At least consumers might be able to sue in addition to several governments when it turns out to be a bunch of crap.
It sounds like one term is being used for two very different things.
Yes, because people don't know the difference between "in transit" and e2ee.
Doesn't that just mean HTTPS then?
Sounds like the crappiest data source for AI training yet.
But in all seriousness, of course they can access the data. Otherwise who else would process it to give any health results back? I don't think encryption in transit is relevant to privacy concerns because the concerns are about such data being tied to you at all, in any way. At the same time, yes, this could product valuable health information.
Their better bet would be to allow full anonymity, so even if there is a leak (yeah, the puns write themselves), there is never a connection between this data and your person.
You could have a classifier running on-device that sends summary data (rather than raw images) back to Kohler.
Yeah, it’s kinda like such a reasonable thing too
Doing on device compute is probably expensive and would prohibit such a product based on the economics but ITS A GENITAL CAM
Well, this waste analyzing piece of e-waste costs $600, so you could probably cram a lot of inference horsepower in there if you wanted to.
And the heat from the processor(s) would make for a comfy user experience in the wintertime.
Chuck Berry doesn’t see your point but would like to talk more.
Only for the very well endowed since it points down. Though hopefully they're doing something other than let their bits dangle in the toilet water.
Only for the very well endowed since it points down.
Each day after 50, your line and bobbers get a little closer to the pond.
Isn’t it more of a poo cam if it’s pointed down?
>Otherwise who else would process it to give any health results back?
Well it could be processed on-device.
That would only work after they're done training the ai models.
So like after the alpha and beta phases, when they have an actual product worthy of selling?
If there's anything circa five dozen wannabe-techbro blogposts have taught me, it's that if you wait for a product that's worthy of shipping, you're never gonna ship.
> But in all seriousness, of course they can access the data. Otherwise who else would process it to give any health results back?
It's "of course" for very knowledgeable people, normal people just assume that it means guaranteed privacy
[dead]
Imagine the collective brainpower that could be used to help solve the world's ills, and instead decided, no, what we need is a camera pointed at your asshole which we feed into an AI-powered SaaS we can then sell to you for a subscription. This industry is finished.
It’s pretty impressive that that juicero thing wasn’t the most bizarre thing they could come up with.
I watched a teardown of it and the truly bizarre thing was that the build quality was actually amazing. Machined out of a huge block of aluminum, really big bearings, etc.
That was part of why it failed though. The over-engineering made it very hard to recover costs
it literally just squeezed juice out of a plastic packet, that's it.
It's pointed at the toilet bowl contents though it may catch some scrot in the edge of frame depending upon ambient temperatures.
https://images.ctfassets.net/veq5rt4lbvkn/2bpiwr3gYoRPnXqB8e...
Can you send it in for servicing when the lens becomes obscured ?
Hopefully in a tyvek mailer...
I just want to note: I upvoted you for the phrase "catch some scrot".
"[D]epending upon ambient tempertures and user age" is probably more accurate.
This is downstream from the notion that companies need to have infinite growth forever. Of course, that's not possible, so this is the end stages of that: wealth trickles up while the, well... you can guess what's trickling down.
Ironically, "Trickle-Down Economics" was phrased in a circa-1900 political cartoon as "The horse eats the grain, and then trickles it down to the sparrow on the barn floor." I'll let you picture the image.
They claim it only points about your doings, but even then...
Is there a spare 'i' in your post?
Who the hell buys this...
The Norwegian term for e2ee is "ende-til-ende-kryptering".
And "ende" can also mean 'butt' https://naob.no/ordbok/ende_3#52867988
So I guess it makes some kind of sense.
Rear-end-to-end encryption, if you will.
We're past The Onion clips coming true, now it's Adult Swim:
https://youtu.be/DJklHwoYgBQ
This brings back memories of Adult Swim's "Smart Pipe" spoof infomercial.
https://youtube.com/watch?v=DJklHwoYgBQ for those who haven't seen it yet.
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.
Kohler is a registered sex offender.
Satire is dead. A toilet company killed it.
Could easily have been an SNL sketch in 2010
Smart Pipe https://www.youtube.com/watch?v=DJklHwoYgBQ
They can encrypt data coming out of both ends?!
Sounds like something they pulled out of their ass..
But their algorithms are number 1 on the market!
#2. There's always somebody better. Sorry, just taking the piss there.
This obsession with personal health data collection is in its self counter productive to health outcomes and insane behavior.
congratulations, you have lived to see man made horrors beyond your comprehension
The problem is genuinely the misleading nature of the phrase "end to end" and the lack of a better alternative. HTTPS is "end to end". There should be some new word for "decryptable only by the user".
We need more products to be vendor agnostic, really.
There are numerous benefits. For one, it will make people aware where their data goes when they set up the device.
It's in the name. TLS- Transport Layer Security.
> Kohler Health’s homepage, the page for the Kohler Health App, and a support page all use the term “end-to-end encryption” to describe the protection the app provides for data. Many media outlets included the claim in their articles covering the launch of the product.
When companies first wanted to sell things over the Web, a concern I heard a lot was that consumers would be afraid of getting ripped off somehow. So companies started emphasizing prominently how the customer was protected with n bits of encryption. As if this solved the problem. It did not, but people were confused by confident buzzwords.
(I was reminded of this, because I actually saw a modern Web site touting that prominently just last week, like maybe they were working from a 30 year-old Dotcom Marketing for Dummies book, and it was still not very applicable to the concern.)
Some marketers lie, or don't care what the truth is. They want success, and bonuses, and promotions. And, really, a toilet company possibly getting class-action sued for a feces camera that behaves in an unexpected way, that attorneys would have to convince a judge was misrepresented, and then quantify the unclear harm, and finally settle, several years later, for lawyers' fees and a $10 off coupon for the latest model Voyeur Toilet 3000... isn't on the radar of the marketers.
How does one "train" an AI with a flood of random toilet pictures and no corresponding medical data to match it with?
"potty training". Sorry.
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.
You pay someone in a developing nation $1.00 per day to look at thousands of photos of shit. Like, how do people think Facebook moderation and semantic labeling happen? Cheap labor in places with no labor laws. It was ever thus.
Appropriate username.
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.
They probably do clinical trials (or at least something like that) where they get baseline data from participants through other means.
I'm talking about sold units in the field.
I meant that they train their system on pictures where they have the underlying medical data. Their system might still be total crap (teehee), but I'm guessing that they at least try to make it predictive/generalized.
The same thing we always do. Pay some citizens of an African nation a pitiful wage to just make up annotations.
Then you can incorporate this into a "health care product" and charge insurance companies insane rates on personal toilet cameras.
I think the obvious things are:
- 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.
They probably do match it, with data collected from other sources
Even (especially?) for its stated purpose, this is cursed technology.
Here we are 35 years after the invention of the web browser, and now browser fingerprinting is an exact science. [1] I'm guessing 35 years from now toilet bowl fingerprinting will be an exact science. Claims of "de-identified and/or anonymized data" are reckless and naive.
[1] https://news.ycombinator.com/item?id=46016249
Kohler can "de-identify [the user’s] data for lawful purposes." I mean exactly how would that ever be justified? "Hey, we see a man-sized log in the bowl. There's only supposed to be women there. The perp must be in that house!!!"
That is very strangely worded, to a degree they I wonder if maybe the wordsmithing was outsourced to either an ai or someone who didn't do English very well. Or if it's meant to be confusing.
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).
IP address, device identifier, mother's maiden name, SSN, etc etc
You mean the I-Pee address? Sorry, y'all, I gotta get it out in this thread, it's too easy.
oof, how did I miss that?
So basically some idiot company connected toilets with cameras to the internet claiming the media collected of peoples "ends" was end to end encrypted. Except, it wasn't.
These compromised toilets could be easily used to exfiltrate compromising videos of exfiltrations.
The toilets leak pictures of people taking leaks.
The internet really is going to shit.
?? I got very confused from the start of this article because it is clear that Kohler is one end of the communication from how the product is described and marketed. They’re just stating the data is encrypted between the device and them.
> it is clear that Kohler is one end of the communication
That’s not end-to-end encryption. By that logic HN, and any other website over HTTPS is E2E encrypted.
Is HTTPS really always E2EE?
I was under the impression that large companies use proxies so they can do deep packet inspection.
PS: you are right of course.
That is what "end-to-end encryption" has come to mean in marketing. In the same way that every single product is "natural."
All natural blends of hydroxyapatite, sodium laureth sulfate, and methylpropanediol, just like grandma used to make
No, they're just trying to mislead their clients
I'm so sorry for the people who work on this and have to look at the data.
The old adage is "garbage in, garbage out". s/garbage/feces/g
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.
some poor soul has to do train this AI. Imagine your job is categorizing pictures of poop
What. Who is buying a $600 camera to take pictures of your stool?
People who have clinical gut issues need to track this kind of thing
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.
You know, obvious humor potential aside, that’s a great point. Fewer people would laugh about a pee analyzer: “Oh, it can tell if you’re dehydrated, or in ketosis, or whatever? Makes sense!” I can imagine how this could gather similar types of information.
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.
Yeah I hate to kill the party but if you can’t imagine a need for this product, consider yourself blessed. GI issues are not pleasant.
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.
Which GI issues are currently only medically manageable with a camera in your toilet bowl, and how were people managing them before?
It's the idea of buying it that's nonsensical. I'm not sure how you could realistically use this thing long term. Someone has to sort through the data, spot trends, and offer competent advice. Presumably once you have your diet under control then there is no further need of this bowl level analysis.
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?
$84/yr. It’s a $600 purchase, then $7/mo.
[dead]
Assuming you're appropriately sighted, you don't need a $600 toilet cam to tell you if you're dehydrated.
Not the people spending $12.1m on a gold toilet that's for sure.
You wouldn't want that cheap tat miring up the clean lines of your throne.
* https://www.bbc.com/news/articles/cjd07dprln9o
Don't forget the subscription fee
Our crypto cookies implement end-to-end encryption by creating a digest of the input morsels and securing their transit between the front end and the back end. Be warned, certain failure modes can result in over-encryption or return of partially-encrypted ciphertext to the sender.
So they made Google TISP?
https://archive.google/tisp/index.html
To me it reminds me of Smart Pipe.
https://youtube.com/watch?v=DJklHwoYgBQ
Fingers crossed they'll pivot to a smart anal probe I can just leave in there
It would be naive to assume they couldn't access the data from a technical perspective. I think anyone in here would think so. The problem is regular customers who aren't technical and don't have much choice but to trust claims by the seller - these are the real victims here.
I feel End-to-end is over marketed. Yes it protects your data from transmission pipes, but data on both your "ends" can be easily controlled and duplicated. Your picture on your device can be accessed by 3rd party, so does your data on the server.
End-to-end encryption is not a term used for communication between clients and servers, although I saw several marketers trying to do it.
For normal people E2EE means privacy, and that's why some company tries to sneak the term in products where it makes no sense.
> For normal people E2EE means privacy
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.
> > For normal people E2EE means privacy > > It's misunderstood.
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
https://www.youtube.com/watch?v=DJklHwoYgBQ
Smart Pipe | Infomercials | Adult Swim
Everything in our lives is connected to the internet, so why not our toilets? Take a tour of Smart Pipe, the hot new tech startup that turns your waste into valuable information and fun social connectivity.
[Smart Pipe Inc. is a registered sex offender.]
Huh what could possibly go wrong here?
>https://www.nytimes.com/2025/12/02/world/asia/south-korea-ca...
Oh...
This world is upside down. I wake up feeling like I am the man in the middle being attacked from all sides.
Let's think about why we're in a world where someone wants to sell you a camera to put in your toilet.
At least it is still optional. Imagine a world where cameras came preinstalled, and your toilet would phone home like your SmartTV and there was no way out of it.
Holy crap.
I remember a sign in our dorm bathroom that read, “toilet cam is for research purposes only”. It was a joke, but always got a nice reaction from new people in the building.
But they actually sell this?! And want to charge me for it!?
Holy crap!
The Dekoda should come with this sticker Aus hygienischen Gründen wird diese Toilette videoüberwacht
https://shop.digitalcourage.de/digitalcourage-und-ccc-aufkle...
They want to charge you $600 for it, plus a $7/mo subscription.
Features fully secure e2mitm2ee.
Did they say which ends they meant?
The theranos of toilets
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
> No, before that it was simply not a term, except in some obscure radio protocol
> 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.
> "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.
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
The 1994 paper (freely available at https://digital.library.unt.edu/ark:/67531/metadc1341727/m2/...) is actually about proper E2EE.
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
> The 1994 paper (freely available at https://digital.library.unt.edu/ark:/67531/metadc1341727/m2/...) is actually about proper E2EE.
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.
To be clear, SSL/TLS and other transport protocols can absolutely be considered end-to-end encryption, if they're established between the two real interlocutors.
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.
"end to end" I see what you did there.
Holy fuck they actually built Smart Pipe[1]
1: https://youtu.be/DJklHwoYgBQ?si=bSRE2lOqwwm1Q_D9
I'm convinced whatever Torment Nexus we can think of will get built.
Rule 34(B)?
Now's the time to get on board so that, when they launch the social network, you can be a top influencer just like Scout
#itsmyanus
Enshittification has gone too far.
What exactly is the toilet camera for? Are they taking pictures of your daily bowel movements?
So, end-to-end-encraption?
Oh wait, maybe this is what Cory Doctorow is referring to as enshittified?
I mean, these jokes make themselves, including whoever buys the hardware, AND buys the marketing pitch.
It would be end-to-end only if it was pee-to-pee.
Does this count as enshittification?
I honestly cannot believe this device exists. I'm living in the absolute weirdest timeline that I could have never imagined. Imagine being an engineer working on this particular ring of the torment nexus.
No pictures were shown on the website.
"Hey man, we didn't specify where the ends are."
I’m sorry the shit had hit the fan at Kohler, but there’s no reason a cloud poop camera even exists.
Hi, who just joined?
Enshittification.
Apotheosis of enshitification.
Years ago, a friend and I were kicking around startup ideas. We weren't coming up with anything good, so we flipped it and decided to come up with the worst/dumbest idea possible. We landed on a social media site dedicated to poop (this was back when social media sites were all the rage). People could upload pictures of their poop, discuss poop, share "best poop" stories, and so on. We never actually built anything, realizing it was just a joke, a total waste of time. ... Fast forward to 2025: For $600-plus-monthly-subscription, we'll take pictures of your poop!
BTW, someone please tell me that there is/was a social media site dedicated to poop, and the founder got rich from it. I need that today.
Look on the bright side: you can tell people you were simply ahead of your time!
I believe it is called "reddit"
> collects images and data from inside, promising to track and provide insights on gut health, hydration, and more
cough bullshit.
What I want to know is who is taking pictures of their poop like this? There has to be a better way.
AI enshitification. Literally.