Closed Bug 1537955 Opened 7 months ago Closed 3 months ago

privacy.resistFingerprinting option makes PDFs rendering blurred

Categories

(Firefox :: PDF Viewer, defect, P3)

66 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 70
Tracking Status
firefox-esr68 69+ fixed
firefox70 --- fixed

People

(Reporter: code, Assigned: tjr)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [tor][fingerprinting][fp-triaged])

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

  1. Use a high resolution (HiDPI) display
  2. Enable privacy.resistFingerprinting
  3. Load https://juliareda.eu/wp-content/uploads/2019/02/Copyright_Final_compromise.pdf

Actual results:

The PDF rendering is blurred to the point where it’s difficult to read the text.

Expected results:

Either Firefox should render the PDF with good quality, or failing that defer to another PDF reader.

Component: Untriaged → PDF Viewer

We seem to have a lot of burring bugs lately. Did something change to make the devicePixelRatio or whatever start causing this?

Priority: -- → P3
Whiteboard: [tor][fingerprinting][fp-triaged]

@tjr: The bug is not new, I already reported that 1 year ago, you even participated to the discussion (https://bugzilla.mozilla.org/show_bug.cgi?id=1428331). What is likely changing the rate of reports is more and more HiDPI devices together with more and more RFP users.

Duplicate of this bug: 1551592

should PDF.JS browser component be made privileged as a temporary solution?

I am not quite sure but this might be caused by spoofing the property window.devicePixelRatio.

Depends on: 1554751

pdfs should not have a way to exfiltrate the true device pixel ratio,
so it is safe to provide the correct value, enabling them to be rendered
correctly.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/85385b4957e3
Do not spoof DevicePixelRatio for pdfs r=Ehsan

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

Had someone test this for me and confirmed it worked.

Status: RESOLVED → VERIFIED

Comment on attachment 9081855 [details]
Bug 1537955 - Do not spoof DevicePixelRatio for pdfs

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fix for Tor, who only uses ESR
  • User impact if declined: Tor will have to carry the patch
  • Fix Landed on Version: 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Only affects the Resist Fingerprinting mode; which is a non-default mode. Additionally, very small patch.
  • String or UUID changes made by this patch:
Attachment #9081855 - Flags: approval-mozilla-esr68?

[Tracking Requested - why for this release]: Patch for Tor

Comment on attachment 9081855 [details]
Bug 1537955 - Do not spoof DevicePixelRatio for pdfs

Fix for PDF rendering when resistFingerprinting is enabled (needed by Tor browser, off by default for Firefox). Approved for 68.1esr.

Attachment #9081855 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

I’m still getting this issue on Firefox Nightly (currently 20190813, but haven’t seen it working since it landed), but not in default conditions: if I try in a clean profile it works, but in my existing profile PDFs are still blurred unless I disable RFP (so it’s not something else causing this by itself, but something that in conjunction with RFP makes this bugfix ineffective). Not sure what can be causing this, but if you could provide me some debugging instructions we might be able to pinpoint it.

(In reply to Bruno Pagani from comment #15)

I’m still getting this issue on Firefox Nightly (currently 20190813, but haven’t seen it working since it landed), but not in default conditions: if I try in a clean profile it works, but in my existing profile PDFs are still blurred unless I disable RFP (so it’s not something else causing this by itself, but something that in conjunction with RFP makes this bugfix ineffective). Not sure what can be causing this, but if you could provide me some debugging instructions we might be able to pinpoint it.

I cannot imagine anything about this patch that relies on your existing state. Weird! Have you changed any prefs beginning with 'pdfjs'? Tried new pdfs that wouldn't be cached?

No, they are no prefs beginning with pdfjs that don’t have their default value (they are many other prefs having non-default values though, if I get some time I could try to find if any particular one is causing this by bisecting).

And I’ve tried with random PDF on the web, same issue. Also note that toggling RFP and reload the PDF page gives a correct rendering, so I doubt this is a cache issue.

You need to log in before you can comment on or make changes to this bug.