On Aug 19, 2013, at 11:21 PM, Karen Rudnitski <[email protected]> wrote:
> 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. Given the current direction and scope of our MVP, I don't think there is really any significant benefits to class A. We've got a tightly controlled environment that keeps a user's data in the realm of our three main products - desktop, android, and firefoxos. What I'm trying to understand is what constraints the current design puts on our future possibilities for integration with 3rd parties (apps, devices, web apps, etc). I am *not* trying to detract focus from milestone 1. lloyd > 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
