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.

▲ bmandale 8 hours ago | parent | next [-]

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.

▲ WatchDog 7 hours ago | parent | next [-]

Any new term you come up with, will end up being misused by marketers.

▲ fastball 8 hours ago | parent | prev | next [-]

I have never seen "e2ee" abused this way personally.

▲

N-Krause 3 hours ago | parent | next [-]

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

▲

charcircuit 2 hours ago | parent | next [-]

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

	▲	swiftcoder an hour ago \| parent \| next [-]
		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...
	▲	zarzavat 31 minutes ago \| parent \| prev [-]
		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?

▲

pyuser583 an hour ago | parent | prev [-]

I saw a YouTube video claim similar levels of privacy are possible using trusted computing.

▲

ljlolel 6 hours ago | parent | prev | next [-]

Zoom also did this once

	▲	wkat4242 2 hours ago \| parent \| next [-]
		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.
	▲	internetter 6 hours ago \| parent \| prev \| next [-]
		They also paid me something around 100 dollars in settlement for this
	▲	bayindirh 3 hours ago \| parent \| prev [-]
		I believe they now have a proper e2ee mode which disables all the cloud powered features, no?

▲

hulitu 4 hours ago | parent | prev [-]

Whatsapp, Signal, Telegram, iCloud

	▲	baumschubser 2 hours ago \| parent \| next [-]
		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...
	▲	junon 2 hours ago \| parent \| prev [-]
		Please cite where Signal is not e2ee.

▲ g-b-r 7 hours ago | parent | prev | next [-]

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

▲ tacitusarc 8 hours ago | parent | prev [-]

“In transit encryption”

▲ boomboomsubban 8 hours ago | parent | next [-]

Creating a new term for the less secure definition doesn't work, as they'll just continue to call it E2EE encrypted.

▲ calebio 8 hours ago | parent | next [-]

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.

▲ kstrauser 8 hours ago | parent | next [-]

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.

▲ calebio 7 hours ago | parent [-]

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.

▲ Sophira 4 hours ago | parent | next [-]

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.

▲ g-b-r 6 hours ago | parent | prev [-]

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

▲ calebio 5 hours ago | parent [-]

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

▲ g-b-r 2 hours ago | parent [-]

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

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

	▲	calebio an hour ago \| parent [-]
		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.

▲ g-b-r an hour ago | parent | prev | next [-]

> 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

▲ lukeschlather 7 hours ago | parent | prev [-]

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.

▲

calebio 7 hours ago | parent [-]

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

	▲	lukeschlather 5 hours ago \| parent [-]
		> 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.

▲ SchemaLoad 7 hours ago | parent | prev [-]

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.

▲ kstrauser 8 hours ago | parent | prev [-]

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?”

▲ koolba 8 hours ago | parent | prev | next [-]

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

	▲	hulitu 4 hours ago \| parent [-]
		Every front end needs a rear end. So, yes.

▲ addaon 8 hours ago | parent | prev | next [-]

While they’re taking one “end” much less literally than usual, they are taking the other “end” much more literally…

▲ geoduck14 8 hours ago | parent | prev | next [-]

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.

▲ modeless 7 hours ago | parent | next [-]

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.

▲ 5 hours ago | parent | next [-]

[deleted]

▲ RHSeeger 7 hours ago | parent | prev [-]

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.

▲ modeless 7 hours ago | parent | next [-]

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.

▲

RHSeeger 6 hours ago | parent [-]

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?

▲

modeless 6 hours ago | parent [-]

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.

▲

RHSeeger 4 hours ago | parent [-]

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.

	▲	jstanley 2 hours ago \| parent [-]
		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.

▲ stephen_g 6 hours ago | parent | prev [-]

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!

▲ calebio an hour ago | parent [-]

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

     $ 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

▲ pyuser583 an hour ago | parent | prev | next [-]

It sounds like one term is being used for two very different things.

▲ kstrauser 8 hours ago | parent | prev | next [-]

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.

▲

lukeschlather 7 hours ago | parent [-]

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.

	▲	kstrauser 7 hours ago \| parent [-]
		That is an uncommon interpretation that’s far different than the usual meaning.

▲ hahn-kev 7 hours ago | parent | prev [-]

Doesn't that just mean HTTPS then?

▲ lmm 3 hours ago | parent | prev [-]

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