On Tue, Jul 10, 2012 at 4:27 AM, Gervase Markham <[email protected]> wrote: > 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?
We won't of course know until people start submitting apps, as it'll entirely depend on what types of apps people will be writing at first. However I would say that the vast majority of apps should be implementable as "normal" apps. > If we move to a package format, will "normal" apps have to use that > format too? No. > I assume not from the above, but I wanted to check. I don't know how I could have said this more clearly :( >> 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? App-cache stores all header values and so as long as we use that (which is the best thing we've got for non-packaged apps), we need to sign them. Otherwise it's hard to say just how the app would behave differently based on header values. Technically we could strip all headers when dealing with resources for a signed app, but it'd be yet another way that signed apps would be subtly different from "the web" while still trying to act like they still are webby. >> 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. Having to deal with other people's bugs is nothing new to us. Claiming that it's somebody else's problem because it's somebody elses bug won't help our users. >> 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. I'm told that requiring SSL has been deemed as not ok still. >> 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. I'm much more worried about people no longer being able to generate their HTML using php/cgi than that they no longer can generate their images using php/cgi. >> 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? That is exactly my point. >> 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? At this point trusted apps won't run in other browsers anyway since standardizing the APIs which require trusted privileges hasn't gotten far enough. I.e. we've barely gotten to the point that the WG has been started. Standards take a long time :( Hopefully by the time we get to the point when these APIs are getting implemented in other runtimes, we will have gotten to the point that the packaging format is standardized too. Also note that the reason that we're requiring trusted apps to exist at all is that we feel that some APIs are too sensitive to expose to normal web pages. I.e. we have not been able to figure out a way to make for example raw TCP sockets safe for plain webpages. It's most likely that other browser vendors will feel the same and so these APIs might never be available in "browsers" at all. Ideally we will figure out a way to make these APIs available to web pages but changing how they work, and by expanding the security models for web pages. At that point the apps that want to use these APIs won't need to be trusted apps at all, and hence won't need to be packaged, and so none of the discussion in this thread will apply to them. But we're not there yet. >> 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)? Depends on how we do updates. Though as mentioned, I'll request that we do updates in separate threads. >> 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? See above regarding standardization. >> 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 you point to more information about the "feed:// debacle"? > 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. It's not standard no. We could do something like this, but it wouldn't reduce any of the confusion around the fact that the resources inside the package has different cookies than resources outside it. >> 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? I think using new URLs is a relatively small problem. There are much bigger issues, like having to get review, having to use signatures, and having to use CSP. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
