Intent to deprecate: Legacy subresource requests.
Mike West
bcc:net-dev
Primary
Summary
I'd like to block two kinds of subresource requests from webby documents:
1. Subresources with an "legacy" scheme (e.g. "ftp://my-awesome-ftp-server.com/yay.tiff")
2. Subresources with credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff").
Motivation
1. Removing FTP subresources from webby pages would enable us to extract FTP support out of Chrome, handling top-level FTP requests via some other mechanism (Chrome app. protocol handler, etc). Given the low usage, and the code we could remove, this seems like a sizable win.
2. Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. This is especially the case for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.
Compatibility Risk
This effects ~0.003% of page views. The impact would depend on the resource being loaded: best case, an image would be broken. Worst case, script wouldn't load and a page would be broken.
Alternative implementation suggestion for web developers
1. HTTP(S).
2. Cookies.
Usage information from UseCounter
Legacy schemed subresources are hovering around 0.0025% of page views[1]. Credentialed subresources are closer to 0.0033% of page views[2]. This potentially undercounts the enterprise, where I expect this sort of thing to be marginally more common.
I need to keep an eye on those numbers, though; they're both new in M39, and are displaying weird behavior this week. They were both around half where they currently are when I initially poked at folks internally about this topic. :/
[1]: https://www.chromestatus.com/metrics/feature/timeline/popularity/531
[2]: https://www.chromestatus.com/metrics/feature/timeline/popularity/532
Entry on chromestatus.com, crbug.com, or MDN
Requesting approval to remove too?
I'm on the fence. I'd like to just drop support. However, I suspect we'll need to add a flag for some level of enterprise support. +Saswat and Drew for their thoughts.
Chris Bentzel
app. If one existed, it would allow Chrome to rip out the FTP logic in
Chromium (although other Chromium users may object). There's other
upsides too, such as sandboxing the FTP logic.
One of the sticking points is that the app could intercept main frame
navigations, but not handle subresources. Given the low usage of FTP
subresources, I think it's safe to deprecate that behavior and open
this up.
On Tue, Dec 9, 2014 at 2:31 PM, Mike West <mk...@chromium.org> wrote:
> On Tue, Dec 9, 2014 at 8:26 PM, Chris Palmer <pal...@google.com> wrote:
>>
>> On Tue, Dec 9, 2014 at 10:34 AM, Philip Jägenstedt <phi...@opera.com>
>> wrote:
>>
>> > We discussed this point in today's API owners meeting. Which bits of
>> > code could actually be removed? Is it by ripping FTP support
>> > completely out of Chromium, so that one cannot even follow a link to
>> > download something over FTP?
>>
>> Ideally (to me) yes, but then implementing FTP support as a Chrome
>> Extension for those people who need it.
>
>
> This is my understanding of Chris (Bentzel (CC'd))'s vague hand-waving.
> There's apparently a Chrome App that mostly exists that does FTP stuff.
>
> -mike
>
Matt Menke
>
> -mike
>
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CABJO0QJ%3DXMDJHQtLDY-d22q5A%3DJvHt43Bd%2BdS8Zo3HULmryOSw%40mail.gmail.com.