New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 435547 link

Starred by 26 users

Issue metadata

Status: Assigned
Owner:
OOO until 4th
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Task

Blocked on:
issue 504300
issue 685084
issue 707761

Blocking:
issue 333943
issue 904455



Sign in to add a comment

Evaluate dropping legacy and credentialed subresource requests.

Project Member Reported by mkwst@chromium.org, Nov 21 2014

Issue description

We should evaluate:

1. blocking `ftp:` subresource requests inside `http`/`https` pages.
2. blocking credentialed subresource requests on uncredentialed pages.
 

Comment 1 by rob@robwu.nl, Nov 21 2014

Labels: -OS-Linux OS-All Cr-Internals-Network-FTP
Related: issue 435547 ("Remove built-in support for FTP from Chrome").

Comment 2 by rob@robwu.nl, Dec 9 2014

^ That link points to this issue. This is the bug that I meant: issue 333943

Comment 3 by mkwst@chromium.org, Jan 25 2017

Blocking: 333943

Comment 4 by mkwst@chromium.org, Jan 25 2017

Issue 377231 has been merged into this issue.

Comment 5 by mkwst@chromium.org, Jan 25 2017

Blockedon: 504300

Comment 6 by mkwst@chromium.org, Jan 25 2017

Blockedon: 685084
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 25 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/81c970230a492e70e9a580c38e4de8a3f0fcc29b

commit 81c970230a492e70e9a580c38e4de8a3f0fcc29b
Author: mkwst <mkwst@chromium.org>
Date: Wed Jan 25 16:48:45 2017

Add deprecation messages for blocked subresource types.

Intent 1: https://groups.google.com/a/chromium.org/d/msg/blink-dev/bIJdwwoQ98U/-F1aL2FgBAAJ
Intent 2: https://groups.google.com/a/chromium.org/d/msg/blink-dev/lx-U_JR2BF0/Hsg1fiZiBAAJ

BUG=435547,504300

Review-Url: https://codereview.chromium.org/2647283007
Cr-Commit-Position: refs/heads/master@{#446038}

[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies-expected.txt
[add] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests-expected.txt
[add] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests.html
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/security/location-href-clears-username-password-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/access-control-and-redirects-async-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/workers/referer-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/LayoutTests/security/block-test-expected.txt
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/81c970230a492e70e9a580c38e4de8a3f0fcc29b/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

Project Member

Comment 8 by bugdroid1@chromium.org, Jan 27 2017

Labels: merge-merged-2987
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/781c4e2bbdd94ae563f4540136a2384443e5ec5d

commit 781c4e2bbdd94ae563f4540136a2384443e5ec5d
Author: Mike West <mkwst@google.com>
Date: Fri Jan 27 08:06:12 2017

Add deprecation messages for blocked subresource types.

Intent 1: https://groups.google.com/a/chromium.org/d/msg/blink-dev/bIJdwwoQ98U/-F1aL2FgBAAJ
Intent 2: https://groups.google.com/a/chromium.org/d/msg/blink-dev/lx-U_JR2BF0/Hsg1fiZiBAAJ

BUG=435547,504300, 685084 

Review-Url: https://codereview.chromium.org/2647283007
Cr-Commit-Position: refs/heads/master@{#446038}
(cherry picked from commit 81c970230a492e70e9a580c38e4de8a3f0fcc29b)

Review-Url: https://codereview.chromium.org/2659823004 .
Cr-Commit-Position: refs/branch-heads/2987@{#136}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies-expected.txt
[add] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests-expected.txt
[add] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests.html
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/security/location-href-clears-username-password-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/access-control-and-redirects-async-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/workers/referer-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/LayoutTests/security/block-test-expected.txt
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/781c4e2bbdd94ae563f4540136a2384443e5ec5d/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

Project Member

Comment 9 by bugdroid1@chromium.org, Feb 21 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66

commit e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66
Author: mkwst <mkwst@chromium.org>
Date: Tue Feb 21 06:30:40 2017

Block 'ftp:' subresource requests from non-'ftp:' pages.

Usage of the 'ftp:' protocol when requesting subresources from non-'ftp:'
clients has slowly declined over the last few years to the point where
it represents a [negligable amount of traffic][1]. The protocol does not
support modern requirements, like encryption, and we're interested in
removing support from //net.

To that end, this patch alters Fetch to block FTP subresources from
webby clients. That is, a page delivered from `http://example.com/`
will receive a network error response to requests like those generated
from `<img src='ftp://example.com/image.png'>`.

Intent: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bIJdwwoQ98U/-F1aL2FgBAAJ
PR against Fetch: https://github.com/whatwg/fetch/pull/464.

BUG=435547

Review-Url: https://codereview.chromium.org/2656443005
Cr-Commit-Position: refs/heads/master@{#451709}

[add] https://crrev.com/e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66/third_party/WebKit/LayoutTests/http/tests/security/ftp-subresource-blocked.html
[modify] https://crrev.com/e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66/third_party/WebKit/LayoutTests/security/block-test-expected.txt
[modify] https://crrev.com/e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/e4cfac9d67e1b30d60f84def4a7c7cb5f4883c66/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Project Member

Comment 10 by bugdroid1@chromium.org, Mar 24 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4

commit c48f6533dbd721f4401bf82b6f7ccc4e760da9d4
Author: mkwst <mkwst@chromium.org>
Date: Fri Mar 24 14:42:55 2017

Block 'ftp:' subresource requests from non-'ftp:' pages.

This patch flips the flag to begin blocking 'ftp:' resources from non-'ftp:'
pages in stable.

Intent: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bIJdwwoQ98U/-F1aL2FgBAAJ
PR against Fetch: https://github.com/whatwg/fetch/pull/464.
Dashboard: https://www.chromestatus.com/feature/5709390967472128

BUG=435547

Review-Url: https://codereview.chromium.org/2775763002
Cr-Commit-Position: refs/heads/master@{#459421}

[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/chrome/test/data/extensions/api_test/cross_origin_xhr/background_page/test.js
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/chrome/test/data/extensions/api_test/cross_origin_xhr/content_script/test.js
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/multiple-report-policies-expected.txt
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests-expected.txt
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/LayoutTests/security/block-test-expected.txt
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/c48f6533dbd721f4401bf82b6f7ccc4e760da9d4/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Is this still work in progress (for "blocking credentialed subresource requests on uncredentialed pages")?  Or can it be marked fixed?
Labels: -Type-Bug OWP-Type-Deprecation Type-Launch-OWP
Project Member

Comment 13 by bugdroid1@chromium.org, Mar 27 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8574b4d96720361e495573ac5868f845017f7aa7

commit 8574b4d96720361e495573ac5868f845017f7aa7
Author: mkwst <mkwst@chromium.org>
Date: Mon Mar 27 10:07:10 2017

Block subresource requests whose URLs include credentials.

Usage of the `http://user:pass@host/` pattern has [declined significantly
in the last few years][1]. We've taken steps in this direction in the past
(see the discussion in  https://crbug.com/174179  and
 https://crbug.com/303046 ). My hope is that usage has decreased in the last
~2 years to the point where it makes sense to try again.

Intent: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/lx-U_JR2BF0

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

BUG=504300,435547

Review-Url: https://codereview.chromium.org/2651943002
Cr-Commit-Position: refs/heads/master@{#459737}

[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/fetch-event-redirect.https-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/cachestorage/resources/credentials-iframe.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/cachestorage/serviceworker/credentials.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/fetch/script-tests/thorough/redirect-password.js
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/security/location-href-clears-username-password-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/security/location-href-clears-username-password.html
[add] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/security/resources/post-location-to-opener.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-access-control-login.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-access-control.php
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/access-control-and-redirects-async-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth.html
[delete] https://crrev.com/4a6245e626500c412e86e74e110542d33408e679/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout-expected.txt
[delete] https://crrev.com/4a6245e626500c412e86e74e110542d33408e679/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth.php
[delete] https://crrev.com/4a6245e626500c412e86e74e110542d33408e679/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password-expected.txt
[delete] https://crrev.com/4a6245e626500c412e86e74e110542d33408e679/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password.html
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/workers/referer-expected.txt
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/workers/resources/referer-test.js
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/8574b4d96720361e495573ac5868f845017f7aa7/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Comment 14 by mkwst@chromium.org, Mar 27 2017

Still in progress for the credentials bit, which is mostly landing shortly in https://codereview.chromium.org/2651943002. I'll follow that up with a kill-switch so we can back it out if enterprises yell at us.
Project Member

Comment 15 by bugdroid1@chromium.org, Mar 27 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1ddb4a2eacb8a77affdb05061644ee4f23adbd58

commit 1ddb4a2eacb8a77affdb05061644ee4f23adbd58
Author: mkwst <mkwst@chromium.org>
Date: Mon Mar 27 14:50:10 2017

Enable blocking of subresource requests whose URLs include credentials.

This patch flips the 'BlockCredentialedSubresources' flag to 'stable', and
ties it to a feature flag in //content that we can use as a kill switch if
it turns out that enterprise usage of the feature is higher than we hope
(the overall numbers still look reasonably low[1]).

Intent: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/lx-U_JR2BF0

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

BUG=504300,435547

Review-Url: https://codereview.chromium.org/2779603002
Cr-Commit-Position: refs/heads/master@{#459781}

[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/chrome/browser/ui/login/login_handler_browsertest.cc
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/content/child/runtime_features.cc
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/content/public/common/content_features.cc
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/content/public/common/content_features.h
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/LayoutTests/http/tests/security/deprecated-subresource-requests-expected.txt
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/access-control-and-redirects-async-expected.txt
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth-expected.txt
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth-expected.txt
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/1ddb4a2eacb8a77affdb05061644ee4f23adbd58/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Blockedon: 707761
Hello. 

This comment relates to Basic Auth and clearing the browser cache for Basic auth on log out and how that is affected by this change. 

I used to use the following code ( inside NodeJS response ) to clear Basic Auth cache to provide a nice logout experience. 

             <!DOCTYPE html>

              <head>
                <script>
                  "use strict";
                  {
                    const url = "https://${req.get('host')}/human/login";
                    const logoutRequest = new XMLHttpRequest();
                    logoutRequest.open( "HEAD", url, true, "logout", Math.random() );
                    logoutRequest.send();
                  }
                </script>
              </head>
              <main>Logged out.</main>

As a result of this change, I'm updating the script to:

                  "use strict";                                                                                
                  {                                                                                            
                    const url = "https://logout:" + Math.random() + "${req.get('host')}/human/login";                      
                    self.location.href = url;                                                                  
                  }     

This new code is actually not so bad as it just repeats the login dialog again which is standard. 

However, I'm wondering if the Chromium authors have any other preferred way of clearing the basic auth cache to create a logout and prompt the human to relogin by repeating the login dialog.

I sort of feel like I'm hacking around the fringes here. And I think it ought not be like that since Basic Auth is a long time resident of web standards.

Thanks in advance



We care about this functionality, as we use a web page that does an image-request with embedded credentials to check whether users' VoIP phones are actually connected to the network, and even to send commands to the phone (as described on: http://wiki.snom.com/FAQ/Can_I_control_my_snom_phone_remotely). Flaky, yes, but it doesn't seem we have (m)any alternatives as of current. 

The feature as described on https://www.chromestatus.com/feature/5669008342777856 currently has status 'removed`. Does this mean that credentialed subresource requests are no longer scheduled to be removed from Chrome by release 59?
We definitely need an update on this and whether these requests are really going to be blocked.  I'm getting a deprecation warning on android when using coax and couchbase lite on a hybrid mobile app.  I've looked into using something other than coax but all the libraries I've looked into would generate the same deprecation warning since couchbase lite exposes a restful interface to the local db.  If this ends up blocked a lot of hybrid apps using couchbase are going to have issues.  
chriscanbereached@: After some helpful input from a few folks, we carved out an exception for XHR in https://codereview.chromium.org/2808753003. Your original code should continue to work.

tijszwinkels@: The status "removed" means "the feature was removed from Chrome". You can evaluate the behavior via the beta channel right now to see if you're impacted. I believe we dropped embedded credentials from image requests quite some time ago, however. I'd be surprised if they were working for you in stable today.

mbecatti@: As above, you can evaluate the behavior we're currently planning to ship by running our beta channel (https://www.google.com/chrome/browser/beta.html on desktop and https://play.google.com/store/apps/details?id=com.chrome.beta&hl=en on Android). Perhaps the XHR carveout solves your problem?
Is there any way to override this blocking of credentialed subresource requests, i.e., using chrome flags? I actually need to view images that have credentials in their URLs and this change is blocking them from loading :(

Comment 22 by mkwst@chromium.org, May 11 2017

brian.tully@: I believe that Chrome hasn't been sending credentials for image requests for quite some time. Are you sure that the images actually require basic auth?

Comment 23 by mbeca...@gmail.com, May 11 2017

mkwst@: I've installed Chrome Beta (v59) on my test device, but my app still uses Chrome v58 when it launches.  Do you have any tips on testing the v59 web view?
The current way to preserve image request behavior is the "--allow-cross-origin-auth-prompt" flag. But it does not appear in the "chrome://flags" page. It must be set when starting Chrome.

The use case for requesting images w/ Basic Auth credentials is extremely common for IP Surveillance Cameras. These are usually viewed on an Enterprise LAN (or VPN over WAN) and so credentials are not exposed to general public.

Please reconsider:
1) The ability to use this feature for Image/Pseudo-stream/Stream Requests.
2) If you insist on forcing a flag to use it, please make that flag available via "chrome://flags" settings.
3) Worst case, allow the existing flag usage to continue.

Many of our customers, including DC Public Schools (~200 sites, so thousands of users), would need to move away from Chrome if you eliminate this feature.
If this is done for security reasons, shouldn't at least https be allowed? is there a vulnerability that is being fixed here or is it just because of the drop of ftp support?

What are the alternatives for basic authentication if the support for this feature is dropped?
I have another use case where removing this feature would be problematic.

A user is developing a Drupal website on their local laptop that has a number of large assets on a pre-production server, currently protected by htauth. Rather than copying the assets to the local server, the Stage File Proxy module is used to obtain the assets from pre-prod when pages are rendered.

This will not be possible with the removal of this functionality.
So this will still allow you to navigate to a protected page via https://username:password@example.com, but doesn't let you load assets using the same origin? That renders the initial navigation useless. If I have a page that's protected:

<html>
<head>
  <link href="/style.css">
</head>
<body>
  <h1>Hello World</h1>
</body>
<html>

It'll load the html at https://username:password@example.com, but all the relative subresources like the CSS/SCRIPTS/IMAGES will fail (https://username:password@example.com/style.css). A solution could be to allow subresource requests through (1.) Same Origin and/or (2.) https

Are there any other solutions?

Comment 28 by ja...@imaj.es, May 31 2017

Hey all, I know this has gotten merged and made its way to (at least) the beta channel, however I'd like to add a couple thoughts:

1. I know your overall penchant for removing entire modules of code even if there are smaller/tighter use cases, however (as has demonstrated I think in similar other removals), creating an external module/extension to step-in here for something like this is seemingly tough.

2. This is happening even on local resources (10.x, 192.x), and on DNS that resolves to local resources. Is there any reason you wouldn't allow in-network resources to still use this kind of scheme? It's true that requesting remote resources presents itself as an attack vector, but on a local network? that feels like a stretch.

3. incorporating user:pass in the URI is very much still part of the HTTP spec. I know that adhering to specs is not a priority when also trying to advance the web for you guys, but do you have a proposal to amend the spec?  Surely you all remember the saga of IE and its choice to deviate from the specs creating so many years of pain for developers.... this is kinda lending itself there too.

Finally: would someone mind passing this up the chain... Chrome/Chromium team: it's possibly a good time to start thinking seriously about hiring a vocal evangelist to help ease the path for devs if you want to keep this momentum up. Someone like Asa Dotzler at Mozilla, for example, did a great job of helping shepherd firefox when it deviated from specs, as does Maciej et al over in the Safari team. Y'all seem to be quiet! It'd be great to hear more so we're not slapped in the face with these changes, and they're broadcast wide so we can prepare better.
I need ability to use https://username:password@domain at selenium. Without this feature chrome is useless for our team. 
Are there any ways to turn this on (settings, flags ...) ?
Are there suggestions on possible solution around this. With the forced update to Chrome v59 all our automation tests are broken since our test environments all require basic auth.
I'm here because "Drop support for embedded credentials in subresource requests." has just bitten me in the ass because it's how ovh.co.uk's Serial-Over-Lan console for dedicated servers works.

I had to scramble to use Firefox instead just to access the console (to monitor a reboot of the host).

Is there any chance of allowing a whitelist for this ?

Comment 32 by mosk...@gmail.com, Jun 14 2017

What the hell, I was using that!  At least give us a flag to turn it back on when you do this stuff.  Isn't there a memory leak you could be hunting down?

Comment 33 by mkwst@chromium.org, Jun 14 2017

There's a bug in M59 that made it through to stable (https://bugs.chromium.org/p/chromium/issues/detail?id=731618) which prevents relative URLs on top-level pages that were loaded with embedded credentials from loading correctly. Sorry about that: I missed the comment at https://bugs.chromium.org/p/chromium/issues/detail?id=435547#c27, which pointed that out ~2 weeks ago.

I've landed a fix on ToT and will see what I can do about merging it back.

In the meantime, the command-line flag `--disable-blink-features=BlockCredentialedSubresources` might be useful. That should remove the block.
Thanks mkwst@chromium.org - that commandline flag does indeed mean I can now use OVH SOL again with Chrome.

Of course it sticks up a warning on the first tab as well.  Given use of this will likely be limited to just certain sites/domains a whitelist for such would probably be the better long term solution.

Comment 35 by mkwst@chromium.org, Jun 14 2017

suisanahta@: Glad to hear that the flag works as a temporary workaround. Ideally, tomorrow's Canary will Just Work for you, and we won't need either a whitelist or a command line flag.
Is there a way that I could use this flag with ChromeOptions ?
Hi, 
as Patryk wrote - provide us with possibility in ChromeOptions how to disable ths feature.

Also what exactly this feature shall prevent "bad guys" from? 
If I have a script that is trying to login into some page using some list of credentials in url then this will not stop me from anything. Once I receive http 200 code then I can (in same browser session) simply reload url without credentials and I have full page content...

We use this in Chrome Sign Builder to display protected content on internal display boards. For example, we have a monitoring system that requests HTTP Basic credentials, but we want the same screen to show on our large NOC projector. Entering the user:pass@url was a perfect work around. Now we are scrambling to figure out some work-around that is compatible with Sign Builder for this type of display. We tried to write a PHP page to pull what we need from the monitoring system and display it without requiring HTTP Basic, but it is proving very time consuming to "reinvent the wheel" so to speak. Sign Builder was a great way to have a very secure signage box without having to put a small PC with every display that could be used for nefarious purposes, should someone find a keyboard.

Comment 39 by meyer...@gmail.com, Jul 18 2017

Blocking by default does indeed make Chrome useless for my team as well.  I can understand a notice, but the outright blocking, flag or no flag, of URLs with embedded credentials within iframes are a PITA for light-weight traffic management jury rigging.

Comment 40 by ray...@gmail.com, Jul 24 2017

This "feature" (I call it "bug") is killing of the WebCam viewer of my app, where the users supply the credentials to view it in a configuration file.

All in all this is even worse than CORS.

Comment 41 by math...@qiwi.be, Jul 26 2017

Can we distinguish between URLs that explicitly embed credentials, and relative URLs made from such pages? This would reduce confusion involving bookmarks containing such URLs.

Here’s the situation I’m running into:

1. Bookmark a URL with embedded credentials
2. The HTML document at the URL contains relative URLs to subresources, e.g. <script src="foo/bar.js"></script> or <link rel="stylesheet" href="baz/qux.css">
3. Click the bookmark

Expected behavior: the credentials are used to log in, and then the page loads along with its subresources (since those don’t explicitly contain the credentials).

Actual behavior: the HTML document loads, but all subresources fail to load. Gut reaction (for those not checking the DevTools console): the page or browser is broken.

As a workaround, I currently click the bookmark to force a log in to the site, then focus the address bar containing the non-credentialed URL, and hit Enter.

Comment 42 by mkwst@chromium.org, Jul 26 2017

mathias@: That's https://bugs.chromium.org/p/chromium/issues/detail?id=731618, fixed in 61, which should be rolling to beta shortly.

Comment 43 by jav...@deevop.com, Aug 10 2017

Hi,
here another use case that gets broken by removing http auth in urls.
We run a website development platform where developers access their websites in a cloud collaborative environment and those development websites are htauth protected.

I am pretty much with everyone here, specifically https://bugs.chromium.org/p/chromium/issues/detail?id=435547#c27

If I am allowed to use the auth in the url for the main page, if I cannot access its css or images (being served by the same domain), it makes this useless.
Currently there is no other way to accomplish the user auto login using http auth.

You can copy firefox's behaviour and add a warning to the user that he is about to log in using credentials. And he can disable that warning by adding a flag.

Please reconsider this.


Project Member

Comment 44 by bugdroid1@chromium.org, Aug 30 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b43863ad9ea99cc432eb95f99c15375bd73bee5e

commit b43863ad9ea99cc432eb95f99c15375bd73bee5e
Author: arthursonzogni <arthursonzogni@chromium.org>
Date: Wed Aug 30 15:53:20 2017

PlzNavigate: Make BlockLegacySubresources work.

Chrome blocks 'ftp:' subresource request inside 'http'/'https' pages.
See https://crbug.com/435547.

It was broken with PlzNavigate (--enable-browser-side-navigation) when
the subresource is an iframe. The page was blocked, but only after the
request had been sent to the server.
This CL makes chrome block requests before they are submitted.

Additionnally, it removes the
--enable-blink-feature=BlockLegacySubresources switch. It should be
removed for M60 and this patch will land for M62.

Test: NavigationHandleImplBrowserTest.BlockLegacySubresources
Bug:  757809 ,435547
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_browser_side_navigation_rel;master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Ia85417af453b2e0532b0b7c0f381fa8a2f8e6e8a
Reviewed-on: https://chromium-review.googlesource.com/625942
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498476}
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/chrome/browser/chrome_navigation_browsertest.cc
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/content/browser/frame_host/navigation_request.h
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/third_party/WebKit/Source/core/loader/BaseFetchContext.cpp
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/b43863ad9ea99cc432eb95f99c15375bd73bee5e/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Labels: migrated-launch-owp Type-Task
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge

Comment 46 by rob@robwu.nl, Sep 20 2017

Can requests to ftp from chrome-extension:-URLs be allowed again?
My PDF Viewer (https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm) (and forks thereof) cannot view PDF files from FTP any more, and that has resulted in some user complaints.
Hi, I'm confused on the final resolution. Will basic auth be allowed again? I have a home security app that runs on ionic which uses a chrome web view. A lot of users are using basic auth with the server it relies on (due to LDAP auth) and only expose their systems to the outside world via a VPN. I don't have the ability to re-compile chrome or use flags. 
because of this I was forced to downgrade Chrome to v58 as since I updated to Android 7.0 I can't use standalone webview.
I don't really have any alternative as I'm using LDAP auth with Apache.

Comment 49 by geroy...@gmail.com, Nov 28 2017

This is breaking webcam integration. Their security model is still largely http-basic-auth. Leading manufacturer AXIS lacks CORS-Headers, so fetching the image with JS, or even using the img tag and crossorigin attribute to move credentials to an auth-header in not an option.
We've researched this a lot, and while I can see action the IP cam manufacturers could take to allow for a workaround, I don't see anything that can be done absent that.  The "--disable-blink-features=BlockCredentialedSubresources" Chrome startup flag seems to have no effect.  We can't pass user:pwd via the URL.  We can't use xhr, as it's cross origin.  In our testing, Samsung doesn't have the CORS headers either.
I am not stating  an opinion on this but I want to bring into attention that this breaks non-credential, chrome-extension static urls: "chrome-extension://_MSG_@@extension_id__/static/blabla.css" 

You can still get urls dynamically with chrome.runtime.getURL('static/blabla.css') but not from an html context.

Comment 52 by andr...@hzdg.com, Jan 16 2018

I'm experiencing the same issues as Benjamin in comment 50
Has anyone else had any success on this?  This is really aggravating for webcam integrations.  We've got basically black boxes that we can't fix/modify without throwing out completely good hardware and buying it all over again because of this feature deprecation.  In our environment, I could maybe even cook up a custom chromium for this particular purpose, but apart from being loathe to have to maintain a fork of Chrome (no matter how minor the changes might be), my attempts at modifying chromium to remove this "feature" have been in vain.  Since the chrome startup flag to disable this doesn't work anymore, I tried setting the flag back to "experimental".  That seemed to stop the explicit blocking of credentialed subresources, but it's still stripping the user:pass somewhere.  There really has to be some workaround for the environments that depends on this.
I've been spinning my wheels on this one for quite some time.

Same issue as several comments - attempting to access HTTP cameras. My attempts are frequently stripped of credentials or outright blocked from the subresource request issues. Make progress on one side and it breaks on the other.

Just chiming in. Are there any known workarounds or solutions for this issue?

Comment 55 Deleted

For webcam integration, I've had to revert to this strategy:

1. Don't pass user:pass in HTTP URLs (AJAX requests). Instead inject an Authorization header. I believe this is do-able and the right approach.

2. We are screwed when we render MJPEG images with the HTML <img src> tag. There is _no_way_ to add a Authorization header as the implicit HTTP requests are handled inside the browser innards and cannot be trapped by HTTP interceptors to inject headers. Using custom directives don't work either because the images keep streaming, so if you think you can write your own image handler (in angular, for example) that does a $http.get and creates a blob to display, well, the $http.get won't ever stop "getting" as the image keeps streaming. As a workaround, if basic auth is enforced by your web server (as opposed to inside the camera), then I've started recommending to my users they exclude the streaming URLs from basic auth. In my limited testing, I've not been able to directly access the streaming URLs without authenticating on the primary portal, so that gives protection. I'm not an Apache expert, but this is my setting: https://github.com/pliablepixels/zmNinja/wiki/FAQ#i-cant-see-streams-i-use-basic-auth

Comment 57 by geroy...@gmail.com, Apr 27 2018

You cannot do basic auth with authorization header as a work around. That's the whole issue. The camera would have to send cors headers in its response, which many don't. As far as img tags go, you can technically add the cross-origin attribute and set it to true. This leads to the browser automatically converting url-based credentials to an authorization header. But solves nothing if the cors headers are missing from the camera response. 
@geroy I should have clarified, my setup doesn't talk directly to cameras -they talk to a server (Zoneminder) (served by apache) that in turn communicates to the cameras.

On your comment on Authorization not working, I only have the following set in apache2.conf:
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
Header add Access-Control-Allow-Headers "x-request, origin, x-requested-with, content-type"

is that what you mean? I don't have Access-Control-Allow-Origin * enabled and it still works

Comment 59 by geroy...@gmail.com, Apr 28 2018

well yes, a proxy in the middle solves all those problems, but that's not always possible or desireable. and yes, you don't need * if you access your own server from the same domain. but cameras would need to have it in order to allow any client to access resources with auth headers
My apologies for derailing the core issue being reported here, but I did want to make sure I understood this issue fully, since it does impact a lot of users who use "intermediary" servers that in turn talk to the cameras. This will be  my last request for clarification, I promise:

You said:

"and yes, you don't need * if you access your own server from the same domain"

This confuses me. The mobile app, which communicates to the intermediary server is not on the same domain as the server. The mobile app inserts the authorization header and sends it off to the intermediary server which implements basic auth (via apache). 

Comment 61 by geroy...@gmail.com, Apr 28 2018

You're probably right, but the blunt truth is that I don't care right now. This issue is about being able to contact a server from the browser where you are not in control of the response header. I am coming at this from a background where a proxy would mean a new dedicated, powerful piece of hardware. 
Blocking: 904455

Sign in to add a comment