Re: Not expose credentials under Credential Management to JS?

> On Feb 13, 2018, at 2:21 AM, Craig Francis <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
>