undefined | Better HN

0 pointsshpxnvz12y ago0 comments

Given the nature of JVM agents, this means that the Tikipi backend, should it choose, may access all the data in the production application. Correct?

ETA - Thanks, missed that page on the site.

0 comments

nivstein12y ago

The moment you sign-up for Takipi a secret AES-256 key is generated for you (and never stored by Takipi in any way or form, and you manually enter it on your machine when installing the agent). This key is used to encrypt every piece of application data which leaves the machine. The source code is also encrypted similarly. The source code and the data are only decrypted in your browser when viewing the details of the event.

You can read more about security at Takipi here: http://www.takipi.com/features.html?nav=security

sillysaurus12y ago

This makes no sense whatsoever. Their application is doing the encrypting. That means their application can do whatever it wants, including making it trivially easy to reverse the encryption.

I get that the intentions are good, but https would provide exactly the same trust guarantees, and ultimately it bothers me that they would try to mislead people into a false sense of security like this. If their application is encrypting data which is sent to their servers, then that means their severs have complete access to your data. (Whether they choose to make use of this power is up to them. They certainly have it, though.)

Encrypting the data prevents it from being leaked if their servers are hacked and their database stolen, which is good. But acting like they have no power to access your data is absurd.

jcheng12y ago

I think the distinction is meaningful. A rogue employee would not have the power to access your data (as we've seen at Google for example[1]) unless they were able to sneak some code into the application code (as, sadly, we've also seen at Google[2]). That seems like a significantly higher bar and also would require a great deal more premeditation. Not to mention the possibility you mentioned of them getting hacked (which would be a FAR bigger concern to me).

Now that I think about it, I never did move my stuff from Dropbox to SpiderOak, did I... hmmm, maybe today.

[1] http://www.theatlanticwire.com/technology/2010/09/rogue-goog... [2] http://tech.fortune.cnn.com/2010/06/06/google-blames-wi-spy-...

baboo12y ago

They are probably either lying or incompetent.

If they really had no access, then their server cannot do any "analysis" beyond storing it, and the app could as well just store it locally, or with Amazon S3 or whatever storage system the website already uses.

Obviously not everything is encrypted, or otherwise they don't realize that there is no reason for them to provide a simple storage service, considering most websites already have some way to store data.

Or maybe they want to hold the data hostage.

3 more replies

mseebach12y ago

For tons of applications this falls somewhere in the range "impossible" -> "totally unacceptable" -> "very worrisome, requires extensive debate before signoff"

j / k navigate · click thread line to collapse