Live data from Hacker News

Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

varlogsimon.leaflet.pub

161–170 of 227 posts

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#163

Earlier quoted context omitted.

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

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#164
post #152

Earlier quoted context omitted.

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 Des…

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 ex…

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.

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#165
post #87

Earlier quoted context omitted.

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

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

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

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#166
post #87

Earlier quoted context omitted.

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

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

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

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#167

Earlier quoted context omitted.

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.

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

     $ 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

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

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

Re: Kohler Can Access Pictures from "End-to-End Encrypted" Toilet Camera

#170

Earlier quoted context omitted.

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.

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?
Post reply on HN