To recap my arguments from the previous issue, I believe that remote control extensions are a use case worth preserving - I don't know what scale is considered relevant, but just considering the two addons I use personally (Play to Kodi[1] and Remote Torrent Adder[2]) there are already 100,000 users potentially affected (by the webstore stats).

Further, I believe that because extensions are already afforded extra trust it may be acceptable to control access to requests with credentials behind a permission flag.

mkwst@chromium.org notes that he'd like to delete the relevant code altogether, and the actual Intent mentions treating "all subresource requests the same to the extent possible".

I would respond that requests originating from extensions are already treated differently, on account of their ability to bypass the SOP.

+rdevlin.cronin@ for extensions thoughts.

+palmer@ for sadness thoughts.

Can we should reach out to the developers of these (and any related) extensions, and advise them/show them how to do the same job by different means (e.g. adding Basic Auth headers to the request)?

I've reached out to one developer myself, but I'm waiting to see how  issue 707761  turns out to contact others - if username/password support is retained in XHR.open, it may not be necessary.

If it is needed however, it may be worth contacting jQuery, etc, as well - both of the extensions I've examined use jQuery's $.ajax instead of XHR.open directly

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

commit fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6
Author: mkwst <mkwst@chromium.org>
Date: Wed Apr 12 14:38:23 2017

Carve out an exception for embedded credentials in XHR.

As discussed in  https://crbug.com/707761 , the security justification for
restricting username/password in XHR is weaker than I thought it was.
I'd still _like_ to remove developer-controlled usernames and passwords
from the platform, but I was incorrect to point to them as an actual
vulnerability, given the way basic/digest auth actually works (requiring
CORS-same-originness, and handshaking through a 401 response).

So, this patch limits the previous restrictions against embedded
credentials to non-XHR use cases. That will make SAP happy, and should
resolve the other complaints this change has generated.

BUG= 707761 ,708131,504300

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

[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/chrome/browser/ui/login/login_handler_browsertest.cc
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/cachestorage/resources/credentials-iframe.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/cachestorage/serviceworker/credentials.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay-expected.txt
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/inspector/network/network-xhr-replay.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-access-control-login.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-access-control.php
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/access-control-and-redirects-async-expected.txt
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth-expected.txt
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/failed-auth.html
[add] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout-expected.txt
[add] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/logout.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth-expected.txt
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/null-auth.php
[add] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password-expected.txt
[add] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/remember-bad-password.html
[modify] https://crrev.com/fd04d4a0b5f4a35c4acd66a0b35773deb33e8bb6/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp

From an extensions perspective, I agree with mkwst that we should strive to treat extension requests as similarly as possible.  It's true that we already deviate from that in some respects, but we try to limit those areas.

I'd prefer we not break things unduly, and there is a workaround to embedding the credentials in this way, so I don't think we'll fundamentally restrict any use cases.  That said, it would be great to reach out to these folks and make sure they're aware of this change, and hopefully have them switch over before any breaking changes ship.

mkwst@, it sounds like your patch in #7 restores this capability (at least temporarily), right?  Would it still be worth reaching out and seeing if we can't wean people off this technique to open the door to removing it in the future?