On Tue, Mar 10, 2015, at 06:35 AM, Antonio Manuel Amaya Calvo wrote: > On 10/03/2015 1:23, Jonas Sicking wrote: >> * Enable Marketplace to hand out the ability to use a particular API to a developer, rather than to a particular version of a particular app. > This is nice... but I believe it's ultimately futile. It works for > well known, giant developers... I could say I trust Google, or > Mozilla, or Facebook... but I don't think it'll work for Pop&Mom SW, > Inc. How would Mozilla know if they should trust them and with what APIs? > > The model we have right now sucks: it's slow to deploy, it's slow to > update, it's not similar to the rest of the web, at all (it's > basically Apple's model on a smaller scale, in other words). But as a > user I can be reasonably secure that whatever I install will use only the permissions it needs, and won't get my data and run with it. But just giving access to random developers, which will then do whatever they want with that permission is the same as opening the permissions to everyone, only more complicated to implement.
I think it's important to recognize that there are real limitations to the marketplace review mechanism. I have not participated in our apps marketplace, but I was a reviewer for addons.mozilla.org previously and authored extensions that went through the review process (which is documented at https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Reviews). Much of those reviews is about avoiding doing risky/ill-advised things: using eval from a chrome context, remotely loading code in a chrome context, using sync XHR which results in a nested event loop spinning, etc. Other aspects were making sure there was no hidden sketchy stuff (obfuscated blobs), or known sketchy stuff (third-party monetization libraries provided to add-on authors by third-parties that were known to violate Mozilla addons policy.) Most of these were automatically detected. Doing thorough code review is hard. And slow. The review queue can be a major hassle for extension authors, especially for complicated extensions. At some point, we are simply just trusting the developer and the reputation they've built up with the reviewers and the users. Recognizing that fact can be an improvement for everyone: it lessens review-burden and lets the developers get security fixes and feature enhancements out to their users faster. For real-world examples in the add-ons domain, I'd cite the enigmail Thunderbird extension (https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/) that provides PGP support for Thunderbird and the Thunderbird Conversations extension (https://addons.mozilla.org/en-US/thunderbird/addon/gmail-conversation-view/) that provides a conversation view reminiscent of the gmail experience. These are both deeply complicated projects in their own right that fundamentally depend on their developers' competence, intentions, and their policies/procedures for security and correctness. It's also possible and acceptable for us to require specific policies as a precondition to use of this mechanism, especially for significantly more dangerous APIs and/or where self-updating is a risk. For a web-app example, https://whiteout.io/ has an HTML/JS/CSS based PGP mail client. If I knew that Firefox OS would only accept an updated release of the app (manifest) when it has been signed by 2 of the developers of the client using their own personal private keys that are nominally kept encrypted with a strong passphrase, that would greatly increase my trust. (Noting that that's a pretty hard-core example.) Andrew
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
