http audio downloads from https sites warn about "potential security risk" which is unclear
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
People
(Reporter: carlf, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
1)Navigate to podcast RSS feed.
2)Right-click on audio file and choose to Save As. Feed URL example: http://rss.sciam.com/sciam/60secsciencepodcast
Actual results:
Firefox does not download the file, and the Downloads menu (from the toolbar icon) drops down with a warning: "File not downloaded. Potential security risk."
Expected results:
No, no it is not a potential security risk. It is a data file from a really trustworthy source, such as Scientific American or the BBC. Please stop pointlessly blocking harmless, even beneficial, audio downloads for no valid reason.
Thank you.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 years ago
|
||
I can't reproduce. For one, I get the unstyled XML view for the feed and have to select URLs by hand that I may then want to download. For another, I don't see the warning you mention. So a few things must be different for you though it's not entirely clear to me what things they are.
If I had to guess, then I suspect that you're downloading files provided over http
that are linked to by a secure (https
) site.** Firefox now warns about this, because in principle the http download isn't secured via encryption and so a malicious person on the network could interfere with them. You can turn this off in about:config
by turning dom.block_download_insecure
to false
. Does this stop the issue happening for you?
**Though this isn't the case for the example you gave, for me - the page loads over insecure http and so do the audio files. Perhaps if for you the page is somehow rendered by an extension or redirects to https
, that could explain the difference...
Thank you, @:Gijs. I realized after posting that I had left out key information, for which I apologize. I get those links via the Tiny Tiny RSS server I run on my personal VPS.
Here is a sample audio URL that would not download:
http://flex.acast.com/www.scientificamerican.com/podcast/podcast.mp3?fileId=63801245-1909-43C8-8DB47AE055457681
Interestingly, if I right-click on the link from the tt-rss feed and Save As, I get the warning. If I right-click and copy the link, then paste it into a new tab ... the file loads in the tab and can be downloaded with ^s.
So ... I have no idea what's going on.
Sorry about the delay in responding ... for reasons to boring to explain, I've had no internet access here for a couple of days.
Comment 4•2 years ago
|
||
(In reply to Carl Fink from comment #3)
Thank you, @:Gijs. I realized after posting that I had left out key information, for which I apologize. I get those links via the Tiny Tiny RSS server I run on my personal VPS.
OK. And am I right in thinking you access that personal VPS and TTRSS using https
(lock icon in the URL bar) ?
Comment 6•2 years ago
|
||
Thanks for the quick response. So I think the reason you're seeing the warning is the one I gave in comment 2:
If I had to guess, then I suspect that you're downloading files provided over
http
that are linked to by a secure (https
) site. Firefox now warns about this, because in principle the http download isn't secured via encryption and so a malicious person on the network could interfere with them. You can turn this off inabout:config
by turningdom.block_download_insecure
tofalse
.
(In reply to Carl Fink from comment #3)
Interestingly, if I right-click on the link from the tt-rss feed and Save As, I get the warning. If I right-click and copy the link, then paste it into a new tab ... the file loads in the tab and can be downloaded with ^s.
This works because in that case (as far as Firefox's security mechanisms are concerned) there is no connection between the pasted URL you loaded in a new tab (which isn't secure, ie no https
, no lock icon) and the page it came from (your VPS that does have the lock icon etc.). Copying to the clipboard loses that "this was a link from a secure context" information, as it were.
I'm afraid that this is basically working as designed: Firefox is trying to make you aware that when websites have a lock icon (indicating encryption so you're definitely talking to the website the URL bar indicates you're talking to), while the downloads linked to from that websites are not encrypted. As said in my quoted comment, you can turn this off in about:config
by turning dom.block_download_insecure
to false
.
My understanding is that other browsers like Chrome/Edge do the same thing, in an effort to encourage more of the web to adopt encryption.
Christoph, have we considered doing something like per-site permissions (for the referring site!) to make this less annoying for usecases like the one described in this report? I also wonder if the warning that shows up could be clearer about what the problem is that Firefox is pointing out.
So, the solution is for the BBC and Scientific American to use HTTPS for their audio downloads, essentially? I can certainly complain to them (instead of doing more of it here).
Thanks.
Comment 8•2 years ago
|
||
(In reply to :Gijs (he/him) from comment #6)
Christoph, have we considered doing something like per-site permissions (for the referring site!) to make this less annoying for usecases like the one described in this report? I also wonder if the warning that shows up could be clearer about what the problem is that Firefox is pointing out.
For the longest time I thought our error message it's pretty clear, now that I look at it again (see this blogpost) I agree it could be better. I think we should http download
in top-level https content
or something similar to make it clearer - I filed Bug 1800453 to get that done.
However, we have the Allow download
option which allows an end user to overrule Firefox' suggestion.
As of know we have not considered hooking it into per-site permissions or anything similar like that. Obviously we can discuss it, though I am not sure if it's worth doing, given we have the allow download
option.
(In reply to Carl Fink from comment #7)
So, the solution is for the BBC and Scientific American to use HTTPS for their audio downloads, essentially? I can certainly complain to them (instead of doing more of it here).
Yeah, ideally they would also use https
for their downloads.
Comment 9•2 years ago
|
||
The severity field is not set for this bug.
:freddy, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 10•2 years ago
|
||
This message was updated in bug 1800453
Updated•2 years ago
|
Description
•