My assumption is that while the concrete complaints are not the same they are both related to the recent changes in downloading behaviour. I apologize if OP is referring to an older issue.
Correct. I did all of those. For Content Type
I set it all to Open in Tor Browser
where possible, otherwise to Always ask
. I also have Ask whether to open or save files
(just under the table) checked.
However Tor Browser still automatically writes files to default download location (which I haven’t touched either) without prompt on certain websites, such as libgen (click “GET” link to reproduce): https://library.lol/main/4E0132B1F9BF0474BD67889EA7954AE9
I’m guessing this behaviour depends on the response headers, specifically because Content-Type
is not application/pdf
. Here’s the response headers for the PDF above:
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 03 Aug 2023 11:50:02 GMT
Content-Type: application/octet-stream
Content-Length: 225094
Connection: keep-alive
ETag: "5f0da18d-36f46"
Accept-Ranges: bytes
Content-Disposition: attachment; filename="(expository notes) J. Peter May - Notes on Tor and Ext (2011).pdf"
After the PDF is written to the disk to default location, it opens the local file (file:///home/etc/...
) in Tor Browser’s built-in reader.
In this case where the browser can’t tell the file is PDF before downloading it because of generic Content-Type
header, I would have expected it to offer me an open/save dialog instead. That is the way it worked previously (IIRC before 12.5 release).
As a side note, opening the same online PDF multiple times even creates multiple local copies in the default download location.
- It starts writing the file to disk.
- It’s unnecessary and wasteful when fetching the response header is enough to read the file size, which I assume is how the save/open dialog manages to do it without downloading the file itself.

What do you mean by download to RAM?
I mean that you can mount RAM space as a filesystem and write files to it, thus avoiding writing files to disk. This is useful if you want to keep the file only in memory but need to open it with an external program.
The point is that even if someone wants to write a file outside of the Tor Browser process, it is not necessary that they want the file to be written straight to disk to default download location. Another example would be writing to an encrypted container such as LUKS, or to an external storage.
What’s bad is that Tor Browser now automatically writes to disk for certain websites / response headers, and worse even, it can happen completely unexpectedly because you can’t predict the response header of the link you clicked on.
Since Tor Browser is aimed at providing anonymity, it should also make it possible for its users not to leave unnecessary traces outside of the Tor Browser program, in this case making it possible to not write files straight to disk without asking you first.
That is how Tor Browser worked previously by default. Now this is not possible at all anymore, as far as I can tell with the options provided in about:preferences
.
So I would consider this to be a regression.