Hacker News new | ask | show | jobs
by alokedesai 1533 days ago
I definitely understand the concerns. For our public beta, we do send telemetry and associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... Once we hit general availability, our plan is to make telemetry completely opt-in and anonymous.
8 comments

Wow, this is just unbelievable. You don't say anywhere on your privacy page that you are associating this data with specific users.

Everything your company says regarding privacy seems to be a complete lie. You contradict yourselves everywhere. As a security officer I would never allow any company whose security I run to use your product- even if you fix this issues now who knows if you're going to lie again in the future.

Trust is hard to regain once lost, and your company definitely blew it here.

Maybe don't put this lie in the middle of the homepage?

> Private & Secure

> All cloud features are opt-in. Data is encrypted at rest.

Encryption at rest is fun until the keys are leaked.
Or prefix it with a "Final product will be ..."
This looks very interesting to me, but some of this telemetry is a deal breaker. On your privacy page, it says "Our general philosophy is complete transparency and control of any data leaving your machine." If I have complete control of any data leaving my machine, can I opt to turn off the telemetry entirely?
of course not. how else will they be able to make you the product without their trojan rabbit sending back all kinds of telemetry goodness.
> we only track metadata, never console output

It would be meaningful to indicate whether you track console input as well.

That's an important callout! By console output, we really mean output from the pseudoterminal, which includes command input and output printed to the terminal.

We don't store any content of _any_ part of a command that's executed in Warp.

... and never will?
Why even ask?

Founders don't really have much control over what the tools they create wind up being used for.

Assume that some people will use any tool you encounter for the worst thing it can possibly do.

If the tool has significant potential to do things that bother you, don't use it.

Why do you say "wind up being used for" as if it is act of god rather than a business decision?
Because I'm talking about founders and how much control they have over the tools they bring into being.

Acts of God are a better model for that than business decisions.

Some users will abuse the snot out of it, and a small start up may not even realize that's happening for months.

The founder may not retain the authority to control decisions about what changes to make to the tools or how to monetize them.

Hackers may break into the servers and use the tool for their own ends.

And, yes, often enough the founder themselves will throw the users under the bus when push comes to shove.

From their link, it seems they don’t. Agree that positive confirmation would be good, for beta.

> We do not store any data from the command input or output itself as part of our telemetry.

This is correct. We do not send or store any terminal contents (input or outputs) to our server.

The only case in which that is not true is if a user elects to use Warp to share the output of a command using our Block Sharing feature.

With the rest of your responses I'm left looking for weasel words in here.
You should do that now and just ask on startup.

Honestly opting in by default is, at least in my opinion, not acceptable.

People who would say no to that popup would not appreciate you randomly reaching out to them anyway.

That's a ton of data being collected. I would rather much have this submitted during a crash, rather than opt-in/opt-out. I'd not want to use a terminal that has data collection that crosses the internet every time I use it.
Totally understand if you don't feel comfortable using it!

The reason we don't submit this only during a crash, is because there are a lot of other things we want to know about users like: Which features are they using? Are they sticking to warp as their daily driver? How much time do they spend in the app?

We do want to make the telemetry opt-in after Warp is out of beta.

There are better ways to gather feedback, even if your application is in beta. Most loyal customers will let you know what’s wrong and what features they’re most excited about- that honest feedback is far superior than telemetry data. You can even add a survey form after the application exits to try and maximize the feedback loop.

Totally understand you’re a new venture backed business, however, you most likely are targeting the wrong group of users by automatically sending data over the internet for “no reason”.

> Most loyal customers will let you know what’s wrong and what features they’re most excited about- that honest feedback is far superior than telemetry data

That's just wrong. Very few users, regardless of loyalty, would bother sending feedback. That's why many companies have drives with gift cards or whatever as reward for participating in giving feedback. And even then, you'd get a limited subset of users ( loyal, loud, with time available to waste) instead of everyone like with telemetry.

How are you checking if they stick to warp as daily driver? Are you checking for other shells open?
We are seeing if people are using Warp regularly.

We don’t know about any shells outside of Warp so technically, they could also using other terminals - but that’s enough info for our product development.

We never track the contents of commands. A full telemetry table is included in our user docs.

I definitely will not try it if the analytics part are not optional, though I am glad to see you're documenting exactly what gets sent. I might consider trying it and even opt-in to the analytics once you make it optional.
At least for EU users, you cannot collect information like this without the explicit consent of those users.

It's 2022 FFS, and still companies are over-stepping the mark - companies behaving like yours are exactly the reason GDPR and ePrivacy etc exist in the first place :/