Can you please provide a sample PDF and extension that reproduce this issue?

It's possible that this has the same underlying root cause as  Issue 756021 .

I included the PDF that we used in this comment.

We discovered this behaviour for all extensions that we tested, this includes AdBlock, Adblock Plus, Privacy Badger, Ghostery etc. By using the extension debugger, we noticed the requests initiated by our PDF file were never handled by the onBeforeRequest listener.

Deleted: pdf-iframe.pdf 1.2 KB

pdf-iframe.pdf 1.2 KB Download

Yes, this is accurate - extensions cannot intercept requests from PDFium.  PDFium, in Chrome, is (partially) implemented as a component extension, and extension requests cannot be monitored or manipulated by other extensions.  The behavior of protecting component extension requests is critical for security reasons, and we are unlikely to change it.

I could see potentially treating PDFium differently in some way, but it would be costly and difficult to get right (requesting the PDF should not be protected, but other requests from the component extension should).  I don't know if that's something the team is willing to take on, due to both the initial cost and likely steep maintenance burden (not to mention risk of security holes).

There are workarounds for these extreme cases in which users need stronger guarantees.  The most desirable may be that you can provide an alternative PDF-viewing extension to be used in lieu of PDFium, and in that incorporate the desired privacy guarantees.

I don't think the trade offs of treating PDFium specially are worth the risks. I'm going to close this as WontFix as it's working as intended per #4.

I understand that extensions are not supposed to intercept other extensions' requests for security reasons and that making an exception for PDFium would require quite some resources. Nevertheless, it's unfortunate that Chrome users - including privacy-aware users that made the effort of installing a tracking protection extension - are (still) exposed to trackers and have no way to protect themselves other than to stop using Chrome's default PDF viewer. You are right that there are workarounds like using a third-party PDF viewer extension or using the OS's own PDF viewer, however, the issue itself and these workarounds might not be so obvious to even the more privacy-aware portion of Chrome users.

Interestingly, we found that Opera's built-in ad blocker actually does block cross-site requests to tracking domains initiated by PDFium. Maybe a solution in this direction would also be more suitable for Chrome, solving it through Chrome's recently introduced ad blocker? Or alternatively, providing an option to block JavaScript execution inside PDFs, prompting the user for permission to execute the JavaScript code inside the opened PDF, etc. could make this issue at least more manageable and visible for the user without them having to abandon PDFium?

The idea of allowing users to block JS on pdfs is interesting.  We already have the option for users to block JS on websites through content settings.  Have you checked to see if that happens to "just work" for pdfs?  If not, that may be a change we could make.

+raymes for input on that.

Just checked; it does not work for PDFs.

I would be supportive of that change (though I'm not an expert in content settings).

raymes@ and +msramek@, as content settings OWNERs, any thoughts?

I think that is tracked in issue 696650

Yep, that appears to be the same request (for similar reasons, too).  It looks like that's currently restricted; does it need to remain so?

Just to (fully) close the loop, this should hopefully be fixed by tsepez's patch at revision 51cd319fd6aac5ff056fa323d7072b917a7b1a7b.