On Fri, Jun 20, 2014 at 5:09 AM, Nicolas B. Pierron <[email protected]> wrote: > Hi, > > I might not understand all the details and constraints well, so feel free to > explain if I miss understood something. > > On 06/18/2014 11:28 AM, Jonas Sicking wrote: >> >> So in short, packages still are useful for: >> * Additional security through signatures >> * Managing dependent resources >> * Possibly some performance issues >> >> >> So the question is, how can we make sure that packages have all the >> benefits that normal webpages have today. > > > One thing I am not sure to understand, why are we making the streaming > choices for the app developer? From what I understand of signatures, we do > not have to bundle the signature with the file it-self, it can just be a > separated file which index all others with their signatures. The same > applies to meta-data.
I'll avoid the term "streaming" since it can mean so many different things. Yes, it is technically possible to sign files the way we normally do over http, and then just add signatures to that. For example by sticking the signature in a http header, or by putting it in a manifest of some sort. However signing http resources is pretty risky. First of all you need to decide which headers you cover in the signature. If you include all of them there's too much risk that unrelated server configurations are going to break the signature. If you include none of them then there's a risk that changes in headers (such a mimetypes and charsets) dramatically affect the behavior of the resource, even if the contents of the resource hasn't changed. Second you need to worry about proxies modifying the content, especially headers, in ways that normally cause little to no issues, but of course with signatures completely break things. If you aren't using SSL there's a risk that transparent proxies will make such modifications. But even over SSL you have to worry about a client-configured proxy messing things up. >> 1. Create a new package format. The format should support streaming >> and support adding metadata, like headers, to individual resources. It >> likely also needs to support metadata for the package itself. > > I have never understood packaged apps. From my point of view packaged apps > should only be a transparent optimization provided by Gecko based on the > content of a manifest file. That's essentially what this approach tries to accomplish. Turning packaging into a transport-level thing rather than something that fundamentally changes what a webapp is. >> 2. Add CSP syntax similar to "self" but which means "in the same >> package" rather than "from the same origin". > > I am not an expert with CSP, but it seems that we might want an app to have > a r/w access to the origin and to the app, but prevent the origin to have > any access to the content of the app. We have no plans to prevent data connections, using things like XHR, WebSocket and WebRTC to resources outside of the package. Likewise <img>, <audio> and <video> can be loaded from anywhere without problem. The only thing that we are limiting is the ability to load HTML, script and CSS from somewhere that isn't signed for. > This way multiples apps from the same origin could share some content with > the rest of the applications hosted on the same origin, while keeping some > info reserved to the current application. Allowing signed and unsigned content to share data storage is certainly an interesting idea. The application would have to thread very carefully though as to never copy sensitive data to a shared storage area. Another problem is that the web currently doesn't have the concept of overlapping storage areas. You either share 100% of all storage, or none of it. I'd definitely be interested to hear proposals for how to improve this situation though. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
