In other words, it is your anecdotes against his. I thought I would not need to remind you, but I guess I do: THE PLURAL OF 'ANECDOTES' IS NOT DATA!
BTW: adducing the MIDP and Win7 experience is most unconvincing even for its already unconvincing anecdotal class. This is because in both those schemes, there was no alternative: you HAD to request permissions every time, even if it had been granted before. But Android already supports asking on a per application basis. Now it is time for my anecdote against yours AND his;) I got very fed up with both Win7 and MIDP under Symbian because it kept asking over and over, but I recognized that a major complicating frustration factor was that the Symbian implementation of the Socket and HTTP APIs was so busted in the first place. That is, it would have been far less annoying, IMHO, if the network connection had actually WORKED when I gave it permission to go ahead. But instead, it was asking even more frequently than their questionable design called for, because they had to keep setting up the connection again every time it broke -- which was SO often. So after suffering though that, what I decided was needed, what I THOUGHT this thread was going to drift to, was a "two-tiered" permissions scheme: allow granting some permissions on a per- application basis, but some on a per-run basis. That is not to say I am sure which should go to which. Perhaps the Manifest needs to grant the application permission to ask permission;) But thinking about this reminds me of another relevant data point: until the user sees an application ask over and over for net permission (for example), the user has only a fuzzy notion in his mind of when which application DO use the net (and when). This is one Achilles' Heel (that millipede may have many more) of the current permissions scheme in Android. Why, for example, does Bump need Network at all, if it is using Bluetooth to communicate between Bumper and Bumped? This is an example of why I have to agree with what was said earlier: the current permission scheme really does look like it was designed by software developers, NOT by a UX expert. But such features really do need to be designed as a joint effort between UX and security experts. Otherwise the difficult trade-off between usability and security will come out badly -- as it already has so often. While I am making proposals, I suppose I should also propose an enhancement of the current Internet permissions: separate permissions for low and high bandwidth. I propose this because when Android was designed, carriers were offering unlimited bandwidth plans for smartphones. But now they are backing away, offering unlimited data plans only for feature phones -- if at all. So now we can no longer splurge on bandwidth. Yet I have noticed that many websites and many web clients still assume we can splurge, forcing the poor user to load and reload what should have been cached as well as download lots of junk before he gets to the data he -really- wants etc. But on AT&T, this can easily cause him to go over the 2G download limit on the high-end smartphone data plan. I know, because it has happened to me already;) Splitting Internet permissions into low and high does not solve the problem, but it might help mitigate it. On Aug 28, 1:00 pm, Dianne Hackborn <hack...@android.com> wrote: > On Sat, Aug 28, 2010 at 7:12 AM, Zsolt Vasvari <zvasv...@gmail.com> wrote: > > Let me try this from an end-user perspective. Obviously, the whole > > permission feature was designed by a developer and, IMO, it's not a > > very good system in a usuability sense. > > Oh my, I so very disagree with this. > > The current design is *very* much designed for end users. In particular, it > is designed for *most* users. Not geeks, like you and me and the others on > this thread. > > In the vast majority of cases when people are unhappy with the way things > work, the requests being made are coming from geeks for them to do more > geeky things. This thread is no exception. And this is very much an > anti-goal. > > > As an end user, I only care one and ONLY one permission: INTERNET. I > > only look for that one permission and the rest is just noise and might > > as well not even be shown. Why? Because I know as long as the app > > has no way of getting my personal info off my phone, I am good, as far > > as I am concerned, the app can read all my passwords and credit card > > info it wants, if it cannot do much with it anyhow. > > Sorry but you are wrong. When my wife got her Droid and started installing > apps, she quickly came to me asking about a game she was installing that > said it would read her contact data. She knew what that meant, and wasn't > happy about it, and decided not to install the app. > > In addition, there are so very many good reasons for an app to have access > to the internet, that basing all decision on that is ridiculous. So you > aren't going to install multi-player games, or an app that lets you post to > twitter, or countless other things, or need to have strong faith in any such > app because you have no idea what stuff about you it will have access to? > We aren't going there. > > > What I would like to see is the Internet permission broken up into: > > > - Full unrestrictued internet access: This is fine for a replacement > > browser, but if anything else requests it, I probably wouldn't install > > that app. > > - Local network access only (for printing or network management apps.) > > What does local network access on a cell phone even mean? And how many > normal users are even going to really understand what this means? > > > - An spelt out protocol/domain list that the app declares it wants to > > have access to and nothing else be allowed. This should be the most > > appropriate for the majority of the apps. > > I will claim again that this is another example of designing for geeks. > > That said... I would like to be able to have a way to enforce that apps can > only get to domains they declare they need. In fact, we looked at doing it. > You know what? This is hard. It is hard to enforce in the platform (think > about domains vs. IP addresses and how the kernel is going to figure out > that a particular socket is valid for the app). It is hard to make > meaningful (think of the tricks you can make with safe looking domains that > redirect elsewhere). It is hard to present to *normal* users in a > meaningful way that they can make a good decision about. > > Of course if you figure out a good implementation of this, I'd be happy to > review the patch. > > My focus right now is on simplifying permissions, giving apps other ways to > do things that are safe without requiring permissions, etc. Making things > more complex for users is not desired. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
