On Thu, Jul 5, 2012 at 6:31 PM, Lucas Adamski <[email protected]> wrote:
> > The odds of encountering outright malware are fairly small, but users > > routinely install applications that want to stretch the bounds of data > > usage. I'm personally in favor of designing for the much more common > case. > > I'm more concerned with overtly malicious apps. The sanctions you mention > above don't seem to have significantly dissuaded overtly bad actors from > distributing malicious apps on Android devices. If they get a few thousand > victims before they get pulled, they are still happy. Having apparently > trustworthy UI that something like "this app would like to have your > location/picture for the purposes of verifying your Bank of Whatever > account information" seems like a serious issue to me. We have always > treated security bugs in our chrome UI which let a 3rd party confuse or > deceive the user as significantly worse & very different than simply the > ability to display deceptive content. > Consider the two cases with a malicious app: 1. Without explanations the install dialog will say something like "this app wants access to your contact database" 2. With the explanation the install dialog might say something like "this app wants access to your contact database for the reason: 'to see if any of your friends are also using the service!'" (or whatever particularly innocuous claim they can come up with). In theory with 2 they could be making a claim that is falsely reassuring, essentially downplaying the extent of what they are asking for. (Though I would question the ability of such app developers to actually perform this social engineering competently, given what I've seen elsewhere.) They could also try to simply confuse the user, perhaps: "this app wants access to your contact database: 'no access required'" thus confusing the user into whether they really are giving access or not. On further thought, simply confusing users seems like the greater danger. With 1 I believe the danger is that the confirmation dialog is so hopelessly boring that no one will pay attention to it, and my understanding is that evidence backs this up* *(as does personal experience). I think we have a general security problem that confirmation dialogs do not lead to intelligent decisions on the parts of users, they only cover our butt because in theory it's the user's fault when they confirm something they shouldn't have. So I'm a little skeptical of our conventions here. We do have the opportunity to style the dialog to visually differentiate between our text and the provided reasons, and there is some convention around this distinction (and in the end it's all visual differentiation). It would be neat if we had a "report this permission" option on that confirmation dialog – report that the description is nonsensical, that it's inappropriate for the scope of the app, or that it's used in a way that is not consistent with the rationale given. Of course you have to figure out who to report to... which is clear in the case of the Marketplace, but not for self-install (and it's unclear how much you would trust a third-party store – we have put up very few barriers to keep people from putting up fraudulent stores). Keep in mind that web installed apps (aka untrusted) don't have to be > distributed by any app store, so blocking them is tricky. The ability to > blacklist + review process are the two reasons I'm pretty happy to display > "intended usage" for trusted apps. > Trusted apps are just a subset of apps on the Marketplace, right? _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
