Re: Installing web apps
On Feb 1, 2012, at 21:20 , Paul Libbrecht wrote: Le 1 févr. 2012 à 21:03, Boris Zbarsky a écrit : Android goes somewhat in this direction with its app-security model... With all due respect, the app-security model on Android is a joke. Everyone just clicks through the permissions grant without even reading what's being requested, because _every_ app asks for a bunch of permission grants up front and won't run until you grant them. Any random game wants permission to do arbitrary internet access (as mentioned earlier on this thread, already a security hole if you happen to be behind a firewall when you run the game), listen to your phone conversations, read your addressbook, etc. Perhaps they do have some sort of rarely-used features that require such access, but the model forces them to ask for all the permissions immediately... and the user is trained to just accept. I agree that the current UI is not great. However, I disagree about everyone clicking through permission grants. I've done two user studies and found that about ~18% of people look at permissions for a given installation, and about ~60% look occasionally. We found that most have no idea what they really mean -- but that is a separate problem pertaining to the presentation. Also, about 20% of people have in the past avoided apps that they considered bad because the permissions alerted them to something that they didn't like. No, no app has yet demanded me my addressbook access and some apps add advertisement: and hey, I do not need network. That's the general problem with demanding permissions... I agree it's in infancy. Apps on Android are unlikely to request access to your address book because the Android Intents model makes it so that unless you're installing a contacts manager app, there probably is no reason why any app would have access to that. That said, if it did require access, the odds that a user would notice are close to nil. One thing I've found is that developers often don't understand the relationship between Intents and permissions in Android. A common mistake is for an app to ask for the READ_CONTACTS permission even though it's actually using an Intent to access contacts (which doesn't need the permission). Either that, or apps will unnecessarily implement things that are already provided via Intents for no particular reason. I think these issues could be avoided on the Web by first introducing something that can be accessed via WebIntents and only later introducing direct access via permissions, and also making the documentation very clear.
Re: Installing web apps
I agree that the current UI is not great. However, I disagree about everyone clicking through permission grants. I've done two user studies and found that about ~18% of people look at permissions for a given installation, and about ~60% look occasionally. We found that most have no idea what they really mean -- but that is a separate problem pertaining to the presentation. Also, about 20% of people have in the past avoided apps that they considered bad because the permissions alerted them to something that they didn't like. Did you publish this research somewhere? Would be interested to know your sample size and type, response rate, etc. It's in submission, but I can put together a tech report if you are interested. Results are from two studies: self-reported data from 308 online Android users (recruited via Admob), and confirmed by an observational study of 25 Android users in the bay area (selected from a large pool of Craigslist applicants so that they match the overall Android population by gender, age, etc.). One thing I've found is that developers often don't understand the relationship between Intents and permissions in Android. A common mistake is for an app to ask for the READ_CONTACTS permission even though it's actually using an Intent to access contacts (which doesn't need the permission). Either that, or apps will unnecessarily implement things that are already provided via Intents for no particular reason. I think these issues could be avoided on the Web by first introducing something that can be accessed via WebIntents and only later introducing direct access via permissions, and also making the documentation very clear. Do you think this might be a consequence of developers copy/pasting permissions? I wonder if anyone has looked into that (might be easy to see overlaps or replication across applications). I've found several cases of bad permission behavior being copied and pasted by developers, although I am sure there are more cases than I found since I did not originally go out looking for it. (If you check out section 6.3 of http://www.cs.berkeley.edu/~afelt/android_permissions.pdf I give a few other examples of common reasons why developers ask for more permissions than they need.) Adrienne
Re: Adding Web Intents to the Webapps WG deliverables
Android developers chronically misunderstand and misuse Android Intents, and these mistakes lead to security bugs. To illustrate how prevalent the confusion is, Erika Chin and I found that 9 of 20 popular Android apps (45%!) contain security vulnerabilities due to misusing Intents. I've also found these same types of bugs in Google-produced Android applications (the default ones that ship as built-in apps). I posted examples details of two real-world applications that exhibit these vulnerabilities: http://www.adrienneporterfelt.com/blog/?p=313. It's my hope that Web Intents can be designed to prevent developers from making the same mistakes. There are two common types of errors: 1) Android Intents can be used for both inter- and intra-application communication, and developers don't know the difference. A canonical accident occurs when a developer creates a unique action string like foo.bar.xyz and uses it for internal communication. The problem is that any other application can register for the same action string, even if it's supposedly hard to guess. This introduces two security bugs. (1) The component that receives foo.bar.xyz has been unintentionally made public, since anyone can send that action string to it. (2) Another application could register to receive foo.bar.xyz and steal any data associated with it, or simply gain the user's attention away from the original app. 2) The Android OS sends Intents to applications as notifications. Developers register components to receive these system Intents. By default, registering for a system Intent makes a component public. Developers don't realize that these components become public by default, so they don't check that the Intent was really sent by the OS. I have two suggestions to prevent these same errors from appearing in Web Intents: 1) Developers need to be discouraged from using Web Intents for internal application communication. One way to do this is to make it so that Web Intents are only delivered after the user selects a service in a browser popup window. (Nothing hidden in the background!) This would be annoying for intra-application communication, so I think developers would avoid it. 2) If a developer registers to receive a Web Intent from the browser (like for a system notification), that component should NOT be invocable by any other application unless it's registered for a second Intent as well. Adrienne
