Live data from Hacker News

Here's the Most Idiotic and Brilliant App Ever

thevine.com.au

111–120 of 122 posts

Re: Here's the Most Idiotic and Brilliant App Ever

#111

I wonder how smart "throw" detection is. Could I strap it to a two-stage model rocket with a couple of D class motors? Or are you limited to a single impulse event, in which case I've got a couple unfired air bags kicking around. There's a phone recycling bin here at school; I'm tempted to grab a few old android phones and see if I can get one working well enough to try it out.

Nope, because phones don't have altitude detection. The only thing it can go by is accelerometer data, and you can infer what that data should look like using high school physics. They probably measure the duration of "weightlessness" (freefall), and maybe also check that there are large enough spikes of acceleration at beginning and end, although those will be mostly outside the range of the accelerometer. You can p…

Presumably you could use the GPS for altitude detection?

Re: Here's the Most Idiotic and Brilliant App Ever

#112
post #84

Earlier quoted context omitted.

Can I ask how you discovered the URL the app was making requests to?

I'm guessing Wire Shark.

Correct. I created a tcpdump trace on my OpenWrt router and then opened it in Wireshark. The HTTP request was easy to spot from there.

Re: Here's the Most Idiotic and Brilliant App Ever

#113
post #110

Earlier quoted context omitted.

How exactly do you prevent something like this? How do you ensure that the stats sent over the internet are coming from an actual approved client? My instinct tells me the simplest solution would be security by obscurity - adding some validation token that the client generates by some obscure and hard to reverse engineer manner. Is there any better way to 'validate' your client?

I had to deal with this before. Basically we combined several obscuring techniques: Use SSL for the requests which makes it harder to sniff the API. Add some sort of tamper token like you suggest. Use a specific User Agent string and check for that. Provide no error messages if any of the above fails.

> Use SSL for the requests which makes it harder to sniff the API.

Won't help - it's trivial to setup a proxy to MITM the traffic.

> Use a specific User Agent string and check for that.

Won't help - it's easy to manipulate a User-Agent. Assuming you're manually creating the GET request (via cURL or other means), then it's only one more option to bypass this.

> Provide no error messages if any of the above fails.

Will make debugging a pain. Also, if I'm an attacker, I'm going to try and clone the request as best as I can the first time, then see what I can get away with.

> Add some sort of tamper token like you suggest.

This is the best option. Not quite sure the best way to implement it, but perhaps some sort of CAPTCHA (this would be a pain), or some kind of random request id, etc. might work.

Re: Here's the Most Idiotic and Brilliant App Ever

#114

I hope they have a standing connection to the server during the throw and detect ... disconnects. That way, they could detect crashes and give approximate credit for the height. I don't want to throw my phone high into the air, watch it go to pieces and not even get a high score.

they should multiply the height with the current market price for the phone you used. so you have to keep throwing to stay in the charts as your model devalues.

Also, a multiplier for the case you describe.

Re: Here's the Most Idiotic and Brilliant App Ever

#115
Randall Munroe published some relevant calculations recently on the ability of humans to throw things high:

http://what-if.xkcd.com/44/

Summary: a professional baseball pitcher might be able to reach fifty metres but the human arm is optimised for throwing horizontally.

Re: Here's the Most Idiotic and Brilliant App Ever

#116
post #110

Earlier quoted context omitted.

How exactly do you prevent something like this? How do you ensure that the stats sent over the internet are coming from an actual approved client? My instinct tells me the simplest solution would be security by obscurity - adding some validation token that the client generates by some obscure and hard to reverse engineer manner. Is there any better way to 'validate' your client?

I had to deal with this before. Basically we combined several obscuring techniques: Use SSL for the requests which makes it harder to sniff the API. Add some sort of tamper token like you suggest. Use a specific User Agent string and check for that. Provide no error messages if any of the above fails.

I would add to that: use a self-signed cert for the SSL. If you rely on the OS's PKI its relatively easy for an attacker to add their own CA and read the connection.

Re: Here's the Most Idiotic and Brilliant App Ever

#117
post #96

Earlier quoted context omitted.

My other half dropped her phone recently and was utterly distraught. Neither of us realised just how insanely favourable the like for like replacement deal was, and were unsurprisingly hugely complimentary about Apple afterwards. I cannot overstate how helpful and efficient the staff were and the process was just so quick and simple. If (mildly idiotic) apps like this being banned are the price of that piece of mind?…

Agreed. The screen my girlfriends iPad broke edge to edge, so I decided to bite the bullet and go pay to have it replaced. Took it to the Apple store, he looks at it for a second and runs into the back. Hands me a new one(refurb?) and (after verifying that I backed up already) says "You're all set! Have a good day". I was pleasantly surprised, and looked like an awesome boyfriend.

I know someone who broke an iPad the day after buying it and the Apple store people refused to do anything for free.

Re: Here's the Most Idiotic and Brilliant App Ever

#118

Earlier quoted context omitted.

Nope, because phones don't have altitude detection. The only thing it can go by is accelerometer data, and you can infer what that data should look like using high school physics. They probably measure the duration of "weightlessness" (freefall), and maybe also check that there are large enough spikes of acceleration at beginning and end, although those will be mostly outside the range of the accelerometer. You can p…

Presumably you could use the GPS for altitude detection?

Or the barometer.

Re: Here's the Most Idiotic and Brilliant App Ever

#119

Earlier quoted context omitted.

>the weight and aerodynamics of the object being thrown Somehow I doubt that's included in the Android API. ;)

aerodynamic is calculatable from deceleration which is sum of gravitational "g" plus aerodynamic "Cx" multiplied by square proportional to the speed. The weight is known for a given model of device.

>The weight is known for a given model of device.

By "known", I assume you mean "known, assuming you want to track down (an trust!) the specs of the ~4,000 different Android devices", correct?

Re: Here's the Most Idiotic and Brilliant App Ever

#120

I wonder how smart "throw" detection is. Could I strap it to a two-stage model rocket with a couple of D class motors? Or are you limited to a single impulse event, in which case I've got a couple unfired air bags kicking around. There's a phone recycling bin here at school; I'm tempted to grab a few old android phones and see if I can get one working well enough to try it out.

My take on this, not:

- on GPS, as mattbessey suggested. (precision: 2m max)

- integrating accelerometer data : Very difficult, as the telephone would spin. Also: measurement errors are integrated too, so not too precise.

Best option is time based:

1) Detect launch/landing time by looking at accelerometer spikes (easy, good time precision)

2) Altitude = 1/2 * g * ((timeLanding - timeLaunch) / 2) ^ 2. Air resistance negligible. g = 9.81 m/s^2.

Post reply on HN