mpetrov

Also just putting a space in front of https:// works, the script tag handles the leading space just fine.

Wouldn't Soylent eventually add some flavouring to make it less utilitarian/boring? It's still the first version of the product and it seems that the author doesn't even consider the possibility that there would be variations of the powder for variety and different taste preferences in the future. Does anyone know if they ever stated anywhere that the taste won't change?

This: https://map.couple.me

We kept the design simple, otherwise a "batching" mechanism could be introduced that would replay a single batch of 50 messages but that would make everything a second delayed. However, part of the map allows you to login and see your messages live on the screen as you're sending them to your partner and for that the real time streaming is pretty critical.

I tried using faye and it died very quickly under load with the redis backend. For every message that you send it queues it up into a redis list for each faye server in the cluster to read which doesn't scale very well in their very chatty redis queue system.

I would do significant load testing for each use case before using it (or socket.io for that matter). I needed to push 30-50 messages per second to each connected client and faye started choking as soon as there were more than 20-30 clients. socket.io would choke at around 50-100 connected clients. Raw websockets were able to reach closer to 100 clients but performed more or less similar to socket.io.

Sticky load balancing was a deal breaker for us when we built the https://map.couple.me visualization with socket.io. At the last minute I just pulled older browser support and left it with raw websockets instead of socket.io because the cluser module couldn't be used otherwise.

We had two issues with sticky load balancing:

1. AWS ELB had to run in TCP mode (for websockets) which meant no stickiness

2. Within each instance we have a node-cluster running to utilize multiple CPUs and putting haproxy with stickiness there increased complexity

We could avoid using the ELB but then you lose the ability to use an EC2 Auto Scaling group, introducing significant admin overhead.

Ultimately we didn't need the nodes communicating between each other (it's a one way stream from us to the client) so raw websockets ended up being the simplest solution.

Good catch! There is a small variation depending on the server that you hit but the variation should never be more than 1,000 messages. It's just a side effect of how we're scaling the system.

It's the geographic center of Canada, that's the coordinate that the geo-ip database gives us back when no specific city is available. Works well for smaller countries, but in Canada it's quite visibly "off" :)

Those data points appear as circular flashes without a line, there are quite a few of them there. The app appeals to a lot of long distance Couples so the map is somewhat biased towards long distance communication.

Also if you look at big cities (LA, NYC, SF) you'll see a continuous stream of circles flashing without lines. So the data just overlaps a lot.

That's pretty much exactly what's happening with some locations. We do our best to get an accurate location based on a few sources, but ultimately Maxmind is the database we fall back to for pure IP based location if that's all we have.

We're planning to do a larger tech focused write-up on this infographic soon. On the backend it's powered by Node and Redis and runs within an EC2 auto scaling group.

Let me know if I can elaborate on any of the tech behind this visualization.

We're planning to do a larger tech focused write-up on this infographic soon. On the backend it's powered by Node and Redis and runs within an EC2 auto scaling group.

Keep in mind that you have to run this with OpenSSL v1.0.1 and above. Running it on a stock OS X Mavericks install will not detect the extension because v0.9.8 of OpenSSL is installed.

The commentary on last example from Tarsnap seems wrong. The error was that the nonce stopped being incremented (see the linked Tarsnap blog post), but the author suggests the issue there is the unbraced if. The unbraced if is still not great style, but it wasn't the cause of the security blunder.

This will be awesome for terminating SSL closer to the user and should make a big impact on latency in mobile apps on high-latency connections.

Combine that with a custom SSL certificate at all the edge nodes ($600/month) and this is a pretty compelling dynamic CDN offering.

Can't wait to try it out for our API.

Nah, it was something between a lucky hunch and laziness. The backup plan was to test it an hour later when leaving the office for lunch but the restart worked. I actually realized it had to do with significant location changes early on since it was the new thing we added.

By the way, in general this isn't a reboot specific bug, the most secure setting is actually not the "allow after unlock" one but the one that gives no access to keychain if your phone is locked at any time. I noticed that keychain starts refusing access 15 seconds after you lock the phone but most apps keep their credentials in memory after they're read and the problem appears at reboots only.

I agree, the whole point of the logout bug is that the keychain is locked, and that happens for a reason. I came up with a different solution that worked great for us:

Just pause the startup process of the app (in a non-blocking way) if accessing the keychain fails at startup. Then during applicationDidBecomeActive the startup continues with access to the keychain data. That way we don't weaken the security of our customers.

At Couple, we found a much simpler solution to debug this exact same bug two days ago, and there was no driving needed:

1. Add lock code to your phone

2. Open the app without a debugger attached and start monitoring for significant location changes

3. Minimize app

4. Turn off iPhone

5. Turn iPhone back on.

Now if you wait 3-5 minutes in the same spot, your app will be woken up and will get a significant location change. Much simpler than driving and easily reproducible in the office.

Now to know when the app actually wakes up while you're in the lock screen, I added a local notification as part of the startup process. Now we just keep the phone locked for a few minutes until it shows the local notification, then you unlock it and see the logout problem.

Hope that helps everyone else!

I also used Protocol Buffers in multiple projects and languages. One huge advantage was that I could serialize data in Objective-C on the iPad, stream it to a C++ server on a desktop, and then forward some of it to a Ruby plugin in a different application. The performance was great and the libraries in each language made it seamless to use the same data structures across the board.

It would be great if this was supported along with key based authentication. Using the PAM method outlined here works only with password based authentication and the TFA is completely bypassed when a key is used.

I researched this a few months back and was not able to find a clean way to add TFA to a key based login. Any suggestions from other HN readers?

Sounds like it might be reserving space for the top status bar in a different orientation.

Either this is a weird device specific bug or perhaps the author of the post launched Safari in a different orientation on one of the devices and then rotated (and Safari cached a different "screen" size).

This is complete speculation and I don't have a device next to me to test, but the 20px difference suggests that it's referring to the black status bar at the top.

Edit: looks like it might be related to tabs: http://stackoverflow.com/a/13380055/552710

Exactly, there is just generally no need for it. It can be ok for prototyping because of the easy autolayout flags but at the end it just made sense to do the cells programmatically.

All the cool stuff is fully programmatic. I think right now it's just the onboarding screens that are still using interface builder - they're simple and mostly remain static.

One lesson though: do not use interface builder for table view cells, just don't. Cell reuse is tricky to get right as is and you should take the time upfront to make it all work programmatically.

We do it with a lot of custom code that responds to keyboard events, input text changes, etc. The underlying timeline is mostly UIViewController based but also does a lot of listening and responding to events all around it. We did try to use some of what is provided (inputAccessoryView for example) but ended up just going with a floating UIView for text input that keeps getting realigned as things happen.

It was definitely not meant to be sarcastic :) we actually do have Android very close to being done and soon Pair will be cross platform! Sorry for any confusion :)

We're working furiously fast to have Android ready ASAP. It's only a few weeks behind and is almost done. This is right now our #1 request, cross-platform relationships are in these days!

I actually have a 100% reliable solution that exploits the executable stack on level 04. No need to guess the address of the stack using one side effect that I found in this specific case:

https://gist.github.com/807e81ad64c4e84a7770 (SPOILERS)

For level 06, I came up with a completely different solution. After hitting my head against the wall all day trying to fight with blocking/non-blocking IO, I resorted to a timing attack on the system call which worked really well. Check it out:

https://gist.github.com/1899389 (SPOILERS!)

I actually just found a way to kill the worker process remotely (on my localhost). Perhaps they don't have it hooked up to supervisord for autorestart. It's almost trivial to run sys.exit() on that worker.

That being said, your tmp folder permissions theory is much more interesting though and that would be a brilliant way keep everyone else from catching up. :)

I'm also stuck at this point. Have the python exploit working on my localhost, now just need to run it live.