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…
Here's the Most Idiotic and Brilliant App Ever
111–120 of 122 posts
Re: Here's the Most Idiotic and Brilliant App Ever
#112Re: Here's the Most Idiotic and Brilliant App Ever
#113Earlier 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.
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
#114I 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.
Also, a multiplier for the case you describe.
Re: Here's the Most Idiotic and Brilliant App Ever
#115Summary: 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
#116Earlier 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.
Re: Here's the Most Idiotic and Brilliant App Ever
#117Earlier 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.
Re: Here's the Most Idiotic and Brilliant App Ever
#118Earlier 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?
Re: Here's the Most Idiotic and Brilliant App Ever
#119Earlier 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.
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
#120I 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.
- 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.