Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To me it is. The server you'd be talking to in my case is physically mine, in my home, so if I'm an endpoint and someone else is an endpoint, and they have an encrypted connection to the server, for all intents and purposes, it's end to end encrypted.

Of course, there's no way you can tell from the outside since it looks like an ordinary https connection to an ordinary server. Then again, I can think of more ways to implement end-to-end encryption over wiretapped channels without it being obvious that encrypted data is being exchanged (stego is quite easy to make but very hard to detect if you don't know the method). So the whole ban is pointless.

Terrorists and other criminals have an interest in arranging this, and it's quite easy, so they'll succeed. The general public will not care enough, and any widely used end-to-end solution will be banned anyway, so they'll just have to give up a little bit of privacy. No gains but at least the government is trying, right?



Sorry, but that's just wrong. End-to-end encryption has a specific definition that you can't distort just to play devil's advocate.


Can you elaborate? If I am communicating with a server over tls, how is that not e2e encryption?

The communication between both clients (my computer and the server) are encrypted locally such that mitm are not able to read our secure communication. The "end" of the connection is either the server or my laptop.


"End to end" refers specifically to the two people involved - that is, nobody but the sender and recipient of a communication can read it. Twitter DMs happen over TLS, but they're not end-to-end - Twitter knows the content of the messages.


There are two people involved. To quote myself:

> The server you'd be talking to in my case is physically mine, in my home, so if I'm an endpoint and someone else is an endpoint, and they have an encrypted connection to the server, for all intents and purposes, it's end to end encrypted.

There are two people who can read the communications: me and whoever I'm talking to.

But rather, my point was this:

> Terrorists and other criminals have an interest in arranging this, and it's quite easy

Setting up https is easy, and steganography is easy to do. Thus, a ban would be pointless because everyone who needs it for criminal activities, still can do it. It's everyone else that's put at a disadvantage.


Wikipedia just defines end to end as communication between nodes and it never specifically defines end to end as "person to person". [0]

Do you have another source?

[0] https://en.wikipedia.org/wiki/End-to-end_principle


> . . . application-specific features reside in the communicating end nodes of the network, rather than in intermediary nodes . . .

No one ever said it was people. We're talking about communication between two nodes that is simply facilitated by intermediary nodes. Your own source supports the argument, I think you should reread it.


Node 1 would be my laptop.

Node 2 would be the server.

Intermediary nodes would be the various routers, switches, and other networking devices that inspects the traffic between the two nodes.

so my own source supports my question. nodes do not need to be "humans"


Too bad that has nothing to do with the topic at hand, namely end-to-end communication between two individually-operated clients.


> Sorry, but that's just wrong.

Sorry, but you're just wrong. I am not playing the devil's advocate, nor am I changing the definition.


Were you unhappy with the fact that no one felt like arguing with your reply to SpaceManiac, so you're trying again?

The scenario you presented, client <-> server, has nothing to do with wisty's original statement,

"As I understand it, it means banning end to end communication between clients. So you can chat over https, but only if the server in the middle (which can be served warrants) is doing the encryption."

which is client <-> server <-> client, and is completely irrelevant. You are changing the definition to client <-> server. Think about it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: