171–180 of 227 posts
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".
There are numerous benefits. For one, it will make people aware where their data goes when they set up the device.
Let's think about why we're in a world where someone wants to sell you a camera to put in your toilet.
?? 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.
I was under the impression that large companies use proxies so they can do deep packet inspection.
PS: you are right of course.
This brings back memories of Adult Swim's "Smart Pipe" spoof infomercial.
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.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
> 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
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.
Earlier quoted context omitted.
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…
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)
Earlier quoted context omitted.
>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?
Earlier quoted context omitted.
>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...
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."