Hector Martin

So yeah, um, this is not okay. It is not discoverable and could easily leak sensitive information. Auth credentials even, seriously? Also Chrome does this too. And it is preserved across `mv` to another filesystem.https://twitter.com/gynvael/status/1077671412847046657 …

not that having a password in the URL would be a good security design anyway

This is how HTTP Basic authentication works. It's part of the HTTP URI standard. And wget is smart enough to hide the password when showing its messages on stderr, but then goes ahead and dumps it in the xattr verbatim.

You don’t need to support credentials in URLs in order to support basic auth. The credentials are placed in header fields in the HTTP get request.

Credentials in a URI is one (perhaps the only?) standard way for supplying the contents of that header field that is cross-application.

Microsoft disabled it in IE for security reasons, so it wasn’t all that cross-application. A standard rule of web development is never to put anything confidential in the URL because URLs leak all over the place. Browser history, for example.

The *point* of putting confidential information in the URL is to make it portable. So you can paste the URL into another app and it'll work. Yes, it's a tradeoff. But I don't expect the browser to deliberately leak them as non-discoverable xattrs on files.

RFC 3986 section 7.5: "URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies)."