[MacTriage]

Considering this as a feature request and making the status to Untriaged so that the issue would get addressed.

Thank you.

Does the URL in the details object not contain the scheme?  Would that be sufficient?

Hm. I don't think it does, but I don't have code at hand. 
Memory tells me only the hostname.
There is a "scheme" property, but I don't think it is the same:
"The authentication scheme, e.g. Basic or Digest."

There is "details.challenger.host" but this lacks scheme information.

> Would that be sufficient?
It would. Any means to identify challenger as using SSL or not works. 

The url I was referring to was the one specified here:
chrome.webRequest.onAuthRequired.addListener(function(details, asyncCallback) {
  details.url;  // <-- This one.
});

From a code point of view, this will be the URL of the associated net::URLRequest, and should be the full URL (including scheme).  There's also the challenger object, as you point out (in the example above, details.challenger), which includes host and port.

Is there a time when the challenger is significantly different than the origin of the url associated with the request?  In doing some code spelunking, nharper found that this was pretty much only the case with web socket requests (where we happen to change the challenger scheme to http/https instead of ws/wss), but that shouldn't matter for checking whether the request was made over a secure scheme.  But, it wasn't an exhaustive search.

It would actually be pretty easy (and non-breaking) to add a |scheme| property to challenger, so I'd be fine going that route if there's circumstance when details.url is insufficient.

I think i misunderstood the API.
I understood `details.url` to be the target URL.
`challenger` being the proxy, or authentication target.
I will do some tests locally and see what I find.
Thanks.

Thanks!  To be clear, I'm not 100% sure these are guaranteed to be the same/similar, especially when it comes to proxy code (I'm not super familiar with our proxy code), but I'd like to make sure there's a definitive case where they differ before expanding the API.

If the request goes through a proxy, then the challenger could be the proxy (if it requires auth) instead of the requested URL (from the net::URLRequest).

Sorry. Should have made that clear. I forgot there was other options for this event. 'challenger' is a proxy in my case.

My tests aligns with comment 9, and comment 7.
I observe `details.url` being "target" URL (or destination. where the proxy will visit on behalf of browser). I observe `details.challenger` being the auth target.

Cool, thanks.  Would adding a challenger.scheme string property be sufficient for your use case?

Yep. But please document the possible values :) Thanks very much.

nharper@, can you clarify which schemes are possible?  IIRC, we found code transforming ws/wss -> http/https; are all the others possible?

I also worry a bit about our ability to report all possible schemes.  For instance, if there's a custom protocol handler for foo:// installed on the machine, is foo:// considered a valid scheme?

On the HttpAuthController side of things, it looks like http and https are the only possible schemes. However, AuthChallengeInfo.challenger can also be set in URLRequestFtpJob, generating an origin from URLRequest::url(). I haven't looked to see what the possible schemes are here.

In the URLRequestFtpJob case, the scheme is supposed to be empty: https://cs.chromium.org/chromium/src/net/url_request/url_request_ftp_job.cc?l=310

Sorry. There is one other thing that would be useful.
Is it possible to include TLsv1, TLSv1.1, TLSv1.2, and cipher info?
I would like to relay this information to the user.
It seems separate.
I'm just curious is there already an API I can use for this.
If not, could it be added?

To be clear: I want to relay whether one of: tlsv1.0, tlsv1.1, tlsv1.2 was used or not (with challenger) as well as what cipher was chosen. Does it make sense?

It's unlikely that we'll expose any information from the TLS stack - see https://bugs.chromium.org/p/chromium/issues/detail?id=107793#c20

I understood the reply as "too hard", or "Chrome limitation".

Rather unfortunate, because there is no way to tell the user if the protocol they are using is "bad" (eg TLSv1) or just unexpected(not TLSv1.2), or an unexpected cipher is used. This isn't good, for people providing proxy services with strong considerations for such things.

It kinda makes extensions blind to encryption. Not good. There's no way to verify.

Sorry for the spam of comments.
The use case is 1) informative (for user) and 2) warn if TLSv1.0 is used (for example).
I don't want to lock users out, by not providing TLSv1.0, but I don't want them to be unaware, too.

Let's try and keep the conversation on this bug focused on exposing the challenger scheme. :)  FWIW, I'm not entirely sure exposing TLS is dead, but this isn't the right place to discuss.

Yes. Sorry.

CCing myself on this issue.