By the way, to address the problem of guessing your friends' identity: I know this is a critical point in the system and thus I added something to prevent that guessing, of course. However, it's a dirty fix, as it may introduce new issues (but of course that may be improved soon): When address books are synced with the friend lists in the app, those "friend" connections are always reciprocal. So even if you have only one single person in your address book, and you're seeing posts from friends in the app, you don't know if that's the person in your address book or any of your friends who has started using the app as well. Someone that you don't want to hear from may add your phone number to their contacts, but you may block any user inside of the app and this blocking is persistent.
Thanks! I hope this open-source project can help so that we all benefit from such openness. And I'm convinced that such software should not be closed-source and in the need for a business model.
Exactly. Sorry, should have mentioned that. I wasn't really sure how to handle this. The problem is that (a) the app is optimized for phones and (b) it has to ask the user to enter their phone number manually if the device has no telephony features and (c) it can run on a single device only. I wanted to prevent users from the confusion that arises when they have the app on their phone already, install it on their tablet as well and then see that it stops working on the phone.
You can find some more projects on GitHub [1] as well. But the only web apps are "Localize" [2] for translating Android applications and "Ballmanager" [3] which is an online soccer managing game.
Thank you :) First and foremost, this has indeed been a tinkering project. But now, I think there may be enough potential to put this to a good use. Did you think of anything specific when you referred to "practical use"? Actually, the app is live on Google Play and this may already provide some practical help to users.
Curious if this takes the same pains with anonymity as Secret itself, where identities and post associations are, supposedly, opaque even to individual founders - it takes at least two to reveal the identity behind a post, and only reveals it for a single post.
Didn't we learned it the hard way we can't trust anyone's claims about their services, unless it's really verifiable?
There are loads of services who claim one thing, but that's either completely untrue or somehow true but filled with "if"s and "but"s.
Say, Dropbox had claimed they do encrypt everything in a manner they don't have any way to access to user data, but it occurred they had just lied.
Or, Secret claims they don't send phone numbers and email addresses and says nothing about names but from reverse engineering their app I found out they do for whatever reason send contact names - which, for many Google/Gmail contacts, are the same as email address - and if you use "invite" function they do send unmangled number/address (the latter's reasonable, but still it's an exception from the claim and users aren't really warned about it).
Exactly, this is why I hope this app can prove beneficial and I hope that any weaknesses are found by people checking the code. And, of course, the possible risk factors "lies" and "hidden practices" are off the table for this app. Not to forget: Services that are valued at $100M need to find a proper business model. True anonymity/pseudonymity prevents you from pursuing ideas for potential business models in many cases.
I've made this open-source so that anybody can check for security weaknesses and report/fix them. And, of course, nobody has to use the app that is already live on Google Play, but you are free to host your own version.
thanks for putting this out here, I will use this as a resource for a project I was planning on getting started on. I am excited to play around with it.
Do you have any screenshots of the android application you could put on the github or an imgur link. Thanks!
Thanks! On the GitHub page, there is a link to the app in Google Play [1] and this is where the screenshots can be found. I'm quite sure the app is not really beautiful (yet), so it was an intentional decision not to put up screenshots on the GitHub page which would impair the first impression ;)
great one more question, on my rough inspection it looks like the encrypted text and the key is stored in the same database entry. pardon my lack of knowledge, but this seems insecure.
There is a server secret that is not stored in the database at all and there is a message secret (unique per message) that is stored in each message's database entry. They are combined to the actual key for decryption.
No, why do you think so? :) Twilio is actually only a very small part of what makes the app work. It's used for the verification via SMS only, i.e. usually once per usage on a device.
These kinds of startups really aren't tech startups. They're media startups. It's not about their technology. When Facebook bought WhatsApp they were not buying technology.
That being said-- trying to replicate such thing is not a bad programming exercise.
I agree that the technology part is not the hardest and a large part of the success or failure is marketing and media issues. But lots of startups have a lot of CRUD and I wouldn't call every technology product that isn't really pioneering a simple media product.
They do - but Facebook didn't buy Whatsapp for the technology. They bought them for the users. If the technology was absolutely horrible, but they still had the same users, etc, it still would have been $19B
I didn't say it was bad, just that it wasn't the primary asset that was acquired. Facebook could easily have built a massively cross platform mobile chat app in-house.
... and it wasn't the best, either... look up their single hard-coded AES key for example.
Of course, you can "securely encrypt" things, and it doesn't matter if this is a phone number. But you're probably referring to the fact that the phone number is used as an identifier and is thus hashed and not encrypted. Nevertheless, it makes sense to call it "encryption" when describing the app to non-tech people and give the technical terms (i.e. hashing) in brackets etc.
I am not an expert but it seems to me that hashing of phone numbers is relatively useless here because there is a relatively small search space of potential phone numbers so I can just brute force check, right?
Well, the search space is certainly small and thus brute force becomes much easier. But I wouldn't really call this "useless". You can, of course, apply your hashing repeatedly too make brute force slower.
The title makes a dubious connection between their valuation and their technology. I guess that Secret investors are not interested in the technology but rather the network of users.
I guess it just points out that technology != valuation. However, it also highlights that what Secret is doing isn't terribly special (nor Twitter, etc) and that they have a pretty reasonable chance of someone swooping in and taking over their market (happened with MySpace for example) at some point if the community becomes bored.
Sorry for that! I just wanted to show the connection to a quite recent event, and I actually thought that anybody who knows about Secret already knew that their value is not 100% in their technology.
Why PHP? I would argue that in this day and age, that is a bad decision. There are simply better, lighter weight languages to use that will get you going faster and cause less problems down the road. Maybe not you personally if you're a PHP wizard, but certainly the industry in average. I'd recommend you skate to where the puck is going. :)
PHP isn't inherently a bad decision. The ecosystem is full of good examples of what not to do, but that's not a failing of the language itself. It can be done right.
Yes, there are design warts. There are also RFCs to iron them out. (I opened one recently to deprecate MCRYPT_RAND so people can stop generating weak random IVs in their crypto libraries one day).
Personally, I spend a lot of my free time opening issues and submitting pull requests to PHP projects on github to increase the likelihood of a budding developer being exposed to better code.
I don't think this is a bad decision, but I'm sure that it's not the optimal solution, either. I chose PHP just for the sake of rapid prototyping. I actually planned to rewrite the complete server-side code in Node.js or Go, but haven't managed to do so yet.
If you downvoted, feel free to share your opinion on why this is wrong. I could care less about the votes, I want to hear your discussion! Why would you use PHP?
Here's an excerpt from a Facebook engineer explaining why we still use PHP: "The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style - the worst attributes of the language are avoided and coding style is rigidly enforced through a fairly tight culture of code review"
You answered the question yourself. If someone is a wizard in PHP, then they should use PHP. People that get caught up in the decision of what language to use don't ship code. Shipped code > language decision circle jerks.
I'm not a habitual PHP user, and I have perturbed many electrons on why I wouldn't use it for nontrivial projects, but I could slam out something for which I don't care about security or performance in a very short period of time.
Rails, Play, etc. have some friction; Sinatra makes you reinvent a lot of wheels. You really can just fart something out in PHP very rapidly.
I downvoted because you make grandiose claims without any real, non-FUD sources beyond you work at Facebook. You just say there are "BETTER THINGS!!!" without listing at least one and why.
1) From a productivity standpoint PHP is pretty hard to beat in general....if you already know PHP.
2) A poor craftsman blames the tool.
3) PHP's inertia extends to the entire ecosystem really, not just the tool.
You mean that the backend should have been based on parse.com and not be written in PHP? Well, there are several reasons I didn't do this: (a) I wasn't familiar with parse.com (b) PHP code is independent from a single commercial provider (c) you can easily host the PHP code on Heroku etc. (d) I wasn't really sure if parse.com was appropriate for more complex tasks, encryption, etc.
