On Thu, Sep 20, 2012 at 1:17 AM, Fabrice Desre <[email protected]> wrote:
> Read https://wiki.mozilla.org/Apps/PackagingProposal for the rationale
> that lead us to use this packaged apps format. Trust us, this was not
> "gratuitous".
>From the cited document, "Serving Privileged Apps from the Web Won't Work":
"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."
wow. living in 1990 still, huh?
The following paragraph (something about links to twitter) is pretty
incoherent. It should be replaced with a reference to the Web Intent
specification.
I'd love to see a coherent argument, but this wiki doesn't really make
it. It serves up some strawmen and complains that some things are
harder that it would like.
Here's a better proposal: you use a signed jar file (exactly, no
inventing new signature formats and other craziness) to contains a
bundle of files. You add two extra fields to the SETTINGS section of
an appcache manifest (this is backwards compatible with current spec).
One setting is: "bundle: <url>" and specifies a (optionally signed)
jar file containing the resources named in the manifest.
Now you can distribute a manifest + jarfile pair and get a self
contained webapp without inventing a bunch of new bespoke stuff.
Update mechanisms are integrated with appcache update mechanisms.
(Extensions may be needed, but they will help out appcache as well.)
Use https to authenticate the manifest. Sign the jarfile if you need
proof that the app was approved by some app store or other.
Bonus points for future work:
a) include the manifest in the jar file and use the fact that you can
do reads within the jar file to fetch just the manifest using a range
request. Then you can serve this as text/cache-manifest-zip and
reference the jar directly from the manifest attribute of the HTML
tag.
b) If you want to authenticate sites completely offline (ie,
installing from a jar file while disconnected from the internet), you
will also need to add the canonical URL as another line in the
manifest's "settings" section (and include the manifest in the JAR as
in (a)). Presumably you add additional signatures to the JAR file to
"prove" that this resource is actually found at the canonical URL
specified using some chain of trust (tracing back to a trusted cert
for the domain in question). You'd need to arrange for all of the
signed certs in the chain of trust to be available in the JAR.
--scott
--
( http://cscott.net )
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
