1732448 - inconsistent blocking of PDF file download over HTTP: mixed content blocked, same origin allowed

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox 93.0b9 on Windows 8.1

Bug 1685479 enabled mixed content blocking outside Nightly.

For downloads of PDFs using the HTTP, the behavior is the following:

• PDF linked from a third party site where the download is initiated (e.g. context menu of PDF link used to download, PDF served as download, "Open in Firefox"): download blocked
• PDF opened in Firefox's internal PDF viewer: download button works
• PDF linked from same origin: download e.g. with context menu works

Steps to reproduce:

1. Open https://stumblingandmumbling.typepad.com/stumbling_and_mumbling/2021/09/the-death-of-free-market-ideology.html
2. Scroll to "rentierism (pdf)" link.

The PDFs are not embedded which begs the question if there is a security difference from the user perspective for the aforementioned scenarios.

Comment 1

[Marco Bonardo [:mak]]

Sebastian, could you please answer this?

Comment 2

[Sebastian Streich [:sstreich]]

Hey! The Goal of this feature is to warn users who are on an https:// secured site to transmit/download http files.

PDF linked from a third party site where the download is initiated (e.g. context menu of PDF link used to download, PDF served as download, "Open in Firefox"): download blocked

If the Site is using https:// and the linked resource is using http:// , this is the case we want to warn about. In any other case we have a bug :)

PDF opened in Firefox's internal PDF viewer: download button works

I agree the pdf viewer is a bit special case: the default "open in firefox" this is handled as a page navigation - which are not beeing touched. So in this case there is no need to block the pdf when pressing the download button in the viewer as it has been loaded already. - Also the omnibox would be showing that the current connection is insecure.

PDF linked from same origin: download e.g. with context menu works

This is also expected; if a user is browsing an http origin there is already the supporting ui to show it's insecure.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Marco Bonardo [:mak]]

If I read this correctly, the issue here is that the PDF viewer should allow downloads regardless of mixed-content, and not block them.

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

The PDF viewer allows the downloads while a direct download of the PDF from a website gets blocked. If the PDF download to disk gets blocked should be consistent.

Comment 6

[:Gijs (he/him)]

Fundamentally we're treating navigating to a PDF and navigating to HTML the same, and we're treating downloading a PDF and downloading any other file the same. This even includes HTML: if you have an https site that links to an http site (just a normal webpage, not a PDF), and right click the link and "save link as", the download is also blocked. E.g. try saving this link: http://www.speedofanimals.com/ .

This makes it seem like, if we want to do anything, then we should bypass download blocking when users actively context-click a link and try to save it, because we also allow them to navigate to the link and then save it. We did a similar thing for CORP checks in bug 1733274.

Except then we're still not going to warn them that the content they saved to disk might have been tampered with, whereas if the user navigates we don't save content to disk (beyond whatever HTTP caching we normally do, that is), and they can tell from the address bar then that they're no longer on a secure page.

So I'm not convinced there is anything we can reasonably do here (ie I believe that this might be WONTFIX, esp. considering that bypassing the block is pretty easy), but either way it's a DOM: Security decision.

Comment 7

[Daniel Veditz [:dveditz]]

The one unfortunate thing about the experience is that you get the filename picker first, and then it fails. Would be nice to know we were going to reject it before that point but I don't see how we can. If the URL is http:// there still might be an HSTS header for that site that upgrades it, and if the url is https: it still might redirect to an insecure http: url.

The only way to fix that would be to download first, and then let the user pick the destination. I guess we could do that? not sure it's worth revamping the whole flow for this case though.