Comment by zachlloyd | Hacker News Reader

Comment by zachlloyd | Hacker News Reader

Parent Full thread

Hi - as the poster and founder I again completely get the concern.

We should make it even more transparent what we collect. You can see it here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel...

Re: big business, we're still pretty small, but it's true that we are trying to build a business around the command-line. I get that's controversial and it's not something that exists and that the terminal is a super-sensitive low level tool.

We will never ever build a business around terminal data, and to be super explicit, we are 100% not collecting any command inputs or outputs.

The business that we want to build is around making a terminal (or a platform for text based apps) that grows because it makes individuals and teams a lot more productive on the command line.

I've there's one thing I've taken away from this ShowHN so far is that there is a lot of well-founded concern about the terminal and user data and that we need to do a better job on this issue.

Hey Zach, while I think your post is well-intentioned, the contemporary default level of trust around tech companies and data privacy is just very low. As a new entrant to the field, you inherit the default valuation—people have no other info to go off of.

Given that, it's probably the case that the only options are to either be fully open source or to make a fully offline mode an option.

In any case, I think the concept for your product is excellent—it's been mind-boggling to me that something along these lines wasn't tackled years ago, so I look forward to your guys' future success, hopefully moving the state of terminal interaction into the modern era.

> ...the contemporary default level of trust around tech companies and data privacy is just very low...

It's not just that the level of trust is very low. I shouldn't need to place any trust in the developers of my terminal at all. If I can't know for a fact that it's not acting against my interests, then I'll pass. I already have such a big selection of fully open-source terminals available. Why would I even consider taking any king of risk with this one?

I can’t speak for you, but generally people at least consider this tradeoff because of the additional utility of the third party tool. Ideally all these features would exist in the system terminal, but that hasn’t happened, and it possibly won’t ever.

As much as I can appreciate the community’s reaction to your approach of default collection of telemetry, I can also equally appreciate you and the rest of the team sucking it up and accepting the feedback. Thanks for that, and I’m personally interested to see where you’re able to take Warp. I think there’s something potentially pretty compelling here.

My advice here would be to simply make telemetry opt-in during the beta period. I’m typically pretty liberal about opting in to telemetry (particularly when the extent of which is documented), but obviously a lot of your users will not be. Your desire to accelerate your progress seems to conflate with the needs of your target demo, and I think this warrants adjustment.

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.

> If it can send to remote hosts, this can be abused.

A useful terminal cannot be prevented from contacting remote hosts.

You may be conflating programs running in a terminal and the terminal itself. We've managed to get this far without the latter.

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.

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

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

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.

And what I'm saying is that there's no way to set a terminal's permissions on the host system such that it can access the internet on behalf of the user but cannot access the internet on behalf of its creators.

This is a human problem, not a software one. Your terminal is as trustworthy as its creators. It cannot be locked down to prevent telemetry and still be a useful terminal. That was my original point and it is still true.

No one should use a for-profit terminal emulator, especially one created by a VC-backed startup, full stop.

Reply on news.ycombinator.com