allo jonas, i missed what jim said here so i'll just reply to it. jim: i covered this earlier but i appreciate that with the number of messages on the topic it's very hard to follow so i don't mind repeating it: everyone else who has seen this already your patience greatly appreciated.
On Fri, Mar 16, 2012 at 7:39 PM, Jonas Sicking <[email protected]> wrote: > On Sun, Mar 11, 2012 at 6:51 PM, Jim Straus <[email protected]> wrote: >> Hello Jonas - >> The problem I'm trying to solve is knowing that the app I think I'm getting >> is the app that I'm getting. SSL doesn't do anything to solve this, it just >> protects the privacy on the wire, not what is actually going through it. actually, SSL *does* solve it, i forget the name of the technical solution but it's used by the BBC on the HTTPS traffic for the bbc ipplayuh. they allow *ONLY* certain PKI Certificates to be used. they have issued one such certificate to apple. they have issued one such certificate to microsoft. they have NOT issued one such certificate to the Free Software Community, because it's a private key / public key infrastructure. thus you see clearly the disadvantage of using SSL for PKI authentication: yes you can limit the downloads to be *only* from that site, but the problem is that the downloads can *only* come from that site. to add more sites, you must issue more private key / public key Certificates - one per URL. now you're into a logistical nightmare if the app becomes popular (1 million downloads per day). >> Black listing based on scheme/host/port is probably not sufficient for an >> organization that distributes more than one application. This was raised in >> a different discussion related to web apps in general. But even if it was, >> we may want to blacklist a particular version of an application, not the >> application in general. The signature provides a mechanism for this. yes... in combination with a mechanism for performing updates etc. >> I agree that removing permissions for some application infractions might be >> a good idea. The actual semantics of what the black list can do to to a >> particular app can be discussed and enumerated. But there will definitely >> be apps that we want to completely disable (eg. if we find an app is >> hijacking information, I don't want it running at all.) i described this earlier... hmmm, i hadn't added it to the wiki, i'll do so. https://wiki.mozilla.org/Apps/Security#dealing_with_rogue_applications done. > I have to admit I've lost track of what it is that you're actually > asking for. "knowing that the app I think I'm getting is the app that > I'm getting" depends highly on the definition of "the app". > > As I've stated, I don't want to force app developers to have to their > code inspected by stores, nor do I want to force stores to review > developers code. And if a code review hasn't happened I don't see what > signing the code buys anyone. at least it allows you to track down the real person. if their real identity is associated with the app, and/or there was a price to pay (time or money) for actually getting the app through into a store, and that person's digital signature becomes blacklisted, they've just completely destroyed their reputation. > Instead I want stores to verify that they can trust a developer > through things like contractual means and restricting which set of > privileges they give an app. It has also been suggested that stores > should be able to require certain technical security measures from the > app, like EV Certs and/or certain CSP policies. i'm sorry, jonas, i don't know what EV Certs or CSP policies are. perhaps you might like to add them to the Definitions section on the wiki so that people know clearly what's being discussed? https://wiki.mozilla.org/Apps/Security#Definitions l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
