Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-18 7:22 AM, Mike West wrote:

On Thu, Mar 17, 2016 at 10:04 PM, Justin Dolske  wrote:


On 3/14/16 3:01 PM, Martin Thomson wrote:

The actual benefit is something that is only realized once a site puts

in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.



This is the key issue, IMO, which makes me not interested in having
Firefox implement this API.



My understanding of the objections Martin and Matt have outlined are that
they're not interested in _this spelling_ of the API, and would prefer that
it be spelled using `requestAutocomplete`.



Far too many sites either simply don't care about user password management
(ie, they do problematic things that could easily be fixed), or actively
take steps to intentionally break password managers. In the past we
considered this an advocacy/evangelism problem, and it was deemed the
site's responsibility to play nice. That's worked poorly, and sucks for
users. We now believe that we have to assume a adversarial environment:
it's our job to serve as the user's agent and do whatever it takes to work
on a site.



Sure. Heuristics should continue to work, and I agree 100% that they should
be aggressive enough to trigger on sites that are actively disinterested in
allowing password managers. I don't see that as being at odds with allowing
a site to explicitly integrate with the user's password manager if they
decide to do so.

With the explicit understanding that I don't work at Mozilla, and that
y'all's prioritization is very much yours to set, this sounds like a good
argument for investing effort in those heuristics. It doesn't sound like an
argument against accepting the contribution that Axel is offering.


Coupled with what Justin and Martin said above about adoption (which I 
also expressed), I don't see how it makes sense for us to add more 
complexity to that system. If this was a replacement or alternative to 
the heuristics (like it would be if built on rAc) then it makes more 
sense (rAc is mostly independent of the password manager heuristics) to 
pursue but that's not how I see the interaction with the current spec 
and password manager.



If there's interest in assisting sites that want to play nice, I think it
would be better to start with documenting a set of cross-browser "best
practices" that they can follow, for the standards and implementations that
exist today.



I agree that we should do this regardless.
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
exists, for instance, and I'm sure Mozilla has a similar page somewhere.
Perhaps it would be worthwhile to collaborate on something more visible?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Justin Dolske]

On 3/14/16 3:01 PM, Martin Thomson wrote:


The actual benefit is something that is only realized once a site puts
in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.


This is the key issue, IMO, which makes me not interested in having 
Firefox implement this API.


Far too many sites either simply don't care about user password 
management (ie, they do problematic things that could easily be fixed), 
or actively take steps to intentionally break password managers. In the 
past we considered this an advocacy/evangelism problem, and it was 
deemed the site's responsibility to play nice. That's worked poorly, and 
sucks for users. We now believe that we have to assume a adversarial 
environment: it's our job to serve as the user's agent and do whatever 
it takes to work on a site.


If there's interest in assisting sites that want to play nice, I think 
it would be better to start with documenting a set of cross-browser 
"best practices" that they can follow, for the standards and 
implementations that exist today.


I'd also note that Mozilla Labs tried going down a similar path in the 
past, with Account Manager -- see 
https://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/. 
The team involved in that did a _lot_ of outreach with sites and web 
developers. I remember it as having a somewhat tepid reception... 
Especially around sites not wanting to cede any UX control to the 
browser in the signup/login/logout experience, and some industries being 
very disinterested doing anything beyond what was mandated by 
regulations (ie, they saw doing anything outside their rulebook as 
adding legal risk).


Justin


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-14 2:29 AM, Mike West wrote:

On Thu, Mar 10, 2016 at 9:07 PM, Ben Kelly  wrote:
I believe Matthew Noorenberghe had some concerns about the necessity of the

API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.



I agree with MattN that a rAc-style API is a reasonably good fit for
signing up for a new account on a website*. Sign-up forms often encompass a
variety of kinds of information, and layering something on top of existing
forms and autocomplete attributes sounds like a way of providing all of
those bits and pieces at once, rather than having 15 calls to a APIs that
hand them out piecemeal.


Given that, do you think it makes sense to have a separate API for login 
when there is overlap with rAc as well?



With some caveats around XSS protection, I think that rAc could work for
signing-in with passwords. I guess it could work for signing in with
federations, though I think it starts to break down pretty rapidly. I don't
think it would work for any other potential uses of the API. `store()`, in
particular, is more or less the opposite of rAc and seems valuable
(especially for federations, but also for passwords), and FIDO is a good
example of a set of proposals that seem to entirely require additional
interaction above and beyond filling a form. I haven't seen a
counter-proposal for those pieces.


You're convinced me that an imperative method for saving (local) 
credentials is useful but I don't think we need new interfaces and 
objects surrounding it when we have the autocomplete values. See 
https://github.com/w3c/webappsec-credential-management/issues/13



I'm inclined to continue pursuing this more imperative proposal, as it
seems flexible enough to support the use cases we know we have today, and
those we'll discover in the future. The developers I've spoken with see the
API as an improvement and have been able to layer it on top of existing
sign-in systems with minimal change to their authentication backends
(which, as probably won't surprise you, are _always_ the oldest,
least-well-understood, and most fragile bits :) )**. I think it's worth
exploring.

-mike

* I also agree with him that sign-up is an important use-case, and that we
should do the work to support it. Anyone interested in working with me on a
draft proposal for what that might look like?


This is already specified in the requestAutocomplete[1] section of the 
HTML specification so I think it's probably (close to being?) ready to 
implement already. The other part for XSS protection is @writeonly[2] 
which can be added to the HTML spec. I'm not sure what else you have in 
mind but I can try help.


Matthew

[1] https://html.spec.whatwg.org/#dom-form-requestautocomplete
[2] 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-10 12:07 PM, Ben Kelly wrote:

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.


Axel was already on a thread about this concern before sending out the 
intent to implement so I'm not sure why this intent was sent out a day 
later when the concerns weren't yet addressed.


Matthew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.

On Mon, Mar 14, 2016 at 8:02 PM, Mike West  wrote:
> 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.

Maybe it's a value thing, I don't see that gold-plating this
experience is going to make a difference commensurate with the cost.
The fetch API changes are the core of the purported benefit, and that
turns out to be a non-trivial thing, with the added cost of indefinite
support for a feature we don't really want in support of a mechanism
that isn't that great.

The actual benefit is something that is only realized once a site puts
in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Mike West]

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  wrote:

> On 12 Mar 2016 7:28 PM, "Anne van Kesteren"  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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

Now that is a frightening observation. Is this creating a more persistent
(pernicious?) tracking mechanism?

In that case, credentials stored by a site should last no longer than
cookies. Credentials created by a user maybe can live longer.
On 12 Mar 2016 04:41, "Anne van Kesteren"  wrote:

> On Fri, Mar 11, 2016 at 6:08 PM,   wrote:
> > That does raise the question, however, of how such a credential differs
> from, say:
> >
> > * A cookie
> > * A random nonce in localStorage/IDB
> > * A non-extractable WebCrypto key
>
> The idea is that these are all less persistent. When you clear
> storage/cookies, you don't delete password manager entries. (Which is
> also why store() requires UI, if I remember correctly.)
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

On 12 Mar 2016 7:28 PM, "Anne van Kesteren"  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)

> > 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.

> 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?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Anne van Kesteren]

On Sat, Mar 12, 2016 at 3:48 AM, Martin Thomson  wrote:
> Now that is a frightening observation. Is this creating a more persistent
> (pernicious?) tracking mechanism?

It should be identical to password manager integration.


> 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 we think this API should have no more power than storage/cookies,
there's not much point in having this API. A site could then simply
remember the federation provider itself, and such, and lose it
whenever the user is done with the site (or has visited enough other
sites).


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Anne van Kesteren]

On Fri, Mar 11, 2016 at 6:08 PM,   wrote:
> That does raise the question, however, of how such a credential differs from, 
> say:
>
> * A cookie
> * A random nonce in localStorage/IDB
> * A non-extractable WebCrypto key

The idea is that these are all less persistent. When you clear
storage/cookies, you don't delete password manager entries. (Which is
also why store() requires UI, if I remember correctly.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Axel Nennker]

Am Freitag, 11. März 2016 05:27:34 UTC+1 schrieb Martin Thomson:
> On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker  wrote:
> > no password generation help by the UA
> 
> I agree with MattN here, not doing this eliminates much of the
> advantage of having a password manager.  Or do you have a plan to rely
> on sites doing that with CredentialContainer.store()?  That doesn't
> sound optimal to me.

The questions is whether password generation should be part of the standard.
The login manager / Firefox can still add password generation.
I am not per se against adding password generation to the standard but there 
should be a PR that WebAppSec agrees on quickly. Support by major / popular 
sites would help. I fear that a 
password-complexity-and-renewal-policy-description-language is something that 
grows out of hand easily.
The spec should focus on simple-and-useful features.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Martin Thomson]

On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker  wrote:
> no password generation help by the UA

I agree with MattN here, not doing this eliminates much of the
advantage of having a password manager.  Or do you have a plan to rely
on sites doing that with CredentialContainer.store()?  That doesn't
sound optimal to me.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Ben Kelly]

Thanks for taking this on Alex!

I had some initial concerns with the API from a fetch/SW perspective, but
Mike seems open to addressing them:

  https://github.com/w3c/webappsec-credential-management/issues/11

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.

Thanks again.

Ben

On Thu, Mar 10, 2016 at 1:56 PM, Axel Nennker  wrote:

> Summary: This API is enabling a website to request a user's credentials
> from a user agent, and helps the user agent to correctly store user
> credentials for future use. It helps the LoginManager to get rid of most of
> the heuristics.
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156047
> Link to standard: https://w3c.github.io/webappsec-credential-management/
> Platform coverage: Desktop first, every platform that today has
> LoginManager
> Current code is here: https://github.com/AxelNennker/firefox_credentials/
> Estimated or target release: spec is still work in progress
> Preference behind which this will be implemented: not implemented yet
> DevTools bug:
> Suggested Additions: none, minimal viable API e.g. no password generation
> help by the UA. Federated Identity support is probably removed in the next
> version.
>
> Intend to ship in Chrome:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7ouLjWzcjb0
>
> Web designer / developer use-cases: examples are in the spec
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform