Description: Security restrictions not applied while exporting to PDF document. Steps to Reproduce: Select Export as | Export as PDF; at Security tab. Password applied to Permission: set; Printing and Changes: Not permitted; Copying of content: Not enabled. Actual Results: I am able to print the document and copy content and paste it into other document – even with a watermark applied. Expected Results: Restrictions to be applied while exporting to PDF document. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.1.1.2; Build ID: 10(Build:2); CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI: en-US: Calc: threaded
Created attachment 170718 [details] Security options set
Which PDF reader are you using ? Perhaps your PDF reader is configured to not obey this kind of restriction. For example Okular, when configured to obey to DRM restrictions, does not allow to copy selected text if that is not permitted by the PDF. So, for me, restrictions are set, but the PDF reader can do what it want. Status set to NEEDINFO, please set it back to UNCONFIRMED once requested information is provided. Best regards. JBF
Omitted to mention in the report indeed; environment: Gnome 40.0; PDF-reader: evince-40.1-1.fc34.x86_64. No particular setting allowing bypass of those restrictions in dconf-editor (/org/gnome/evince/).
(In reply to ricky.tigg from comment #3) > Omitted to mention in the report indeed; environment: Gnome 40.0; > PDF-reader: evince-40.1-1.fc34.x86_64. No particular setting allowing bypass > of those restrictions in dconf-editor (/org/gnome/evince/). Thank you. I suggest you to try with Okular. You will see that the "problem" is on the PDF reader side. If my guess is correct, perhaps should we add a warning in the PDF export dialog about the effectiveness of these restrictions. So added needsUXEval keyword. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #4) > ... perhaps should we add a warning in the PDF export > dialog about the effectiveness of these restrictions. Would be good to mention in the help and perhaps in the tooltip but not the dialog itself. If your assumption is correct.
On Fedora 34; Tested with: atril v.1.24.1, okular v.20.12.2 | Reproducible. On Windows 10; Tested with: Adobe Reader DC 2019.008.20071; Source: still PDF file created on Fedora | Not reproducible; as expected 'Copy' and 'Print' options cannot be selected.
(In reply to ricky.tigg from comment #6) > On Fedora 34; Tested with: atril v.1.24.1, okular v.20.12.2 | Reproducible. Did you configure Okular to obey to DRM restrictions ? Best regards. JBF
Each PDF reader's settings are all as defaults. Then Okular's option 'Obey DRM limitations' is enabled. Let's keep it accurate; there are "restrictions" not "limitations". Here is the Okular starting: $ okular <...>.pdf QSocketNotifier: Can only be used with threads started with QThread Nevertheless that property should not be a relevant criteria regards to the present issue since the presence of Writer's option 'Set passwords...' | 'Set permission password', to be kept relevant, has to lock the PDF document's settings in order to enforce their appliance when submitted to PDF readers.
(In reply to ricky.tigg from comment #8) > Each PDF reader's settings are all as defaults. Then Okular's option 'Obey > DRM limitations' is enabled. Let's keep it accurate; there are > "restrictions" not "limitations". Here is the Okular starting: > > $ okular <...>.pdf > QSocketNotifier: Can only be used with threads started with QThread > > Nevertheless that property should not be a relevant criteria regards to the > present issue since the presence of Writer's option 'Set passwords...' | > 'Set permission password', to be kept relevant, has to lock the PDF > document's settings in order to enforce their appliance when submitted to > PDF readers. I disagree. My understanding of the PDF format is that there no mean to enforce a PDF reader to obey these restrictions. From https://en.wikipedia.org/wiki/PDF#Encryption_and_signatures : > PDF files may also contain embedded DRM restrictions that provide further > controls that limit copying, editing or printing. These restrictions depend on > the reader software to obey them, so the security they provide is limited. So for me there is no bug on LibreOffice side as it sets these DRM restrictions. It s up to the PDF reader to obey them. Or not. Best regards. JBF
NAB but documentation issue. Forwarding...
*** Bug 141884 has been marked as a duplicate of this bug. ***
This is really a dupe of bug 95424 which was => WF, as is bug 141884 But remains open for documentation o LibreOffice's handling of PDF "privacy"
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/7d55112c83309001d9f68f6f92959911312258dc tdf#141237 Make clear that security depends or PDF reader
Above commit | "You can enter an optional password that allows the person viewing the PDF to edit and/or print the document." A Jean-Baptiste Faure; that was all what was needed. Are you looking now where your reaction leads to? One of yours ended up deliberately with a piece of counter truth which from a commit was even made despite it had been dully reporters to those very developers that no knowledge of that password or any other paswword was even needed by a person viewing the PDF document in order to allow editing the document, copying its content or printing the document.
(In reply to ricky.tigg from comment #14) No that was the previous content. The addition just made to the documentation for this issue: "The restrictions that limit copying, editing or printing depend on the reader software to obey them, so the security they provide is limited." Which is valid. The Open password and the Permissions password both function in a fully PDF 1.5 compliant program--e.g. current Adobe Reader or Acrobat DC releases. Google Chrome's PDF parser also complies.
Above commit | "The restrictions that limit copying, editing or printing depend on the reader software to obey them, so the security they provide is limited." While the sentence it replaces was a plain countertruth, this one now excels as an example of waffle. Is it then so unusual nowadays to speak without hiding, trying to embellish or diminish the truth? Such an attitude sets the ground for more reports to come with regards to this topic. Here is a text that would bring a full comprehension of the context and its immediate consequences. Do you perceive the difference between your text and mine? "The requirements of passwords set for opening document and setting document permissions are only observed by a PDF reader fully 1.5 compliant program such as current Adobe Reader, Acrobat DC releases and Google Chrome's PDF parser. Then despite the use of passwords, in others PDF readers those restrictions may have no effect."
(In reply to ricky.tigg from comment #16) > > "The requirements of passwords set for opening document and setting document > permissions are only observed by a PDF reader fully 1.5 compliant program > such as current Adobe Reader, Acrobat DC releases and Google Chrome's PDF > parser. Then despite the use of passwords, in others PDF readers those > restrictions may have no effect." Sure, regards help for the PDF Options "Set password..." dialog [1], something more descriptive like that might be helpful. @Olivier? Also, is the correct help link being picked up from the PDF options dialog? Seems to be misdirected. =-ref-= [1] https://help.libreoffice.org/7.2/en-US/text/shared/01/ref_pdf_export_security.html
Yes we can. But I'll remove trademarked names. Suggestion: "The requirements of passwords set for opening document and setting document permissions are only observed by a PDF reader version 1.5 compliant program. Then despite the use of passwords, in others PDF readers those restrictions may have no effect."
Olivier Hallot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/ad82ae5f3d9c01f46ecab00a767be9bbbac76872 tdf#141237 Improve text on PDF security