Great, I'll make sure to attend that session! :) Btw, do you know why the Calculator app is packaged? I unzipped it and pushed it to https://gaia-calculator.5apps.com/ and it seems to work identically, and it even sort of works in my desktop browser. (I also tried with the Clock app, but that relies on mozSettings and some other things).
Maybe we can use the Calculator app as a super-simple first test case to make it entirely offline-first and publish it hosted. Cheers, Michiel. On Fri, Dec 4, 2015 at 4:42 PM, Paul Theriault <[email protected]> wrote: > (was "Re: How to differentiate ourselves from everyone else”) > > Splitting this off because I think its important and I want to talk about > this. We’ve long talked about moving to a more ‘webby’ security model. My > team has been working to make our package apps more web like, but I > consistently hear that developers want pure web apps (no packages, no > signing etc). This won’t be possible for ALL gaia apps - the permissions > are simply to complex to expose to the web’s untrusted security model. But > I think its possible if we start talking about splitting gaia apps into > some hosted and some packaged. > > > > This is something I would really like to do with the new Music NGA app. > A true “web app” is something that should be able to run anywhere. However, > currently, this is not the case with our Gaia apps. The biggest roadblock > preventing this is our reliance on packaged apps and the security model. > Once we can finally move away from packaged apps towards *hosted* apps, we > will be much closer to having *real* web apps that can run anywhere. This > will also solve our problem with app updates as our Gaia apps could simply > be hosted on a public web server in the cloud where users receive live > updates like any other web app. We should have Service Workers available to > us in FxOS again soon, so our “offline” use case should be covered. So, I > *think* that means that the only thing really blocking us from > transitioning to hosted apps is the security model, right? > > Firstly let me say I completely agree with you. But “security model” is an > overloaded term. When you say hosted apps, you are talking about websites - > there is no difference from a security perspecitve. The security model for > hosted apps/websites is already well established - that is, content is > untrusted and APIs must be designed with this in mind. > > Compare that to privileged & certified apps: this model involves the > content being either signed or shipped with the device. i.e. the security > model is that the content is trusted, and can thus request additional > permissions. My point is that its a completely different security model. My > team is working currently to make this model ‘more webby’ but I that will > not get us closer to a “truly hosted” experience (but I think its still > very important, but solving a different problem). > > If you want a truly hosted Music NGA app, then we need to: > 1) reduce the permissions that the NGA (and certified only things like IAC > etc) > 2) make the essential APIs (e.g. device storage) safe enough to expose to > the web which involves > - creating a UX to allow users to safely grant access to music > files (or even allows pre-granting of the pre-installed music app) > - refactoring the deviceStorage API to make it safe > > 2 is challenging but I think its possible. There is a session this week > 5pm wednesday to talk about security & UX where I want to talk about some > ideas here for how we involve the user safely but I think we also need a > discussion around platform (who’s going to refactor the device storage API > to make it safe for web…?) > > BTW I know the TEF people had a go at refactoring the Music app to be > completely web. Im on a plane but I think there’s a thread on the old b2g > list about this which has more details. > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
