Intent to deprecate: Legacy subresource requests.

[Mike West]

bcc:net-dev

Primary

mk...@chromium.org

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

https://crbug.com/435547

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.

WDYT, blink-dev@?

-mike

[Jochen Eisinger]

LGTM, ship it. Ehrm, remove it!

[Anne van Kesteren]

On Fri, Nov 21, 2014 at 2:49 PM, Mike West <mk...@chromium.org> wrote:
> 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").

Please file a bug on Fetch if this succeeds.


--
https://annevankesteren.nl/

[Justin Schuh]

I believe Tom briefly shipped #2 in the past, and may have some additional context to provide on why it was reverted.

[Philip Jägenstedt]

These sounds like very worthwhile changes, I hope it works out! As for the usage data, I usually wait until the top of the S-curve is clearly visible because it's hard to predict where it'll stop. Fingers crossed...

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Thomas Sepez]

While I'm in favor of both, I was unable to accomplish #1 the last time I tried, because the internet wanted to kill me for doing so.  While I firmly believe that if the internet isn't trying to kill us from time to time that we are not being aggressive enough, I'm not sure anything has changed that would allow us to go forward on #1.

Part of the story can be found on https://code.google.com/p/chromium/issues/detail?id=303046

[Thomas Sepez]

s#1/#2/.

[Mike West]

Holding off on this for the moment, as the numbers are still skyrocketing. :(

Looking more like ~0.008% of page views now, which makes me sad. I'll ping the thread again next week after the numbers have some time to level out.

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Mike West]

A weekish later, and the numbers have stabilized a bit:

1. Legacy subresources are hovering around 0.0075%[1].

2. Embedded credential subresources are hovering around 0.01%[2].

What say ye, OWNERS?

[1]: https://www.chromestatus.com/metrics/feature/timeline/popularity/531

[2]: https://www.chromestatus.com/metrics/feature/timeline/popularity/532

-mike

[Chris Harrelson]

Are you asking to deprecate or block? Also, is there good reason to believe this will overcome the problems Thomas mentioned?

Chris

[Mike West]

On Mon, Dec 8, 2014 at 6:40 PM, Chris Harrelson <chri...@chromium.org> wrote:

Are you asking to deprecate or block?

Certainly deprecate. Block if you'll let me.

 

Also, is there good reason to believe this will overcome the problems Thomas mentioned?

Yes. I'm meaner than Tom. :)

-mike

[Chris Harrelson]

On Mon, Dec 8, 2014 at 10:15 AM, Mike West <mk...@chromium.org> wrote:

On Mon, Dec 8, 2014 at 6:40 PM, Chris Harrelson <chri...@chromium.org> wrote:

Are you asking to deprecate or block?

Certainly deprecate. Block if you'll let me.

LGTM to deprecate but not remove yet.

 

 

Also, is there good reason to believe this will overcome the problems Thomas mentioned?

Yes. I'm meaner than Tom. :)

Meaning you expect the same use cases that were broken before to still be broken, but the benefits outweigh the costs?

 

-mike

[Philip Jägenstedt]

On Mon, Dec 8, 2014 at 7:15 PM, Mike West <mk...@chromium.org> wrote:
> On Mon, Dec 8, 2014 at 6:40 PM, Chris Harrelson <chri...@chromium.org>
> wrote:
>>
>> Are you asking to deprecate or block?
>
>
> Certainly deprecate. Block if you'll let me.

Definitely LGTM to deprecate.

SchemeRegistry.cpp tells me that the legacy protocols are ftp and
gopher. A quick grep in the httparchive data shows that 'ftp://' is a
much more common than 'gopher://', so these two removals need not be
coupled I think.

All instances of 'gopher://' that I found were in CSS selectors like
'a[href ^="gopher://"]' so immediate removal of the gopher case LGTM,
if you want to do it.

For ftp and credentials-in-url the usage is high enough and potential
breakage large enough that it's unlikely to be completely smooth, so
eventually trying those removals with flags seems like a good idea.

If you do some searching in Google's internal index or the httparchive
data, maybe you can identify the biggest sites that depend on this
stuff, and maybe fixing only a few will see usage drop to a point
where removal is trivial. Worth a shot?

Philip

[PhistucK]

Credential bearing links are/were very common in file search sites, where they point to some sort of private FTP (IP addresses) URLs with credentials to download a file (MP3, for example).

☆PhistucK

[Victor Costan]

On Tue, Dec 9, 2014 at 5:00 AM, PhistucK <phis...@gmail.com> wrote:

Credential bearing links are/were very common in file search sites, where they point to some sort of private FTP (IP addresses) URLs with credentials to download a file (MP3, for example).

I don't think these would count as sub-resources. 

[Mike West]

On Mon, Dec 8, 2014 at 7:27 PM, Chris Harrelson <chri...@chromium.org> wrote:

> Yes. I'm meaner than Tom. :)

Meaning you expect the same use cases that were broken before to still be broken, but the benefits outweigh the costs?

This was flippant, sorry.

I do expect there to be impacts. I think we've already sucked up some of the impact by stripping the credentials from <img> requests (and I just realized that the UseCounter data doesn't exclude these requests, which are almost certainly already broken). I do think those impacts are worth accepting.

On Tue, Dec 9, 2014 at 10:56 AM, Philip Jägenstedt <phi...@opera.com> wrote:

All instances of 'gopher://' that I found were in CSS selectors like
'a[href ^="gopher://"]' so immediate removal of the gopher case LGTM,
if you want to do it.

We don't actually support gopher in the network stack, so blocking the requests in Blink doesn't make much difference. :) FTP is the scheme I care about here.

 

For ftp and credentials-in-url the usage is high enough and potential
breakage large enough that it's unlikely to be completely smooth, so
eventually trying those removals with flags seems like a good idea.

Note that these two are likely linked: that is, 'ftp://user:pass@whatever/' is likely a common case of embedded credentials.

 

If you do some searching in Google's internal index or the httparchive
data, maybe you can identify the biggest sites that depend on this
stuff, and maybe fixing only a few will see usage drop to a point
where removal is trivial. Worth a shot?

I'll take a look. Maybe it's all just `https://ftp-with-embedded-credentials-r-us.com`! :)

-mike

[PhistucK]

Right, sorry. I keep remembering this one.

☆PhistucK

[Philip Jägenstedt]

On Fri, Nov 21, 2014 at 2:49 PM, Mike West <mk...@chromium.org> wrote:

> 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.

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?

Other than that, deprecation and learning more about what kinds of
things would break from this change seems like the path forward.

Philip

[Chris Palmer]

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.

[Mike West]

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

[Chris Bentzel]

We had interns last summer move pretty far on an FTP client chrome
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.

[Matt Menke]

Another concern is the app can't handle FTP over HTTP proxies that support it (We don't support FTP over other proxy types).  Adding proxy support would be non-trivial.

>
> -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.