Telemetry is now optional in Warp
Zach Lloyd
Today we are announcing that telemetry (app analytics & crash reporting) is now optional in Warp. In addition, we are launching a “network logging” Workflow in Warp that allows users to see exactly what data we are sending to our server.
Our aim with the network logging workflow is to make it completely transparent what data Warp sends to the cloud, as well as to give Warp users more control of what is reported. As has always been the case, no terminal input or output is ever sent to Warp’s servers unless a user explicitly uses a cloud-oriented feature that requires us to store and serve the data, such as Block Sharing.
Controlling app analytics and crash reporting
If you are a new Warp user, you can now elect not to have analytics sent before logging into the app during the signup process.
Screenshot of Warp's sign up screen.
And if you are an existing Warp user, you can navigate to the Privacy section of our settings and turn analytics and crash reporting off.
Screenshot of the privacy panel in Warp.
Viewing network requests via the Network Logging Workflow
As part of this launch, we are also launching a live network log (documentation here), which allows users to see exactly what info we are sending to the server. You can view this log by running the Network Log workflow from within Warp, simply by typing CTRL-R and searching for “tail warp network log” (or by searching within the command palette using cmd-P):
How to access Warp's network log
The network log shows a live view of all server requests and their responses. For example:
This is simply a screenshot of the network log. To see the full output, check out this shared block.
Why make this change now?
When we first launched Warp in private beta, our goal was simple: figure out if we were on the right track in our approach to reinventing the terminal to make it a more productive tool for individuals and teams. So far the reaction has been overwhelmingly positive and we now have tens of thousands of developers using Warp as their daily driver in our public beta.
As part of the initial launch, we wanted to understand if the features we were building were useful. We approached this in a number of ways - talking to users, observing them use the product, getting feedback in our Discord and on Github. We also looked at telemetry data in aggregate to see if features like Blocks, Workflows, and natural language command search were being used.
We now have enough signal to relax the requirements to just use a sampling of data. As a user, you may now choose to opt-out. If your workplace doesn’t allow telemetry, you can turn it off. But if you are someone that is thinking about continuing to share crash/event data, I want to reassure you that that data sent does not contain any terminal session content (inputs or outputs) and is only used to make the product better. We hope you’ll take a look at our new network log so you can review all data that is sent and you can read more about our overall approach to privacy here.
Why opt-out and not opt-in?
We want to continue to see as much crash and telemetry data as we can while still allowing anyone who can’t or won’t use Warp because of telemetry to turn it off. Having telemetry collection on by default is most likely to get us the most signal while still respecting those users’ wishes.
It’s a similar model to VSCode and done for similar reasons.
From the VSCode documentation:
“Visual Studio Code collects telemetry data, which is used to help understand how to improve the product. For example, this usage data helps to debug issues, such as slow start-up times, and to prioritize new features. While we appreciate the insights this data provides, we also know that not everyone wants to send usage data and you can disable telemetry as described in disable telemetry reporting. You can also read our privacy statement to learn more.”
Warp’s approach is basically identical – we would love telemetry so that we can improve the product but understand that not everyone wants to send this data, and have therefore made it optional. We have also taken the additional step of making all server requests entirely transparent, in the hope that transparency will build trust.
What about login?
At this time, Warp continues to require login. The primary reason is that login allows us to build cloud-oriented features that make the terminal have a concept of “your stuff” and “your team’s stuff” – for example Block Sharing. This is the same reason other collaborative apps like Figma and Github require login – identity is the basis of building cloud-native apps.
That said, we understand the desire to try Warp before logging in, and are exploring product experiences that will allow users to preview Warp before signup.
Thank you all for the continued support!
