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
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,
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:
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
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,
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
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"
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
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
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.
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.
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
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
13 matches
Mail list logo