jokull

Hi Hacker News. I’m one of the developers at QuizUp. We’re very proud of the product, but obviously we missed the mark when it comes to privacy and user data. On a cultural level we take these things to heart, and we take them seriously. It’s a matter of not having taken the time to review these things carefully enough.

Let me address the things mentioned in the article:

No data is ever sent or received to or from our servers in plain text. Due to a bug in our third-party network library the certificates were not being verified so a self signed certificate could decrypt the data. This issue has been addressed in an update waiting review at Apple. Users' passwords are hashed before we store them in our databases (pbkdf2, salt, multiple iterations).

Our user's address books are not stored on our servers and only used temporarily to help us find your friends. It was a mistake to not hash the contents of the address book before sending to our servers and we are currently changing the client application so it hashes the address book contents before sending to our servers.

Sensitive user data was exposed in certain endpoints (although only accessible for authenticated users). We have already addressed this issue in a server deployment and the hotfix is live now.

We are currently wading through inboxes looking for Kyle’s outreach. It looks like it may not have reached the core server developers. Please contact me personally at jokull@plainvanilla.is if you have questions.

Finally I want to thank Kyle Richter for working out our security holes, small and large. We’re currently reviewing our endpoints and codebase to further harden security and ensure the privacy of our users.

ELB, CloudFront, SQS, SES ... it’s nice to have those things at your disposal even though alternatives exist. Consolidated billing, fewer accounts to log into (admin overhead) etc.

The truth about these tools is that they appease to our OCD side. There is a honeymoon period during the which you find various reasons to use the tool. After a while you realize tools only help with organization during that first burst of excitement. At this point you either have to confront the fact that getting organized isn’t a technical problem or you find a new tool to get excited about.

What makes these tools succeed at least for the short term, is they fuck with the organizational habits of people. Their landing pages are huge cues to get more organized, which people love. People love the idea of getting their shit together and becoming organized once and for all.

The challenge these apps are facing is creating a habit loop. You need a cue and a reward, but more specifically when replacing a habit (email) with something new, you need to replace either the cue or the reward. In between those you have your tool. Without this change people just go back to their old habits. In the case of Inc the reward is "thanks for sharing that link, you’re awesome!" and the cue is "I need to send this to my whole team". Currently everybody immediately reaches an internal mailing list or enters in a few autocompleted emails when they encounter this cue, the urge to share with team members.

Now what Kippt, their original product did, which was clever, was creating new cues. They heavily pushed their Chrome extensions which inserted "Kippt" buttons and links to loads of websites with potentially interesting links. There’s even one for all hacker news links. This created new cues for people to respond to.

For Inc to succeed it needs to cleverly introduce more cues because email works fine for this particulare habit loop and will be hard to replace.

Add Michael Lewis to the list

Fair point.

It’s markdown so migrating is easy.

This would be cool as an extension of the Mixpanel API. So instead of just tracking users you’d have all these features as well. I’ll agree with the criticism of this being a point of failure too big for mission critical systems, but if it gets proof of concepts off the ground sooner, who knows? Could be a great way to save time. I would suggest thinking carefully how you would eventually grow out of each component. That’d be my main concern. I want to be able to switch out components one at a time.

The lazier it allows me to be the better. Bootstrap is a good bet because you can Google really stupid things and it comes up with trivial code snippets and examples.

Seems like Docker will be the way to go soon. I’m most excited about parallelizing tests and shipping docker diffs from development, to testing, to staging, to production. I’m sure we’ll see startups tackle this level of integration with a suite of tools.

Why wouldn’t you just allow any length but only hash the first 4096 bytes?

or http://calepin.co

DNS on its own can be enough in some scenarios

The premise, the logic stands on its own. We coevolve with other organisms and bacteria, not in a vacuum. So wether there is hard evidence for this or that, regardless it’s an interesting field of study right now and many are looking into it. Sometimes before you have evidence, you need a hypothesis.

For those interested in recent research focusing on the interplay between bacteria and our immune systems, I recommend An Epidemic of Absence by Moises Velasquez-Manoff.

Podcast introduction from Chris Kresser: http://chriskresser.com/what-are-the-hidden-costs-of-modern-...

Amazon link: http://www.amazon.com/dp/1439199388?tag=chrikres-20&link_cod...

Very cool! Limited to US only though. Check out behindthename.com/api/ if you need country distribution. Had to map country codes to groups of names. Let me know if you need this data. I’ve got some scripts to generate random users, although not address or picture data.

We reviewed the current options at one point (Zookeper, Doozer and something from Netflix) but ended up just using DNS (Route 53) for our config. This however looks great, and supports nested keys (trees) whereas DNS comes up short in that, and other aspects.

What makes me excited about Docker’s diff-based filesystem stack is that it potentially allows a build of code to go through a CI chain untouched, all the way into production really quickly. I’m not a virtual machine expert, but I believe this is slower in traditional virtualization like Vagrant for example. Am I far off? At work we’re using layered AMI build tools to roll new services and app builds into production, and the process is not quick.

This project has roots at least some years back, so it’s not starting from scratch with lofty ideas that are unlikely to come to fruition. Solid team with a great ideology!

For the record, we have a very similar production environment and we bake on every deploy. We have some tricks to make it as fast as possible though. A deployment takes 2-3 minutes with code changes and more with requirements changes. We then place it in the ELB server pool and pull out old machines if everything behaves correctly. Looking into autoscaling now.

Good points. Not 100% sold on scaling being a problem. The master-apprentice relationship scales for a lot of industries and has for hundreds of years. Also, I didn’t get the perception from this article that they’re trying to replace university education altogether. This could be a great way to get into startups, advertising and some other industries universities haven’t managed to create coherent lines of study for. [My background: dropped out of university, worked for digital agencies, now at a startup creating a mobile game platform]

Are you kidding me? Ending up with the kid after a divorce takes opportunities away too. It’s what is expected of most women and in my mind contributes to inequality tipping job opportunities and hirability in the favor of men.

Hi Simon - I greatly appreciate your work and opinion! The reason I think HTML forms libraries are insufficient for the problem domain: JSON is richer, both in datatypes and structure. We’re working on a forms library of sorts that is better suited for API serialization/validation and having one central place to define models for multiple internal DB’s.

https://github.com/plain-vanilla-games/schematics

Flask’s documentation is great, and the codebase is readable and small. The third party community is not as big as Django’s, but the 3rd party work is verified and approved by Armin (Flask and Jinja2 author). These guidelines encourage authors to publish higher quality code and better documentation. You couldn’t verify my claims, but this is my experience coming from Django a couple of years back. Django’s extensions are often very poor quality.

I’d also like to point out that Flask-Admin has come a long way with adapters for SQLAlchemy and at least one other ORM library. Very usable and extendible.

Django middlewares is a poorly designed system. Flask has all of the things you mentioned except for forms. For that you can use Flask-WTF, but these libraries are becoming outdated anyway because they’re HTML based and don’t work so well for JSON validation.

Exactly. I’m afried App.net will die soon if they can’t figure out how to appeal to anyone trying to build a business (not hobbyists making free apps, because charging your users to create an account has be a negligible part of your value proposition). The only way to fix this problem is by having a generous free tier or by allowing the app pulling in new users to remain free forever, for those users you brought in through your app.

As an app creator, even in this situation, where the user gets a free ride in your app because she’s a first time App.net user, you’re asking a lot from the user. When user acquisition and retention is your bread and butter, placing a huge level of complexity at the signup step, explaining what the hell an App.net account is, it’s basically strangling the acquisition part, and you never, ever, want to do that.

Taking a step back, what problems are they solving anyway? Shorten time to market for app makers? Because social app plumbing is getting pretty cheap and easy to pull off at scale with IaaS. Besides ending up with something very limited. Using App.net to build your app must add value, either for the creator, or the user. I’m failing to see how it does either. Unless, maybe, if App.net login is an optional part of your app that could lover the already in-place pricing scheme for all users (failing to see when this would make sense, but it’s possibly I guess).

Conclusion: Ask yourself, what app in the past 5 years, could have been pulled off, logistically, using app.net plumbing?

Congrats! It’d be cool if I could collect uploaded files and logs into S3.

I see. We tackle the same issue by having a redis keyspace with emails. It can get pretty huge without any problems.

That’s not what they’re doing. They are sharding horizontally on the user. ID’s are 64 bits with the db location (logical shard id) in the first 16 bits. This will allow anyone with an ID to go to the right db for querying, granted they have logical to physical shard mappings.

For those interested, we’re creating a multi-platform trivia game. We’ll have many satellite apps which will help us bring in new users, and one main app where people can create a profile and discover many topics. Further down the road we intend to open up to user submitted trivia and hopefully have a healthy community of trivia fans. If this sounds interesting to you please have a look at our site www.plainvanilla.is and look at the available jobs.

Great effort! Any reason this shouldn’t be the basis of Boto unit tests?