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.
For the dependencies, one way might be to have a link tag to refer to the
file which is used to index all others, and multiple pages can refer the
same index file.
Also, this implies than one can have a coarse grain approach of which files
are signed (certified) and which one are not. It might be interesting to
only certify the core of the application but still keep the interface away
from the certification process to avoid the overhead of making updates.
> 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.
If we keep signatures separated, I do not see any reasons for not having
incremental updates of files as long as we check for updates if the index
file of signatures to check for changes.
> 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.
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.
This would give the ability to people to migrate from the web to an app, but
this probably implies some uninstall logic such as people are not loosing
info which is only part of the app, and not the origin.
> 3. Add a new URL syntax for referring to resources within a package.
> One candidate is
> http://server.com/url/to/myapp.webpackage!//images/pic.jpg. I.e. the
> "!//" signals boundary between the URL sent to the server to fetch the
> package, and the path within the package to get a resource. But we
> need to check that this is web compatible.
I think this is a nice way to scope the CSP. As of today we have the
protocol with the origin, but with this model, we would add the app with its
packaging method.
http://server.com/url/to/myapp.dir!//images/pic.jpg
--> not bundled (just a security scope)
This might be useful to prevent inspection within different user account
on the same computer. (see the CSP answer)
http://example.com/~foo/.dir!//index.html (can access same origin)
http://example.com/~bar/index.html (same origin, except ~foo/.dir!//)
http://server.com/url/to/myapp.zip!//images/pic.jpg
--> bundled (with an additional security scope)
Give the ability to bundle everything into one file, at the discretion
of the content provider.
The presence of the signature/certification is just orthogonal to the way
the content is accessed. The index file of signatures can be added next to
the rest of the files and provide an annotation on which file of the bundle
are signed/certified.
--
Nicolas B. Pierron
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
