Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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.


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


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.


No, there's no reason to go looking for conspiracies. Nor do I think their intent was malicious. I think they genuinely believed that this was beneficial. We should support them if they change their presentation from "we can't access your data" to "we're not evil, so if you trust that, then use us." We should let their actions speak for themselves.


Your tone in all of your comments on this post is inappropriate for HN. You have a new account so if you are indeed new here, I suggest you read other comments on the site to get a feel for the community.


See "Graph Analysis" section on the linked page, they make it pretty clear that there is info that is sent unencrypted but those parts aren't useful for reverse engineering. The data and source code itself sounds like it is encrypted though.


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




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: