pdf.js doesn't respect document permissions

REOPENED
Unassigned

Status

()

defect
REOPENED
7 years ago
9 months ago

People

(Reporter: david.smitmanis, Unassigned)

Tracking

(Blocks 1 bug)

18 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox19-, firefox20-)

Details

(Whiteboard: [pdfjs-c-other] https://github.com/mozilla/pdf.js/pull/2657)

Attachments

(1 attachment)

Reporter

Description

7 years ago
This pdf restricts copying of text:
http://www.sstb.se/Homepage/Download-File/f/161759/h/6bc6229975f4c76695ee17246c645a86/Engelsk+svensk+ordlista%2C+version+2.1

Chrome and Adobe Reader respects this, but copying text is possible in pdf.js

(If you are promted to download it rather than are able to open it directly, open it from your local disk)
Reporter

Comment 1

7 years ago
This direct link might be better:
http://h24-files.s3.amazonaws.com/65073/161759-FDUyc.pdf

Updated

7 years ago
Whiteboard: [pdfjs-c-other]
[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A (pdf.js ignored document permissions from the start)
User impact if declined: We ignore document permissions and violate the PDF spec.
Testing completed (on m-c, etc.): upstream pdfjs repo
Risk to taking this patch (and alternatives if risky): Low
String or UUID changes made by this patch: none
Attachment #709411 - Flags: approval-mozilla-beta?
Attachment #709411 - Flags: approval-mozilla-aurora?
Whiteboard: [pdfjs-c-other] → [pdfjs-c-other][pdfjs-f-fixed-upstream] https://github.com/mozilla/pdf.js/pull/2657
With the try builds above, on Win 7 x64, when trying to open the pdf, the Open with/Save as dialog appears; PDF is not opened with the internal (pdf.js) viewer, even if "Preview in Nightly" is selected for PDF handling. Is this the desired behavior?
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #5)
> With the try builds above, on Win 7 x64, when trying to open the pdf, the
> Open with/Save as dialog appears; PDF is not opened with the internal
> (pdf.js) viewer, even if "Preview in Nightly" is selected for PDF handling.
> Is this the desired behavior?

Firefox opens this dialog for file with content-disposition "attachment". See response headers:
...
Content-Type:application/pdf
Content-Length:720391
Content-Disposition:attachment; filename="Engelsk svensk ordlista, version 2.1.pdf"
...
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #5)
> With the try builds above, on Win 7 x64, when trying to open the pdf, the
> Open with/Save as dialog appears; PDF is not opened with the internal
> (pdf.js) viewer, even if "Preview in Nightly" is selected for PDF handling.
> Is this the desired behavior?

Yes, it is unrelated to this bug. Please download and open the file.
Also note that only the second URL of comment #2 will be non-selectable (this is consistent with Chrome PDF Viewer).
It's too late in the cycle to be taking change of this nature, and I'd like to hear Bill's opinion about whether we need to take this on any version of Firefox at all. I'm not aware of a legal requirement to 100% match the spec.
Flags: needinfo?(bwalker)
Fixed on trunk by bug 835954.
Depends on: 835954
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 10

6 years ago
I confirmed "forbidding copy" rule is now respected with the latest pdf.js.
But still it seems "forbidding print" rule is not repsected.

http://www2.cman.jp/pdf/sample/pdf_security_print.pdf
http://www.sourcenext.com/~/media/Files/product/pc/ikp/pc_ikp_000853/sample_copy.ashx
are examples of forbidding print.
Status: RESOLVED → REOPENED
Flags: needinfo?(bwalker)
Resolution: FIXED → ---
Comment on attachment 709411 [details] [diff] [review]
Make an effort to adhere the PDF spec 7.6.3.2

Not a critical fix, therefore no need to uplift.
Attachment #709411 - Flags: approval-mozilla-beta?
Attachment #709411 - Flags: approval-mozilla-beta-
Attachment #709411 - Flags: approval-mozilla-aurora?
Attachment #709411 - Flags: approval-mozilla-aurora-
I don't think this patch should have landed without input from the Product team shipping PDF.js in Firefox (me.) 

Please remove this from m-c until we've decided whether or not to ship this feature. Thank you.
(In reply to Asa Dotzler [:asa] from comment #12)
> Please remove this from m-c until we've decided whether or not to ship this
> feature. Thank you.

Will be fixed by bug 839627
(In reply to Yury Delendik (:yury) from comment #13)
> (In reply to Asa Dotzler [:asa] from comment #12)
> > Please remove this from m-c until we've decided whether or not to ship this
> > feature. Thank you.
> 
> Will be fixed by bug 839627

Thank you, Yury!
Duplicate of this bug: 845302

Updated

6 years ago
Duplicate of this bug: 851285

Comment 17

6 years ago
The idea that Mozilla would actually enforce the silliness of PDF permissions is strange to even consider. DRM like this is not really possible, and a pathetic "no" from this reader would just mean I would need to download it and open it in the reader that came with my OS that doesn't care. At this point, everyone should really just consider these silly copy & print permissions to be a dead part of the spec and move on.

I don't see how Mozilla would decide to volunteer to enforce this flimsy DRM, now after release, so can this just be WONTFIXed please? We're probably going to get more users filing bugs about this so it would be nice to have the decision officially made.

Comment 18

6 years ago
I do not at all think that the concept of PDF permissions is silly.
If Firefox won't fix this bug or feature, I am afraid, not a small number of enterprise users may have to forbid using Firefox on their corporate sites.

Because of bug 840439, since we webmasters can not detect if pdf.js is disabled or not, forbidding Firefox entirely may be the only solution for many companies in order not to allow printing of PDFs that are supposed to be secured by many PDF-related softwares and drivers. Does Firefox community wish this?

Comment 19

6 years ago
(In reply to rshimazu from comment #18)
Most PDF readers don't care about these permissions. There are even websites that will freely convert your PDF to HTML or just view and print it online. You are not capable of enforcing this restriction in most instances.

If, however, we're talking about a corporate environment where you have total control of what's installed on the computers in question, then you could simply push out an override to all Firefox installations disabling pdf.js for them and forcing them to use Adobe's plugin. You'd just need to override pdfjs.disabled to true for everyone. (and of course also have the proper restrictions in place to prevent users from changing their Firefox prefs) There would still be easy ways around this, but you can set up this environment if you wish.

Of course the print restrictions are particularly silly, as users have always been able to just take a screencap and print that, even with Adobe. No matter how much you might want to make it "impossible" to print, if you allow users to get it on their screen, you really have no say in the matter. ;)

Comment 20

6 years ago
Oh, cool. There's even websites that will just strip the permissions from a PDF file and give you a modified one without them. Yeah, the ship has long since sailed on PDF permissions being enforceable. Sorry, but if a company truly relies on this for security it's really going to need to face the reality that it's not a viable solution (and probably never was).

Now that I think about it, an option here would be to have pdf.js support permissions but have them disabled behind a pref. That way organizations could turn that on and apply these restrictions to those users who don't make an attempt to override them. It feels kind of stupid to me, but it sounds like the sort of odd compromise some people would want so they can pretend there's some security here.

Comment 21

6 years ago
I have thought Firefox is more a "gentleman" and I expect that Firefox take corporate social responsibility.

Comment 22

6 years ago
It may be that any attempt to "secure" a PDF through Adobe's specification may be a weak security attempt, one that is possibly "easily" overridden by "sophisticated" users. I don't believe the majority of PDF authors that have set these security settings expect this to be a hard security constraint that would require tremendous effort to violate. I would expect that most of these authors expect these settings to be enforced by legitimate software available to the general public on the regular market. Since Adobe's standard is publicly available, obviously you can fairly easily write non-compliant software that will not enforce the permissions. But just because such software (or web sites) may exist or do exist, does not mean legitimate software should not enforce the permissions. To do so means you are still writing non-compliant, rogue software. Certainly a major, well respected browser should not fall under the domain of rogue software. I am sure most authors of "secured" PDFs would not expect to be thwarted so easily by mainstream "legitimate" software.

Taking a screenshot of one page and then printing it is not the same thing as being able to easily print the entire document. If the user wants to take 1,000 screenshots of a 1,000 page document and then print each screen shot, then yes, they can do so. Compare the amount of work involved to the click of a single button to print the entire document. Oh, but perhaps they have a software program to do that for them. I guess we just shouldn't bother then, again.

If you really want the document content so bad and have a legitimate use for it perhaps you should just try to contact the document author or the organization hosting the document and ask for permission to use it. Most organizations do have some channel for customer service. Or perhaps that is why the organization is using the "weak" PDF security; they want to limit your ability to access the document in some way. Even if it can be thwarted.

Yes, there may be better, more secure security solutions. But what is next? We won't use SSL to secure transactions just because 128 bit may be computationally feasible to break? Obviously we should just not use SSL at all then. Make it clear text. Why bother?

What is next? Will Firefox next implement an SSL decryption cipher for every user to view "secure" SSL transactions just because it may be possible to do so? Something else just because they can? It is potentially possible to hack into anything, let's just do it then since we can.

The bottom line is that if you will not enforce permissions addressed in the software specification then you are writing rogue software. It is as simple as that.

While it may be "impossible" to stop all users from doing whatever they like to content you are serving them in all cases, there are things that can be done to make sure I do have some say in the matter.

I will discuss with my client that I can write a custom solution for him that may provide him more document security than that which might be given him in a popular, widespread format under one of the major browsers on the market, if he desires such security.

There are other potential options in anything.
(In reply to Dave Garrett from comment #19)
> Of course the print restrictions are particularly silly, as users have
> always been able to just take a screencap and print that, even with Adobe.
> No matter how much you might want to make it "impossible" to print, if you
> allow users to get it on their screen, you really have no say in the matter.
> ;)

By the same logic, we shouldn't block third-party cookies because advertisers can still track users.
Anyway, please open the discussion in m.d-platforms or in m.d.pdf-js or anywhere else, not here. Technically I already wrote the patch and even landed once. Non-technical arguments do not belong to Bugzilla.

(In reply to Dave Garrett from comment #20)
> Now that I think about it, an option here would be to have pdf.js support
> permissions but have them disabled behind a pref. That way organizations
> could turn that on and apply these restrictions to those users who don't
> make an attempt to override them. It feels kind of stupid to me, but it
> sounds like the sort of odd compromise some people would want so they can
> pretend there's some security here.

Regarding to my patch, no new options are needed because user style sheets can override the behavior.

Comment 24

6 years ago
PDF permissions aren't security; they're DRM, which is in some ways the opposite. Your counter examples are about ways to protect the user; this is a way to dis-empower the user.

(In reply to Masatoshi Kimura [:emk] from comment #23)
> Regarding to my patch, no new options are needed because user style sheets
> can override the behavior.

My suggestion of a pref would be for the expected case of this feature being off by default, rather than on, seeing as most free PDF readers already ignore this and pdf.js has already been released in Firefox with this behavior. A pref would also make it much simpler to deploy these restrictions organization wide for those who really want it, and it'd be better than only using a pref to disable pdf.js entirely.

Anyway, before I started mentioning alternatives I was primarily asking if the product team had gotten around to analyzing what it wants to do on this topic. I didn't mean to spark any sort of large debate on the merits of DRM (though I couldn't imagine Mozilla being in favor of it). :/
Firefox are already released with third-party cookies enabled for a long time.
I don't follow the logic of "We shouldn't do that because it's easy to circumvent" or "We shouldn't implement the feature because it's already shipped without that" or something.

Comment 26

6 years ago
(In reply to Masatoshi Kimura [:emk] from comment #25)
Sorry, I guess I wasn't clear enough.

Things like 3rd party cookie restrictions empower the user against larger entities working against them. (e.g. trying to track users across domains) This is a general goal Mozilla is always working towards. DRM does the opposite: it works for the larger entities against the user. (e.g. trying to say what one can do with data on their own computer) My point is that Mozilla generally works to incrementally move in the direction of adding more protections for users, not protections against users. Steps in the positive direction are generally good, and steps in the negative direction really need a lot of justification. (and this bug would qualify as a step in the negative direction to undo a positive thing that has already been released)

The trivial-to-ignore argument is another matter, and one which I do think should apply in both directions. Blocking 3rd party cookies is not trivial to ignore, as sites would need to switch to some other cookie-like thing which we either are in the process of applying the same policy to or should consider doing so. DNT, on the other hand, I believe is a silly idea and a waste of everyone's time to work towards.

Again, just to be clear, at no point did I disagree with the use case of an organization wishing to add a restriction to their own computers to make it harder for their employees to print out supposedly confidential PDFs. (they'd also have the ability to not allow other PDF readers that would ignore this, so it's also not as trivial) I am merely stating that this is not the default use case for Firefox and such a thing should be an option defaulted to off.

Comment 27

6 years ago
In our Bank we have firefox installed in our systems for browsing the Portal. We have some secured pdf available on our Portal which are restricted to be printed. Before the introduction of pdf.js the pdfs were downloaded in the end-user's system before he can view the document. 

Let me know if you guys have understood the importance of PDF Protection and have any intention to solve this problem? If not than we are afraid that we will have to replace Firefox with some other browser in our organization.

Comment 28

6 years ago
(In reply to Amir Ali from comment #27)
> In our Bank we have firefox installed in our systems for browsing the
> Portal. We have some secured pdf available on our Portal which are
> restricted to be printed. Before the introduction of pdf.js the pdfs were
> downloaded in the end-user's system before he can view the document. 

Brendan, that doesn't seem to be fixed in 

  https://github.com/mozilla/pdf.js/pull/2657/

and therefore the whitboard "[pdfjs-f-fixed-upstream]" is wrong?
Flags: needinfo?(bdahl)

Comment 29

6 years ago
This is a big issue.  We set document permissions on our PDFs.  If pdf.js will not respect that by default, we will have to reconsider allowing Firefox use on our website.  There are always ways to circumvent security on digital items.  If someone wants to do it bad enough, you can not stop them.  That being said, I would prefer to not make it easy on them.  When will this bug be corrected?
@Julian
It was fixed upstream but then backed out after input from Asa (see comment 12).  I've removed the tag anyways.
Flags: needinfo?(bdahl)
Whiteboard: [pdfjs-c-other][pdfjs-f-fixed-upstream] https://github.com/mozilla/pdf.js/pull/2657 → [pdfjs-c-other] https://github.com/mozilla/pdf.js/pull/2657
Duplicate of this bug: 873776
Duplicate of this bug: 877704

Updated

5 years ago
Duplicate of this bug: 962748
Duplicate of this bug: 1235245

Comment 35

3 years ago
(In reply to Dave Garrett from comment #19)
> (In reply to rshimazu from comment #18)
> Most PDF readers don't care about these permissions. There are even websites
> that will freely convert your PDF to HTML or just view and print it online.
> You are not capable of enforcing this restriction in most instances.
> 
> If, however, we're talking about a corporate environment where you have
> total control of what's installed on the computers in question, then you
> could simply push out an override to all Firefox installations disabling
> pdf.js for them and forcing them to use Adobe's plugin. You'd just need to
> override pdfjs.disabled to true for everyone. (and of course also have the
> proper restrictions in place to prevent users from changing their Firefox
> prefs) There would still be easy ways around this, but you can set up this
> environment if you wish.
> 
> Of course the print restrictions are particularly silly, as users have
> always been able to just take a screencap and print that, even with Adobe.
> No matter how much you might want to make it "impossible" to print, if you
> allow users to get it on their screen, you really have no say in the matter.
> ;)


My employee uses PDF with Print Restriction because ISO9001 requeres it.
It´s impossible to use Firefox under this conditions.
Still use Firefox, but need to disable pdf viewer in all stations. Most IT guys simple configure to use another browser.
Please recognize that it´s a bug, not a feature. Mozilla is not a Apple company :)

Comment 36

3 years ago
Please add in setup installation (setup.exe) an option to not include pdf viewer, it´s simplify method to use Firefox in our company without edit prefs.js after installation. If its possible use a msi format, better.

Comment 37

3 years ago
(In reply to hamacker from comment #36)
> Please add in setup installation (setup.exe) an option to not include pdf
> viewer, it´s simplify method to use Firefox in our company without edit
> prefs.js after installation. If its possible use a msi format, better.

There is a bug report to use msi format (bug id 231062). I think that is an oldest new bug in entire bugzilla, 12 years old, it´s a teenage bug ;-)
This seems like a pretty serious issue for enterprises. Why wouldn't we put this in behind a pref?
(In reply to Mike Kaply [:mkaply] from comment #38)
> Why wouldn't we put this in behind a pref?

Disabling of internal pdf viewer is bind a pref. 

If you are talking about adding a pref to disable printing/permissions, it might require some contributors' effort at https://github.com/mozilla/pdf.js. Our previous stance (see comment 12) was to not contribute to this functionality. Mike, is it okay if Firefox product team to add this functionality due to this enterprise requirement? Will this have an effect on the project Mortar?
Flags: needinfo?(mozilla)
> If you are talking about adding a pref to disable printing/permissions, it might require some contributors' effort at https://github.com/mozilla/pdf.js.

I am.

> Our previous stance (see comment 12) was to not contribute to this functionality.

That's not a correct statement. Asa said:

> Please remove this from m-c until we've decided whether or not to ship this feature. Thank you.

But then there is no additional information in this bug where the firefox product team was actually asked whether or not to ship this feature.

It was simply removed and there was no followthrough.

1. As Asa indicated, the product team should be asked about this feature.
2. If we decide not to include this feature by default, we should put it behind a pref so that it can be enabled for enterprises.

As far as project mortar goes, that's a little ways off. I'd like to have this for firefox 52.
Flags: needinfo?(mozilla)

Comment 41

3 years ago
(In reply to Mike Kaply [:mkaply] from comment #38)
> This seems like a pretty serious issue for enterprises. Why wouldn't we put
> this in behind a pref?

Yes, I do that times ago. But cmd options to remove it from install that can not be turn on after install (can not enable it via prefs.js).

Adobe Reader it´s good enought for everyone, I dont know exactly why this feature exists in firefox, IE, Chome,... except for mobile devices.

In Particular, some PDF forms are different from original when printed via Firefox, but OK via Adobe Reader (or Adobe Reader plugin).

If this feature are enable by default then I would prefer modus operandis like other browsers respecting PDF secure settings. I know that setting it´s a mess and there is a lot obscure programs to remove it or override, but not Firefox, ´cause I recommend it for other IT professionals.

If can I opine, my vote is to remove it from Firefox(maybe lives in mobile devices) or change it to respect PDF secure settings.


[]´s

Comment 42

3 years ago
(In reply to hamacker from comment #41)
> Adobe Reader it´s good enought for everyone, I dont know exactly why this
> feature exists in firefox, IE, Chome,... except for mobile devices.

The Adobe PDF plugin no longer exits as an option. All non-Flash NPAPI plugin support is being removed.

If for some silly reason the desire is to use no plugin and only open in the external viewer, a pref for that sounds reasonable. A pref to turn on this voluntary DRM, however, is not one that Mozilla should be considering, especially after it not existing for so many years.

Comment 43

3 years ago
(In reply to Dave Garrett from comment #42)
> (In reply to hamacker from comment #41)
> > Adobe Reader it´s good enought for everyone, I dont know exactly why this
> > feature exists in firefox, IE, Chome,... except for mobile devices.
> 
> The Adobe PDF plugin no longer exits as an option. All non-Flash NPAPI
> plugin support is being removed.
> 
> If for some silly reason the desire is to use no plugin and only open in the
> external viewer, a pref for that sounds reasonable. A pref to turn on this
> voluntary DRM, however, is not one that Mozilla should be considering,
> especially after it not existing for so many years.

Well, I open my PDFs using Mozilla Firefox using Preferences|Apps|Search adobe and set to "open with Acobat Reader". If its a plugin or not, it´s good enought, we dont need pdfjs.

But I need to deploy using autoconfig.js/mozilla.cfg/override.ini,... only to remove pdfjs from app and its not a easy method, and not secure. 

I still think the same way, to remove it from Firefox(maybe lives in mobile devices) or change it to respect PDF secure settings.
Duplicate of this bug: 1316458

Comment 45

2 years ago
Just asking again here since the last update was a year ago. 
Does anyone know if there is any work being done to align Firefox (pdf.js) with other browser behaviour rules to respect "forbidding print" rule similar to "forbidding copy".
Asa:

What was your reason (originally) for allowing this feature?
Flags: needinfo?(asa)

Comment 47

2 years ago
Sorry to ask again, but is there anything in FF road-mapped to apply 'forbidding print'? Similarly to IE, Chrome and Safari. 
FYI - print is disabled properly if the Adobe plugin is enabled in the browser.
(In reply to Mike Kaply [:mkaply] from comment #46)
> Asa:
> 
> What was your reason (originally) for allowing this feature?

I'm no longer the person to ask about this. I suspect it falls to Jeff Griffiths. Years ago I was opposed to implementing PDF DRM without more discussion of its value and its costs. IMO, taking away freedoms from the person at the keyboard is something Mozilla should do very rarely and very thoughtfully.
Flags: needinfo?(asa)

Comment 49

2 years ago
Also, just to be a bit of a broken record, there are plenty of other PDF readers that handle this similarly, and Firefox has had this as-is for over 5 years. People rely on the current state. This is almost certainly not getting changed.

If you really must use the laughably bad PDF DRM, stick with official Adobe products and just disable the Firefox PDF reader, as has always been possible. You don't need to load the PDF inside Firefox itself; external handlers are just fine. If you have an environment where you can't force this, then sorry to break it to you, but you never had the capability to actually enforce this DRM in the first place. Hiding the print button doesn't do much if someone can trivially load it in something else they control.

Further discussion/debate on this topic is not productive, so I'll probably avoid replying here again for at least another year.

Comment 50

2 years ago
Responding to customer feedback, to align behaviour with other browsers, as 'laughable' maybe attributing to the Mozilla loss in market share.
Needinfo'ing RT as this came up when discussing group policy options for Firefox. tl;dr I think the best thing to do for organizations is provide a GP policy similar to chrome that disables pdf.js.
Flags: needinfo?(rtestard)

Comment 52

2 years ago
(In reply to ivan.terry from comment #50)

I am not a Mozilla employee.

Also, ethical problems aside, please try to understand that a flag just asking nicely to disable standard features available in everything for decades is not now, nor has it ever been, a serious security feature.

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #51)
> Needinfo'ing RT as this came up when discussing group policy options for
> Firefox. tl;dr I think the best thing to do for organizations is provide a
> GP policy similar to chrome that disables pdf.js.

I 100% agree. Improving the ability to mass-configure Firefox keeps coming up, and it's the simplest and best solution. It's still silly and sad if some decide to use it to pretend they can control stuff like this, but being able to easily disable software you don't want is a perfectly reasonable expectation.
Marking as depending on the policy engine work since this now is part of the policy scope we want to ship in ESR 60 (a policy that sets pdfjs.disabled and requires a browser restart).
Depends on: 1419102
Flags: needinfo?(rtestard)
Depends on: 1429160
Blocks: 1446148

Updated

a year ago
Duplicate of this bug: 1450910
From Brendan how to fix this properly:

1) Expose a way to read the bit fields of the "User access permissions" from the PDF in PDF.js (see section 7.6.3.2 and Table 22 of the PDF spec[1]).
We'll have to read this in on the worker side, then send and expose it to the main thread. We have something very similar to this for getting a document's info.
API: https://github.com/mozilla/pdf.js/blob/a7a034d803094b5d421a0d429c84906aea94edf2/src/display/api.js#L686
Worker side: https://github.com/mozilla/pdf.js/blob/c33bf800cc87941cc681c3c54279ab1b9745650d/src/core/worker.js#L706
Where the data is actually read: https://github.com/mozilla/pdf.js/blob/a7a034d803094b5d421a0d429c84906aea94edf2/src/core/document.js#L545

2) Add a preference to the PDF.js viewer to respect the above document permissions. Somewhere in the viewer startup then we'll read that pref and take some actions e.g. disabling selection on the text layer by adding "-moz-user-select: none"
https://github.com/mozilla/pdf.js/blob/master/web/app_options.js

3) Add a function to check within Firefox if we should enable the above preference.
Close example is how we check to see if the find bar is supported.
On the pdf.js side:
https://github.com/mozilla/pdf.js/blob/a8e9f6cc290e4f12ceb01f36c783477d1fc75bfe/web/firefoxcom.js#L281
On the Firefox side:
https://searchfox.org/mozilla-central/rev/a0665934fa05158a5a943d4c8b277465910c029c/browser/extensions/pdfjs/content/PdfStreamConverter.jsm#313

[1] https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf
You need to log in before you can comment on or make changes to this bug.