[zachlloyd]

As the author of the post, I think this is totally reasonable feedback and something we have discussed quite a bit on the team.

The general stance on telemetry that we have is that a) we are just starting and it's really helpful to see which of our product ideas are useful to our users (e.g. does anyone use AI Command Search? Should we continue to invest in it) b) we tried to be very explicit about what we are and are not sending - it is only metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... c) if you aren't comfortable with telemetry, then please don't use the product just yet - we will make telemetry opt-in when we have a large enough sample size that we can be confident extrapolating what's going on

For googleapis - this is for login. We use firebase as our auth provider.

For segment - this is for temeletry, as you point out.

For sentry - this is for crash reporting.

As for why we have accounts, it's because we are starting to add features for teams and it's important in that context that there is some type of identity associated with the user.

But like I said at the start - the feedback is totally reasonable and we are trying to figure out how to balance concerns here while still being in a good place to iterate on and improve the product.

[btown]

As a Sentry user (for a web app where people are not placing sensitive IP!) - it is INCREDIBLY easy for it to be configured to suck up massive amounts of PII and sensitive IP in the context of its crash reports. If I am running `kubectl create secret --from-literal` and something crashes, can you guarantee that the contents of that command will not be loaded into Sentry? Breaching this guarantee would be as simple as having some code somewhere in your stack (including a parsing library) format an Error with the command contents, miles away from anything Sentry-specific.

I'd be much more trustful of your product (and indeed, I do desperately need a better terminal!) if you were to:

- make Sentry crash reporting opt-in (or at the very least have a popup that occurs with the content of what will be sent to Sentry before anything is sent to Sentry), AND

- clarify in your event telemetry documentation, and explicitly in your Privacy Policy, that ONLY the event ID/name, timing, and the user ID are sent to Segment, nothing else.

But I simply cannot use a terminal where my keystrokes might be logged to anyone's Sentry or Segment account - even if it were our company's own Sentry account. The risk of partner-entrusted credential leakage into an insecure environment is simply too high.

[stouset]

> - make Sentry crash reporting opt-in (or at the very least have a popup that occurs with the content of what will be sent to Sentry before anything is sent to Sentry), AND

100% this. I don't entirely understand why Warp needs to connect to Sentry right at application launch. If it crashes, capture that crash and present me an opportunity to report it or not. If I do agree to report it, first present me the complete text of everything that will be reported.

I understand that this puts some hurdles in the way of getting crash reports. But terminals frequently contain information far too sensitive to trust with these things being automated.

[Terretta]

Is this answer minimizing a bit?

You can use the Firebase login tools without the person identification stuff pulled in. Note that for companies failing to do this in a privacy respecting way, a savvy user can usually get granular at the firewall and get the login to work without the audience reporting. Which means you could…

Similarly, in my book, segment.io isn’t just “telemetry” so much as it’s killer feature of cross app audience persona correlation, so less about what’s up with the app, more trying to learn more about the users without asking them. If you were instrumenting the app UX and not trying to see who is using you, there are other choices.

A number of ways to do accounts that can leverage a person’s own IdP or other approaches where you don’t have to have accounts, e.g. most any channel the team or group can access will do to get in sync on a session start.

Regardless, and even if GitHub and e.g GitHub Orgs are your way, all of them should be optional since not everyone is desperate to team their cli.

Last, and sorry to put it like this, if you’ve “discussed it quite a bit” as a team, I’m not sure but maybe that gives me less confidence in your respect for security, privacy, and users.

I’d imagine that deliberate discussion backed by respect for your users and team know-how should have resulted in a different set of choices.

[gitgud]

Is login and authentication really necessary? No internet -> no terminal?

Even VScode a massive Microsoft project does not require signup/authentication to use it...

Love the design, but seems like a very enterprise-driven and niche product for a lot of developers