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-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
