121 comments

[ 2.4 ms ] story [ 207 ms ] thread
Might actually be a good benchmarking app for makers of rugged phones
As someone who compulsively throws things in the air when bored, this sounds amazing.
I'm curious why this was banned from iTunes. Does anyone know if this is against a specific rule, or if it was a subjective decision?
2.1 Apps that crash will be rejected 8-)

Actually,

13. Damage to device

13.1 Apps that encourage users to use an Apple Device in a way that may cause damage to the device will be rejected

It really bothers me that Apple banned an app like this. Just allow people to be idiotic. There's even a disclaimer after all...

As for the app itself, cool! I'm glad somebody had the audacity to ship something as outrageous as this. I don't think it will get much of a following, but I suppose if you really don't care about your phone or you're really confident in catching this could be a cool, reckless waste of 10 minutes.

EDIT: For clarification, I don't really side with or against Apple in general on things, so this isn't meant to be a "Apple's always a walled garden, BAH" post, etc...I just really feel any company should let users feel free to destroy hardware. But I understand that might not be the best philosophy to run a multinational company.

EDIT2: Just thought of a way to game this after reading another comment - slap on a Lifeproof case, go in a big pool shallow enough to stand, throw it really high. Eliminates the need to catch it (within...reason...).

Maybe because Apple might need to fix the phones? Or their carriers insurance providers would?
They sell phone warranties for damaged phones so it's a fairly direct conflict of interest.

Also "13.1 Apps that encourage users to use an Apple Device in a way that may cause damage to the device will be rejected"

Perhaps it is worth more to Apple that a user can download apps and continue the "iPhone lifestyle" than worry about how to fix their device. I personally think that it is not a conflict of interest.
Perhaps I didn't explain myself - I'm not saying the rule isn't transparent, I understand very well there's an actual rule. My complaint is that it's there at all.

Although, what you said about warranties makes sense...however honestly that hasn't kept friends of mine from deliberately breaking their phones just to get new ones.

...then your friends are dishonest, and their dishonesty raises the price I have to pay when I buy a product from Apple.

Did you criticize them when you found out they did that?

Sure. Not that it helped any. Interestingly, it's more my "untechnical" friends - exclusively those, actually. The technical ones are somewhat invested in technology news and wouldn't do that because they understand a lot more of the process. On the other hand, those that are dishonest in this way, in my experience, know nothing about the tech of Apple except that it's, well, new and shiny.

As for myself, my iPhone 4 is half-broken and I'm still eeking out whatever life I can get from it before I get the iPhone 6 in the Fall.

Apple should ban this app. The amount of support it is going to eat up not to mention the headlines the tech press is going to write are not worth it. Selling an app that is basically designed to break the phone is just a really bad idea.
Bad idea, perhaps. But why should Apple get to determine what is or isn't a bad idea for one to do with their own phone? (Although I would suspect part of the reason they banned it is to avoid claims of "Apple's so greedy that while they ban so many legitimately useful apps they allowed this one, just because it can break phones resulting in added profits for them from people buying replacement phones".)
Because, Apple is warranty liable for selling an app that basically get you to break your phone either via current replacement plans or the expected lawsuit. This is a money loser and a problem for parents.
(comment deleted)
Apple rejected the app. Did you read the article?
Yes, I read the article and knew they banned the app before leaving my comment. I agree with their position and further added why. Should is often used as an agreement with an already taken position.
When friends ask which smartphone to get, I often recommend the iPhone, despite being a long time Android user and fan.

The reason is that Apple has a very generous straight replacement policy (at a fraction of the retail new price) even if you don't subscribe to any of their care plans. This is a world different from makers like HTC and Samsung who fully intend to double dip if you have an issue with your device, where a replacement of a broken device costs 100% of its original price (meaning you are paying again for marketing, R&D, profit, markup, etc). I have faced exactly this twice (both with Samsung), once where they claimed nebulous, unproven corrosion damage on a device that had never touched water, and had all clear water sensors. As a user there is nothing I can do to contest this, their warranty being effectively useless through no negligence of mine. They nicely offered to fix it for just over a thousand dollars.

Samsung and HTC and others want you to bust your device. Apple doesn't, because they have a stake in it as well, making no profit from your own misadventure.

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? I pay it gladly.

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.
you sir are not an idiot, contrary to the guy you are replying to.
I know someone who broke an iPad the day after buying it and the Apple store people refused to do anything for free.
Won't take long until someone takes that thing skydiving to get the world record. :-)
(comment deleted)
I would assume that it measures against upward motion as well, but I could be wrong.
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.

Plus they would be able to keep a total count of destroyed phones, which would be quite interesting. "This app has destroyed ??? phones."
(comment deleted)
A cute error message would be appropriate afterwards for comic relief, when you accessed it on your computer, etc.

"Your phone soared 100 ft. before dying a soldier's death. New high score! Good luck about the phone though."

>"I don't want to throw my phone high into the air, watch it go to pieces and not even get a high score."

I'd think that would defeat the purpose of the "...and catch it!" step.

If anything, I'd want such an app to record video or perhaps fire the camera for a still the peak. I'm thinking that would a be huge plus to the idiotic entertainment potential, like a less inane Vine and a slight deterrent from the inevitable result spoofing.

I agree with your idea of the camera firing...but you think this could be less inane than Vine...?
There is a camera design that uses exactly this method, unfortunately patented:

http://www.slashgear.com/squinto-throwable-ball-camera-grant...

Prior art, unfortunately also attempting a patent is at:

http://jonaspfeil.de/ballcamera

Heh - Great idea, but can you imagine testing that during development?
No way! This is the price is right rule. Go over and you lose it all!
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.

Actually, Sergey Brin made the same app and showed it at the Android G1 launch :)

https://www.youtube.com/watch?v=VWwLZfVpCyU

I am quite surprised this isn't at the top.
Came here to post this as well.

In the end, he decided it might be irresponsible to leave the app on the market and encourage people to throw around their shiny new expensive phones.

Pah. That's nothing. I have an app idea called 'iSkip', where you skim your phone over the water and your phone sends back how many hops it did as it's last act.
Don't fool people, there is no such thing, but there is something cooler called "the skipping movement". A real skipping app would be much more brilliant: http://iskip.com/
Turn the app on, wrap the phone in bubblewrap/foam.. Clean,Safe,Fun
Well, looking at the "World top 10" high scores (on app), the top one has a record of 43.16m. I cannot imagine why someone would threw a cellphone to this far.

I wonder if there is a way to "hack" the accelerometer...

It's probably easier to hack the protocol it speaks with the server. That's what ruined the world-wide stats in the iOS game center too.
I'm not so much concerned with the why, but more... how? 43m straight up is a pretty tall throw, I'm picturing water balloon slingshots or something...
Perhaps they were on a rollercoaster or one of those rides that you take vertically straight up?
In addition to "why someone would throw a phone that far"... that height of 43 m is impressive, since it (neglecting any force except gravity) requires an object to be thrown vertically at around 29 m/s to stay in the air for almost 9 seconds. 29 m/s is over 104 km/h... but throwing things upwards is not that easy.

That top score should be the result of manipulating the sensors or the data sent to the server. [edit: ... or measuring some other action than throwing the phone]

You could fairly easily throw and catch it while in the vomit comet (https://en.wikipedia.org/wiki/Reduced_gravity_aircraft). That should get you in the 25s range. Next up would be using it while in the IIS.

If the software is not too picky detecting weightlessness, just holding your phone while inside a fast elevator going down could also work.

It would be in air for 6 seconds. 2 * (29/9.8) ~= 6s
"I wonder if there is a way to "hack" the accelerometer..."

A fun, if elementary, physics puzzle.

Drop it from a great height? It's probably just measuring the flight time, by measuring the time for which the accelerometer reads zero. Infinite points if you can get your phone into orbit!
Idiotic because you might destroy your phone?

Or idiotic because the energy spent on this could have been used to build something that actually provided value?

I'd argue that entertainment, no matter how small, is value to someone.
People are playing crazier/riskier games everyday! I mean why not ...
The current high score is 43.16m - I wonder if somebody found a way to cheat, or if they really really do not care about the wellbeing of their smartphone.
Not that hard. Lifeproof case, throw it from a pool of water, watch it land in the pool of water.
Step one: find a tall building.

I don't endorse this.

Alternatively: skydiving!

I was wondering how fast someone would hook this up to a rocket and see if it can actually record a few thousand feet.
Put it in an egg drop style container that will protect it from a large impact, the drop it off a building our launch it from a trebuchet.
Look at this app: https://play.google.com/store/apps/details?id=de.nichtlustig... It shows comics from the German nichtlustig.de In the appstore you can see some screenshots, also of the included 4 panel instructions: It visualizes the 4 operations to be done with the app: forward/backward, mark as favourite, random cartoon and destruction.

When I saw it I laughed for a long time :-)

I wonder how this app works: Obviously it must transmit the highscore quickly enough before the phone shatters. I hope it opens and warms up a connection before you throw it. Maybe it can constantly transmit the height and falling time/speed up until the last second of life of the phone
If the app is indeed able to have a fairly accurate height value, it just needs the turning point height in order to calculate speed, duration of fall, and the (more or lees) exact time of impact. So it could transmit the value whenever it detects that the phone has stopped moving upwards.
You're not going to get the turning point from accelerometer data, as the phone is in free fall the whole time. The non-zero acceleration will be on takeoff & landing (or launch & catch, or impact...).
If you don't catch it, you don't get points. Sucks, but that's the rules!!
Wow, amazing! I wish I had thought of this.

Think of it as the heart of a 2-part high-school physics project:

1. Develop a rocket that will carry your smartphone as its payload.

2. Develop a case that will allow your smartphone to survive the landing.

...and a 2-part college project:

3. Find investors for your high school project, then market it.

4. Profit!

Ok, the app's web service is rather prone to manipulation:

You just need to HTTP GET the following URL:

    http://www.carrotpop.com/smth/php/save_result.php?id=<UID>&nickname=<NICK>&country=&result=<HEIGHT>&latitude=0&longitude=0
* UID looks like an autoincrement ID

* NICK is what you entered for the highscore

* HEIGHT is the float value of the height in meters, i.e. "1.23"

In the HTTP response, you get a data structure (not sure which encoding it is, but it is straightforward) of the highscore data:

    [[["1.","LIATO","44.19m"],["2.","ROYBOY_91","43.16m"],["3.","YAIR40","35.12m"],["4.","GABRIEL","34.70m"],["5.","KAI","31.10m"],["6.","KAFAC99","21.06m"],["7.","JOSH","20.37m"],["8.","KEANSKI","17.61m"],["9.","EKREM6363","16.10m"],["10.","LORENZO","12.24m"],["2047.","MY BEST TRY","0.71m"],], ...
Edit: just opening the URL http://www.carrotpop.com/smth/php/save_result.php you can see the current stats, encoded as above.
With heights in the 50m range, it looks like it's already being manipulated
50m seems to be an artificially set limit.
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.
Decompile the apk with one of a number of tools (apktool, baksmali). Least that would be what I would do.
Set up a proxy setup pointed to a squid or whatnot that logs request. Use tcpdump on the router. If you have a rooted Android device you can use tcpdump there, or instrument the HTTP framework code to log requests, or...

But assuming you have control of your home network and aren't just using a Linksys thing out of the box, just logging into the router and watching traffic is by far the most straightforward.

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.

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.
This app should sell a kit with a parachute...This would be the new Toy Parachute Men.
It requires GPS. Crashes on my tablet.

Also, see their Facebook. They publicly post GPS location of winners, together with StreetView. Is that stated in the app? It can be a privacy concern.

  com.carrotpop.www.smth         E/AndroidRuntime: FATAL EXCEPTION: main
        java.lang.IllegalArgumentException: requested provider gps doesn't exisit
        at android.os.Parcel.readException(Parcel.java:1429)
        at android.os.Parcel.readException(Parcel.java:1379)
        at android.location.ILocationManager$Stub$Proxy.requestLocationUpdates(ILocationManager.java:646)
        at android.location.LocationManager._requestLocationUpdates(LocationManager.java:660)
        at android.location.LocationManager.requestLocationUpdates(LocationManager.java:482)
        at com.ansca.corona.CoronaSensorManager$1.run(CoronaSensorManager.java:163)
        at android.os.Handler.handleCallback(Handler.java:615)
        at android.os.Handler.dispatchMessage(Handler.java:92)
        at android.os.Looper.loop(Looper.java:137)
        at android.app.ActivityThread.main(ActivityThread.java:4745)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:511)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
        at dalvik.system.NativeStart.main(Native Method)
They are assuming all Android devices have GPS. Is it common for tablets to have GPS?

btw, I see com.ansca.corona.CoronaSensorManager in the exception stack trace, suggesting this app was written in Lua using Ansca Corona.

man, you've tried it with tablet! How big your tablet is? I think they should appropriately rescale scores for the weight and aerodynamics of the object being thrown.
>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?

I remember a piece of advice for taking original photos is to set the timer then throw it in the air. I would love to try it but no one will let me borrow their camera.
use a gopro. this is exactly the sort of silliness they're made for.
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 probably fool it by throwing it from some high point (bridge, building) and have someone catch it at the bottom.
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.

Is the Galaxy Tab version available? That could get dangerous.
A simpler and safer version of this would be something where you spin your phone and catch it right-side-up. Scoring could be done by counting the number of times this was done successfully in a row without catching it the wrong way or dropping it, or double-triple spins etc. I do this for fun all the time. So far, no drops on concrete.