- From: Patrick Toomey <ptoomey3@github.com>
- Date: Wed, 21 Feb 2018 07:44:32 -0700
- To: John Wilander <wilander@apple.com>
- Cc: Jochen Eisinger <eisinger@google.com>, Craig Francis <craig.francis@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-Id: <3F2FF2F3-5742-4B58-9572-060A552D6699@github.com>
Just wanted to give a +1 to John’s comment. We (GitHub) will implement it at some point, but our excitement/priority dropped a bit when we found out that this part of the spec was likely not being pursued. > On Feb 20, 2018, at 10:06 AM, John Wilander <wilander@apple.com> wrote: > > > On Feb 20, 2018, at 8:33 AM, Jochen Eisinger <eisinger@google.com <mailto:eisinger@google.com>> wrote: > >> I left TPAC with the impression that there was no implementor interest. Has this changed? > > We lost much of our interest due to the change where credentials are now exposed to JavaScript. In our view, there is not enough security or enduser benefit compared to heuristic auto-fill unless managed credentials are significantly harder to exfiltrate. > > Regards, John > >> >> John Wilander <wilander@apple.com <mailto:wilander@apple.com>> schrieb am Mi., 14. Feb. 2018, 01:02: >>> On Feb 13, 2018, at 2:21 AM, Craig Francis <craig.francis@gmail.com <mailto:craig.francis@gmail.com>> wrote: >>> >>> I believe Mike West has done some work related to this: >>> >>> http://mikewest.github.io/credentialmanagement/writeonly/ <http://mikewest.github.io/credentialmanagement/writeonly/> >>> >>> Personally I'd love to use the @writeonly attribute on other fields as well - e.g. hidden input for a CSRF token; or applying it to to all fields when JavaScript does not need to touch the data. >> >> Thanks, Craig! >> >> Mike, do you intend to incorporate write-only elements in CM? Would they be required for CM to work or would they be opt-in? >> >> Any other thoughts on this issue? >> >> Regards, John >> >> >>> >>>> On 13 Feb 2018, at 05:21, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote: >>>> >>>> Hi again WebAppSec! >>>> >>>> Not exposing credentials under Credential Management to JavaScript was discussed briefly at TPAC. Both Apple and Mozilla raised concerns. >>>> https://www.w3.org/2017/11/06-webappsec-minutes.html#item06 <https://www.w3.org/2017/11/06-webappsec-minutes.html#item06> >>>> >>>> Since then we’ve learnt more about trackers exfiltrating credentials in the wild: >>>> https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/ <https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/> >>>> >>>> … and web analytics accidentally exfiltrating passwords: >>>> https://techcrunch.com/2018/02/05/mixpanel-passwords/ <https://techcrunch.com/2018/02/05/mixpanel-passwords/> >>>> >>>> In addition, several of us are debating the dangers of non-SRI 3rd-party scripts on the Twitters. >>>> >>>> In light of these things, I would like to revisit the decision to expose credentials under Credential Management to JavaScript. If we could block them we could offer safer and more convenient logins than today. How do we get there? >>>> >>>> Regards, John >>> >>
Received on Thursday, 22 February 2018 01:45:29 UTC