In the prototypes we built, we've considered encryption as a way to protect transient data so it can be transferred safely between people. e.g. we're not thinking about apps like encrypted shared resources that would stay in that state "for ever".
So I made the assumption that if a password gets reset, people would have to resent the data. I agree it sucks tough, in terms of UX, since we would need to update the directory when this happens, and maybe have all the apps do something special. That's what is currently happening when you loose your pgp key and people are still sending you e-mails using it, and that's why open pgp users directory evolved into sks services so deprecated keys would be less present on the web. On Fri, Dec 19, 2014 at 12:48 AM, Ryan Kelly <[email protected]> wrote: > > On 19/12/2014 10:42, Christopher Karlof wrote: > >> On Thu, Dec 18, 2014 at 3:45 AM, Tarek Ziade <[email protected] >> <mailto:[email protected]>> wrote: >> >> Following up yesterday discussions on encryption key, I've started >> to prototype a "Key Directory" service. >> >> The goal of the service is to allow people to discover other >> people's public keys in the context of a 3rd party application, in >> order to be able to do end-to-end encryptions of app data. >> >> The two use cases we have in mind are: >> >> - The password manager >> - A file sharing application >> >> If users are collaborating on something encrypted, then key(s) used to >> encrypt that thing need to be stable. If users lose a shared resource >> because someone reset their password, that is bad. >> >> This makes me wary about using kB for any part of this infrastructure, >> although we might find a way. >> > > Conversely, some users may see using kA as little better than using no > encryption at all. > > Perhaps we will eventually need to revisit the user-choice option here, > allowing each user to choose between recoverability and security/paranoia. > But that's a very wriggly can of worms. > > > Ryan >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
