Fennec openning PDFs inline

I’m using Fennec F-Droid on Android, and when I’m trying to download any PDF file, instead Fennec asks for download or open it, it is openning the files without ask, where to change this behaviour in about:config?

You can Share → Save PDF :wink:

I know about this one, but the ask to download method is better.

Thank you!

@SkewedZeppelin ?

113 might help: Firefox for Android 113.0, See All New Features, Updates and Fixes soon

If you want to disable the internal viewer entirely via about:config the preference is pdfjs.disabled, set it to true.

v113 still seems unchanged of how the share sheet is used to save (which may not even actually directly save it, not sure).

1 Like

Some times is better use the internal reader, but I like the ask to download option, so I’ll wait for it, maybe sometime they bring it back to us, it happens just with PDF files.

Thank you!

Considering all past security issues with that code that should be hardcoded into Fennec/F-Droid

@RichZ

pdf.js is one of the safest PDF viewers there is.

Maybe if you compare it with industry legends like Adobe PDF reader. Did you compare with MuPDF or similar?

However there is a few drastic differences between say MuPDF and pdf.js:

  • pdf.js does download and display without any user interaction. It does accidentally/incidentally download and render possibly a factor 10*times more pdffiles than a normal user would download and render manually - increasing the attack surface at least by that factor. In addition it doesn’t warn about (possibly unexpected) PDF content and does “streamline” the process to increase the chances of a 0-day exploit. Normally I would download pdfs on my phone and read them at night on another device with a few hours to days of quarantine time. Normally I would not ever download pdfs from untrustworthy sources, or not without an extremely good reason and triple checking the such files.
  • Every exploit is a zero click exploit and thus extremely highly valued and at the same time applicable to a large number of devices… Happened frequently enough in the past. In addition the browser id gives the attacker a good hint which exploit to use, whereas he has much worse chances to guess which external reader might be used and which exploit to try there.
  • The stupid pdf.js appears to do scripting by default which very few users would ever enable
  • If pdf.js is the zero click default it is not enough to be “one of the safer” ones. Zero click defaults should be the safest ever by a large margin imho.
  • This is a mobile platform browser and downloading megabytes of irrelevant pdf files should at least ask for confirmation.
  • Many users have their longstanding preferences for PDF and various other file types. pdf.js certainly isn’t mine.

In addition to the previously said, MuPDF won’t have give an attacker immediate access to your email, GitHub and social media which pdf.js conveniently does once an attacker finds yet another fundamental flaw in the browser security model.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.