27516 2014-12-04 15:28:42 +0000 exposing passwords is a bad idea 2015-06-15 16:29:51 +0000 1 1 1 Unclassified WHATWG URL unspecified All All RESOLVED FIXED P2 normal Unsorted 1 rubys annevk julian.reschke karl+w3c mike rubys sideshowbarker+urlspec oldest_to_newest 115928 0 rubys 2014-12-04 15:28:42 +0000 This bug is opened on behalf of David Walp, based on http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0505.html Original comment: Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea. Based on received feedback, customers agree and I suspect our customers are not unique on this opinion. 115933 1 annevk 2014-12-04 15:41:25 +0000 This is how e.g. XMLHttpRequest implements the user/password arguments. Has Microsoft dropped support for these in ftp URLs too now or are they still not telling the whole story when giving feedback? 115935 2 rubys 2014-12-04 15:45:38 +0000 A concrete example of an intentional difference from the proposed standard: http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b IE intentionally raises an exception of somebody attempts to fetch the href from an <a> element if that element contains a password. 115936 3 annevk 2014-12-04 15:49:44 +0000 Nothing is fetched in that test right? You mean invoking href's getter? I don't think that should ever throw. I don't really see what attack that would protect against. 115944 4 rubys 2014-12-04 18:21:21 +0000 Ah, I should have avoided the word 'fetch' as it has other meanings in this context. :-) Yes, I meant invoking the getter for href on an anchor (<a>) element. Do you have an alternative to throwing an exception to suggest that meets the stated customer requirements? 115945 5 annevk 2014-12-04 18:33:38 +0000 Yeah, align with all the other UAs. I don't see the security problem. The password can also be retrieved through getAttribute(). 115949 6 rubys 2014-12-04 18:49:14 +0000 document.querySelector('a').getAttribute('href') does indeed expose the password with IE11. 115951 7 annevk 2014-12-04 19:26:12 +0000 Apologies to Microsoft for comment 1, that was out of line. The last time this was discussed in the context of XMLHttpRequest it turned out that username/password was not disabled for all URL schemes. And it wasn't clear what they were protecting against. That is why the URL specification aligned with the majority of implementations. There's definitely something to say for not handling URLs that username/password set in Fetch, at least for certain type of fetches, but that's a separate discussion (recently held on blink-dev). 116726 8 rubys 2015-01-02 10:22:51 +0000 This syntax is deprecated per RFC 3986 and RFC 7230. See: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13571.html At a minimum, URLs that contain a non-blank password should be considered a conformance error. 116727 9 karl+w3c 2015-01-02 11:38:39 +0000 Probably related, but maybe it deserved a proper bug at Moz. https://bugzilla.mozilla.org/show_bug.cgi?id=479038 119233 10 rubys 2015-04-04 02:49:25 +0000 Related: https://support.microsoft.com/en-us/kb/834489 121001 11 annevk 2015-06-15 15:21:27 +0000 So yeah, if we want to match the RFCs we should make both username and password a conformance error. That seems very reasonable to me. 121003 12 annevk 2015-06-15 16:29:51 +0000 https://github.com/whatwg/url/commit/e0c721b680d0977013ef2a14ba578388c01bd331