I would love to use this, but I'm not willing to send my code to Kite.com. Sounds great for open source projects!

Sorry.

They need to offer a downloadable version of everything. I won't use it for this reason as well.

(Copied from above.) Totally legit concern. when we started working on this we realized if we wanted to index tens of thousands of libraries, we wouldn't be able to ship the entire index along with the client. Hence the cloud-based architecture. We've thought a lot about privacy and written up our thoughts here: kite.com/security. The short answer is: we don't index anything on your computer that you don't explicitly ask us to, and our plan is to earn trust the hard (i.e. only) way: transparency, published policies, and a track record of good decision making.

One of the big things we've worked on over the past few months is giving users fine grained control of which files are indexed by kite:

- Kite only indexes directories that you have explicitly enabled

- You can create a .kiteignore file (same semantics as .gitignore) to exclude specific files / patterns.

Would it be possible to allow a # nokite at the end of lines; these would then have any strings scrambled. This allows me to know immediately that things aren't being sent to Kite rather than have to do a few checks before I write something secret.

Actually, it should just remove strings if it does not already.

Good idea - will look into it.

Oh no, not tens of thousands of indexes! My 5 Mb hard-drive just couldn't handle it.

> when we started working on this we realized if we wanted to index tens of thousands of libraries, we wouldn't be able to ship the entire index along with the client.

Why not? that's a _tiny_ amount of data for a modern computer.

How many GBs would the database take on a local machine? Wouldn't it be possible to pick and choose what libraries to include in it?

I'd rather have a few gigabytes on my machine than have all the code I write automatically in the cloud.

I think this answer (which you used in few places here) does not address concerns people raised all over:

1) kite is useless (or at least substantially less useful) if you explicitly disable files/directories.

Example: Customer says: This fridge I bought, poisons my good. Company: If you don't put your food into fridge its not poisoned. Yeah, but it also not frozen afterwards, which was the reason for the fridge! And no files/directories/lines/whatever policy does solve that problem. Partially because of 2)

2) Human errors will kill this. Just google for number of problems around security tokens, sshkeys and other thing commited to github by mistake.

The only solution is LOCAL index only.

Why not just use .gitignore as a default (if local indexing is enabled)?

I can't speak to whether they still send up all code as it's typed, but I think, for now, they're addressing this concern by offering Kite Enterprise, https://kite.com/enterprise which allows you to run kite on your servers.

I think the answer to your question is :

"* Fine-grained privacy controls modeled after the .gitignore file format means that you can selectively and precisely decide which files and folders Kite indexes."

Unfortunately, that means that a really simple app where a developer hardcoded something like an API key, and didn't put it in a separate file they told Kite to ignore, will get uploaded.

Any system that relies on people following best practices is doomed in the real world :(

You mean like Git?

Git isn't generally configured to automatically upload your files as you type or as files are saved.

There are things like GitFS, but I imagine those aren't part of an average developer's workflow.

My point is that an inexperienced Git user can push their secrets to Github for example, just like a Kite user who doesn't specify a .kiteignore.

My point is that it's a lot easier to happen accidentally when the upload happens automatically and without intervention. With git, you directly specify what files you're committing (with the .gitignore as an additional safety net) and when that commit happens. It's all manual.

If I'm testing an app and I want to hard code an API key for testing, and I'm using Github, it's not a problem. I have to explicitly commit that file. Now, I have to both remember that Kite uploads everything, and avoid using that workflow at all, and use the .kiteignore thing (which is another random dotfile in my repo, great).

Again, I go back to your whole issue with how an inexperienced user of Kite can easily shoot themselves in the foot. The same applies to Git: 'git add .' and push.

Yes, you are correct in that an inexperienced Git user can mess up, I won't deny that. My issue here is that Kite requires you to proactively place a .kiteignore, before even whitelisting a directory. It also doesn't alert you that it's about to start indexing the files in the directory tree or that you need to add a .kiteignore to protect sensitive files before you whitelist them. At a minimum they should be respecting the existing .gitignore, and realistically they just be scrubbing all strings before sending any data.

I can 'git add .' and commit my life away, but that requires much more intention and explicitness than clicking enable on a prompt and continuing your standard workflow (ie: a simple 'vi super_seceret_file.py')

You can run your own git repository (it's really easy). And most of the Git-service providers offer an "enterprise" version where you can self-host.

What happens when someone inexperienced pushes their SSH private key to Github? Isn't that same as not specifying a .kiteignore file?

To do that, you have to commit and push. With kite, you might not even realize it uploaded something it shouldn't have.

We're talking about inexperienced users, so it sounds pretty much the same to me. Case in point: go search for API keys on GitHub.

That reads like "enabled by default, denied only on request"

Another post somewhere here from a kite Dev said that your code is only indexed of you explicitly allow it.

Does installing Kite and clicking "I agree" on a legalese dialog count as explicitly allowing it?