This is related to my earlier comment on application (or android process (a la Joe-E)) which would identify applications with suspicious behavior (excessive permissions).
I imagine my point is a bit hazy here so let me try an example. Presume that police worked the way the most anti-virus software works. The local constabulary would iterate over the citizenry comparing them to a set of wanted posters. If he found a match then he would cart them off to jail, no judge no jury. This sounds like what is done with escaped convicts and parolees. Although this technique is useful it should not be the first and only line of defense. Alternatively the police could patrol the neighborhood looking for suspicious behavior and responding to distress calls. These are related to POLA. If a suspect is asking for more permission than seems reasonable to do his legitimate job that constitutes a suspicious behavior.
(Is there any way to provide partial permissions to and android application?)
An android application presents a set of permissions (needed resources) and a set of intents+ (messages). The assumption is that the resources requested are needed by the application to satisfy messages of the specified types. It seems then that POLA responsible applications should be as "small" as possible (but no smaller).
If this makes sense then it would seem that it would be possible to rank Android applications via a POLA score. These scores would be part of the android market. Developers would thus be encouraged to make more modular applications which would interact more. _______________________________________________ cap-talk mailing list cap-t...@mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk
As a reminder, I'm not an Android Security Spokesman, but since I was asked directly…
On Mon, Jun 28, 2010 at 2:28 PM, Fred <phr...@gmail.com> wrote: > Dan, what do you think [about the report from CNet about the survey of app permissions used by apps listed in the Android Market]?
That it was written sensationalistically. Note that CNet toned down the rhetoric in the piece after it was first posted.
That's not actually a case in point, at least not as stated. AIUI, the report doesn't talk about "excess authority;" it's just a census of apps that have "sensitive" permissions such as "read contacts list."
> (Is there any way to provide partial permissions to and android application?)
Nope. This was debated — at length — within the Android team. In the end, the consensus was that partial permission grants would lead to two bad things: (a) more apps that asked for unnecessary permissions, on the theory that, after all, the user could just turn off the ones they don't want; and (b) more bugs for app developers whose apps would get run with unexpected permission sets, leading to worse end-user experience and more trouble for developers. Consensus was that the existing status quo ends up exerting pressure exactly in the direction of reducing overly-authoritied apps. If you want to debate this, I recommend joining android-discuss@googlegroups.com and posting there (after catching up on the archives).
> If this makes sense then it would seem that it would be possible to > rank Android applications via a POLA score.
Commenters in the Android Market *already* make comments along the lines of "Why does this app need to read my location?" etc., and some will down-rank (e.g., rate as one-star) apps that they perceive to be too permission-heavy. This has already had a positive effect on improving the effective "POLA score" of apps. Personally, I have rarely run across an app which seems to require more permissions than its stated purpose would imply.
One grey area is that advertising-supported apps, by their nature, require internet access and often often coarse location as well (for geographic targeting). If one is uncomfortable with that, then one doesn't have to install such an app; and the Android system will inform you in advance that the app requires those things in such cases.
>> (Is there any way to provide partial permissions to and android >> application?)
> Nope. This was debated — at length — within the Android team. In the > end, the consensus was that partial permission grants would lead to > two bad things: (a) more apps that asked for unnecessary permissions, > on the theory that, after all, the user could just turn off the ones > they don't want; and (b) more bugs for app developers whose apps would > get run with unexpected permission sets, leading to worse end-user > experience and more trouble for developers.
I just recently got an Android phone, and I noticed a particular example of this: I installed Pandora, which requested access to my contacts. I assume this is for the 'Share' functionality, but I have no intent of ever using it and would prefer that the app not have this information.
It would be easy to stub out this functionality in a non-fatal way (pretend the contact list is empty) -- but then you have the complaint "why isn't share showing anything?"
I would in general rather have the option of trying apps with low permissions and then possibly giving them more later, but atypical user blah blah blah.
On Wed, Jun 30, 2010 at 7:46 PM, Kevin Reid <kpr...@switchb.org> wrote: > On Jun 30, 2010, at 17:29, Dan Bornstein wrote:
> >> (Is there any way to provide partial permissions to and android > >> application?)
> > Nope. This was debated — at length — within the Android team. In the > > end, the consensus was that partial permission grants would lead to > > two bad things: (a) more apps that asked for unnecessary permissions, > > on the theory that, after all, the user could just turn off the ones > > they don't want; and (b) more bugs for app developers whose apps would > > get run with unexpected permission sets, leading to worse end-user > > experience and more trouble for developers.
> I just recently got an Android phone, and I noticed a particular > example of this: I installed Pandora, which requested access to my > contacts. I assume this is for the 'Share' functionality, but I have > no intent of ever using it and would prefer that the app not have this > information.
One very useful suggestion made by Shriram Krishnamurthi was for each requested permission to come with a developers (or attackers) free-form explanation of why they needed the permission. In addition, the user feedback would include "app asks for too much permission for what it provides" and the particular permissions that were inexplicable.
This has an advantage over the free form feedback Dan mentioned earlier in the thread because its easier to parse for someone looking for this information and can be used more reliably when ranking apps.
It would be easy to stub out this functionality in a non-fatal way
> (pretend the contact list is empty) -- but then you have the complaint > "why isn't share showing anything?"
I agree this works most of the time but mock stubs can sometimes have unexpected consequences. For example, if you grant an contact list syncing app a mock contact list, does it delete all your contacts upstream?
I would in general rather have the option of trying apps with low
---------- Forwarded message ---------- From: Shriram Krishnamurthi <s...@cs.brown.edu> Date: Thu, Jul 1, 2010 at 2:06 PM Subject: Re: [cap-talk] Android using capability discipline To: Mark Miller <erig...@gmail.com>
[Feel free to forward this message.]
More precisely, I suggested that users also have the right to vote on a capability, and each capability would be shown in a color that reflects its vote. So if lots of people voted against a particular capability, it would show up heavily red (say).
This would be an indication to a user that this is a capability many people think is disconcerting. It might even cause the developer to realize it is better to write the application without need for that capability (or provide a credible explanation for its need).
This lets the crowd give feedback to the developer with very little work (a check-box rather than copying an email address and arguing with a potential crank), and for thoughtful users to potentially help the rest make more informed decisions.
I will add that some of the Google applications (Maps, as I recall) are particularly demanding of capabilities. The only reason I install them is because Google already knows everything about me (as indicated by the ads it shows me in Gmail for vacations I didn't know I need, products I didn't know I want, and diseases I didn't know I have).
Shriram
-- Text by me above is hereby placed in the public domain
On Thu, Jul 1, 2010 at 3:32 PM, <ihab.a...@gmail.com> wrote: > There's a whole "social" component to this -- I could assign greater > trust to my friends or to specific [groups of] people whose opinion I > particularly respect.
I should add that this linking of a social graph to permission grants was first formulated by my friend Joel Truher.
On Thu, Jul 1, 2010 at 3:13 PM, Mark Miller <erig...@gmail.com> wrote: > More precisely, I suggested that users also have the right to vote on > a capability, and each capability would be shown in a color that > reflects its vote. So if lots of people voted against a particular > capability, it would show up heavily red (say).
There's a whole "social" component to this -- I could assign greater trust to my friends or to specific [groups of] people whose opinion I particularly respect.
> Commenters in the Android Market *already* make comments along the > lines of "Why does this app need to read my location?" etc., and some > will down-rank (e.g., rate as one-star) apps that they perceive to be > too permission-heavy.
This seems to indicate that there is significant end user demand for a POLA operating system - not that we should use such words and phrases as "capability" or "principal of least authority" in front of end users, but it does indicate that the concept of granting relatively fine grained permissions is intuitive and important to end users.
>>> Commenters in the Android Market *already* make comments >>> along the lines of "Why does this app need to read my >>> location?" etc., and some will down-rank (e.g., rate as >>> one-star) apps that they perceive to be too >>> permission-heavy.
James A. Donald: >> This seems to indicate that there is significant end user >> demand for a POLA operating system - not that we should >> use such words and phrases as "capability" or "principal >> of least authority" in front of end users, but it does >> indicate that the concept of granting relatively fine >> grained permissions is intuitive and important to end >> users.
Dirk Pranke wrote:
> I'm not sure that I would agree with your conclusion. What > it says to me is that if you present users with a list of > options, some of them will ask about it, and wish for > finer-grained control. We do not know if that percentage of > users is "significant", and we certainly can't conclude > from that that end users have any concept of what a POLA > operating system would be
As I said, we should not use such a term in front of end users.
What users want is not POLA, but that applications should not be doing surprising things behind their backs.
If, for example, one's minesweeper app was accessing one's contacts list and sending out emails, one does not need an electrical engineering degree to smell a rat. _______________________________________________ cap-talk mailing list cap-t...@mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk
I would like to continue on the social issues related to POLA though.
A social problem is that at least one developer (me) gets lazy and writes a program which grants more authority than is necessary to do a job to a delegate. The reason I do this is manifold. It really isn't my authority that I am exposing. I wrote the software but I'm not the one operating the software. It is the operator's authority that is being leaked. Mostly I'm just lazy. I use global variables which get me in trouble all the time, I know I shouldn't use them but they are sooo convenient. I know I shouldn't do it but the problem I am working on is hard enough without trying to follow good design principles. Then there isn't anyone keeping me honest. Sure we have reviews but the reviewers are just as lazy as I am, and in the same ways. Once the system is working I forget about my earlier laziness. That is where social pressure becomes helpful.
As an aside, I generally am a believer in cooperation over competition but I think this is one case where competition trumps cooperation. If I produce a piece of software which is a permission pig and someone else makes one that is more parsimonious then I should lose. (Competition is social pressure?)
The question of partial permissions is really about applying social pressure. I argue that the "two bad things" resulting from partial permissions are actually good things.
"(a) more apps that asked for unnecessary permissions, on the theory that, after all, the user could just turn off the ones they don't want" --Dan
When user's turn off permissions they are *voting*. And as stated by Shriram, voting is a good thing. The question is, for what are they voting? I think the thing being voted on is the mapping of jobs being done to permissions required to do them.
"(b) more bugs for app developers whose apps would get run with unexpected permission sets, leading to worse end-user experience and more trouble for developers." --Dan
This is the old "A person buys a drill bit not because he wants a drill bit but rather because he wants holes". Shouldn't there be some relationship between the job being done and the access required to perform the job? When I hire someone to landscape my yard I don't give him the keys to my house because he needs to use the phone from time-to-time. (I know, why doesn't he have a cell phone!) I don't mind him asking to use the phone each time because it isn't going to happen very often and I want to monitor his use. Similarly, the police metaphor. I prefer to monitor suspicious activity rather than known criminals. Suspicious behavior is characterized by behavior inconsistent with the job being performed.
I think the "problems" mentioned introduce a social force which if properly harnessed could encourage smaller more well defined applications, greater delegation and in general discourage non-POLA applications. _______________________________________________ cap-talk mailing list cap-t...@mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk
