5 ms·

Just to clarify, the text you type into the terminal NEVER leaves your device. Fig does not store or collect this information. We send an event when you insert

Just to clarify, the text you type into the terminal NEVER leaves your device. Fig does not store or collect this information. We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app. We also send which completion spec (eg. git, npm or cd) was used to generate the suggestions to know which commands to prioritize.

sidlls 5y ago
A distinction without difference, in my opinion. And it doesn't change the fact that anything other than 0% telemetry without full, complete disclosure and permission from the user is not good.
smoldesu 5y ago
So wait a second, the text I type into the terminal never leaves my device, but the commands I invoke do? What's the difference?
- rabidrat 5y ago
  Yeah just don't accidentally paste your password into a terminal and press Enter.
  - sidlls 5y ago
    I don't know if that's a fair reading of the functionality. It seems likely your mistakenly pasted password will generate an autocomplete and the (mis-)matched "spec" command will be sent as the telemetry, e.g., pasting "gi)#(RCS23!_)(U" into your terminal might result in "git" telemetry, not the password itself. It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.
mbreese 5y ago
>We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal. If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea. And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.
- smoldesu 5y ago
  +1 for this. I don't wanna be rude, but dataops isn't a joke: I'm not going to put my security into the hands of someone who already made egregious security oversights an integral part of their product.
ljm 5y ago
> generate the suggestions to know which commands to prioritize What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration. Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline. What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?

sidlls 5y ago

A distinction without difference, in my opinion. And it doesn't change the fact that anything other than 0% telemetry without full, complete disclosure and permission from the user is not good.

smoldesu 5y ago

So wait a second, the text I type into the terminal never leaves my device, but the commands I invoke do? What's the difference?

rabidrat 5y ago
Yeah just don't accidentally paste your password into a terminal and press Enter.
- sidlls 5y ago
  I don't know if that's a fair reading of the functionality. It seems likely your mistakenly pasted password will generate an autocomplete and the (mis-)matched "spec" command will be sent as the telemetry, e.g., pasting "gi)#(RCS23!_)(U" into your terminal might result in "git" telemetry, not the password itself. It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.

mbreese 5y ago

>We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal. If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea. And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.

smoldesu 5y ago
+1 for this. I don't wanna be rude, but dataops isn't a joke: I'm not going to put my security into the hands of someone who already made egregious security oversights an integral part of their product.

ljm 5y ago

> generate the suggestions to know which commands to prioritize What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration. Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline. What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?