Seconds. We should move the web forward instead of restrict us to the packaged app approach.
Ben Francis <[email protected]> writes: [...] > Are we happy with a packaged model for trusted apps going forward, or is > now the time to embrace the challenge of making trusted apps genuinely part > of the web? Perhaps we don't even need to restrict our thinking to the > "app" and "app store" model and can explore ways of exposing more > privileged APIs to all web content in a trusted way. > > If you're interested in the nitty gritty of this problem, I've tried to > summarise Jonas' original email below. I hope he forgives me if I > mis-represent him in any way, but you can read his original email in the > archives [1]. > > ... > > In his email, Jonas proposed the following requirements for trusted apps: > 1. The ability for a trusted party to review an app and indicate some level > of trust in the app (or potentially in the app developer). > 2. A mechanism for signing an app to verify that the app actually contains > the content that was reviewed. IMO these two are the biggest problems. The current trust model on the web is to trust the author; how do we extend that to trust the content? > 3. Use of a minimum CSP policy for all pages of an app to ensure only the > reviewed code runs. > 4. A separate data jar for local data to ensure a compromised web site can > not write to the local data of an app to alter the way it behaves. > 5. A separate origin for the resources of an app so that the app can not be > tricked into running un-reviewed code from the same origin with escalated > privileges. > > Jonas explained that the initial intention was to host trusted apps in the > same way as non-trusted apps, to retrieve the signatures for reviewed files > from an app store, but the files themselves directly from the app's own web > server. > > He explained some problems with this approach: > a) HTTPS must be used to ensure proxies don't modify the headers or body of > HTTP responses, invalidating the signature. This would create an overhead > for app developers. > b) If multiple stores host signatures for the same app but review the app > at different speeds, updating of the app resources and signatures must be > synchronised between different stores and be limited to the speed of the > slowest review. Packaged app could also suffer from the slow review speed. The app has to handle the co-existing of old/new app version anyway. If the app could use a version-ed URL then the signing won't have to be synchronized between stores. > c) Signed resources have to be static because if a resource is dynamically > generated by a server side script, the signature would also need to be > dynamically generated, requiring a private key to be stored on the same > server, which largely defeats the object of the signing system. > > It was argued that this would result in a system which, while hosted like > the rest of the web, is not very "webby" and is the worst of both worlds. > > This led to the conclusion for us to package up trusted apps and to serve > their resources locally over a new app:// protocol. Later the app:// protocol also served other purposes like faster app loading. Kanru _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
