On Thu, Apr 9, 2015 at 1:32 AM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote: > The second question we had is whether or not HTTPS+CSP could establish > the same level of trust. The answer is probably no because of our 300 > root CAs in NSS and CNNIC, but it is also because HTTPS encrypts and > signs the streamed files on the fly -- you would not be able to > establish true accountability between the code executed and the > certificate without recording the whole HTTPS session. It also deny > the possibility of 3rd-party reviews before hand.
Exactly. > So the lunch conversation boil down to one question: can we associate > and sign the resources individually? Either by inserting an > X-App-Signature in HTTP header or with some signature string in the > manifest. These ideas sounds utterly familiar to Privileged Hosted > Apps proposed by the one and only Ben Francis :) but I can't find any > discussion in written or remember any conversation that prompt us to > decide on Hosted Packaged App over anything based on the said > proposal. The conversation in the thread "Proposal: Privileged Hosted > Apps" doesn't look directing to the proposal directly -- Hosted > Packaged App does not solve many of the problems raised in that thread > either (and we may never be able to for problems like creating wall > gardens). This was discussed at the recent workweek. The problem with Ben's proposal is that it only gives content privileges once that content is installed. This because at the time when we load and execute the HTML/JS, we won't have loaded the manifest, and the manifest is what contains the signatures, or even indicates that there are signatures. Using a X-App-Signature header would improve that. However keep in mind that to have a "signed app", you don't just need a set of individually signed resources. You need to make sure that the the set of resources you have were signed together. So you don't want to end up with scriptA.js from version 1 of the app, and scriptB.js from version 2 of the app. That can be very bad if a security check was moved between the two scripts between version 1 and version 2. You also want to make sure that you have all signed resources that go along with the app. If an attacker can prevent a given script from being loaded, that might prevent certain security checks from happening which cause the app to be exploitable. So we need to not just verify each resource, we also need to get some form of manifest which enumerates all resources that make up a version of the app, and verify that that manifest is signed. I'm talking here about manifests in general, and not necessarily the W3C web-manifest. Though it could of course be the W3C web-manifest. And, because we want to make sure we always run only signed code, we can't allow at least script resources to be modified by the service worker in order to patch in a delta update to the script. At least not without somehow ensuring that the resulting resource is can be verified against a signature which is part of the above mentioned signing manifest. All of this puts some pretty severe limitations on what a service worker script could do, even if we let the serviceworker handle the update. I think it'd still qualify as a different update model than plain service workers. By nature of signing, anything that we do in this area is going to be different from the "normal web" and quite unwebby. But if someone is willing to put together a proposal which fulfills all of these requirements I certainly be interested to look. It might be doable by having the ServiceWorker call some API and pass in the set of resources that make up the signed app, as well as the signing manifest. However we'd also have to solve how the signature verification is done before the service worker is installed, when the user visits the app the first time. Another thing to keep in mind, is that signed content is a *really small* minority of content that developers will create for FirefoxOS. A much larger set of content is the normal web. And that is already quite webby :) / Jonas _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
