Taking the liberty to cc the group in reply, because I think this is important to talk about.
> ozten & jedp. Does this assessment match your experience with FirefoxOS? Is > there anything from Native persona ffx explorations or Firefox OS that would > be reusable here? > (I want to open a web container from chrome code and map in some functions, > basically.) Oh yes. The recipes have minor differences on FirefoxOS from Desktop Firefox, but the principles are the same. We have various ways at our disposal to do just what you're asking: open a web container from chrome code, sandbox it, map in functions, or inject tentacles into it, or postMessage to it. (You're showing me that it's time to blog and document these things! :) And I want to second your assessment in your previous message of the value of the design on FirefoxOS. (And I can do this with sincere admiration because, though I've spent a lot of time working on it, the core architecture was Ben Adida's idea.) A certain native footprint was necessary in order to interact with the Trusted UI and to provide a way for Persona to function across apps and browsers in the face of FirefoxOS's data siloing. But we've been able to keep this footprint very small. No footprint is not an option, but I think it can be smaller yet. Having a minimal footprint on the client and serving our content and code from persona.org has given us tremendous and invaluable flexibility for adapting to feature requests, fixing bugs, flowing with new UI, keeping prior versions of the device up to date, and just iterating fast. Want to talk about identity bridging (gmail, yahoo)? I don't even want to think about the tearing of hair and gnashing of teeth if we had to let native devices somehow behave differently. It was even possible (though with no small amount of pain), to use a CNAME change to perform the most awesome OTA ever - a complete replacement of the Persona service operating on the device with no user impact, and greatly minimizing the impact of FirefoxOS on Persona's train schedule. So yes, this architecture has saved our buns on more than one occasion. Furthermore, as Chris Karlof has said elsewhere, having a single team devoted to the auth system (Persona, in this case, though his analogy was drawn from Google's services) is a good thing - there are not duplicate copies of the logic residing in other teams' code bases, which would just be a recipe for inconsistent features and UI, weird bugs, unevenly-applied security fixes, and widespread sorrow. This may not always be possible to achieve (Android, for example, poses some challenges); but it's worth striving for. +1 to your request to draw a "clear line" between client and cloud, articulating the "tiny contract" (I like that) between the native codebase and the service through the API boundary. Speaking strictly of FirefoxOS here, and not so much Desktop in this case, I think there's also a call to action to do just this. The device is made of the web (with love!). The Persona architecture on FirefoxOS is (I think) exemplary of this ideal. Cheers! Jed (on PTO this week - apologies in advance for email silence) ----- Original Message ----- > From: "Lloyd Hilaiel" <[email protected]> > To: "Austin King" <[email protected]>, "[email protected] Parsons" > <[email protected]> > Sent: Friday, August 9, 2013 8:02:10 AM > Subject: Re: Implementation approaches for Create Account / Sign In > > ozten & jedp. Does this assessment match your experience with FirefoxOS? Is > there anything from Native persona ffx explorations or Firefox OS that would > be reusable here? > > (I want to open a web container from chrome code and map in some functions, > basically.) > > lloyd > > > On Aug 9, 2013, at 5:31 PM, Lloyd Hilaiel <[email protected]> wrote: > > > Chris Karlof and I were talking yesterday, and I was noting how awesome the > > implementation approach of Persona on FirefoxOS has been. The, the > > relevant code that ships with the device is limited to a container capable > > of running web content, and some setup code which invokes a function > > within the context of that web content when necessary. Further, the > > navigator.id. apis are intercepted by firefoxos, and cause raising of the > > "trusted" content window and relaying parameters into it. > > > > All of the code inside the persona dialog is still loaded live from our > > servers. > > > > This approach has saved us a number of times, and is the thing that allows > > us to fix issues related to persona or roll out changes that land on all > > firefoxos devices instantly. The other nice thing that this does is > > provide a tiny contract between the firefoxos codebase and persona (both > > of which are still very dynamic at the moment). > > > > So as I look at the UX mocks that we need to implement, I wonder why we > > wouldn't use the same approach here? Namely, the "setting up sync" window > > could be entirely implemented in HTML, and the only desktop client work > > would be to raise a container. > > > > We could still get native key stretching by mapping a couple functions into > > that environment, and the client could use them if available. > > > > Is there any really good reason not to explore this option? > > > > Gavin / Dolske, how would you guys react to this approach as a way to draw > > a clear line between the client and the cloud and accelerate this thing? > > > > lloyd > > _______________________________________________ > > Sync-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/sync-dev > > _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
