Hi, another note about 'always prompting' for sensitive/private UI's :
while i personally agree that these should always prompt, partially since prompting when the permission is about to be used helps users understand how and when it's going to be used, there will be pushback against this - it's not how other devices operate as well, which helps the case of the people who feel differently. (even Firefox for Android doesn't always prompt for geolocation every time, see https://bugzilla.mozilla.org/show_bug.cgi?id=682455) there are definitely going to be users who want to permanently grant sensitive permissions to apps who will find being prompted every time annoying them, especially when other platforms don't do this. i particularly dislike systems where doing something X times or for example, granting for some period of time (like iOS with geolocation, granting it allows your location to be accessed by that domain for 24 hrs, with a status bar indicator to show you something has access to your location - usually lacking information about exactly what, beyond 'Safari' in my personal experience) - because i feel that this has the user implicitly opting into sharing their data via a contract that wasn't explicitly communicated to them (I would be more alright with this if the user was informed what was decided on their behalf and could possibly revoke it via an additional dialog, perhaps.) . I understand the viewpoint that 'users don't read dialogs and always click through them' but Adrienne's research on Android has proved this isn't even true for those giant lists of permissions at install time and i'm yet to hear a better suggestion rather than just implicitly making the decision for the user, which means it's going to be wrong at least some amount of the time. additionally thanks Chris Lee and others for stating the security model will be documented on a wiki at some point. I hear many questions and concerns about 'what will the security model for B2G be ?' both from inside and outside the Mozilla project, so it's great to see this starting to happen - i agree with other posters that it's critical to get something up soon, both so people can see that security is a first-class concern and to start debating/finding flaws in the model - just like crypto, security models absolutely must have outside review and the more the better :) thanks, ian ----- Original Message ----- From: "Ian Melven" <imel...@mozilla.com> To: dev-security@lists.mozilla.org Sent: Monday, March 12, 2012 11:14:50 AM Subject: Re: [b2g] OpenWebApps/B2G Security model Hi, along similar lines, since the current discussion seems to rely heavily on SSL, has thought been given to what root certs a B2G device will ship with ? will it be the same as the Firefox root store ? personally, i think this is not a good idea - there are many certs in, for example, the desktop SSL store that i wouldn't want to trust for the purpose of granting privileges to apps, or even necessarily authenticating a connection to a store. i assume the vendor/carrier for the device may also want to customize the root cert store for their devices. the current cert pinning proposal (https://wiki.mozilla.org/Security/Features/CA_pinning_functionality) assuages some of my concerns - it would be great if the device vendor would pin the cert of their own store (and Mozilla did the same for the Mozilla apps store) to avoid MITM-with-valid-SSL-cert attacks on installs or permission granting. just some thoughts. personally i would prefer code signing (helps secure upgrades, if we follow Android's model of only an app with the same cert can upgrade an installed app) rather than totally relying on SSL - Firefox updates are now signed in FF12+ as well as being verified against a hash downloaded over SSL, for defense in depth. thanks ian ----- Original Message ----- From: "Kevin Chadwick" <ma1l1i...@yahoo.co.uk> To: dev-security@lists.mozilla.org Sent: Monday, March 12, 2012 3:54:53 AM Subject: Re: [b2g] OpenWebApps/B2G Security model On Sun, 11 Mar 2012 21:11:48 -0400 David Barrera wrote: > SSL works well for authentication and as Jonas points out, it is well > understood by developers and the community. Actually the whole security community is looking for ways to fix SSL Google chrome has announced a lookup website. SSL lookup via DNS similar to DNSSEC has an RFC but record size was a problem (1500 bit RSA limit). ECDSA keys now given the secure to be used go ahead and being more secure at a smaller key size (256bit), now make that viable but it hasn't picked up traction yet. That may be a good well tested and RFC'd method similar to DKIM for email in having a dns record to validate an app is from a domain, it's easy but may be more difficult for a website to realise how to add TXT records (dnsmadeeasy.com etc.) than just putting up a website via Joomla. For closed source apps like many on Android, private signing keys are the only way to go. All you have to trust is your trust in the developer. Forget the permissions it's good and useful and raises the bar for an attacker especially when users demand to install apps willy nilly, but nothing to base real trust on especially with a slow update mechanism to battle exploits, like on phones. For debian you are trusting that their build machines are secure and the download of the source code secure. They will take methods to verify the developers keys themselves etc.. and possibly reviewing code. This eliminates the risk of an author gaining trust through releasing source code but then offering a trojaned binary. A distros build infrastructure also makes it easier for the user especially when using the primary and more highly reviewed repos but it is almost a certainty that with the sheer number of packages (> 16GB) in all of the official Debians repos that there will be some malware/rootkit in there somewhere. I know I've been too liberal before and found DDOS trying to go out from a debian box. p.s. Of course, I'm not saying don't use SSL for transport security or domain verification, it is the easiest option for the masses, but also bear in mind it is likely to be replaced. It's been said for years but the traction does seem to be increasing against it. All these CA problems sure make the loudness of browsers "don't connect", it has a self signed key rather laughable/annoying. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
