- From: Eduardo' Vela\ <evn@google.com>
- Date: Thu, 16 Oct 2014 01:31:59 +0200
- To: whatwg@whatwg.org
Yea the keyup/down/press restrictions are definitely not useful, at least for password protection since the user has clearly no way to know if the field is safe or not. The tainting is never gonna work reliably and consistently as Michal hinted (say, a blob: URL would run in the same origin but not be bound to CSP which could be used to exfiltrate the data). The dependency on CSP also makes this a bit aspirational. I can agree that the login form could be CSP protected but the whole origin is not as likely. Specially for connect- and form-. And even that might be insufficient (its a common practice to echo back typed passwords when the user doesnt answer a captcha or has it wrong, for example - a same-origin XHR will leak the password). There are other solutions that seem more likely to work to solve the problem of password managers (something like a synced channelId, for example, or even FIDO style solutions). This proposal seems to try to achieve a mixture of just replacing canary values at the network layer based on destination with an httpOnly-style model for user-supplied data. If we have a password manager and are gonna ask authors to modify their site, we should just use it to transfer real credentials, not passwords.. Passwords need to die anyway.
Received on Wednesday, 15 October 2014 23:32:28 UTC