Hacker News new | ask | show | jobs
by _tom_ 1535 days ago
If the code is there, it is potentially exploitable. So, opt out is nowhere near good enough. If it can send to remote hosts, this can be abused. This capability should not be there, at all.

Look at the recent logging fiasco for an example.
1 comments
smt88 1535 days ago
> If it can send to remote hosts, this can be abused.

A useful terminal cannot be prevented from contacting remote hosts.

link
iguana 1535 days ago
You may be conflating programs running in a terminal and the terminal itself. We've managed to get this far without the latter.
link
smt88 1535 days ago
I am not conflating the two. If the terminal can run programs connected to the internet, then the terminal has internet connectivity. The host system would not be able to tell the difference.

Warp could certainly promise not to include any phone-home functionality in their code, but unless it's open-source and everything is audited, it could easily call the host system's HTTP client and still phone home.

link
warent 1535 days ago
> If the terminal can run programs connected to the internet, then the terminal has internet connectivity.

Is this true? This sounds wrong to me but I don't know the inner workings of terminals. The terminal just executes programs and handles pipes it seems. A terminal can be completely walled from the internet, and when you execute something from it, say, curl, then curl has it's own memory space and access layer outside the terminal, and just has it's stdio wired to the terminal.

link
smt88 1535 days ago
> The terminal just executes programs and handles pipes it seems. A terminal can be completely walled from the internet, and when you execute something from it, say, curl, then curl has it's own memory space and access layer outside the terminal, and just has it's stdio wired to the terminal.

As I said in my comment, even if you "wall" the terminal off from the internet, if it can make system calls on behalf of the user, it can still access the internet.

If a terminal has sufficient access to the host system to call `curl https://www.google.com` on behalf of the user, then it can call it without any user input.

There is nothing on the host machine that can authenticate system calls coming from the terminal application as "user-initiated" or not. This is similar to the warning that "you can't trust the client"[1].

1. https://security.stackexchange.com/questions/105389/dont-tru...

link
w1nk 1535 days ago
You're technically correct here due to some sloppy words, but this isn't the point that everyone here is trying to make. We know our terminals can connect to the internet, we don't want them to do that without being instructed to. If our terminals randomly curl'd websites (as opposed to delivering telemetry to a 3rd party), I'm sure the discussion would be similarly displeased.
link