Hacker News Reader

Comment by alexflint | Hacker News Reader

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.

View on HN

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

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

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

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

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

What if Kite can't legally use the data for alternative purposes? I don't think disavowing a contract via a bankruptcy would let a company sell assets they don't own.

So Kite should be able to avoid this fear by asking only for limited license. For example, a license can expire after 1 year, or be untransferable (or perhaps expire at bankruptcy?).

Facebook does this to some extent: "This IP License ends when you delete your IP content or your account unless your content has been shared with others, and they have not deleted it."

Here's what Heroku does: "Heroku claims no ownership or control over any Content or Application. You retain copyright and any other rights you already hold in the Content and/or Application, and you are responsible for protecting those rights, as appropriate. By submitting, posting or displaying the Content on or through the Heroku Services you give Heroku a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Heroku to provide you with the Heroku Services. [...]"

(IANAL)

Disclaimer: I'm not a lawyer, but I did write my company's privacy policy with approval by lawyers.

A lot of companies' privacy policies have a section explicitly dealing with how data is transferred when company ownership changes. Sometimes this just says that all data will be transferred, but sometimes there are stipulations (for instance, my company doesn't sell or rent user data for marketing purposes, and its privacy policy requires that an acquiring company won't do that either).

Of course, there are edge cases (like what happens if the privacy policy changes) that complicate things, but the FTC has a pretty helpful discussion of all of this: https://www.ftc.gov/news-events/blogs/business-blog/2015/03/...

I raised this point with my lawyer recently. His view is that this is essentially impossible - any rules in the company articles can be rewritten or dropped at the whim of the acquirer.

Some technical solutions might be possible, in terms of allowing users provably to withdraw their data, but it would be messy and probably not bulletproof.

How about offering an on-site solution, where the client can deploy the Kite service on their own machines?

It's something we've thought a lot about. For anybody interested in this, shoot us a message at onprem@kite.com

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

An on-site installation would also be able to refer to internal documentation, wikis, etc.

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

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

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

Agreed.

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

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

It indexes your code as well. All your project's libraries for example so it can give you suggestions relevant to your project.

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

Could you also answer the other part of the question: What is your revenue model?

Can I get an invite now? mariodel [at] gmail

Reply on news.ycombinator.com