Kana input exists in japanese and reuses each letter of the keyboard to mean a different kana. So you could have a similar confusion in japanese. I believe many older people use it.
This replacement has already happened. Everyone who can has long since replaced their phone support with a set of menus that end in "use the website". When you need to talk to the human you still need to talk to the human.
>One can argue this is a positive, as a customer if I can push a few buttons and issue a voice command to an AI to fix my problem instead of waiting on hold, that is a net positive.
If you could do it through the website then you would be much happier than having to argue with a chatbot. And if you can't do it through the website, there aren't going to let a robot do it on your behalf.
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...
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.
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.
This is why I specified "mental model". Interacting with ChatGPT is not marketed as "sending messages to OpenAI the company". It is implied to be "sending messages to my personal AI assistant".
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.
I believe we are in agreement. If you are a communication platform that implements e2ee then you provide the guarantee to users, backed by security researchers, that the government can't read their communications by getting a subpoena from the communication platform.
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.
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.
If you like deleting all your files, sure. LLMs, especially small ones, have far too high a propensity for consequential mistakes to risk them on something like that.
I was thinking more in context of interactive help that will just find and display relevant manual info (to get around the problem of "it remembered wrong") rather than vibe coder favourite of "just run what you hallucinated immediately"
So to summarize: a. you're paying that for health insurance, not for the birth of the child. If you, your wife, your children had any other diseases then those would be covered as well. This is a significant benefit. b. all the systems that subsidize health care for those less well off don't apply because you're wealthy. So you are bearing the full cost of extremely high quality health insurance in a western country.
> So you are bearing the full cost of extremely high quality health insurance in a western country.
Overinflated imaginary cost*
There is no way that a medical consultation of 15 minutes actually cost $32k. Examples like this are aplenty, but only from the US. My favourite one was an itemised bill for birth that included a $1k for skin contact with the newborn.
How come other countries have better healthcare at lower real costs? Basically every developed nation has better healthcare outcomes than the US. All other nations have cheaper healthcare.
America is not special, we've just brainwashed our less-observant citizens into believing that solutions the entire rest of the world uses will never and can never work here. There's nothing special about our population or economy that would prevent accessible healthcare. The only thing standing in our way is healthcare companies who want their 6000% cut of every procedure and politicians who will do literally anything to give billionaires another dollar.
As someone who has lived in several countries, I do not believe every developed nation achieves better healthcare outcomes than the United States. Many European countries, as well as Canada, offer some form of universal coverage with free general treatment but waiting times for appointments and procedures can vary widely. That said, I still think universal healthcare is preferable, as these systems tend to prioritize urgent cases effectively and ensure that emergency treatment is fully covered for free.
I think, it's only the Asian countries who have got cheap, easy, and effective healthcare where you can not only get appointments quickly but you can get treatment for cheap too but their emergency services are not always as streamlined as those in more developed systems. There is no clear overall winner. Some places excel in certain aspects. Others perform better in different areas.
> waiting times for appointments and procedures can vary widely
Waiting times for appointments and procedures can very widely in the US. Approvals to get needed treatments can also be denied for seemingly flimsy reasons in the US as well.
When I went to Canada, I talked to someone who said the Canadian government will subsidize trips to the US for certain treatments because it's not available at all in Canada or has insane waiting times. It's one data point, I know, but generally I think it's true that quality and availability of care in the US is much better.
This is only done for very specialized treatments where the province (they run the health care delivery) doesn’t have the treatment and/or the American resource is closer than a Canadian treatment location.
For example Nova Scotia will send some complex paediatric cases to Boston. They could send them to Toronto, but Boston is closer. Same with Manitoba but they use Minneapolis.
Canada is only 40m people and almost half that is in one province. The smaller provinces simply don’t have the population to justify having every possibly medical bell and whistle.
Point is when province sends Canadians for US treatment is isn’t actually about better quality as not all provinces have the same in house capacity and often the next largest city with such capacity is an American city.
Also, outside of the supremely wealthy Canadians, very few go to the US for private care. There is a medical tourism market to Mexico and other parts of Latin America for elective surgeries and uncovered treatments for some chronic conditions, though.
> extremely high quality health insurance in a western country
(Sigh...) Let's put some facts.
Infant mortality and under-five mortality rate (U5MR) are one of best simple indicators of the quality of healthcare. USA's mortality is x3 (!!!) of the countries on top. This puts USA around place 50 in the world, worse than Russia...
Health care could be more evenly distributed, of course, but the health care that OP is receiving is definitely very high quality. General statistics about the entire population cannot speak to that.
No. The original claim was "all the systems that subsidize health care for those less well off don't apply because you're wealthy. So you are bearing the full cost of extremely high quality health insurance in a western country.":
1. The quality is high.
2. The OP pays the full price.
1 is incorrect. The OP is paying a lot, but is getting the same subpar quality healthcare as everyone else. He differs with people without money in only one thing: the latter don't get the full access to the subpar health system. The system itself is the same and its general quality is well indicated by the core metric of the infant mortality.
The health system is subpar and there is absolutely no reason why such a system should cost that much.
DST is just a hack to make the time roughly correspond to when the sun rises, instead of when noon is. It solves the problem that people want their day to start when the sun is up, not before, and not after. The problems it creates are mostly for programmers who can't be bothered to write good software. Well I say tough cookies, you'll have to handle the edge cases so the rest of us have comfortable mornings.
> The problems it creates are mostly for programmers who can't be bothered to write good software
Myopic and ill informed.
> A 2017 study in the American Economic Journal: Applied Economics estimated that "the transition into DST caused over 30 deaths at a social cost of $275 million annually", primarily by increasing sleep deprivation.[128]
> An LSE study found that DST transition increases people's feeling of being rushed for time, and the number of hours spent on leisure decreases by roughly 10 minutes following the transition and more specifically the spring transition into DST decreases life satisfaction by around 1.44 per cent.
I think this summarizes it. The negative effects are concentrated around the transition. The positive effects are spread throughout the year. You lose 1.44% life satisfaction for a few days, and gain immeasurably more over the course of the year.
It's a pretty imperfect hack, since in many parts of the continental US the sun still rises at 5:00 AM even with DST, and you still get up in darkness in the winter. It was dark when I woke up today, for example.
I don’t give a crap about the day starting when the sun comes up. I just want to go home at 5PM in winter and it not be dark already. There are plenty of studies about how this increases depression in the winter. The fact we keep persisting with this perverse nonsense infuriates me.
I’d much rather go to work in the dark and have sunlight after work. The only people that it’s better for are children who would have to wait for the school bus outside in the dark, though in my experience growing up school started early enough that we were still waiting in the dark anyway.
919. The comparators available to us (the Epic Games Store, the Microsoft Store and
Steam’s lower headline rate) suggest that the competitive rate of commission
would be in the range of 12 to 20%. We do think it is reasonable to make some
adjustment to that range to accommodate the points made by Apple about its
premium brand, the quality of its offering and its established market position.
However, we do not think those would be sufficient to displace the upper end
of the range and are likely to operate mainly at the lower end, where the
offerings are arguably less attractive to users for those reasons.
920. Applying again an approach of “informed guesswork”, on the basis of the
evidence before us, we find that the likely range of Apple’s Commission for
iOS app distribution services in the counterfactual is between 15% and 20%.
For the purposes of quantifying the overcharge (for both the exclusionary abuses
and the excessive and unfair pricing abuse) we will use the mid-point of that
range, which is 17.5%.
Judgment can be grounded in reality or it can be picking a random subrange of a list of somewhat random ranges and then picking a midpoint because why not.
It cannot be grounded in reality precisely because it's a monopoly. The whole point of laws against monopolies is to let the market figure out the fair rate, or to define the "fair" rate as the one that emerges in a competitive market. So by definition of what the whole case is about it is impossible to give a fair rate in this case. If you don't want to be subjected to guesswork, stop being a monopoly and let the market figure it out.
Wow sounds very comparable yet notably omitted from the ranges the tribunal considered. Sounds like you agree with me that they just made it up? Or are you saying that it's fair to exclude the app store of an open platform which has plenty of "free market" competition from side loaded and 3p distribution apps because ~vibes~?
Not considered? The words "Google Play" are in the judgment 47 times. Maybe you could read it?
By your logic, each of the two companies could use the other as an example and then both get away with breaking competition law. Two wrongs don't make a right.
They have a literal section "(6) Description of the “comparator” platforms" where the very first item is "(a) Google and other Android platforms"
There's a section "112. On 10 June 2022, the CMA published the final report in its MEM Study, which contains a number of findings in relation to both Apple and Google."
It's amazing that you never even tried to read the actual document but already immediately assume a position that is trivially proven wrong.
> comparable yet notably omitted from the ranges the tribunal considered
Interesting to accuse people of not reading the document in a post where you don’t read a 3 sentence comment (and reply to the wrong one, but we can chalk that up to HN UI).
Imagine if you actually read and understood the document instead of pressing on with your ignorance.
The court considered Google Play. And explained how Google Play has the exact dame issues as AppStore. So whatever Google Play is doing is irrelevant to a case against Apple.
It's not a difficult document to read and understand. Just lengthy.
I would quote relevant sections, but that would be a completely wasted effort.
reply