I would like to propose that we can get the equivalent of a packaged web-app without actually packaging all the content. If the manifest includes a list of components of the web app (the javascript, html, css, possibly more if needed), and a signed hash for those pieces (either in aggregate or individually), then we have the equivalent. The web app can be verified as being the same as the developer created and the individual pieces are still loaded just like a normal web app. If the manifest itself has a signed hash (signed by a trusted source), then it can include a permissions section of a priori granted permissions. The manifest can also specify chrome or not. The web app itself can specify whether caching of the app occurs itself. Web apps can cache and be usable when not connect or not cache and require internet access. It is up to them.
Thus a web site can provide it's content as normal, getting no special treatment. A web site can provide a manifest, which verifies that the content is as a site intends (and maybe gives it a little more permissions if it makes sense). Or a web site can provide a trusted source 9store) signed manifest and get further permissions. On Mar 16, 2012, at 9:08 AM, Ben Francis wrote: > tl;dr: Devices ship with pre-installed apps (including app store apps) > which already have permissions granted to them by the device vendor, the > user can review and revoke these permissions if they wish. Web apps are > only web apps if they're written with web technologies and hosted on the > web. In the interests of working towards a web standard, we should follow > the existing model of Google Chrome Hosted apps with three key differences > proposed by the Open Web Apps team which make the model more open. Updating > Gecko and the kernel are outside the scope of Open Web Apps. > > On Fri, Mar 16, 2012 at 4:33 AM, lkcl luke <[email protected]> wrote: > >>> "A telco can decide which stores to implicitly trust on their devices" - >>> what does this mean? >> >> i've updated >> https://wiki.mozilla.org/Apps/Security#Distribution_.2F_management_of_WebApps >> to provide an analogy which helps illustrate. >> > > OK, so as I said above: > > "A device may ship with one or more app store apps which have permission to > install and un-install Open Web Apps." > > This is an explicit permission granted by the vendor on behalf of the user > for pre-installed app store apps to have permission to install and > un-install apps. The user can review and revoke this permission if they > wish so it isn't implicit, just a permission like any other permission. > > yes.... yet... conceptually, think "what if that https:// link was to >> a web app and the file extension of that web app was '.deb' or '.ipk' >> or '.rpm' "? it's an https link, right? therefore it's a "web app"? >> > > .exe files can be served from an HTTP URL too and they're not web apps. > Equally just because an app is written using HTML, CSS and JavaScript, that > doesn't make it a web app either. > > In my view an app is only part of the web if it's written using web > standards (HTML, CSS and JavaScript) and each of those resources can be > addressed with a URI over HTTP. > > I believe WebOS, Windows 8 Metro, WAC and Webinos apps are all written > using web technologies, but I wouldn't class any of them as open web apps > because as I understand it they're packaged, not hosted. Once they're > downloaded they're no longer part of the web. > > If we're looking for an established model for installable web apps, our > friends at Google have a working implementation of an app store for hosted > web apps and a secure browser they can be installed on. Chrome Hosted Apps > are written in web technologies and hosted on the web > http://code.google.com/chrome/apps/docs/developers_guide.html > > The Open Web Apps team has proposed a model very similar to the Chrome Web > Store model with three important differences: > > 1) There shouldn't just be just one web app store run by one corporation, > anyone should be able to run their own web app store and users should be > able to install apps from stores they trust, without the intervention of > Mozilla or anyone else. > 2) Web app developers should be able to list their web apps in multiple app > stores and even host their own apps on their own web server and have a > direct relationship of trust with the user. > 3) The JSON app manifest and referenced icons should be hosted on the web, > rather than packaged in a funny proprietary zip-like .crx file - note that > Google is actually also now proposing to make this change themselves, to > make projects like Mozilla's Apps project easier! > http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html > > With a view to creating an open standard for installable web apps, my > opinion is that we should concentrate on a model as close as possible to > the one already implemented by Google, but concentrating on these three key > differences (which are themselves potentially very distruptive and have > plenty of challenges of their own). > > :) >> >>> * A web site which hosts an app manifest which provides a name, >>> description, icons and lists permissions the app may ask for >> >> all of these things can be covered by .deb or .rpm (not sure about >> .ipk it's a bit simplified) >> > > Probably, but that doesn't mean they'd make a very good web standard. Both > of these are great packaging systems for native applications with great > dependency management. I don't think we need that much complexity. > >> == Types of runnables == >>> 0) None of the items listed here (drivers, cli tools, browser engine or >>> plugins) should be handled by Open Web Apps, but rather a separate >> process. >>> Out of scope. >> >> why is it "out of scope"? how should the B2G application (B2G the >> executable) be packaged and upgraded? what about the linux kernel, >> and other support infrastructure? whose problem is it to define the >> security and secure distribution of all those components? >> > > A "Gecko Updater" is on the B2G roadmap and I believe will allow Gecko to > be updated in a similar way to how Firefox is updated. > > I don't know how the Linux kernel and other system packages will be > updated, but this isn't a concern for Open Web Apps. Why would Chrome, > Opera or IE care about how B2G updates its kernel? We're talking about a > different level in the stack. > > however that's not to say that there is not room for *both* types - >> "apps" and "web apps" as you've distinguished them - is there? > > > No, in fact Google has both hosted and packaged apps in the Chrome Web > Store. My personal opinion is that packaged apps are bad for the web and > that if we improve the hosted model (including app cache) we don't need the > packaged model at all, but if people at Mozilla want to work on packaged > apps too then there's nothing to stop them. An open packaged model is > better than a closed one. > > >> so in my mind, there's no difference between "remote web app" as >> you've defined it and "just an app" as you've defined it, once you've >> created that uri type "apt://" or "yum://". you see what i'm saying? >> > > A Microsoft Word document downloaded over ftp:// isn't a web page, so why > would a Python application downloaded over apt:// be a web app? > > >> >> plus, yeah, crucially, some apps may require upgrades of other >> functionality (dependencies) - how would a "remote web app" keep >> everything up-to-date if it's not hooked into a proper dependency >> management system? >> > > The only dependencies between web apps I know of are solved by web services > over HTTP. > >> Surely there should be no central authority for permissions requests other >>> than the user? >> >> ah - yes. but are the users technically competent to evaluate the >> safety of the code? no, they're not. they haven't got time. so >> whilst the word "permissions" is the wrong word to use, the concepts >> in this section are still kinda sound. >> > > To be honest, other than verifying that an app developer is who they say > they are and displaying this verification in the app description, I'm not > sure how feasible it is for the app store to verify that a web app (which > has a server-side component) is safe without having full access to the > entire source code of the app and checking every change that's made to that > source code. I could be wrong but this seems to me to be more of a > contractual issue of trust between the owner of the store store and app > developers than a technical one. > > Ben > > > -- > Ben Francis > http://tola.me.uk > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
