On 2016-03-14 2:02 AM, Mike West wrote:
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 <m...@mozilla.com> wrote:
On 12 Mar 2016 7:28 PM, "Anne van Kesteren" <ann...@annevk.nl> 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.
They only guess because authors don't know about or aren't using the
HTML autocomplete values to markup this information:
https://html.spec.whatwg.org/#attr-fe-autocomplete-username
One of my criticisms of this spec is that sites can already use these
attributes and form submissions so password managers don't need to use
heuristics for identifying login credentials so why do we need another
way of doing this?
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,
This could be built on top of <form> instead of creating new interfaces.
See https://github.com/w3c/webappsec-credential-management/issues/13 for
a proposal.
XSS mitigation,
I disagree that the status quo "cannot" (it simply "does not" IMO) as
I've explained in other threads how most, if not all, of these can
mitigations can be applied to <input>/<form> mostly using your
@writeonly proposal:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html
federation hints,
This is possible via new @autocomplete values too or could be its own
API and/or spec.
and automatic sign-in for users who have
done whatever dance the UA requires to enable such a feature.
This could also be implemented on top of <form>/rAc for local credentials.
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.
I agree there are ways to improve the status quo but I think there are
more incremental improvements like imperative storing of credentials in
a <form> (issue #13), support for @writeonly for XSS mitigation, and
promoting/improving requestAutocomplete for login/registration that are
less complex and more backwards-compatible.
Matthew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
