On 13-08-09 7:31 AM, Lloyd Hilaiel 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.
Prior art: the UI to the Firefox Health Report is delivered in this way.
Jelly is injected into a wrapper doughnut. about:healthreport
implements a containing iframe (the doughnut) into which
fhr.cdn.mozilla.net is loaded and the FHR data injected (the jelly).
The iframe and jelly communicate via a small postMessage API.
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).
I'm a fan of this approach myself, partly for the quick development
cycle and because I'm bullish on us A/B testing our interface in the wild.
But with FHR we ended up shuffling problems around. For example,
building mobile-friendly FHR jelly took about as long as building
desktop-friendly FHR jelly. There are UI issues -- we've had problems
with font sizing, reflow and zoom, event handling, AZPC scrolling
inconsistencies, and misleading back button handling on Android -- but
my assertion is that these can be satisfactorily addressed.
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.
This seems misleading to the point of obfuscation. The "only [desktop]
client work" will be to actually do the auth dance and create an Account
and all the other related setup. (On Android, there's a good deal of
plumbing to create and manage the Android Account: no jelly that is in
any way /secure/ is going to let us rev the interesting bits. It is
technically possible to allow the jelly to call Java directly via the
JNI, but forget that I mentioned it.)
If we have the jelly do the auth dance (and return some set of tokens to
the client?), then I think we're changing the TOFU + SRP security model
of the auth server pretty significantly. But I suppose such issues are
well enough understood from the Persona shim case that we'd be
comfortable having served jelly handle user passwords? I'm scared.
Also, now we have a versioning problem on two axes. The client version
and the server version have to agree. So now all of our jelly-wrapper
messages need to be versioned.
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?
One complexity reason we might not want to pursue this is that while
Persona has essentially zero persistent state, and it surfaces
essentially no interface for the user to manage that state (IIUC: it
knows an email and some keys, but AFAIK the user can't change the one
and never even knows of the keys existence). On the other hand, your
Firefox Account will have a great deal of persistent state and we are
trying to surface quite a bit of it (what's syncing, what other devices
are in your constellation, if, when, and what those devices are syncing,
...). The interface to the wrapper for all that is significantly more
complicated than just "jelly, give me an email and password". If we're
not going to manage settings with the jelly, this just got a lot smaller
and less attractive (since we're still going to build quite a bit of
platform-specific UI).
One "working reality" reason is that we just introduced a blocking
dependency for each client team, and yet another ops dependency.
One "pessimistic" reason is that we still don't have any experience with
this approach for Persona on desktop or on Android. FirefoxOS is it's
own special snowflake, with an operating cadence totally different from
the rest of Firefox. Revving UI is nice, but the actual backend fixes
will ride the trains like everything else.
Sorry for the less-than-focused brain dump,
Nick
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
