Is this worth implementing?  I'm not sure we want to add throwaway code in net/ for this, as this will have to be done completely differently through the network service APIs.

#1: Well, we document that it works, and FTP support still exists in Chrome, so we should do what we say. I found this bug while implementing an extension to block FTP or upgrade it to HTTPS. So for my particular use case, this bug is actually security-relevant.

If it's easier to remove FTP support, well, I'm all in favor of that, as you know. :) But unless and until we do that, the WebRequest API should work as documented (and for all web resource request types).

I'm not arguing it's not worth implementing, I'm just not sure we want to add the infrastructure to support it until extensions are hooked up using the URLLoader API.  Hooking up something twice requires more time, and adds more attack surface area in the meantime (And is particularly likely to get a less careful review, since it's code that will likely be gone within a year).

We should at least update the documentation. Who owns that?

(If it isn't worth wiring FTP up to extensions, is it work maintaining support at all? Can we just drop it on the floor? :) )

FTP is in maintenance mode, and we're not adding any features to it.  We'd love to remove it, but suspect usage is still much too high to do that.

~0.03% of downloads across ~0.08% of users over the last month, according to `Download.TargetConnectionSecurity`.

~0.003% of top-level navigations across 0.13% of users over the last month, according to `Navigation.MainFrameSchemeDifferentPage`.

Not huge numbers. Not tiny, but not huge. +lassey@.

It would be interesting to see what portion of that usage could be upgraded to HTTPS (i.e. with something like palmer@'s extension)