Just like what Tim had mentioned. I had talk with some people about the issues raised by hosted package apps. And, I am also looking for other potential solutions. But, these ideas are still in studying and talking, never be wrote down.
Jonas Sicking <[email protected]> writes: > On Thu, Apr 9, 2015 at 1:32 AM, Tim Guan-tin Chien <[email protected]> > wrote: > 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. I don't get it! If a given script is not loaded, the app should be failed to load. It would be stop. Right?! > > 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 Or, every resource authenticates itself as a part of a manifest (a version). With this way, it eases developers who working on a new app by without signing whole app/package for every little changes. To implement it, every revision of an app is seen as an entity that had a certificate issued by the developer or a trusted 3rd-party. By signing every resources with a revision's certificate, resources prove they are a part of a revision. The signing is done by the issuer of the certificate. For the trusted 3rd-party case, the developer should submit a list of resources with their digests to a trusted 3rd-party, so the trusted 3rd-party could verify the code, generate a certificate, and sign every resource separately in one time. For the developer signing case, people may trust FB and accept certificates issued by itself. So, FB could change and update apps continously without distribute new certificates or manifests. > 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. With the idea mentioned above, UA could verify resources (provided by service worker, maybe) against the certificate installed. Or, service worker could request UA to re-verify and update all resources in app's cache. This idea could handle both the develop model with revisions and the model that allows continous change without apparrent revision (current web style). > > 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 -- Sinker -- 天教懶漫帶疏狂 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
