Unable to reproduce this issue on reported version 68.0.3400.0 using windows 10 with steps mentioned below. Attaching screencast for reference. Not seeing any Unknown / canceled entries.

@Reporter please check the video and let us know if we miss anything.Please check the issue on fresh profile which do not have any apps/extensions. Also please check the issue by resetting devtools to default. Any further information on reproducing the issue would help in further debugging.

Thanks!

Deleted: 834771.mp4 755 KB

	834771.mp4 755 KB View Download

Your screencast isn't missing anything.

New profile didn't help.

Reset via Settings --> Reset and clean up --> Restore settings to their original defaults didn't help either.

Is there anything else I can do besides reinstalling Chrome?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce either. I don't think it is profile related. It might be related to some very specific network environment or it is a temp regression.

@reporter, could you try the next Canary (>68.0.3400.1) to see if problem is still there?  

Yes, it's still there on Version 68.0.3405.0 (Official Build) canary (64-bit).
I guess, reinstalling would solve the problem because I did this in the past, when I had the same problem.

But I wonder why this keeps happening to me.

Now this happened to me again today when upgrading from (stable) Version 66.x to (stable) Version 67.0.3396.62 (Official Build) (64-bit).

I can repro on Linux ToT only when --site-per-process is enabled (which is currently on by default for ToT).  Running with --disable-site-isolation-trials fixes things.

Since there are no OOPIFs on the page and these canceled entries are for subresource requests (fonts, images, scripts), CORB might be involved here.  Also adding some DevTools folks - maybe DevTools isn't sending some relevant info when site-per-process is on?

Does this feature depend on raw headers?  I suspect Pavel's r523583 from  issue 793692  might be involved, from the M63 timeframe.

estark@, do you know who's familiar with the security panel, and might be able to work with DevTools folks to update it?

For reference, Site Isolation was at 10% in M66 and is ramping up in M67.

I'll take a look. When I repro on ToT with --site-per-process, it seems that the Unknown/canceled resources are exactly the ones that are served from disk cache. Can someone else with a repro see if they are seeing the same thing? (from the Unknown/canceled request, click "View requests in Network Panel" and observe that the Size column says "from disk cache".)

I get the same behavior with r523583 reverted locally, btw, so that's probably not the culprit.

#12: I had "Disable cache (while DevTools is open)" checked and still had a repro when these requests weren't coming from disk cache.  Turning that off, I do also see that only the unknown requests are the ones coming from disk cache.

Ok I don't know what I was doing in c13 but I just bisected to the commit that Charlie pointed out (r523583) and now I can't repro with that reverted locally. So I guess that is it after all.

It looks like we need to stop piggybacking on ShouldReportRawHeaders() for security info and plumb through a separate flag. A few notes:

- I'm confused as to why any cross-site requests do appear to have ShouldReportRawHeaders() set to true. For example, when I load www.google.de, I see documents loaded from googleads.g.doubleclick.net that have their security info. This request appears to not go through the r523583 check that sets report_raw_headers to false in ContinuePendingBeginRequest. Is this WAI that these requests should have report_raw_headers set to true?

- I *think* it's okay to send the security info (certificate details, etc.) into the renderer process for protected subresources, but it's not totally clear. The certificate details could include e.g. a locally installed root CA that leaks some personal information about the user that the renderer wouldn't otherwise have access to. But I don't see any way around this unless there is a way to send info to DevTools without it going through the renderer process. For cookies and raw headers, is the plan for DevTools to indefinitely not report them for these requests, or is there some longer-term plan to restore the functionality?

- I'm not sure what the bar is for m67 merges right now, but I'm guessing this doesn't meet it. It sucks to have this broken for all users for a release, but not the end of the world. Hopefully we can merge a fix to M68.

pfeldman@ or DevTools folks: I seem to remember there's a new way to send information to the DevTools panels from the browser process, rather than routing through the web renderer process being debugged.  Is that correct?

I would much prefer not to plumb cross-site network request info through the renderer process if we can avoid it, since that's now considered an information leak.  (+palmer@)

I'm also very curious about the cached vs non-cached distinction, and why raw headers seem to be reported in some cases.  Can we figure out what the difference is, and whether we're leaking cookie values in some cases as well?  That would be problem for  issue 793692 .

It'd be ideal if we could route the information directly to the DT panel, rather than going through the renderer. But if not, we'll have to live with it.

Long-term, the plan is to move network instrumentation to the browser process which will let us expose both raw headers and SecurityDetails without routing them through the renderer, so eventually this will be fixed (we're planning this shortly after the switch to Network Service happens). Short-term, what Emily says in #15 sgtm.

I think the cached/noncached thing was a red herring. A herring that might or might not be red, not sure yet, is that the requests that don't have security info (and thus do go through the report_raw_headers check in ContinuePendingBeginRequest) are subresources like pngs and scripts, whereas the ones that do have security info are text/html. Indeed, it looks like ResourceDispatcherHostImpl::BeginNavigationRequest respects |info.report_raw_headers| without further checks, unlike ContinuePendingBeginRequest. But I guess that is actually okay because the navigation requests' data go to their respective processes, not cross-process.

So, tl;dr, I think we only report raw headers for navigation requests, not for cross-site subresources, which seems fine.

For navigation requests, we already instrument/report everything from the browser, so these checks should not apply -- it's only subresources that get stripped of the headers and SecurityDetails.

I've uploaded https://chromium-review.googlesource.com/c/chromium/src/+/1087721 which adds a separate flag for sending security details through to DevTools even when we don't report raw headers. Once we have a way of doing network instrumentation directly from browser process -> DevTools without going through the renderer, we can use that for security details as well.

Thanks for getting the CL ready!  That plan SGTM.  The security connection details seem less risky than the rest of the raw headers and cookies, and the few places where we'd prefer to keep them isolated should be fixed in issue 849483.

As you mentioned on chat, I agree that it's probably worth making it clear to others not to add more (potentially risky) things in the data sent to the renderer.

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

commit 32bf077ec0acbb23a520a5400010b2b0b0f5d517
Author: Emily Stark <estark@google.com>
Date: Sat Jun 09 05:17:22 2018

Always report security info to DevTools regardless of site isolation

In https://chromium-review.googlesource.com/#/c/821410/, we stopped reporting
raw headers to the renderer for protected subresources, to avoid sending cookies
or other sensitive raw headers into a renderer process that isn't supposed to be
able to access them. The report_raw_headers flag also controls whether security
details (certificate, TLS protocol information, etc.) are sent into the
renderer, so this change broke the Security Panel's display of security details
for subresources. Security details are less sensitive than the raw headers
because they don't contain secrets like cookies, so this CL introduces a
separate flag to control whether security details are reported, even if raw
headers aren't. In the long-term, we should have a way to send network request
details (both raw headers and security details) to DevTools without having them
go through the untrusted renderer process.

Bug:  834771 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I59397d18bb412a32dad43628f29ebe0f09c7b5ed
Reviewed-on: https://chromium-review.googlesource.com/1087721
Commit-Queue: Emily Stark <estark@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565863}
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/content/browser/devtools/devtools_url_interceptor_request_job.cc
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/content/browser/loader/resource_loader.cc
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/content/browser/loader/resource_request_info_impl.cc
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/content/browser/loader/resource_request_info_impl.h
[modify] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/services/network/public/cpp/resource_response_info.h
[add] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/third_party/WebKit/LayoutTests/flag-specific/site-per-process/http/tests/inspector-protocol/network/security-info-on-response-expected.txt
[add] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/security-info-on-response-expected.txt
[add] https://crrev.com/32bf077ec0acbb23a520a5400010b2b0b0f5d517/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/security-info-on-response.js

Requesting a merge to M68 for #25, since the security panel is rather broken without this fix and site isolation is rolling out now. I've verified the change on canary and it's covered by automated tests.

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge for M68. Branch:3440

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

commit 61bb78eaa35c2a56415083b8cb72bf0fc256386a
Author: Emily Stark <estark@google.com>
Date: Tue Jun 12 18:48:19 2018

Always report security info to DevTools regardless of site isolation

In https://chromium-review.googlesource.com/#/c/821410/, we stopped reporting
raw headers to the renderer for protected subresources, to avoid sending cookies
or other sensitive raw headers into a renderer process that isn't supposed to be
able to access them. The report_raw_headers flag also controls whether security
details (certificate, TLS protocol information, etc.) are sent into the
renderer, so this change broke the Security Panel's display of security details
for subresources. Security details are less sensitive than the raw headers
because they don't contain secrets like cookies, so this CL introduces a
separate flag to control whether security details are reported, even if raw
headers aren't. In the long-term, we should have a way to send network request
details (both raw headers and security details) to DevTools without having them
go through the untrusted renderer process.

Bug:  834771 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I59397d18bb412a32dad43628f29ebe0f09c7b5ed
Reviewed-on: https://chromium-review.googlesource.com/1087721
Commit-Queue: Emily Stark <estark@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#565863}(cherry picked from commit 32bf077ec0acbb23a520a5400010b2b0b0f5d517)
Reviewed-on: https://chromium-review.googlesource.com/1097657
Reviewed-by: Emily Stark <estark@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#305}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/content/browser/devtools/devtools_url_interceptor_request_job.cc
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/content/browser/loader/resource_loader.cc
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/content/browser/loader/resource_request_info_impl.cc
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/content/browser/loader/resource_request_info_impl.h
[modify] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/services/network/public/cpp/resource_response_info.h
[add] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/third_party/WebKit/LayoutTests/flag-specific/site-per-process/http/tests/inspector-protocol/network/security-info-on-response-expected.txt
[add] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/security-info-on-response-expected.txt
[add] https://crrev.com/61bb78eaa35c2a56415083b8cb72bf0fc256386a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/security-info-on-response.js