I <3 this thread. Distillation attempting not to discount: 1. setup UI in content isn't crazy, there are a lot of benefits and plenty of precedent A: yay!
2. we're worried about more ops dependencies A: If we make it part of the bridge, then we add no new ops deps. We already will do this on FirefoxOS. 3. can we make it feel trustworthy and fit the environment? (UX) Q: Open device specific question - needs skinny's input. 4. what is the extent of the content's responsibility? More than just auth gets sucky. A: It's just auth. More than just auth gets sucky. Preferences and mgmt are "native". 5. Security loss. (proposed) A: Authing from content is inevitable. Belief is there's no protocol sacrifices we need to make (full SRP from content is viable, stretching viable with native help). Phishing related concerns are all that remain mooted by the first sentence. 6. This could speed us up if done right. A: hell yeah! we've got gherkin and user tested mocks to start from, and a possibility to share code for client teams that want it. lloyd On Aug 9, 2013, at 11:50 PM, Brian Warner <[email protected]> wrote: > On 8/9/13 8:28 AM, Nick Alexander wrote: > >> 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. > > I'm worried about that too. It changes the security model, specifically > the "your class-B data is safe unless X happens" disclaimer, from: > > old X: You type your password into something other than good FF browser > chrome: either you use some web-content bridge, or somebody > pushes a doctored FF update to you (SSL attack during update, or > deliberate action by our servers), or compromises your computer > > new X: Old X plus: somebody gives you a doctored jelly page (SSL attack > during login, or deliberate action by our servers) > > A sufficiently paranoid user could protect themselves against a doctored > FF update by turning off auto-update, or comparing their browser > executable against their friends' copies (e.g. run Debian's version, > which has its own signed-update system, or use the ESR version your IT > department has approved). > > We don't currently have any way to protect against a doctored jelly > page. Firefox should have TLS cert pinning soon, which reduces the SSL > threat considerably, but doesn't remove the deliberate-action-by-Mozilla > vector. > > I recognize the decoupling/update benefits of the approach.. I'd be more > comfortable with it if I knew that is was temporary, and that our plan > was to bake the implementation into the browser ("absorb the jelly"?) > within a year or so. I suspect that won't happen, though, as the > benefits of dynamically updating that code are pretty compelling. > > cheers, > -Brian > _______________________________________________ > 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
