Really, they need a GitHub Enterprise like offering. A local Kite instance to run behind the enterprise firewall that allows control of updating (for those that view that as a hard requirement, as some should), that you can point your Kite client to. Kite still gets their rapid iteration and rollout, and enterprise clients don't get left out due to security. Not to mention Kite would probably make a small fortune on licensing.

That would be great. I can not use Kit for this exact reason.

I used to work as a contract developer for a consulting firm. I kept the project repo in my Dropbox. Everything got uploaded. This was obviously a security issue, but nobody asked, and I didn't tell. Dropbox saved my ass multiple times. The cost of accidentally losing uncommitted changes seems much greater than the probability weighted cost of somebody 1. hacking Dropbox, and 2. giving a shit about the client's project. I would do it again. #thuglife

#thingsYouMostlyOnlyHearFromAnonymousAccounts

#butThatMostPeopleDoAnyway

(?<!DoD)[citation needed]

I don't think that was your trade off to make.

This is great feedback, and definitely something we need to address.

Initially we've been focused on giving users control and transparency. We need to extend this to employers.

One quick idea that we'd love your feedback on: a .kiteignore file that can exclude Kite from responding to files that match a certain pattern (e.g. "secrets.py"). Presumably an employer could put a "[^.]*" in a repo-level .kiteignore file, and anyone working with that repo would have to explicitly delete that file to use Kite with it.

We'd love to hear any other ideas folks might have as well!

The only way to truly solve this problem is on-premise devices that do not push data to Kite, honestly.

I'd need to ignore every file I have.

Why does the device need to be on-premise? Would a Github Enterprise-like setup, where you have a dedicated Kite instance/VPS at their datacenter, work for you?

Contractual agreements, NDAs, etc. might make it impossible to disclose work product and/or source code to a 3rd party which would include Kite.

> If you're a contract developer, or a developer working full-time for a consulting firm, you might not have the authority to determine for yourself whether it's contractually allowable to upload code to Kite's servers. But if you're working for a pro shop, you can bet every dollar in your pocket that the contracts your firm has with its clients technically prohibit it.

As tptacek said, you might be prohibited and/or not have the authority to do so.

> Why does the device need to be on-premise? Would a Github Enterprise-like setup, where you have a dedicated Kite instance/VPS at their datacenter, work for you?

We run GitLab on-premise so I'm not familiar enough to answer. However, if by "their" you mean Kite? Yeah, that won't work as its essentially the same thing. [e.g. Disclosing it to a 3rd party outside of my control]

GitHub Enterprise allows you to run a dedicated instance on a virtual machine in your own datacenter, which lets you keeps all of your stuff behind your own firewall.

A .kiteignore file would be brilliant. I do a lot of contract work, but also a lot of opensource. My issue with Kite is I would forget to disable it for some projects. If I could have my default project scaffold contain a "*" .kiteignore file it would reduce this fear.

A major feedback was that folks need that thing and they need it on premise. On the recent update, you left out that folks should contact you at that other mail address, how so?

I can't use Kite if it's not on premise.

This is absolutely true. Beyond this, there's an additional concern that Kite simply hasn't been around long enough as a company for people who have the authority to allow it to be used within their teams.

If you're in the position to make a judgment call on whether or not Kite would be allowed in your team, there's a real cost to being wrong about the trustworthiness and security of Kite as a whole.

I'm intrigued by the tech, but it'll likely be quite a while before I use this with any of my teams for anything other than trivial coding in pet projects that are already open source/public repos.