>From previous discussions when we initially settled on class B several months ago, that felt like a really good place as default for most of our data types. Like the others are asking, What's the benefit of moving it to class A? This will help me understand the pros / cons of changing our recommendation from a while back.
Thanks, Karen -----Original Message----- From: Sync-dev [mailto:[email protected]] On Behalf Of Chris Karlof Sent: August 16, 2013 7:24 PM To: Lloyd Hilaiel Cc: [email protected] Subject: Re: Reducing the security of class A data On Aug 12, 2013, at 6:55 AM, Lloyd Hilaiel <[email protected]> wrote: > Now that some of the other challenging threads have died down, let's have another one. > > As I think deeply (at least as deeply as I am capable of) about how users will log into different firefox products, and how we can really achieve a high level of integration, I am reminded just how challenging this problem is. I'm at the point in my meditation where I have distilled things down to a single most important question. > > What are the cons of reducing the security of recoverable class A data such that it could be accessed with a persona assertion asserting ownership of the email address stored in your account? > > Note: > I realize that we've taken some shortcuts in email verification, and that a verified email address in firefox accounts isn't as rigorously verified as one in persona. Ignore that for now. Think just about the security delta from competing products and our current design. > > /me braces self > lloyd > Why do you want to do this? Federated access to your FA? In our current plan, you need your FA password to access your class A data, but anyone that can access your email can also access class A data via the "forgot password" flow. Anyone that can access your email can also get a BrowserId assertion for you. So allowing BrowserId assertions for primary access to class A data is nearly equivalent to the current plan. We lose the ability to track failed login attempts, etc. What's the use case? -chris _______________________________________________ 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
