Hi Jonas, On 09/07/12 18:04, Jonas Sicking wrote: > Please note that the various requirements and solutions in this email > *only* applies to trusted and certified apps. It does *not* apply to > "normal" apps, i.e. apps which don't use of any of the APIs which are only > available higher privilege apps. You will be able to do anything that you > can do in a web page today, and more, without worrying about any of the > restrictions in this email.
Are we anticipating that most apps in a store will be trusted, most will be normal, or it'll be about 50:50? If we move to a package format, will "normal" apps have to use that format too? I assume not from the above, but I wanted to check. > We came up with this solution since we wanted to avoid "packaging" apps > into some sort of archive (like zip) and delivering it through the store. > W3C widget specs and Chrome apps use this solution. > > However, there are a couple of problems with this solution. > > As Brian Smith has pointed out, signing HTTP responses isn't trivial. > There's a significant risk that proxies will change headers on the way > between the server and the user's browser. Why would the signature need to include the header? Because the app relies on some of the stuff in the header for its security properties? > There even some risk that > proxies will change the contents of the response bodies themselves. There is, but such networks are broken. Complain to your network provider. And use SSL. > experience. The only way to really prevent this is to always use https to > serve the resources. However, this can be a non-trivial cost for the app > developer. So we are planning to allow resource to be served over HTTP? I'm surprised at that; I'd have thought HTTPS would be a requirement for all apps, to prevent MITM and simply as good practice. > Signing the resources means that you can no longer generate your HTML or > image files on the fly using php, perl, ruby, etc. This is because you > would have to generate a new signature at the same time as you generate the > file contents. However generating a new signature would require having the > private key on your web server, which largely defeats the purpose of > signing since if someone hacks the web server, they can create their own > signed resources. Hence signing effectively requires that the resources are > static files located on the server. Yes; this is a problem. We might be able to solve the image problem by exempting them from the signing requirements, just like we may be exempting them from the Mixed Content warning. > Also, since it's the store that has to review the app and send new > signatures for any updated version, it means that publishing a new version > of your app no longer means simply updating the contents of your web > server. You also have to contact the stores which you are selling your apps > through and ask them to re-review your app and create new signatures for > the app's resources. Surely if the model is that every trusted version needs to be reviewed by a store, you'd have to contact them all anyway? > Hence we have changed the plan to instead base trusted apps on a "packaged" > solution. My meta-question about this: how does this affect the possibility of an app (or as great a percentage of apps as possible) being runnable in a browser, even one which doesn't support WebRT? Have we declared that to be a non-goal now? > The idea will be that to publish a trusted app the developer will > create a zip archive which contains the app manifest as well as all > resources needed for the app. The app can then be sent to all stores which > the developer wants to publish the app trough. These stores can then review > the app and sign the package. At installation time the signed package is > downloaded by the B2G from the store and the package is verified against > the signature. Does this break the useful ability the other model had of doing incremental updates (i.e. updating only what had changed)? > One obvious question once you go with a packaged solution is what URLs the > packaged resources will be available through. My initial thought was to > keep things as webby as possible and to make the resources in the package > available as normal http or https URLs. If the app is to be usable in any way outside a dedicated environment, then surely the app has to use standard HTTP URLs? > Instead I think that we introduce a new protocol, app://, which is used to > load all resources in trusted apps. This is an idea that Jim Straus came up > with over in bug 707625. Introducing this new protocol certainly has the > disadvantage that it feels less webby, however I think the benefit in > clearing up the confusion above outweighs it. The "feed://" debacle, which led to a load of non-working URLs on the public web, makes me nervous about this... Can we use the URL form like: https://developer.com/myapp1.0.zip!path/inside/zip.html ? ISTR that form being used for accessing files inside zips. Not sure if it's a standard or not. It's probably distinguishable in code from a standard HTTP(S) URL. But it doesn't lead to a new protocol. Or, we could modify it slightly and have the URL still work, sort of: https://developer.com/myapp1.0.zip#!path/inside/zip.html > All in all this definitely means that trusted apps won't be as webby as > normal apps. However as long as we have the requirements around signing by > the store, an enforced CSP policy and a separate cookie jar, trusted apps > simply won't be very webby. But, in the old model, they would still _work_ in other clients, wouldn't they? > In the long run I definitely want to make trusted apps more "webby". Both > by changing our trusted apps work, and also by giving the web more > capabilities so that they can meet somewhere in the middle. But I think the > above proposal is a good way to start by doing something secure which will > give us experience and help us develop something better in the future. It seems like using a new protocol would make it harder to have the two converge? Gerv _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
