4 ms·
Alex from kite here. Re privacy: we totally agree that it's a legit concern. when we started working on this we realized if we wanted to index tens of thousands
by alexflint 10y ago
Alex from kite here. Re privacy: we totally agree that it's a 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: www.kite.com/privacy. 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.
- rootlocus 10y agoHow about offering an on-site solution, where the client can deploy the Kite service on their own machines?
- alexflint 10y agoIt's something we've thought a lot about. For anybody interested in this, shoot us a message at onprem@kite.com
- bisby 10y agoI would agree with this. Every client doesn't need this running, but having it running locally would be nice. I imagine, a business with many programmers all using this would get pretty cluttered with constant updates to this, but an onsite installation could easily clean that up. Even if you have to ship individual backend modules (when more languages get supported). One place might only need the bash/python/js syntax whereas another might need only php, etc.
- bjt 10y agoAn on-site installation would also be able to refer to internal documentation, wikis, etc.
- falcolas 10y agoI did read the privacy document, which does not address the acquisition/shutdown aspect, which is fairly important; Oracle (for example) may not have the same views on the privacy of the acquired data as you do. Also, do you have plans to support deletion of indexed data?
- alexflint 10y agoYeah, this is something we should have put in the privacy doc. We're talking about it now. Definitely want to think properly on this stuff before posting something publicly (as with anything privacy-related) but we'll have an update.
- methehack 10y agoI think this is a great point. Does anyone know if it's possible to bulletproof against what an acquirer might want to do with the data? Is there a way, for instance, to shift the ownership away from the company gathering the data such that if ownerhship of the company changes, ownership of the data does not?
- nkw 10y agoLawyer here. Not my area of speciality but off the top of my head (and after thinking about it for all of 30 seconds) that strikes me as a surprisingly hard thing to do. Bankruptcy courts have extremely broad powers to administer the assets of debtors including disavowing contracts. There may be some way to do a structure where the data is escrowed with a 3rd party and the subject company is just holding the data as some sort of fiduciary, but I'm not sure anything like that has been tested. I would want to consult a bankruptcy expert to really figure something like this out.
- methehack 10y agoSuper helpful -- thanks for chiming in. I think its really interesting that this isn't worked out yet. It feels like there should be a way to say to a consumer "I'm just looking after your data -- you still own it, etc. Even if I go bankrupt or get bought, I can't change that and the acquiring company should consider that when valuing me." I mean, banks do it with money (and other assets). One bank buys another and there's no way for it say "Now your money is mine! Muwahaha". Feels like it's a whole missing regulatory / legal area to me.
- matchu 10y agoI like that you're planning to earn trust long-term, but, if customers are entrusting their proprietary codebase to you, some more concrete promises will be important, too. There's a difference between trusting someone not to redistribute your work versus having it in writing. Both are important.
- alexflint 10y agoAgreed.
- zuck9 10y agoEven though I trust you, there's no way anyone can guarantee that a hacker won't get into your database and get my proprietary source code. I'm no security expert but one way I can think of is creating an encryption system which works like this: all my source code will be stored encrypted on your (non-ephemeral) databases. The decryption key will be stored on my computer, and it'll be transferred to the server when I run Kite and destroyed as soon as I quit Kite. The key will be stored in your server only in an ephemeral storage (in-memory database etc.)
- andersen1488 10y agoExcept those keys could still easily be vulnerable to Heartbleed style overflow attacks. The only real answer here is hosting your own service behind your firewall the same way people do with Github.
- _vn5r 10y agoCan I get an invite now? mariodel [at] gmail
- markbnj 10y agoThe issue with actual source being uploaded is going to be a deal breaker with a _lot_ of corporations. People will use it for stuff that's already OSS, no problem, but not for the proprietary stuff they may get paid to work on. Is there any possibility of processing the code on the client side so that what you upload is not the source, but just the data structures necessary for the index, such that the code itself could not be reproduced from what you have stored on your servers?
- odbol_ 10y agoI agree. Why would they even need to upload/store the whole file? It seems like it's basing the suggestions on the line you're typing at that moment, so it doesn't seem that hard to just throw away the history immediately, and only deal with the 1-3 lines you're currently typing.
- greggman 10y agoIt indexes your code as well. All your project's libraries for example so it can give you suggestions relevant to your project.
- mikkom 10y agoCould you also answer the other part of the question: What is your revenue model?
- dsl 10y agoWe host GitHub, etc on site. Not because we don't trust them, but they don't have the resources we do to keep bad guys out.