Hey folks! Glad to see that there's interest in this API from Mozilla. :) On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson <[email protected]> wrote:
> On 12 Mar 2016 7:28 PM, "Anne van Kesteren" <[email protected]> wrote: > > It should be identical to password manager integration. > > But it is not, though I suppose that a password manager might be > exploited to store state. I hope that isn't possible... (note to self, > attempt this attack) > Credential managers guess at a user's username and password, and ask the user if they'd like to persist that information. It's generally stored outside of "site data" (cookies, localstorage, IDB, etc), and users generally treat it differently (anecdotally: ~12.9% of Chrome's users who've opted into sharing usage data cleared cookies in the last week; ~2.7% cleared passwords). I think this distinction is pretty much in line with user expectation. This API offers a few things that the status quo cannot: Imperative certainty about the data being persisted as opposed to heuristic guessing, XSS mitigation, federation hints, and automatic sign-in for users who have done whatever dance the UA requires to enable such a feature. I don't believe, however, that it offers additional tracking capability above and beyond the (quite intentional) capabilities inherent in a credential manager. Sites are not granted any ability to persist data without user knowledge; they are only granted control over the timing of the prompt, but the prompt itself is still required. Nor are sites granted the ability to read data without user knowledge; users are either directly involved in handing credentials over to a site, or they grant the UA permission to hand credentials over. As we add more credential types (FIDO, etc), we'll certainly need to ensure that we don't introduce privacy footguns, but I think we're capable of maintaining that dicipline. > > > In that case, credentials stored by a site should last no longer than > > > cookies. Credentials created by a user maybe can live longer. > > > > How do you distinguish the two if the access is through a UI-mediated > API? > > If credentials created in response to a `get()` call are stored at the > point they are created, you could treat calls to `store()` very > differently. Maybe. If the intent is to use a password manager, see > Richard's earlier mail. > I'm not sure, but it sounds like this is based on some misunderstanding of what the API offers. Does the above description ease your concerns? Or am I missing the critique? > > If we think this API should have no more power than storage/cookies, > > there's not much point in having this API. > > Yes, the source of my concerns, right there. Sure, the fig leaf might > allow us to convince ourselves that we aren't creating a tracker that > trumps the rest. > > If we are creating something that is somehow greater out of the framework > this provides (FIDO), then that is useful. But the stepping stone we are > being offered on that path looks suspicious. Why not go straight for the > real prize? > Websites use passwords today. While I agree that we can and should be working on something better, I don't think that we should overlook small improvements in the status quo. We can give users a better experience on their favourite sites if we allow developers to bypass status quo heuristics, and we keep users safer if we mitigate some of the XSS risks of password managers today. I think this API does both, and is worth experimenting with to see if it's a framework we can build upon. -mike _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
