
Rovio explains why Angry Birds update needs SMS permission - gaiusparx
http://www.androidcentral.com/rovio-explains-why-angry-birds-update-needs-sms-permission
======
rbritton
This sounds similar to something on iOS 4.2. If you use any part of the asset
library framework, which includes something as benign as building a photo
chooser for the media library, the device prompts the user to allow access to
location services because the photos _might_ have GPS information in them.
There is no way to prevent it because the permissions are not fine-grained
enough. In the case of the article, the problem could be solved on the OS with
the separation of SMS access and operator billing as permissions.

~~~
ben1040
There are other permission granularity problems on Android, too. I wrote a
streaming media player and want to listen for when the phone rings or goes off
hook so I can pause. In order to this I need to access a permission that lets
me read IMEI, carrier info, phone number, etc.

That's too much info, and it makes my app look skeezy to be requesting access
to that when all I want to do is not have music playing down the speaker while
the user is on a call.

~~~
panacea
Too granular and it's an endless set of "are you sure?" prompts which users
are likely to develop a blind-spot to...

Not granular enough and you grant root-access to everything when you first
install a 'flash-light' app.

Finding the right balance? Worthwhile.

------
dododo
i wish i could refuse to give android apps certain permissions yet still
install them. i don't want angry birds to ever be able to charge me money and
certainly not read all my SMS messages. i simply won't upgrade.

for other apps, i just have to not install them; it doesn't seem like i can
give feedback to app developers about this.

~~~
drivebyacct2
Unfortunately this change would require changes to the platform that would
break all current applications.

I find it funny, Android informs you as to what applications can access and
people are more leary, even when the developer is up front about it. On other
platforms, the user never has a chance to even be skeptical at all.

~~~
tomjen3
Not really. Android is sometimes used on tablets that can't send SMSs, or you
could be out of range or even in airplane mode.

Just return the same error code you would if there was a physical problem and
continue.

~~~
drivebyacct2
Um no... the application would not just receive the same error code unless
Google specifically set it up just for that permission, and that strategy
wouldn't work for any other permissions. Think about it, the manifest
specifies that the application will have access to whatever it asks for... the
application would just crash when the VM/kernel denies it access to other
applications data or some system permission because the user is given the
ability to override it. Not having an active connection to receive an SMS is a
completely unrelated and irrelevant point.

I find it really super awesome that this is downvoted. Yes, an application
that expects a permission to be available, randomly not being able to access
is sure to not cause problems. Not just -1 too, we really have to ram this
post into the ground, no reply, just watched my karma drop like 10 points. I
expected better. Keep it coming guys, teach me my lesson without actually
replying!

~~~
SoftwareMaven
I think there is a middle ground. Certainly, there are going to be some
permissions an app can't function without (e.g. you can't have a phone dialer
work that doesn't have access to the phone). On the other hand, there are
permissions that are purely optional to an application (such as the afore-
mentioned SMS).

It would be better to specify "required permissions" and "enhanced feature
permissions". I require the phone permission to run. I can use the SMS feature
to make your experience better.

~~~
drivebyacct2
I'm not saying it is a bad idea. I really like it in fact. I really don't
think it will work as smoothly as (apparently everyone) seems to think.
Android wasn't built to have this feature... and I'm not sure that even this
middle ground could be done in a way that doesn't break many existing
applications.

~~~
SoftwareMaven
I disagree. Apps already need to be able to handle some of these situations
(as some parent post mentioned), but you don't even have to alter any existing
app as all existing permissions requests default to "required".

I don't buy the argument that "it would make testing the app too difficult."
It just isn't that hard to put feature-placed guards in place. Web apps do
that all the time today for JavaScript capabilities and they survive just
fine. I have a lot of apps on my iPhone that I don't give location permissions
to that continue to work fine as well.

I don't know the details of the underlying OS change, but I would imagine it
isn't that large of a change, either (if any change at all). The system has to
have the ability to check if an app has permission to perform an operation
today so people can't lie about the permissions they are using. It would just
do the same thing it does today.

So we are down to adding a flag to the permissions requested (required versus
requested), adding a description field to the flag, and altering the
presentation of the permissions at install time.

~~~
drivebyacct2
Why am I bothering replying if no one will take the time of day to explain why
they're crucifying all of my comments here when I'm voicing a completely
legitimate claim about denying apps that have been guaranteed permissions
access to those features...

I never said it would make testing the app hard. I never said it would be hard
to change Android permission model to accomodate for deniable permissions when
they are needed.

I'm saying that it would break every application in existence that is expected
to have guaranteed access to whatever permissions they've declared in their
manifest. Android apps aren't written to handle AT ALL cases where they simply
aren't given permission to do whatever, and they would surely crash as a
result.

I've never been more disappointed in how comments were voted on than I am on
this thread.

\---

edit: If you're implying that NEW apps could mark permissions as OPTIONAL and
then manually request them and handle being granted them or not in code...,
then I'm 100% in support. I think it's a BRILLIANT idea and I have no idea why
it's not being worked on.

edit2: Surely I'm not out of line for assuming that "just return an error code
and act like it's broken" was supposed to mean that users could deny
permissions to existing/legacy apps that had declared the permissions in their
manifest. If we've been talking this entire time about a new schema for new
optional permissions in NEW applications, while still preserving legacy
required permissions... well, I sure wish someone would have had the decency
to point that out instead of just downvoting.

edit3: I'm almost positive he editted that comment to add that last paragraph.
Or else I'm an idiot and missed it. Either way, I apparently misunderstood
what he was talking about, unless that's what we've been discussing this
entire time. Either way, I don't know why it didn't occur to me.

~~~
megablast
No, well it depends on how they handle errors. Not all apps are stupid enough
not to handle errors and crash. YOu can not make blanket statements, that is
why you are being modded down. You can not speak for all apps, and it makes
you sound childish to do so.

~~~
drivebyacct2
How can I make this more obvious.

Are you telling me you'd wrap a System.out.println() in a try/catch? Even
that's not absurd enough to exemplify the problem that all of you are clearly
having in comprehending the magnitude of the absurdity you're spouting. The
program is GUARANTEED the permission. Why would there be code to check to see
if it has the permission? Do you people even understand the current Android
permission model? (Such a function _literally does not exist in the API._ )

It's like a huge joke that I'm the punch line of. And surely, you're not
recommending that a tiny fraction of apps not crashing excuses the fact that
such a change would break undoubtedly near 100% of applications.

I'm just enraged at the fact that everyone is making caveats to try to make me
look wrong while not a single person has actually addressed the claims I'm
making. Actual Android developers in #android agree with me - not only that
this would be bad for legacy apps, but that it would almost guaranteedly cause
them to crash because they WOULDN'T HAVE CODE to check to see, because THAT
DOESNT EXIST in the Android API because the manifest ensures they have that
permission.

------
Lyote
It'd be nice if the Android Market had a place to explain why certain rights
are needed by the developer so this kind of thing doesn't cause such an
uproar. You'd still have to take the developers word for it, but at least
they'd have a chance to defend themselves before the public gets to worked up
about it.

~~~
eli
The Android Market is practically hostile to dialogue between developer and
user. It's really a shame.

------
dtwwtd
I find it interesting that Rovio is choosing to build its own payment system
rather than use the options that Google is integrating into the Android
platform.

I don't have a problem with granting these permissions to an app that I use
that comes from a well known, trusted developer. Also, the features that
require the permissions aren't used unless you actually make the decision to
use them. So while the developers really should make sure they educate their
users before taking their money, in the end it falls on the users to make the
decision to buy.

~~~
jkaljundi
For one thing, Google in app payments via carrier billing are not available
yet. When it will be, I would not bet too many of the world's ~200 countries
will be supported, just a few key markets. Same with Android Market itself, it
works in just a tiny mnumber of countries:
[http://market.android.com/support/bin/answer.py?answer=13829...](http://market.android.com/support/bin/answer.py?answer=138294&hl=en)

Compare that to mobile payment operators, who's key job is to work on carrier
agreements across the world. That's why the likes of Rovio choose companies
like Fortumo: [http://www.socialtimes.com/2010/06/fortumo-launches-
internat...](http://www.socialtimes.com/2010/06/fortumo-launches-
international-in-app-payments-for-android/)

------
moomba
I think the main reason this has become a bigger issue is Automatic Updating
in Froyo. Since then, you have to manually update the app if the permissions
change. Otherwise, the app will automatically update(if you allow it during
installation). I always look at the comments now for an app that requires a
manual update. Many times they are introducing adds or farming your data.
Unfortunately it makes it so companies that are playing nice will be seen as
doing evil. I for instance, did not update Angry Birds until I read this post.
I was thinking they were farming my data to help boost their profits.

------
raganwald
Now of course people seem to trust Rovio. But if another app asked me for
permission to use SMS, could it surreptitiously engage SMS billing where
carriers support it?

~~~
m_eiman
Sure, there's no fundamental difference between a "premium" SMS and normal
one. Except maybe the shorter phone number.

